05/05/15 04:40:59
>>3
だよな('A`)
いや待てよ、あるIPのHostNameが常に同じと限らないのだから
正規化崩しとは言い切れないような気もしてきた。
5:NAME IS NULL
05/05/15 05:39:58
>>4
そういう場合はIP/HostNameテーブルに期間カラムを設ける。
6:2
05/05/15 07:47:51
>>5
期間カラム? 期日カラムじゃなくて期間?
accesslog (ip cidr,host text,uri text,date timestamp,....)
アクセスログだからようはこんなもん。まぁUAとかRefererもあるだろうが。
で、ある一定期間はipに対するHostNameは変わらない(とりあえず1年間)と「仮定」して
accesslog (ip cidr,uri text,date timestamp,....)
ip_host(ip cidr,host text,year smallint)
アクセスがあったら、ip_hostをipで検索して、なければ逆引きして追加。
ってことかしらん。
まぁ、そこまでする気はないけど、新スレ記念のネタ投下ってことで...
7:NAME IS NULL
05/05/15 14:01:12
自動正規化ツールってありますか？
8:NAME IS NULL
05/05/17 11:09:06
ググったらここしかでてこなかった
URLﾘﾝｸ(www.fms-fms.com)
2001年 ITI社と日本初のDB自動正規化ツール「IT_DOA .RAD 」で販売提携
で、たどったらこれだった
URLﾘﾝｸ(www.it-rad.net)
ほかは見ないねえ・・・
9:NAME IS NULL
05/05/18 00:26:23
Microsoft の Access についてなかったっけ？簡単な奴が。
10:NAME IS NULL
05/05/25 01:01:16
sage
11:NAME IS NULL
05/05/28 12:51:06 GrEiaLyo
自動なんたらツールって嫌！
そんなのがあったら俺の仕事無くなっちゃうよ！
12:NAME IS NULL
05/05/28 13:13:19
今まで寝た女のあらゆるデータをカテゴライズしてＤＢにしたいのだが。。
13:NAME IS NULL
05/05/28 14:26:58
女（女ID）
カテゴリ（カテゴリID, カテゴリ名）
あらゆるデータ（女ID, カテゴリID, データ）
14:NAME IS NULL
05/05/28 17:18:20
SELECT count(女ID) FROM 女;
15:NAME IS NULL
05/05/28 17:23:15
レコードが選択されませんでした・・・
16:NAME IS NULL
05/05/28 22:04:23
二年近くかけてやっと第二正規形か。
第五正規形になるのはいつの日か…
17:NAME IS NULL
05/05/28 22:05:55
しかも第一は落ちただけだしな
18:NAME IS NULL
05/05/29 07:55:28
SELECT cunt(女ID) FROM 女;
19:NAME IS NULL
05/05/29 13:16:10
>>18
SELECT 女.cunt FROM 女;
20:NAME IS NULL
05/05/29 19:48:22
select distinct cunt(女ID) as count from 女 group by 女ID;
これで決定か？
21:NAME IS NULL
05/05/29 19:49:09
>>20
大事なことを書き忘れた。
因みにMysql4.1.11です。
22:NAME IS NULL
05/06/07 15:29:45
正規化工数ってﾅﾝﾃﾞｨｽｶ?
いやここで聞くのも間違ってる気がするけど誰か知ってたら教えてｱﾓｰﾚ
23:NAME IS NULL
05/06/17 02:41:50
春のＤＢ落ちた。午後Ⅰあと15点だった。
24:NAME IS NULL
05/07/09 02:15:52
Access好きはIDって列にPrimary Keyつければいいってもんじゃない事を
肝に銘じておいてくださーい!!DBAの敵ですよー!!
25:NAME IS NULL
05/07/09 07:28:02 Ussu/qQy
>>24
意味不明ですが覚えておきます。
26:NAME IS NULL
05/07/09 07:28:18
上げてしまった・・・orz
27:NAME IS NULL
05/07/11 02:30:15
あー、>>24を読んだだけであの歌が頭から離れないー！
28:NAME IS NULL
05/07/19 10:27:19
Normalization!!
29:NAME IS NULL
05/07/20 05:28:41
Normalization is for modeling.
When we actually building a database, we do not have to follow the rule.
You 2ch guys should understand it, should'n you?
30:NAME IS NULL
05/07/25 00:17:02 4Te3/qIT
テーブルの構成の仕方で質問です。
個人テーブル
| 名前 | 趣味コード |
【例】
| 山田太郎 | 2 |
こんなテーブルがあります。この趣味コードというところに数字が入ります。
この「趣味」に関する部分をどう管理するかで悩んでます。
趣味コードテーブル
| 趣味コード | 趣味名 | 趣味カテゴリコード |
【例】
| 1 | 読書 | 1 |
| 2 | つり | 2 |
| 3 | キャンプ | 2 |
| 3 | サーフィン | 3 |
趣味カテゴリコードテーブル
| 趣味カテゴリコード | カテゴリ名 |
【例】
| 1 | インドア |
| 2 | アウトドア |
| 3 | スポーツ |
「趣味」というものを、カテゴライズする必要があります。
しかし、運用当初から、「趣味」「カテゴリー」をすべて定義し尽くすのは無理ですし、どちらも自由に増やしたり、カテゴリを細分化して、「趣味」が属する「カテゴリ」を変更したり出来るようにしたいです。
基本的に上記のようなテーブル構成が無難だと思うんですが気分的には「カテゴリごとに趣味テーブル」を作ってしまったほうが気持ちよい気もするんです。
例えば
アウトドア趣味テーブル
| 趣味コード | 趣味名 | 趣味カテゴリコード |
【例】
| 2 | つり | 2 |
| 3 | キャンプ | 2 |
こうして分けたほうが良さそうな気がするけど、クエリーとかは面倒なことになりそうな悪寒。
やっぱり、趣味はカテゴリに関係なく一つのテーブルに必要になった時点で追加。
趣味カテゴリも同じく、必要になった時点で追加、ってほうほうが良いんでしょうか？
要点をまとめると、カテゴリという属性を持つ趣味というレコードををただひたすら一つのテーブルにいれていいものか？ってとこです。
31:NAME IS NULL
05/07/25 00:32:45 O/Xc/qeP
正規化ってやることのメリットが
イマイチわからないんですが、
どんなメリットが待ち構えているのでしょうか？
私的には、ロックの単位が最小限に抑えられるとは思っていますが、
SQLが複雑になったりしますし、パフォーマンス的にもいい方向に
向かうとは思えません。
識者方のご意見を頂戴したいです。
32:NZ(NULL,NULL)
05/07/25 00:53:04
>30
()…主キー制約、[]->…外部キー制約、| 列のデリミタ
個人テーブル ： (名前) | [趣味コード]->趣味テーブル.趣味コード
趣味テーブル ： (趣味コード) | 趣味名
趣味分類テーブル ：
[(趣味コード)]->趣味テーブル.趣味コード | [(趣味カテゴリコード)]->趣味カテゴリテーブル.趣味カテゴリコード
趣味カテゴリテーブル ： (趣味カテゴリコード) | 趣味カテゴリ名
趣味分類テーブルを連関テーブルとして用意すれば、趣味もカテゴリも別個に管理できる。
そしてひとつの趣味をいくつかのカテゴリに入れることもできる。カテゴリと趣味が一対多なら
前者でよいかと。テーブルを分けるのはお勧めしない。複数カテゴリにまたがる処理を
書きづらくなると思われ。
>31
更新・削除・追加時のデータの異常をなくすため。非正規形の表を見たいならViewをつかえば
SQLもすっきりだ。
正規化の段階を進めると遅くなるのは仕方がない。どうしてもパフォーマンスを得たいなら、
正規化の段階を減らしても異常が発生しない程度に正規化崩しをするのもテクニック。
正規化できないから崩れているのをテクニックと言い張るのは論外。
33:NAME IS NULL
05/07/25 01:29:47 4Te3/qIT
>>32
レスありがとうございます。
趣味は、複数のカテゴリに属する必要はない。
個人は複数の趣味を持つ事はない。
この前提で考えております。
「連関テーブル」というのは、ちょっと初めて聞く言葉です。
おそらく、趣味レコードの趣味カテゴリコードから参照して、カテゴリ名を引っ張りだすためのテーブルと認識しておりますが、これでよいですか？
個人が親なら、趣味は子、趣味カテゴリは孫、みたいな。
どちらにしても、趣味をカテゴリごとに別のテーブルに分けるのはあんまり良くなさそうな気がしてきました。
人間にとって解りやすいテーブル構成と、プログラムを組んだり、処理の効率がよいテーブル構成はまた違うというのが、むずかしいとこですね。
趣味は、趣味テーブルにひたすらぶち込む。
この場合の趣味のキーは、自動連番にしちゃってよいですよね？
34:NAME IS NULL
05/07/25 12:33:28
>>31
正規化の基本はデータの冗長性の排除。
35:NAME IS NULL
05/07/25 13:41:24
個人と趣味、趣味と趣味カテゴリがそれぞれ1:1対応なら、いっそ
趣味コードテーブル
| 趣味コード | 趣味名 | 趣味カテゴリコード |
【例】
| 1 | "なし" | 1 |
趣味カテゴリコードテーブル
| 趣味カテゴリコード | カテゴリ名 |
【例】
| 1 | "なし" |
| 2 | "その他" |
こんな行を用意しておくとか。
趣味のない人は、ひとまず趣味コードを 1 (なし) にする。
未分類の趣味は、ひとまず趣味分類コードを 2 (その他) にすると。
あとは趣味が見つかったり趣味が分類できたときにUPDATE。
36:30
05/07/26 22:53:39 ir4KuP5T
いやー、いろいろ考えまして、
個人、趣味コード、趣味カテゴリ、という構成で行く事に決めますた。
ほかに、趣味カテゴリには趣味カテゴリを表す短い文字列、なんてものもいれてみますた。これによって、カテゴリによって違うclassでスタイルシートを割り当ててしまおう、なんて。けっこうおもしろい事が出来そうです。
37:30
05/07/26 22:59:35
いやー、いろいろ考えまして、
個人、趣味コード、趣味カテゴリ、という構成で行く事に決めますた。
ほかに、趣味カテゴリには趣味カテゴリを表す短い文字列、なんてものもいれてみますた。これによって、カテゴリによって違うclassでスタイルシートを割り当ててしまおう、なんて。けっこうおもしろい事が出来そうです。
38:NAME IS NULL
05/07/28 07:56:23
>>37
エッチビデオと普通のビデオのライブラリを分類するのも悩むもの。
たとえばこんなカテゴリ。
看護婦 痴漢 史劇 盗撮投稿
顔射 痴漢痴女 時代劇 日本の音楽
逆ナンパ 痴女 熟女 美少女
逆レイプ 中出し 熟女人妻 複数プレイ
巨乳 潮吹き 女教師 文芸
巨乳フェチ 伝記 女子校生 未公開フィルム
巨乳美乳 投稿 女優物乱交 野外露出
近親相姦 盗撮 人妻 乱交
西部劇 陵辱 戦争 恋愛
素人 露出 素人ナンパ
裏と表があるとなおややこしい。 しかも、オムニバスだったたどうする？
悩みはつきないものです。
39:NAME IS NULL
05/07/28 10:23:52 KXoQY93/
>>24
一見、あなたの意見があっていると思う人もいると思うが、実はAccessのほうが現実的な正解だったりする。
但し、それを理解してないでとりあえずID=主キーとする人は間違いだけど。
論理的な主キーとDB実装上の主キーは分離すべき。
論理はビジネスの変革で変わる恐れがあるから。
主キー＝ID、論理キー＝ユニークでの実装が柔軟対応への道。
40:NAME IS NULL
05/07/28 20:20:15
>39
現実には ID=主キーにして、論理キーとなるべき列に UNIQUE がついてないデータベースの
なんと多いことか…。わかってる人が作ると Access でもそれなりに安定してて速いけど、
中途半端にかじった素人や似非プロが作ると数百件のデータ表示に数分とか一日の使用で
フォームの入ったMDBが数十MB増えるとかざらだし。
確かに Access は簡単にデータベースアプリが作れるけど、候補キーに UNIQUE つけてないとか
INDEX 闇雲につけて Recordset.Find しか使ってないとかID-PASSWORDテーブルなるものを作って
平文でパスワードを格納して簡易ユーザ認証機能をつけるとか(テーブルエクスポートで丸見え)
珍妙なアプリだらけで(´･ω･`)ｼｮﾎﾞｰﾝ。さらにこれが害虫して作ってもらったものだとわかるともうね。
41:NAME IS NULL
05/07/29 21:57:57
明日正規化のテストでそうだな
42:NAME IS NULL
05/08/04 14:33:24
しょ、正気か？
43:NAME IS NULL
05/08/05 17:21:46
>31
今、どんな教え方しているのか知らないのだが、正規化した後に
パフォーマンス等を考慮に入れて、最後に正規化を崩すてのが
ＤＢ設計の手順にあった。
データ件数や、対象にたどり着くまでの参照回数、使用頻度等
正規化を崩す条件が出来上がるシステムを知っている必要が
あるので、文書化されたもには少ないのかも。
ちなみにこの手順を行っている最中に
「実は同じ物でない項目が正規化されて省かれていた」
「正規化されるべき物が新たに見つかった」
等のミスを発見することが多かった。
44:NAME IS NULL
05/08/12 07:42:08
45:NAME IS NULL
05/08/30 01:16:26
非正規化は正規化→崩すのステップを踏襲する必要は無いんだぜ！
そんなの教科書でそう書いてるだけで、実際にやったらアホだよ。
ってなことをどっかで読んだことがあるが、どこでだったかな
46:NAME IS NULL
05/08/31 00:55:52
非正規化は非正規形と化すってことだろ
元々が非正規形なら非正規化は不要な
んだから非正規化をするということは元
の正規形がないとおかしいんジャマイカ？
非正規放置ならわかるけど
47:NAME IS NULL
05/08/31 11:28:41
まあそりゃそうだ。
頭ん中で、
「わかってるけど、あえてこう」
ってやりゃいいんだ、って話じゃないの？
48:NAME IS NULL
05/09/07 11:42:05
正規化について質問です。
PCテーブル
(id, 製品名, 購入日, メーカーid, CPU clock, メモリ容量)
ディスプレイテーブル
(id, 製品名, 購入日, メーカーid, サイズ, 解像度)
携帯電話テーブル
(id, 製品名, 購入日, メーカーid, 電話番号)
このように一部共通で、他のデータは内容も数も違うデータを管理したいんで
すが、これをもっと綺麗にまとめる方法があったら教えて下さい。
49:NAME IS NULL
05/09/07 12:03:01
id,製品名,購入日,メーカーid,type
typePC
id,CPU clock,メモリ容量
typeディスプレイ
id,サイズ,解像度
type携帯電話
id,電話番号
50:NAME IS NULL
05/09/07 15:38:15
>>48
純粋に正規化なら>>49のとおり。
正規化以前の所から再検討可能で、サイズや電話番号のような情報が備考的な
意味しか持たないなら１つのテーブルにまとめてもよい。
id, 製品タイプ,製品名, 購入日, メーカーid, 製品仕様, 設定
製品仕様にはCPU clock, メモリ容量, サイズ, 解像度
設定には電話番号, 解像度(多解像度対応機種で実際に設定している解像度)
51:NAME IS NULL
05/09/07 18:10:22
>49のパターンにした場合、実際のアプリでSELECTする時SQLが複雑になったりしませんか？
52:NAME IS NULL
05/09/07 22:16:49
状況による。
データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
JOINのパフォーマンスが問題になるケースではテーブルを一個にする。
パフォーマンス的にさほど問題にならないケースでは>>49のようにきれいに設計したい。
絶対正しいDB設計というのはあまりない
53:NAME IS NULL
05/09/17 16:52:19
>52へよくわからん。おせーてくれ。
>データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
>JOINのパフォーマンスが問題になるケースではテーブルを一個にする。
君の考え方は、SQLが明確になってから、DB設計をするのか？？
まぁ、状況によるようだがｗ
パフォーマンスが問題でDB設計しなおすなら、マシンを買い替えたら・・・
人件費よりよっぽど安いよ。
54:NAME IS NULL
05/09/17 17:56:57
>>53
52ではないのだが、データベース設計時にどんな処理や問い合わせが発生するかくらいの予想は
できるし普通する。52が言いたいのはそういうことじゃないかな？
データフローや処理方式をまったく考慮せずにデータ構造の分析だけでDB設計するケースの方が
まれだと思っているがどうなのだろう。
もっとも諸事情で予想がはずれまくることは結構ある（笑）。手戻りを避けたいのは誰でも一緒だ。
55:NAME IS NULL
05/09/18 01:24:50
パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
幸せな人だw
56:NAME IS NULL
05/09/18 18:01:16
53だけど
>>54
>52ではないのだが、データベース設計時にどんな処理や問い合わせが
>発生するかくらいの予想はできるし普通する。52が言いたいのはそういうこと
>じゃないかな？
そうかもね。
>データフローや処理方式をまったく考慮せずにデータ構造の分析だけで
>DB設計するケースの方がまれだと思っているがどうなのだろう。
データ構造の分析だけでDB設計をするというのは、どれだけデータ設計に
覚悟をもっている技術者が存在するかにかかっているのではないのかな。
どれだけ、データ構造が普通であろうがシステム開発目的をクリアしなければ
それは机上の空論であろう。
そのときに、処理方式を考慮しないということもないとは思うが、普通にきれいな
正規化をしたものを、崩すことによるデメリットも怖い。不要にバッチ処理を作ったり
して、翌日にならなければ、データが反映できないなど、パフォーマンスを悪化させても
やったりするのはいっぱい見ている。
データフローを考慮するというのは、どういうことを言っているのか、もうすこし、
解説願う。（いろいろ、思いつくので）
55>>
>パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
システムをパフォーマンスが問題で修正するなら、マシンを買い換えたほうが
安いならすればいい。マシンを買い換えたほうがDB設計をしなおして影響する
プログラムを調査してすべて修正してテストをしてリリースするほうが安いなら
そちらをすればいいと思うよ。 まぁ、人件費がかからないなら後者を選べばいい。
>幸せな人だw
おまえも、コストを考えない地位にいるみたいで気楽だねーｗ
57:NAME IS NULL
05/09/18 23:02:29
文章をまとめるスキルが無いことは分かった
58:NAME IS NULL
05/09/19 07:57:28
>57
スマソ
幼稚園からやり直すので、何年か持っていてくれ
59:NAME IS NULL
05/09/19 17:45:33
ところで、もまいら正規化以前でDBの設計ってどー始める？
60:NAME IS NULL
05/09/20 09:13:51
＞ところで、もまいら正規化以前でDBの設計ってどー始める？
何この最高に頭の悪い書き込み。ふざけてるの？
61:NAME IS NULL
05/09/20 09:52:00
>>59
>>60
まあ、好意的に解釈すれば、正規化なんて設計の後半だからね。
まず実業務などからえんててーのちうしつから始まるわけで。
62:NAME IS NULL
05/09/21 02:11:44
>>61
回答、ありがとう 59です。
＞実業務などからえんててーのちうしつから始まるわけで。
既存システムのようなものがない場合は、帳票を基にお願いして。
既存システムがある場合は、既存システムの説明書から、えんててーの
ちうしつをしてもらうような感じなのかな。
>>60
＞何この最高に頭の悪い書き込み。ふざけてるの？
まじめに判らなかったので聞いてみました。というのはＤＢ設計の
入門記事などでみると、ＤＢの正規化以前に未正規化状態の
表とかができているのが前提で記事が始まっていて、この表自体を
どこから持ってくるのか疑問に思っていました。
気分を害されたようでしたら、謝ります。
63:NAME IS NULL
05/09/21 02:44:44
>59
参考
URLﾘﾝｸ(codezine.jp)
64:NAME IS NULL
05/09/21 03:19:55
63>>
回答ありがとう59です。
参考ホームページを拝見しました。
この羽生さんの記事は、素人にもわかりやすくていいですね。
SQLの部分は、意味がよくわかりませんでしたが、そのほかの
設計に関しては概ね読むことが出来ました。
気になったのは、この文章の「はじめに」の中で書かれている、
データベース設計はスキルが身につきにくいという文意のこと
です。
この文章を読む限りシステム会社の人でもこのようなスキルを
あまり持っていないと言うことでしょうか。
羽生さんの記事自体初級で且つ第一回ということですので、
私も読むことが出来ましたが、この後の回では、段々専門的に
なっていくのかなと恐れています。
データベース設計は、全何回の連載記事かは、わかりませんが、
このとおりにやっていれば、何回かでデータベース設計が
出来るようになってしまうレベルのこと なんですよね？
システムを開発する会社に対して正直に言うと不信感が出てきて
ます。
ちょっと、急いでキー打ったので、読みにくい部分もあると思いますが
もし良かったら、判らないところとか教えていただければと思います
65:NAME IS NULL
05/09/21 07:21:14
>>64
データベース設計は範囲が広いのでトータルでできる人間は少ないかもしれないですが、
部分的にならデータベースを扱うプログラマレベルでも理解してると思います。
この連載は単純で具体的な例でERDの説明をわかりやすくしてくれているようです。
こういうダイヤグラムを作ることは重要ですがこれもやはり設計の一部です。
ただダイヤグラムがあることで部分部分の担当者が相互に理解しやすくなるという
メリットがあります。たとえば私はそのページのERDをみてこんなことを思いました。
テイクアウトで顧客名と電話番号の管理は無理では。注文を注文用紙単位で管理する必要は無いか。
折角システム化するならタッチパネルでお客さんに直接入力させられないか。などなど・・・
66:NAME IS NULL
05/10/03 03:20:52
右手が性器化した
67:NAME IS NULL
05/10/11 11:53:34
皆さん、正規化ってちゃんとしてます？
正規化した気になっていても、第三正規化ができてないケースが多く感じるけど
みなさんのところではどうですか？
キーに関係ないリレーションの項目があったりするのを多くみした。
最近は、そんな項目つけないようにさせてるので、自分ではみないです。
68:NAME IS NULL
05/10/11 15:38:30
ここはお前の日記帳です
69:NAME IS NULL
05/10/13 18:22:42 CdlqOxne
>>49 のパターンで正規化する際に、
俺なら一番上の行のテーブルにtype列はつけないな。
主キー同士でexists演算やれば行抽出の段階では
索引しか物理読み取りしないのでパフォーマンス的にも問題ないと思うのだがどうだろう
70:NAME IS NULL
05/10/29 12:14:45 zOZqpbV9
完全に近い形で正規化された設計を見てみたい(つдT)
71:NAME IS NULL
05/10/30 02:58:04
完全に「近い」形か、難しいな。
72:NAME IS NULL
05/10/30 10:53:28
>>70
完全なのは見たくないの？
とりあえず例となる問題を書いてよ。
「社員がいてー、社員には名前と生年月日があってー、社員は課に属していてー」云々。
わたしは、そういう問題が出されてからテーブル構成が出来ていく様子を見てみたい。
73:NAME IS NULL
05/10/30 10:57:03
じゃあ、社員がいて名前と生年月日があって、課に属している
74:NAME IS NULL
05/11/09 15:37:35
社員テーブル1つ
75:NAME IS NULL
05/11/10 01:16:33
>74
課テーブルくらい作ってやれよ。寂しいだろ。
76:NAME IS NULL
05/11/10 12:40:37
>>72
＞そういう問題が出されてから
問題に出されている条件が正確なら正規化は難しくないが、
現実だとその条件が正しいかどうか抜けが無いかどうかの検証が作業の大半をしめる。
例えば同時に複数の課に所属する可能性や、部付きや社長や役員など課に所属しない
人間はいないのか、いたらどうするかなど検討する必要がある。
77:NAME IS NULL
05/11/10 23:50:11
社員テーブル
------------
社員ID
名前
部署テーブル
-----------
部署ID
部署名
親部署ID
所属テーブル
-----------
社員ID
所属部署ID
プライマリ所属部署?
付き?
78:NAME IS NULL
05/11/10 23:55:33
>>77
お前がやっていることはネタにマジレスってやつだ
79:NAME IS NULL
05/11/11 11:07:24
生年月日テーブルも作らなくちゃ
生年月日テーブル
-----------
生年月日ID
年
月
日
80:NAME IS NULL
05/11/11 16:52:46
年テーブルと月テーブルと日テーブルも
81:NAME IS NULL
05/11/11 17:24:39
じゃあ曜日テーブルも作ろうぜ
82:NAME IS NULL
05/11/11 21:41:39
時分秒も・・・
83:NAME IS NULL
05/11/11 22:01:08
>>82
いや、それはいらないな
84:NAME IS NULL
05/11/11 22:04:55
名前文字テーブルも作らないと
----------
名前文字コード LONG PRIMARY KEY,
名前 IMAGE NOT NULL
社員名テーブル
----------
社員ID LONG PRIMARY KEY,
文字順序数 INT NOT NULL, -- 名前の文字を表示する順序
名前文字コード LONG NOT NULL FOREIGN KEY REFERENCES 名前文字テーブル(名前文字コード)
85:NAME IS NULL
05/11/11 22:11:56
>>84
名前の読みはどうすればいいのだろう？
やっぱ、PCMかな。
86:NAME IS NULL
05/11/11 22:15:41
>>83
そのつっこみ、今週で一番笑った
87:NAME IS NULL
05/11/11 23:29:09
>>77
出直せ。
88:NAME IS NULL
05/11/24 11:31:47
体重テーブルも必須だろ
体重テーブル
-----------
社員ID
体重
updateが多そうなので体重にindex付けるかどうか迷うが
89:NAME IS NULL
05/11/24 11:40:14
>>88
以前の体重と比較できるように計測日フィールド入れないとダメだろ
90:NAME IS NULL
05/11/26 18:01:45
URLﾘﾝｸ(www.doaplus.com)
「正規化するとレスポンスが悪くなる」という「うわさ」は本当か？
百聞は一見にしかず。当分科会が実証実験を行いました。
91:NAME IS NULL
05/11/26 23:39:38
非正規化したテーブルを何でジョインするんだw
92:NAME IS NULL
05/11/27 00:43:20
確かに不思議屋根
93:NAME IS NULL
05/11/27 16:57:05
>非正規形のDBを使っている技術者はJOINが遅くなることを体験しており、
>「正規化するともっと遅くなる」と誤解している。
比正規形のDBを使っている「技術者」だってよ。
94:NAME IS NULL
05/11/27 19:51:55
欺術者偽術者疑術者擬術者戯術者好きなのドソー
95:NAME IS NULL
05/11/27 20:39:15
俺も方法論的にはどっちかというとDOA派だけど、
>>90のようなアホなこと真面目にやってるから
古いって馬鹿にされるんだよな・・・
96:NAME IS NULL
06/01/05 06:21:42 RI5QmBcj
販売系のシステムで、受注データ取り込み時に、
取引先の商品コードと自社の商品コードを1:1で変換する必要があるのだが、
連関（変換）マスタを作るのが面倒という理由で、
自社の商品マスタ内に取引先の商品コードをも持っていた。
当時の設計担当に聞いたところ
「取り込み時に取引先の商品コードが重複してたら警告を出すから問題はない
それにテーブルを増やすとPGが複雑になってバグが増えるだろ？」
と言っていたがしかし・・・・
個人的に変換系のマスタは相手方のキーを主キーにして、
自社コードを従属させていくしか手はないと思っているのだがどうなのだろうか。
97:NAME IS NULL
06/01/05 15:19:39 p0LLZBlZ
俺も基本的には正規化されてた方がいいが、たまにパフォーマンス等のために
あえて正規化を崩すとかするらしいんだけど、
正規化するとパフォーマンスが極端に悪くなるようなデータ量の設計した事ないので、
そこらへんは自分で経験積んで判断するしかないと思う。
理論を最優先にするのもいいのかも知れんけど、俺は色々なことを考慮して方がいいと思う。
正規化しまくってパフォーマンス落ちすぎたら、システム全体から見ると問題だと思う。
まぁ、正規化しまくった当事者は満足かも知れないけど､他にひずみをおこしたら・・
98:NAME IS NULL
06/01/07 03:33:51
複雑にするとバグがおきやすいってのは真だな。パフォーマンス上もシンプルな方がキャッシュとか効きやすいし。
99:NAME IS NULL
06/01/07 05:18:37
>>96は思い込みが激しそうだなw
100:NAME IS NULL
06/01/10 21:22:34 emDEfEEV
すみませんが、質問です。
ユーザの追加オプションを管理する、以下のようなテーブルがあります。
ユーザID オプションID 制限回数
00001 1 12
00001 3 15
00001 4 NULL
...
ユーザIDで検索すると、利用できる追加オプションの一覧が取得できるのです
が、オプションの種類によっては、利用できる回数に制限があります。そして、
・オプションID 1, 2, 3 については、必ず制限回数を指定する必要がある。
・オプションID 4, 5 については、制限回数は要らない。
（仮に指定しても使われない）
このようなテーブルで、誤った組み合わせ
（例） 00001 1 NULL
のような挿入を防ぎたいのですが、どうしたら良いでしょうか？
今ままでも、CHECK制約を使えば、誤った組み合わせの挿入は避けられますが、
オプションIDの即値というマジックナンバーをCHECK制約に埋め込みたくあり
ません。できれば正規化で対応したいのですが。
101:NAME IS NULL
06/01/11 01:19:44
俺的には、テーブルの作り自体は現行で最善な感じがする。
マジックナンバーがいやなら、チェックはアプリケーションロジックでやるとか。
トータルコスト考えて、どこで妥協するかって話だと思う
102:100
06/01/11 12:25:56 VpUtuDIC
>>101
やはりそう思われますか…。トータルコストを考えると、どんな用件に対して
も正規化が可能なわけではないということでしょうか。
マジックナンバーがイヤなのは、オプションのマスタテーブルのレコード追
加・削除に伴って、>>100のユーザテーブルのCHECK制約を書き換えなければな
らないからです。
オプションのマスタテーブルに、制限回数が必要かを示すフラグを、カラムと
して用意すれば、マジックナンバーに頼らなくても済みます。しかし、使用DB
がPostgreSQLなので、CHECK制約で外部テーブルを参照できないのです。
アプリの側でチェックすれば、外部テーブルを参照することもできます。しか
し、いかにも煩雑です。
うーん、やっぱり正規化を諦めるのはつらいなあ。
103:100
06/01/11 12:29:38
外部テーブルという言い方は変ですね。単に、別テーブルという意味です。
URLﾘﾝｸ(www.postgresql.jp)
>現在、CHECK 式には、副selectや現在の行の列以外の値を含むことはできません。
104:NAME IS NULL
06/01/13 01:03:49
>100
オプション4,5 では何を指定しても使われないなら、NOT NULL にして4,5を挿入するときは適当に
0でも入れておけばいいんじゃないの? DEFAULT 0 とかつけてやったりして。
105:NAME IS NULL
06/01/13 03:04:52
>>104
そうやっても 00001 1 0 という誤挿入を防ぐことはできない罠。
106:NAME IS NULL
06/01/13 06:31:18
>105
0 がないとすると、残り1回のまま永久にオプションを使い続けられることにならない?
107:100
06/01/13 11:29:00 TppsOzrm
>>105
説明不足ですみません。カラム「制限回数」は、ゼロを入れる予定は（NULLの
代用でない限り）ないんです。
オプションサービスが利用されると、別テーブル（利用状況記録テーブル）に
新規レコードが挿入されます。そのレコード数と制限回数を比較して、超過を
チェックしております。
だから、カラム「制限回数」の数字がだんだん減る、という使われ方ではあり
ません。
さらに言えば、この制限回数は、月ごとのトータル回数なので、現在月の利用
回数（レコード数）と、カラム「制限回数」を比較します。来月はまた同じ値
の「制限回数」と比較する必要がありますから、このカラムの値を減らしては
いけないんです。
以上、補足でした。
108:100
06/01/13 11:30:11
あ、リンクを間違えました。× >>105 → ○ >>106
109:NAME IS NULL
06/01/13 19:37:09
>>107
アプリで管理すればいいやんとは思うが正規化スレなので正規化で考えると、
ユーザID、オプションID、制限回数のち制限回数には回数とそれを使うかどうかの情報が含まれている。
この制限回数を使うかどうかの情報を分離して回数制限フラグと呼ぶこととする。
回数制限フラグはオプションID毎に決まっており推移的関数従属であるためそれを排除して第３正規系にする。
で答えはオプションIDマスタを作ってそこに制限回数フラグを持つべしということになる。
110:100
06/01/13 22:01:07 TppsOzrm
>>109
ありがとうございます。
ただ、私は、>>102の後半に、かなり似た内容を書いておりまして、それと
どう違うのか、良くわかりません…。
111:NAME IS NULL
06/01/14 00:03:14
>>110
制限回数はnot null にしてユーザーに常に数字を入れさせるということ。初期値ゼロでもよい。
表を参照するときに連結して問い合わせるVIEWを作っておくとよい。
select a.ユーザID, a.オプションID, CASE b.制限回数フラグ WHEN 1 THEN a.制限回数 ELSE NULL END as 制限回数
from テーブル a join オプションIDテーブル b on (a.オプションID = b.オプションID)
これで制限回数を使わないケースでは今までどおりNULLが帰ってくる。
check制約をつけることを正規化とは言わないといいたかったのだが、
同等なことをしたいならトリガーなり更新用のストアドなり作って違反した場合に例外を起こさせることはできる。
処理系で方法は違うだろうけど。
112:100
06/01/15 14:40:37 iP9+MlmJ
>>111
ありがとうございます。返答が遅くなってすみません。
NOT NULL制約を付けるということですが、これだけでは 00001 1 0 といった
誤挿入を防ぐことはできません。オプションID 1, 2, 3 に対しては、NULL と同
様に 0 も不適なのです。
ならば1以上のみを許容するようにすればいいかと言うと、今度はオプションID
4,5に対して、使われもしない数値を入力する義務ができてしまい、やはり良い
設計とは思えません。
本来ならcheck制約でもっとキメ細かい入力値のチェックをできたら良かったの
ですが、PostgreSQLの機能の制約でできませんでした。
ここで、check制約の代りに、トリガを使えば良い、というのは盲点でした。ト
リガというと更新系の動作をさせることしか頭にありませんでした。これならど
んな複雑なチェックでもできます。ありがとうございます。
なお、私はcheck制約と正規化を混同してはいません。check制約が使えないから、
正規化で対応したいと言っていたつもりでした。まずい説明ですみません。
113:100
06/01/15 14:42:47 iP9+MlmJ
ところで、頂いたレスを読み返しているうちに、あることに気づき、そして正規
化のアイディアを思いつきました。
> 制限回数には回数とそれを使うかどうかの情報が含まれている。
とのことでしたが、もっと言えば、このユーザオプション管理テーブルの内容自
体に、2種類の異なったタプルが混在しているのです。つまり、
00001 1 12
00001 3 15
の、3要素のタプルと、
00001 4
の、2要素のタプルとです。
この要素数の異なったタプルが混在しているのが問題の元だったのです。
そこで、このテーブルを、1, 2, 3を入れる3カラムのテーブルと、4, 5を入れる
2カラムのテーブルとに分けます。
同時に、オプションマスタも、1, 2, 3 のマスタと、4, 5のマスタに分け、それ
ぞれのユーザオプション管理テーブルに外部キー制約をつけ、ユーザオプション
管理テーブルの内容が混在しないようにします。
そして、ユーザごとのオプション一覧を1回で取得するために、2つのユーザオプ
ション管理テーブルを UNION でつないだビューを作ります。
しかしこれだと、二つのオプションマスタに共通のオプションIDが入ってしまう
危険があります。そこで、両者のIDを共通のシーケンスから自動採番するように
し、ID番号の重複を防ぎます。
以上です。またあまり分かりやすくない説明ですみません。
ややトリッキーですが、皆さんはどう思われるでしょうか？
114:NAME IS NULL
06/01/15 19:51:17
>>113
それなら>>111の設計の方がきれいだと思うぞ。
PostgreSQLならこういう技も使えるが。
create table user_master (
user_id number primary key
)
create table option_master (
option_id int primary key,
option_class int not null -- 1なら制限なし 2なら制限あり
)
create unique index option_master_class_idx on option_master (
option_id,
option_class
);
create table user_option (
user_id number not null,
option_id int not null,
foreign key ( user_id )
references user_master(user_id),
foreign key ( option_id )
references option_master( option_id ),
primary key ( user_id, option_id )
)
create table user_option_limit (
user_id number not null,
option_id int not null,
option_class int not null,
option_limit int not null,
primary key ( user_id, option_id ),
foreign key ( user_id )
references user_master( user_id ),
foreign key ( option_id, option_class )
references option_master( option_id, option_class ),
check ( option_class = 2 ),
check ( option_limit > 0 )
)
>>100の結果が欲しい場合はuser_optionとuser_option_limitを
outer joinするか、そういうviewを作っておく。
115:NAME IS NULL
06/01/16 00:46:38
初心者にありがちな考えすぎ
116:NAME IS NULL
06/01/24 10:05:52 eUiSn8SR
すいませんが、教えてください。
とあるシステムを解析する事になったのですが、テーブルの設計で分からないところがあります。
内容は下記のようなテーブルで枝構造になっています。
部門テーブル
部ID , 主キー
部門名
部課連携テーブル
部ID
課ID , 部IDと課IDでキー、課IDはユニーク
課テーブル
部ID
課ID , 部IDと課IDでキー、課IDはユニーク
課名
その他課情報項目
グループ連携テーブル
部ID
課ID
グループID, 部ID,課IDとグループIDでキー グループIDはユニークでない
グループテーブル
部ID
グループID, 部IDとグループIDでキー グループIDはユニークでない
こんな感じです。グループ連携テーブルとグループテーブルでなぜ同じキーを使わないのか、
また、なぜグループテーブルで部ID+グループIDなのか。
何か設計上のテクニックがあるのでしょうか
117:NAME IS NULL
06/01/24 13:12:15
>>116
歴史的経緯がいろいろありそうなテーブルですね。
課IDのところの説明を間違ってなければ、
課を複数の部に所属させることができるようにしようとした痕跡がありますね。
結局それは取りやめて部課連携テーブルは使ってない可能性が高いな。
（または課テーブルの部IDを使ってない可能性あり）
グループ＋部IDとグループIDでユニークで、課とグループはｎ：ｎの関係。
グループ連携テーブルはそのｎ：ｎの関係をあらわすためにある。
118:NAME IS NULL
06/01/24 14:32:17
>>117
なるほど。どちらかというと熟考して出てきたテーブルではなく、過去からの成り行きでこのように
なっている感じなのですね。私が使うとき課とグループがn:nにはならないと思いますので、自分な
りにアレンジして再構築します。ありがとうございました。
119:NAME IS NULL
06/01/24 23:52:14
おいおい、ちゃんとヒアリングしろよ・・・
120:NAME IS NULL
06/03/06 02:47:55
正規化しないで作った事とかないんですが、どうしてもテーブル構成なんかを考えてる時間がないんです。
1テーブルでむりやり作っちゃうってのは実際のとこ「あり」ですかね？
121:NAME IS NULL
06/03/06 11:04:40
>>120
あなたのその後の人生をそのシステムに捧げる覚悟があるならば「あり」かもしれない。
122:NAME IS NULL
06/03/06 23:05:20
>>121
ないです。つか、保守とか以前にぽしゃる悪寒＞そのサイト
123:NAME IS NULL
06/03/07 00:48:26
俺はありありだと思うなー。
とりあえずは動けば何でも良いよ
124:NAME IS NULL
06/03/09 23:59:15
>>123
結局1テーブルで全部くんでしまった。
やたらとtextのフィールドが多い・・・
もうしらね。全部のフィールドを検索対象にしてやる。
やけくそでやれば終るもんだ。あとはcssまわりだけ。
125:NAME IS NULL
06/03/10 00:08:53
>>124
自分でいいならいいんじゃね？
レコード数多くなければ全列の全走査でも
なんとかなるさｗ
126:124
06/03/11 01:53:53
基本的なとこは組み上がったからUIまわりをajaxでかっこいくしてたら暗唱に乗り上げた。悔しいがヤメることにする。一日ロスしたorz
127:NAME IS NULL
06/03/13 00:18:21
T字型ERって業務でやってる人居る？
ネットに全然情報ないし、本買わないといけないかな。
128:NAME IS NULL
06/03/13 23:00:16
出向に行ったら表記法がT字型だったなあ。
表記法だけって感じだった・・・・おそまつだったなあ・・・。
129:NAME IS NULL
06/03/14 01:46:14
なんか古臭い感じがするよね。
自分的には主キー、外部キー、カージナリティがちゃんと表現できれば必要十分。
ＥＲ図書くのは好きだけど、それだけじゃシステム動かないし
データモデリングに偏り過ぎてるのはなんだかねぇ・・・
130:NAME IS NULL
06/03/18 16:27:27 B7S2rjh8
勉強中です。第二正規形と第三正規形を分ける理由が良く分かりません。
分かりやすく教えてください。
131:NAME IS NULL
06/03/20 10:08:38
データベース理論的にはボイスコッド正規形との絡みとか色々あるから、
２と３を分けるのは必然だろうね
でも、実務上はそこまで意識しすることあまり無いね。
いつもなんとなく設計しちゃってる
132:NAME IS NULL
06/03/20 22:32:44
俺もなんとなくやったら第3正規形になる。
133:NAME IS NULL
06/03/22 07:14:06
漏れはなんとなくやると第6正規形になる。
134:NAME IS NULL
06/03/22 10:26:27
オレもなんとなくやったら第百万光年正規形になる。
135:NAME IS NULL
06/03/22 19:26:57
自分はなんとなくやったら正上位形になる。
136:NAME IS NULL
06/03/29 03:15:57
>>130
遅レスなので下げる。
第2正規形から推移性関数従属を取り除いたら第3正規形になるよな。
じゃあ、推移性関数従属する非キー項目があるとと何が不味いんだ？
って考えてみな。
ま、結局、単純に言えば更新時にリレーションが消えたり、
データ多重持ちになったりと不整合が起こる可能性を増やしてしまうからだな。
137:NAME IS NULL
06/03/29 04:41:23
>>136
レスありがとうございます。
ただ、私が知りたいのは、なぜ第三正規形にするか、ということではなく、
なぜ、第二正規形という形があるのかということです。
第一正規形から片っ端から関数従属を取り除くと第三正規形になると思うのですが、
その間に第二正規形を置いて第二と第三を区別する理由が良く分からんのです。
138:136
06/03/29 13:02:23 mr4gMX+s
>>137
うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。
もしかして、第一正規形からスタートして第三正規形でゴール！
だから、第二正規形っていう中継点を通過する意味がわかんないよね、
一気にゴールでいいよね、とか思ってるのかな？
もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
あえて正規形を崩す場合もある。稀だと思うが。
で、名前をつけて区別するのは、それぞれの特徴を把握しておく事で、
上に述べた様な更新異常等の不都合に対抗する手を打っておく必要が
あるからだね。（もうこれは主にPGMでだけど）
ちなみに、余計な話だけどすべての関数従属をとりはずすと
ボイスコッドの正規形になるんじゃないかな？
第三正規形は候補キーの中の関数従属については容認してるはず。
間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。
139:136
06/03/29 13:07:11
自己レスだけど、ちょいと言いたい事が足りてなかったかも。
３だとリレーションを保てない、２，１ならOK,なら１にすれば良くて、２の存在価値は
相変わらず不明、とか思われると遺憾かなと思って。
こうなるとやっぱり程度の問題で２の方が更新異常とかの面でまだベターだから、
せめてそこまでは正規化しましょうよ、という事になるのかも。
だから、やっぱり無駄ではないと思うんだけどな。
140:130
06/03/30 03:44:07
度々レスありがとうございます。
>>138
> >>137
> うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。
> もしかして、第一正規形からスタートして第三正規形でゴール！
> だから、第二正規形っていう中継点を通過する意味がわかんないよね、
> 一気にゴールでいいよね、とか思ってるのかな？
正にそんな感じで思っていました。
> もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
> 各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
> リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
> また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
> あえて正規形を崩す場合もある。稀だと思うが。
ここらへんの話を詳しく知りたいと思っています。
ヒントをもらったので調べてみます。
> ちなみに、余計な話だけどすべての関数従属をとりはずすと
> ボイスコッドの正規形になるんじゃないかな？
> 第三正規形は候補キーの中の関数従属については容認してるはず。
> 間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。
そうなんですか、勉強不足でした。調べてみます。
ありがとうございました。
141:NAME IS NULL
06/03/31 18:08:00
>>140
テクニカルエンジニア DB の参考書とか読んでみるといいよ。
こういうDBの理論とかの専門書って少ないし高いし・・・
142:NAME IS NULL
06/03/31 23:46:12
テクニカル DB 保持者ですが設計の経験がほとんどありません、逝ってきます。
143:NAME IS NULL
06/03/32 16:16:11 45VqWbwv
テクデの勉強ってＤＢだけじゃなくて、業務知識のストックにも
なるところが実務向きでいいと思うんだよねー。
なんか、自分の周りではあんまり知られてない試験なんですが。
大規模システムとかやってると、色んな業務形態に触れる
ことが少ないと思うので、こういう試験を通して、自分の未経験分野の
業務知識をつけてくのって、試験受かる受からないに無関係で
重要だと思います。
144:NAME IS NULL
06/04/02 02:41:14
そんなに大きな案件ではなくて、クライアントが言うことばかりでかくて、
たとえば、データは何十万件になるとか、そのくせ、仕様はなんにも決まってなくて時間がない、
その上、実際は1年もしないうちに放置状態になるのが目に見えてるような案件だったら、
DB設計なんかくそ真面目に考えてるより、冗長になっても1テーブルで済ませちゃうってやり方が
我が社ではスタンダードなんですが、これってとんでもないことなんでしょうか？
145:NAME IS NULL
06/04/02 12:28:17
普通。
受託案件は自分がメンテするわけじゃないからなんでもありですよ。
146:NAME IS NULL
06/04/02 13:27:04
>>144
それって逆に開発が鬱陶しくならんか？
147:144
06/04/02 19:07:03
>>145
やりにげ、って感じですかね？
>>146
作り始めてからあれこれ口出されるのにいちいち対応するなら冗長でも1テーブルのほうが楽では？
変なとこで却下されたりすると、正規化してるのが足かせになってよけい面倒なことになってる希ガス
148:NAME IS NULL
06/04/03 13:32:44
確かに正規化しすぎると変更に弱くなるね。
ってか、DB構造見ていじわるしてるのか、という変更ばかり発生する不思議。
うちではその辺、設計者の腕（技術＋業務知識）の見せ所なわけですが。
149:144
06/04/03 23:33:06
>>148
そっちの方への拡張性を考慮して組んだりするとそのマスターまったく要らなくなったりとかw
なんで、足かせになるような仕様を要求しといて、それに対する対処がやっと済んだころに却下になるんだ？
もしかして、もうすごいスキルを持った嫌な奴なのかもしれん
150:白馬の玉子 ◆PqSzNbkqDo
06/04/12 12:43:45
スピードパフォーマンス重視
or
管理効率重視
この二極化しかないと思うんですが。
それぞれに応じて、正規化なんて、教科書どおりにやる必要、
取捨選択すればOKっすよ。
現場で仕事もしたことないOraMasの女とかが、
正規化を演説してたりするんだよなぁ・・・・頃したくなる・・・・。
151:NAME IS NULL
06/04/12 14:11:14
s/頃し/犯し/
152:NAME IS NULL
06/04/12 23:12:50
非正規化するのも、必ずしもパフォーマンスだけが目的ではないしね。
初心者の頃はマスター系とトランザクション系の区別さえつかんかったなぁ・・・
153:NAME IS NULL
06/04/17 14:10:43
T/R系は目的上、正規化しちゃマズい場合もあるし
154:NAME IS NULL
06/05/11 00:57:58 DgrOFV3I
誰か第５正規形を直観的に教えてください．．．
事例を示して、ほら第５正規形じゃないと異状が起きるでしょ？というのは良くあるけど
なんで異状が起きるのか構造的に理解できません。
出来れば結合従属性の概念も。
字面のままの定義は分かるけど、何がどう「従属」してるのかサッパリ。
155:NAME IS NULL
06/05/11 20:58:00
>>154
絶妙のタイミングでこんな記事が・・・
URLﾘﾝｸ(www.atmarkit.co.jp)
これ書いたのお前じゃないの？w
156:NAME IS NULL
06/05/13 01:44:22
>>155
どうもありがと。なんとなく解かりました。
でもこれ、多値従属性の定義の説明が若干間違ってるねえ。
157:NAME IS NULL
06/05/13 02:33:10
？ んー、やっぱ良く解かってないかも。
「すべての情報がそろわないと登録できない」という制約は
別に結合従属性だろうがなかろうが、
ぜんぶの属性がキーであるなら、どんな関係でも当てはまるよね？
何か問題をすり変えられた気分です。
ほかの解説でも、同じなのですが。
結合従属性を持つ関係は、
どういう冗長性があって／どうして情報無損失で分解可能なのか
．．．ってのがやっぱり解らんです。
158:NAME IS NULL
06/05/31 15:26:48
正規化のことじゃなぃんだけんども
リレーションの設定って要るの？
たしかにキーや関係の確認のためにあれば便利だけど、
自分で設計してるもんだから、リレーションを絡めた処理は
ＶＢＡで素で組む。困ったことないんだよ。
みんなどう？
159:NAME IS NULL
06/05/31 21:56:00
好み次第
160:NAME IS NULL
06/06/01 11:06:07
ここで議論が。止まってるけど。
制約っていらなくね？
ｽﾚﾘﾝｸ(db板)l50
161:NAME IS NULL
06/06/06 19:09:59
たしかに最初は律儀にリレーション設定してたけど、漏れも
クエリなんかでその都度繋げるし、参照整合性が邪魔になる時もあるし
同じマスターテーブル（一側ね）を複数繋げるときも邪魔。
設定しないほうが、他人が見たときＤＢの仕組みが分かれにくいから
いじられるの阻止するのにもいいし。
162:NAME IS NULL
06/06/06 22:11:39
データインポートするときとかうざいよね＞リレーション
まぁ、インポート時は無視するオプションとかもDBによってはあるけど
163:NAME IS NULL
06/06/20 02:03:12
あ～～～！むずがゆい！
164:NAME IS NULL
06/10/12 13:35:14 LD5ggMeq
平成の大合併で住所変更。顧客マスタの住所と住所マスタの住所の整合性がとれてない。。
正規化してねーと、こんなことになる。。今日中に終わるかな。。
165:NAME IS NULL
06/10/22 22:41:58
運用部員がマニュアルで作業するときには制約はあったほうがいい。
制約を回避するINSERT、UPDATEを書けるようになれ
166:NAME IS NULL
06/11/15 13:27:54
>155
アクセのレベルを疑うような記事だな。
BC正規化なんて、ひどい。つか、事例悪過ぎ。
ものすごい遅レスなんで下げる。
167:NAME IS NULL
07/01/04 15:07:35 Sogkk2is
すみません質問させて下さい。
共通の商品マスタ（キーは商品コードのみ）をシステムで使用していて桁数や採番ルール等で新たに
商品コードを使いまわすというのは皆さん普通にやりますか？各サブシステムには過去のデータ
が残っていて当然使いまわす前の商品コードも保持されています。ただしDBでリレーションシップが
組まれている訳ではありません。採番ルールを変えて新たな商品コードを取る事も可能です。
過去データを参照するのであればマスタデータを削除、使い回しをする行為は厳禁だと思ってます。（←ここら辺が大きな勘違い？？？）
自分的には採番ルールを変えるのが妥当だと思うんですが。皆さんはどう思われますか？
何分あまり経験が無いもので一般的にはどうしているのかわかりません。
皆さんの意見を聞かせて下さい。宜しくお願い致します。
168:NAME IS NULL
07/01/04 20:18:53
内容が漠然としすぎている気がするが、藻前が設計するんなら
藻前の好きにすればいいと思うが･･･。
つか、DBでリレーションされていないのに商品マスタがどーこーって話を
聞く時点で相当にアレな設計な印象をうけるのだが･･･。
169:NAME IS NULL
07/01/04 22:43:58
物理設計でリレーションシップなしは普通。
それ以前に「リレーション」とかいってる>168の方が
ちょっとなんだかなあという気がするんだが。
コードを使いまわして全く別の商品に割り当てるなんて
信じられない世界だけど、お客さんがそうしたいってなら
しょうがないんじゃないの？お客さん都合を実現するのが
システムなんだから。
お客さん都合でどうなるかわからんコードをキーにするのが悪いよ。
やるとしたら、コードと有効期日FromとToかなんかを複合キーにするしか
ないんじゃないですかね。
170:167
07/01/04 23:32:40
>>168
>>169
ご意見ありがとうございます。
しかし、システムを引き継いだ時点でそういった仕組みで稼動しており
どうにもならない状態だったもので・・・作り直すと結構莫大な工数となりますし。。。
>コードを使いまわして全く別の商品に割り当てるなんて
>信じられない世界だけど
自分が聞きたかったのはこの言葉かもしれません。
お客様もコードが重複する事の弊害も考えずに削除使いまわしを口のにされている模様ですので
コードの桁数を増やし100年位は重複せずにすむ採番ルールを採用する方向で進めて
いくべきだと思いました。
本当にありがとうございました。
171:NAME IS NULL
07/01/05 06:42:50
＞物理設計でリレーションシップなしは普通
物理だろうが論理だろうがリレーションシップがないんなら
そりゃExcelやCSVやCOBOLerな印象があるな。
設計者の理想であるクソ長い商品コードを使うか？か
顧客の要望の通り、過去の番号と重複するけど短い商品コードを使うか？
ってのはそれぞれの事情があるからなぁ。
まあ単に顧客が最初のクソ設計になれてしまったんだろうが。
172:NAME IS NULL
07/01/05 07:25:49
お客さんが既に使ってるコードにはデータベース的な厳密さはないが、
手作業上の必要や業務上のノウハウが詰まってることが多いから簡単にはなくせない。
多くの場合サロゲートキーモデルが有効であることが多く、
主キーはシステム側でユニークで長いのを振り、旧来のコードは属性として使用する。
例えば在庫などに張るシールなどでは後者を大きめに表示した上で両方のコードを印刷している。
173:NAME IS NULL
07/01/05 23:07:34
>>171
まあまあ、COBOLerとか言う前に現実を見よう。
制約っていらなくね？スレでも議論になったくらい
参照整合制約ありなしは結構二分されてるよ。
あり派は実装を見れば設計の意図が判るって意見があった。
なし派は制約つけるとデータメンテが面倒になるからって意見があった。
特に開発段階でテストデータガンガン入れたりする場合とかだね。
どっちも気持ちは判る。
まあつけない派は現場の現実解って感じではあるなあ。
バッドノウハウというか。
174:NAME IS NULL
07/01/05 23:18:39
>>173
いわんとする事はわかるが、だから>>171はCOBOLerと揶揄しているのだろう。
そして、必要最低限のテストもしない人種はCOBOLerに多いな。
職場にもよるが現代(?)のSQLやらJava寄りの人種は
テスト用のツールを用意＆作成したりして、テストのシナリオも
作って開発するけど、ExcelなVB厨やCOBOLerは
あんましそういう概念ないよな。ひたすら手で打鍵とか言うし。
現場の現実解と言えばそうなんだが、COBOLerはあんまし学習能力とか
向上心とかない連中の思想だと思う。
175:173
07/01/06 01:03:19
うーむ、確かに現実解てのは耳障りがよくて
要するに向上心の欠如じゃないかといわれると
ぎゃふんだなあ。
まあ制約に関しては話題がずれちゃった感があるので
ぎゃふんってことでゆるして。
で、制約いらないスレはこっち。止まってるけど。
ｽﾚﾘﾝｸ(db板)l50
>171の、クソ設計にお客さんが慣れちゃって
見直しさせてくれないってのは、判るよー判る。
これも向上心の欠如っていやそうか。
176:NAME IS NULL
07/01/13 19:49:54 xq5OSR3p
主キーが倍精度変数って別におかしくないですか？
主キーは文字変数であるのが望ましいと思っているのですが･･･
177:NAME IS NULL
07/01/13 20:27:34
倍制度でも検索が遅くないならいいんじゃね？
ただ、そんな計算結果みたいなフィールドを主キーにする設計の方がおかしいと思うけど。
178:NAME IS NULL
07/01/13 20:35:58
>>176
numberならアリかも知れんが、doubleみたいな近似値はありえん。
179:NAME IS NULL
07/01/13 20:41:39
64bit整数やdecimal(number)系で桁数の多い場合の主キーで、
それを扱えない言語から利用する場合やむなく実数変数を宛がう事があり
この場合は困ることがある。
180:NAME IS NULL
07/01/15 00:11:04
MSSQL の DATETIME を主キーのタプルに組みこんだらVBAがミリ秒の
分解能を扱えず逝きかけた当方が通りますよ。
181:NAME IS NULL
07/09/25 00:14:21 Cvnl8sn8
SQLから誘導されてきました
ずいぶん初歩的な質問で悪いんですが合併律、分解律、擬推移律の成り立ちを証明したいんですが…
アームストロングの公理系で調べても成り立つとしか書いてないもので…
だれか証明のプロセスを説明していただけないでしょうか？
182:NAME IS NULL
07/10/13 09:57:23
MySQLに natural join ってあったのな。
今頃知った俺ギザ間抜け
183:NAME IS NULL
07/10/21 01:04:39 6GmbKqtg
初心者です、質問です。（他スレで聞いたらここで質問するよういわれました）
Mysqlでテーブル作ってて、フィールド数が90くらいになりそうです。それで問題ないのか知りたいです。
正規化する必要があるのかどうかを知りたいんです。
テーブルは、ライブの情報を扱うものです。なので登録情報は
開催日、開始時間、料金、イベント情報etcの基本情報と
出演者名、出演者のURL、演奏楽器etc の出演者情報になります。
出演者はイベントごとに1～10人に分かれて不安定なので正規化・分離するなら
この部分かなぁと思うんですが、、
それともこの程度なら同じテーブルに入れてもいいのか、判断しかねてます
正規化（テーブルの分離）する場合、登録フローとしては、基本情報の登録時に
自動インクリメントでイベントIDを生成し、それを主キーとして参加者テーブルへの
参加者を登録することになるかと考えています。
正規化する必要あるでしょうか？ 初心者の為判断しかねています。
登録ごとにテーブルに空欄があったりなかったりというのが
マズイような気がしてそれが気になります。 お暇な方、回答お願いします。
184:NAME IS NULL
07/10/21 06:18:18
今はイベントテーブルに出演者やそれに付随するフィールドが
それぞれ10個ずつあるような作りになってるの？
まぁ、分けるとしたら。
イベント(id, 開始時間、料金etc)→出演(イベントid, 出演者id)→出演者(id, 出演社名、URL、吹奏楽器etc)
って感じで新たにテーブル2つ作るような感じかな。
フィールドが90個っての自体はギリギリ許容範囲かなという気もするけど、
同じ出演者が当然何回も出てくると思うんで、
出演者情報はテーブル分けて、別に管理すべきだろうね。
それでかなりシンプルに成りそうだし
185:183
07/10/21 12:48:09
詳しい説明ありがとうございます。ホントに助かります。
アドバイスいただいた中で、出演者情報（名前とURLと楽器、プロフ文etc）にあたる部分は
実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
必ずしも登録してるものと一致するとは限らない可能性もあるので、
イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。
さらに言うと、出演者テーブルへの登録件数（演奏家の人数）が少ないうちは、
プレイヤIDをイベントテーブルに登録するというプロセス自体が機能しないのではという
危惧もあり、無駄にフィールド数が増えてるんです。
1)一覧から参照する（出演者テーブルをリスト表示後、各プレイヤ参照ボタン押す）→IDを入力
2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
みたいな感じで。
なので、１イベントあたり最大10人てのを全部登録したとしても、プレイヤ用フィールドのうち
半分（リスト参照して入力用or手動入力のいずれか）のフィールドは必然的に空欄になるんです
これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
仕方ないよですむならこのままやっちゃおうと思うんですが どうなんでしょう？
プロじゃないんで経験則が働きません…
186:NAME IS NULL
07/10/21 13:52:49
ユーザーインターフェースとテーブルは別だぞ。
187:NAME IS NULL
07/10/21 14:21:27
> 実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
> 必ずしも登録してるものと一致するとは限らない可能性もあるので、
> イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。
イベントごとに楽器が違うということであれば、
楽器は中間テーブルに持てばよいね。
>>184でいくと
出演(イベントid, 出演者id, 楽器)
という感じ。
> 2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
> みたいな感じで。
必ずしも全ての出演者が登録される必要は無いってことだね。
それなら上の中間テーブルで
出演(イベントid, 出演者id, 楽器、名前、URL)
みたいにしたらいいかもね。
出演者idは空白可で。
> これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
> 仕方ないよですむならこのままやっちゃおうと思うんですが どうなんでしょう？
無駄でヘタクソなやり方だとは思うけど、
サイズ的に管理しきれないほどでもないから、
今のままでもいいんじゃないかという気はする
188:183
07/10/21 14:50:38
>>187
なるほど、凄く勉強になりました
イベント基本情報テーブルと、中間テーブルに分ける場合は、
インターフェース的には 基本情報の登録→そのイベントIDを拾って→出演者登録
って流れにすればいいんでしょうか？ 出来れば10人以上にも対応したいんで、
ソッチのやり方で理解した方がいいですよねぇ
>>186
＞ユーザーインターフェースとテーブルは別だぞ。
おっしゃるとおり、その部分の理解が薄いんです。
いろいろ勉強してみます。ありがとうございました。
189:NAME IS NULL
07/10/21 15:56:26
> インターフェース的には 基本情報の登録→そのイベントIDを拾って→出演者登録
それでいいと思う
190:183
07/10/21 18:18:38 6GmbKqtg
わかりました、どうもありがとうございました。
191:NAME IS NULL
07/10/26 11:24:48
許可マスタ
項目名 field名 型 桁数
コード code varchar2 2
エリアコード１ area_code_1 number 2
判定１ area_judge_1 varchar2 1
エリアコード２ area_code_2 number 2
判定２ area_judge_2 varchar2 1
エリアコード３ area_code_3 number 2
判定３ area_judge_3 varchar2 1
エリアコード４ area_code_4 number 2
判定４ area_judge_4 varchar2 1
エリアコード、判定は全84項目存在するが、途中を省略する
.
.
.
こんなDB定義もうやだー
192:NAME IS NULL
07/10/27 09:58:27
lol
193:NAME IS NULL
07/11/01 01:20:19 zMKsxNgF
こんなスレもある。
ｽﾚﾘﾝｸ(prog板)
194:NAME IS NULL
07/11/12 21:07:31
会社コードと会社名だけのテーブルに正規化する価値ってあるかな？
JOINのコストが恐ろしく無駄な気がするんだけど。
195:NAME IS NULL
07/11/12 21:36:34
>>194
「カイシャメイ」 も追加しろ。
196:NAME IS NULL
07/11/12 21:39:15
そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな？
197:NAME IS NULL
07/11/13 11:47:27
>>194
会社なら(>>195のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。
つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。
198:FEQoQDjgtx
07/11/14 04:53:31
gBMpor <a href="URLﾘﾝｸ(sflntwpuclbo.com) [url=URLﾘﾝｸ(vtoysuqfixvo.com) [link=URLﾘﾝｸ(iarrmvwkbpot.com) URLﾘﾝｸ(poyhgemjrdue.com)
199:NAME IS NULL
07/11/17 22:12:21
>>194
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。
200:NAME IS NULL
07/11/18 08:52:47
>>199
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。
でも正規化自体は賛成。
201:NAME IS NULL
07/11/18 09:52:01
取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。
202:NAME IS NULL
07/11/20 02:00:19
いや、それも本とかでは正規化（というか非正規化）の文脈で語られてるよ
203:NAME IS NULL
07/11/20 14:01:50
社名の変更ならその程度で済むかもしれんが、合併とかどうするよ
204:NAME IS NULL
07/11/20 17:12:39
合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。
ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。
205:あぼーん
あぼーん
あぼーん
206:NAME IS NULL
07/11/20 22:25:34
社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい
207:NOMO ESTAS NENIO
07/11/22 07:49:11
>194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。
208:NAME IS NULL
07/11/22 08:26:10
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
２回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか？
209:NAME IS NULL
07/11/22 12:59:43
207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん
ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ
210:NAME IS NULL
07/11/22 20:09:17
吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな？
211:あぼーん
あぼーん
あぼーん
212:NAME IS NULL
07/11/23 23:15:27
>>207
（スレタイ）「頼むから正規化しろよ 第二正規形」
おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。
ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名]（*が主キー）
>>209
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。
213:NAME IS NULL
07/11/23 23:19:50
212の続き
もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。
214:NOMO ESTAS NENIO
07/11/24 03:30:10
>212
取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。
215:NAME IS NULL
07/11/28 01:35:19
>>214
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、１事実１箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。
商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。
よろしく
216:NAME IS NULL
08/04/04 08:17:59
依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で
店舗ID 店舗名 質問1 質問2のA 質問2のB 質問2のA 質問2のB・・・
--------------------------------------------------------------------
ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。
一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。
217:NAME IS NULL
08/04/04 20:25:32
> 一緒に仕事したことないが、開発やってる時は多分できてることを
どういうこと？
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが
218:NAME IS NULL
08/04/04 22:06:03
先輩は勉強しはじめたばかりだから、
そんな仕事はしてない
219:NAME IS NULL
08/04/05 08:22:30
統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。
220:NAME IS NULL
08/04/14 13:44:48
JOINのコストって高いね。
正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。
検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。
221:NAME IS NULL
09/04/11 21:06:53
>>220
釣れますか？
222:NAME IS NULL
09/06/10 17:33:31
>>220
クラウド革命でITエンジニアは監獄行きです
URLﾘﾝｸ(d.hatena.ne.jp)
Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う？
URLﾘﾝｸ(www.atmarkit.co.jp)
223:NAME IS NULL
09/06/22 22:31:06
正規化について質問です
第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば
ＩＤ｜購入者｜商品１｜金額１｜商品２｜金額２｜商品３｜金額３｜商品４｜金額４
01｜ＡＡＡ.....｜ＴＶ１....｜10万...｜ＴＶ２....｜11万....｜ＴＶ３...｜12万....｜ＴＶ４....｜13万...
このような場合は
ＩＤ｜購入者
01｜ＡＡＡ
......と
ＩＤ｜商品｜金額
01｜ＴＶ１｜10万
01｜ＴＶ２｜11万
01｜ＴＶ３｜12万
01｜ＴＶ４｜13万
と２つに分けるかと思いますが
ＩＤ｜購入者｜販売担当者｜購入日｜配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか？
224:NAME IS NULL
09/06/22 22:46:59 Ii7lYaDv
>>223
それって違うんでねーの？
たぶん
225:NAME IS NULL
09/06/22 23:11:29
>>223
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。
226:NAME IS NULL
09/06/23 07:20:42
通常は繰り返しとはみなさない。
あなたの言うとおりなら、
ID、人種類、人ID、日付種類、日付
みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。
227:NAME IS NULL
09/06/24 21:28:15 FsaDUw2R
>>226
ありがとうございます
そうですよね
何かこれに関する情報がのっているサイトとかご存知でないですか？
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど
228:NAME IS NULL
09/06/25 18:47:46
簡単なデータで例を作ってみたら？
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ（その人は
それを言っているのかもしれない）。
229:NAME IS NULL
09/06/25 19:55:02 uVxmIhxY
>>228
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました
具体的な例で話し合うのは重要かもしれませんね
230:NAME IS NULL
09/06/25 22:24:51
よかたねー
231:NAME IS NULL
09/06/27 04:19:07
(・∀・) 白くなっとるﾜﾛﾀｗｗｗｗ
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
232:NAME IS NULL
09/09/21 18:26:25 4bCDESCP
同じ表にmember_idとmember_nameの二つの列があって、
member_id ・・・社内の人間なら社員コード。社外の人はNULL
member_name ・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね？
社員コードは別の社員表にある。
233:NAME IS NULL
09/09/21 20:51:56
社員表(社員コード,社員名)
社外表（コード,名前）
メンバー表(メンバーID,・・・・・)
社員コード∈メンバーID
社員コード∈コード
select B.社員名,C.名前
from メンバー表 A left join 社員表 B ON A.メンバーID=B.社員コード left join 社外表 C ON A.メンバーID = C.コード
234:NAME IS NULL
09/12/24 17:18:39 ao0/KMLR
>>215
＞正規化について言及すると、それは正規形を崩してるだろ。
＞正規化手法は、”既約でない”関数従属を排除する為の射影である
＞必要があり・・・
＞ ：
＞要するに、１事実１箇所になってないと正規形とは言えないってこと。
＞だから、スナップショットは正規化違反ということさ。
超遅レスだが、>>214の見解は的確で合理的じゃね？
販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。
そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。 だから、>>214は優良な実務経験者だと思うぞ。
ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。
235:NAME IS NULL
09/12/26 01:44:47 dn/wTtyt
ニコニコ動画のコメントやアマゾンのレビュー、youtubeのコメントなど
1対多の関係はどういうデータベースの構造になっているんでしょうか？
自分は以下の3パターンを考えたのですがどれも疑問が残ります。
案1：1つのレコードに動画番号とその動画に対する全てのコメント番号を収納する
動画1, コメント1コメント2コメント3コメント4
動画2, コメント1コメント2
欠点：・コメント数が有限になってしまうのではないか。
・複数のコメントが一つのコラムに収納されている場合、
１つのコメントの追加によってそのフィールド全体を更新しないといけないから
重いのではないか。
案2：コメント主導で動画番号を対応づける
コメント1, 動画1
コメント2, 動画2
コメント3, 動画1
コメント4, 動画3
欠点：動画を見る度にコメントの抽出をしないといけないから重いのではないか
案3：各動画毎にコメント用のテーブルを用意する
動画1のコメントテーブル：
コメント1
コメント2
コメント3
動画2のコメントテーブル：
コメント1
欠点(?)：動画の数だけテーブルを用意することになるけど、
自分はどうプログラミングするのか分からないです。
236:NAME IS NULL
09/12/26 02:51:10 rKp6qWLp
>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。
↓こんな風に持たせればそれらしくなるんじゃない？
237:NAME IS NULL
09/12/26 02:51:56 rKp6qWLp
【投稿動画テーブル】
動画ID 会員ID 投稿日時 動画データ ・・・
---------+----------+---------------+----------+---
sm1234567 nv1000000 2008/10/21 11:25 mov999999 ・・・
sm1234568 nv1300000 2009/01/13 18:31 mov888888 ・・・
sm1234569 nv2000000 2009/07/02 09:05 mov989898 ・・・
sm1234510 nv1000000 2009/12/25 23:41 mov010101 ・・・
： ： ： ：
【投稿コメントテーブル】
動画ID タイム コメント
---------+-----+-----------------
sm1234567 00:01 wktk
sm1234567 00:03 高画質
sm1234568 01:52 ああああああああ
sm1234567 00:08 ﾃﾗ画質ｗ
sm1234567 00:12 ｷﾀｰ!
sm1234510 00:02 ｗ
： ： ：
sm1234567 01:32 これはすごいな
sm1234567 01:40 たしかにｗ
sm1234569 03:02 おおおおおおおおっ！
sm1234567 01:59 うｐ主様、乙でした
238:NAME IS NULL
09/12/26 02:52:50
そもそもRDBかどうかも疑うべきだと思うけど。
239:NAME IS NULL
09/12/26 03:21:23 dn/wTtyt
>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。
240:NAME IS NULL
09/12/26 04:06:02
>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。
あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。
241:NAME IS NULL
09/12/26 19:20:41
>>238
ニコニコはMYSQLだと聞いてる。
242:NAME IS NULL
09/12/26 22:13:20
>>238
現実的に考えて、RDB以外にないだろ。
243:NAME IS NULL
09/12/27 00:06:26
多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。