頼むから正規化しろよ　第二正規形

1 ：NAME IS NULL：2005/05/15(日) 03:56:41 ID:43QLdn9b.net

正規化について語りましょう。

前スレ(dat落ち)

頼むから正規化しろよ
http://pc8.2ch.net/test/read.cgi/db/1060690405/

2 ：NAME IS NULL：2005/05/15(日) 04:21:00 ID:???.net

過疎板で深夜の2(σﾟ∀ﾟ)σGets!!

>>1 乙です。

アクセスログのようなもので、IPアドレスを記録するときに、
ホストネームも逆引きして別カラムに記録すると、
これも正規化崩しかな?

3 ：NAME IS NULL：2005/05/15(日) 04:25:33 ID:???.net

>>2
yes

4 ：2：2005/05/15(日) 04:40:59 ID:???.net

>>3
だよな('A`)

いや待てよ、あるIPのHostNameが常に同じと限らないのだから
正規化崩しとは言い切れないような気もしてきた。

5 ：NAME IS NULL：2005/05/15(日) 05:39:58 ID:???.net

>>4
そういう場合はIP/HostNameテーブルに期間カラムを設ける。

6 ：2：2005/05/15(日) 07:47:51 ID:???.net

>>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：2005/05/15(日) 14:01:12 ID:???.net

自動正規化ツールってありますか？

8 ：NAME IS NULL：2005/05/17(火) 11:09:06 ID:???.net

ググったらここしかでてこなかった
http://www.fms-fms.com/gen_coinfo_ogn.htm
2001年 ITI社と日本初のDB自動正規化ツール「IT_DOA .RAD 」で販売提携

で、たどったらこれだった
http://www.it-rad.net/product.html

ほかは見ないねえ・・・

9 ：NAME IS NULL：2005/05/18(水) 00:26:23 ID:???.net

Microsoft の Access についてなかったっけ？簡単な奴が。

10 ：NAME IS NULL：2005/05/25(水) 01:01:16 ID:???.net

sage

11 ：NAME IS NULL：2005/05/28(土) 12:51:06 ID:GrEiaLyo.net

自動なんたらツールって嫌！
そんなのがあったら俺の仕事無くなっちゃうよ！

12 ：NAME IS NULL：2005/05/28(土) 13:13:19 ID:???.net

今まで寝た女のあらゆるデータをカテゴライズしてＤＢにしたいのだが。。

13 ：NAME IS NULL：2005/05/28(土) 14:26:58 ID:???.net

女（女ID）
カテゴリ（カテゴリID, カテゴリ名）
あらゆるデータ（女ID, カテゴリID, データ）

14 ：NAME IS NULL：2005/05/28(土) 17:18:20 ID:???.net

SELECT count(女ID) FROM 女;

15 ：NAME IS NULL：2005/05/28(土) 17:23:15 ID:???.net

レコードが選択されませんでした・・・

16 ：NAME IS NULL：2005/05/28(土) 22:04:23 ID:???.net

二年近くかけてやっと第二正規形か。
第五正規形になるのはいつの日か…

17 ：NAME IS NULL：2005/05/28(土) 22:05:55 ID:???.net

しかも第一は落ちただけだしな

18 ：NAME IS NULL：2005/05/29(日) 07:55:28 ID:???.net

SELECT cunt(女ID) FROM 女;

19 ：NAME IS NULL：2005/05/29(日) 13:16:10 ID:???.net

>>18
SELECT 女.cunt FROM 女;

20 ：NAME IS NULL：2005/05/29(日) 19:48:22 ID:???.net

select distinct cunt(女ID) as count from 女 group by 女ID;
これで決定か？

21 ：NAME IS NULL：2005/05/29(日) 19:49:09 ID:???.net

>>20
大事なことを書き忘れた。
因みにMysql4.1.11です。

22 ：NAME IS NULL：2005/06/07(火) 15:29:45 ID:???.net

正規化工数ってﾅﾝﾃﾞｨｽｶ?
いやここで聞くのも間違ってる気がするけど誰か知ってたら教えてｱﾓｰﾚ

23 ：NAME IS NULL：2005/06/17(金) 02:41:50 ID:???.net

春のＤＢ落ちた。午後�Tあと15点だった。

24 ：NAME IS NULL：2005/07/09(土) 02:15:52 ID:???.net

Access好きはIDって列にPrimary Keyつければいいってもんじゃない事を
肝に銘じておいてくださーい!!DBAの敵ですよー!!

25 ：NAME IS NULL：2005/07/09(土) 07:28:02 ID:Ussu/qQy.net

>>24
意味不明ですが覚えておきます。

26 ：NAME IS NULL：2005/07/09(土) 07:28:18 ID:???.net

上げてしまった・・・orz

27 ：NAME IS NULL：2005/07/11(月) 02:30:15 ID:???.net

あー、>>24を読んだだけであの歌が頭から離れないー！

28 ：NAME IS NULL：2005/07/19(火) 10:27:19 ID:???.net

Normalization!!

29 ：NAME IS NULL：2005/07/20(水) 05:28:41 ID:???.net

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：2005/07/25(月) 00:17:02 ID:4Te3/qIT.net

テーブルの構成の仕方で質問です。

個人テーブル
|　名前　|　趣味コード　|
【例】
|　山田太郎　|　2　|

こんなテーブルがあります。この趣味コードというところに数字が入ります。
この「趣味」に関する部分をどう管理するかで悩んでます。

趣味コードテーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　1　|　読書　|　1　|
|　2　|　つり　|　2　|
|　3　|　キャンプ　|　2　|
|　3　|　サーフィン　|　3　|

趣味カテゴリコードテーブル
|　趣味カテゴリコード　|　カテゴリ名　|
【例】
|　1　|　インドア　|
|　2　|　アウトドア　|
|　3　|　スポーツ　|

「趣味」というものを、カテゴライズする必要があります。
しかし、運用当初から、「趣味」「カテゴリー」をすべて定義し尽くすのは無理ですし、どちらも自由に増やしたり、カテゴリを細分化して、「趣味」が属する「カテゴリ」を変更したり出来るようにしたいです。
基本的に上記のようなテーブル構成が無難だと思うんですが気分的には「カテゴリごとに趣味テーブル」を作ってしまったほうが気持ちよい気もするんです。

例えば
アウトドア趣味テーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　2　|　つり　|　2　|
|　3　|　キャンプ　|　2　|

こうして分けたほうが良さそうな気がするけど、クエリーとかは面倒なことになりそうな悪寒。
やっぱり、趣味はカテゴリに関係なく一つのテーブルに必要になった時点で追加。
趣味カテゴリも同じく、必要になった時点で追加、ってほうほうが良いんでしょうか？

要点をまとめると、カテゴリという属性を持つ趣味というレコードををただひたすら一つのテーブルにいれていいものか？ってとこです。

31 ：NAME IS NULL：2005/07/25(月) 00:32:45 ID:O/Xc/qeP.net

正規化ってやることのメリットが
イマイチわからないんですが、
どんなメリットが待ち構えているのでしょうか？

私的には、ロックの単位が最小限に抑えられるとは思っていますが、
SQLが複雑になったりしますし、パフォーマンス的にもいい方向に
向かうとは思えません。
識者方のご意見を頂戴したいです。

32 ：NZ(NULL,NULL)：2005/07/25(月) 00:53:04 ID:???.net

>30
()…主キー制約、[]->…外部キー制約、| 列のデリミタ
個人テーブル ： (名前) | [趣味コード]->趣味テーブル.趣味コード
趣味テーブル ： (趣味コード) | 趣味名
趣味分類テーブル ：
　 　[(趣味コード)]->趣味テーブル.趣味コード | [(趣味カテゴリコード)]->趣味カテゴリテーブル.趣味カテゴリコード
趣味カテゴリテーブル ： (趣味カテゴリコード) | 趣味カテゴリ名

趣味分類テーブルを連関テーブルとして用意すれば、趣味もカテゴリも別個に管理できる。
そしてひとつの趣味をいくつかのカテゴリに入れることもできる。カテゴリと趣味が一対多なら
前者でよいかと。テーブルを分けるのはお勧めしない。複数カテゴリにまたがる処理を
書きづらくなると思われ。

>31
更新・削除・追加時のデータの異常をなくすため。非正規形の表を見たいならViewをつかえば
SQLもすっきりだ。
正規化の段階を進めると遅くなるのは仕方がない。どうしてもパフォーマンスを得たいなら、
正規化の段階を減らしても異常が発生しない程度に正規化崩しをするのもテクニック。
正規化できないから崩れているのをテクニックと言い張るのは論外。

33 ：NAME IS NULL：2005/07/25(月) 01:29:47 ID:4Te3/qIT.net

>>32
レスありがとうございます。
趣味は、複数のカテゴリに属する必要はない。
個人は複数の趣味を持つ事はない。
この前提で考えております。
「連関テーブル」というのは、ちょっと初めて聞く言葉です。
おそらく、趣味レコードの趣味カテゴリコードから参照して、カテゴリ名を引っ張りだすためのテーブルと認識しておりますが、これでよいですか？
個人が親なら、趣味は子、趣味カテゴリは孫、みたいな。

どちらにしても、趣味をカテゴリごとに別のテーブルに分けるのはあんまり良くなさそうな気がしてきました。
人間にとって解りやすいテーブル構成と、プログラムを組んだり、処理の効率がよいテーブル構成はまた違うというのが、むずかしいとこですね。

趣味は、趣味テーブルにひたすらぶち込む。
この場合の趣味のキーは、自動連番にしちゃってよいですよね？

34 ：NAME IS NULL：2005/07/25(月) 12:33:28 ID:???.net

>>31

正規化の基本はデータの冗長性の排除。

35 ：NAME IS NULL：2005/07/25(月) 13:41:24 ID:???.net

個人と趣味、趣味と趣味カテゴリがそれぞれ1:1対応なら、いっそ

趣味コードテーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　1　|　"なし"　|　1　|

趣味カテゴリコードテーブル
|　趣味カテゴリコード　|　カテゴリ名　|
【例】
|　1　|　"なし"　|
|　2　|　"その他"　|

こんな行を用意しておくとか。
趣味のない人は、ひとまず趣味コードを 1 (なし) にする。
未分類の趣味は、ひとまず趣味分類コードを 2 (その他) にすると。
あとは趣味が見つかったり趣味が分類できたときにUPDATE。

36 ：30：2005/07/26(火) 22:53:39 ID:ir4KuP5T.net

いやー、いろいろ考えまして、
個人、趣味コード、趣味カテゴリ、という構成で行く事に決めますた。
ほかに、趣味カテゴリには趣味カテゴリを表す短い文字列、なんてものもいれてみますた。これによって、カテゴリによって違うclassでスタイルシートを割り当ててしまおう、なんて。けっこうおもしろい事が出来そうです。

37 ：30：2005/07/26(火) 22:59:35 ID:???.net

いやー、いろいろ考えまして、
個人、趣味コード、趣味カテゴリ、という構成で行く事に決めますた。
ほかに、趣味カテゴリには趣味カテゴリを表す短い文字列、なんてものもいれてみますた。これによって、カテゴリによって違うclassでスタイルシートを割り当ててしまおう、なんて。けっこうおもしろい事が出来そうです。

38 ：NAME IS NULL：2005/07/28(木) 07:56:23 ID:???.net

>>37
エッチビデオと普通のビデオのライブラリを分類するのも悩むもの。
たとえばこんなカテゴリ。
看護婦 痴漢 史劇 盗撮投稿
顔射 痴漢痴女 時代劇 日本の音楽
逆ナンパ 痴女 熟女 美少女
逆レイプ 中出し 熟女人妻 複数プレイ
巨乳 潮吹き 女教師 文芸
巨乳フェチ 伝記 女子校生 未公開フィルム
巨乳美乳 投稿 女優物乱交 野外露出
近親相姦 盗撮 人妻 乱交
西部劇 陵辱 戦争 恋愛
素人 露出 素人ナンパ

裏と表があるとなおややこしい。　しかも、オムニバスだったたどうする？
悩みはつきないものです。

39 ：NAME IS NULL：2005/07/28(木) 10:23:52 ID:KXoQY93/.net

>>24
一見、あなたの意見があっていると思う人もいると思うが、実はAccessのほうが現実的な正解だったりする。
但し、それを理解してないでとりあえずID=主キーとする人は間違いだけど。

論理的な主キーとDB実装上の主キーは分離すべき。
論理はビジネスの変革で変わる恐れがあるから。
主キー＝ID、論理キー＝ユニークでの実装が柔軟対応への道。

40 ：NAME IS NULL：2005/07/28(木) 20:20:15 ID:???.net

>39
現実には ID=主キーにして、論理キーとなるべき列に UNIQUE がついてないデータベースの
なんと多いことか…。わかってる人が作ると Access でもそれなりに安定してて速いけど、
中途半端にかじった素人や似非プロが作ると数百件のデータ表示に数分とか一日の使用で
フォームの入ったMDBが数十MB増えるとかざらだし。

　確かに Access は簡単にデータベースアプリが作れるけど、候補キーに UNIQUE つけてないとか
INDEX 闇雲につけて Recordset.Find しか使ってないとかID-PASSWORDテーブルなるものを作って
平文でパスワードを格納して簡易ユーザ認証機能をつけるとか(テーブルエクスポートで丸見え)
珍妙なアプリだらけで(´･ω･`)ｼｮﾎﾞｰﾝ。さらにこれが害虫して作ってもらったものだとわかるともうね。

41 ：NAME IS NULL：2005/07/29(金) 21:57:57 ID:???.net

明日正規化のテストでそうだな

42 ：NAME IS NULL：2005/08/04(木) 14:33:24 ID:???.net

しょ、正気か？

43 ：NAME IS NULL：2005/08/05(金) 17:21:46 ID:???.net

>31
今、どんな教え方しているのか知らないのだが、正規化した後に
パフォーマンス等を考慮に入れて、最後に正規化を崩すてのが
ＤＢ設計の手順にあった。

データ件数や、対象にたどり着くまでの参照回数、使用頻度等
正規化を崩す条件が出来上がるシステムを知っている必要が
あるので、文書化されたもには少ないのかも。

ちなみにこの手順を行っている最中に
「実は同じ物でない項目が正規化されて省かれていた」
「正規化されるべき物が新たに見つかった」
等のミスを発見することが多かった。

44 ：NAME IS NULL：2005/08/12(金) 07:42:08 ID:???.net

　

45 ：NAME IS NULL：2005/08/30(火) 01:16:26 ID:???.net

非正規化は正規化→崩すのステップを踏襲する必要は無いんだぜ！
そんなの教科書でそう書いてるだけで、実際にやったらアホだよ。

ってなことをどっかで読んだことがあるが、どこでだったかな

46 ：NAME IS NULL：2005/08/31(水) 00:55:52 ID:???.net

非正規化は非正規形と化すってことだろ
元々が非正規形なら非正規化は不要な
んだから非正規化をするということは元
の正規形がないとおかしいんジャマイカ？
非正規放置ならわかるけど

47 ：NAME IS NULL：2005/08/31(水) 11:28:41 ID:???.net

まあそりゃそうだ。

頭ん中で、
「わかってるけど、あえてこう」
ってやりゃいいんだ、って話じゃないの？

48 ：NAME IS NULL：2005/09/07(水) 11:42:05 ID:???.net

正規化について質問です。

PCテーブル
(id, 製品名, 購入日, メーカーid, CPU clock, メモリ容量)

ディスプレイテーブル
(id, 製品名, 購入日, メーカーid, サイズ, 解像度)

携帯電話テーブル
(id, 製品名, 購入日, メーカーid, 電話番号)

このように一部共通で、他のデータは内容も数も違うデータを管理したいんで
すが、これをもっと綺麗にまとめる方法があったら教えて下さい。

49 ：NAME IS NULL：2005/09/07(水) 12:03:01 ID:???.net

id,製品名,購入日,メーカーid,type

typePC
id,CPU clock,メモリ容量

typeディスプレイ
id,サイズ,解像度

type携帯電話
id,電話番号

50 ：NAME IS NULL：2005/09/07(水) 15:38:15 ID:???.net

>>48
純粋に正規化なら>>49のとおり。
正規化以前の所から再検討可能で、サイズや電話番号のような情報が備考的な
意味しか持たないなら１つのテーブルにまとめてもよい。
id, 製品タイプ,製品名, 購入日, メーカーid, 製品仕様, 設定
　製品仕様にはCPU clock, メモリ容量, サイズ, 解像度
　設定には電話番号, 解像度(多解像度対応機種で実際に設定している解像度)

51 ：NAME IS NULL：2005/09/07(水) 18:10:22 ID:???.net

>49のパターンにした場合、実際のアプリでSELECTする時SQLが複雑になったりしませんか？

52 ：NAME IS NULL：2005/09/07(水) 22:16:49 ID:???.net

状況による。

データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
JOINのパフォーマンスが問題になるケースではテーブルを一個にする。
パフォーマンス的にさほど問題にならないケースでは>>49のようにきれいに設計したい。

絶対正しいDB設計というのはあまりない

53 ：NAME IS NULL：2005/09/17(土) 16:52:19 ID:???.net

>52へよくわからん。おせーてくれ。
>データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
>JOINのパフォーマンスが問題になるケースではテーブルを一個にする。

君の考え方は、SQLが明確になってから、DB設計をするのか？？

まぁ、状況によるようだがｗ

パフォーマンスが問題でDB設計しなおすなら、マシンを買い替えたら・・・
人件費よりよっぽど安いよ。

54 ：NAME IS NULL：2005/09/17(土) 17:56:57 ID:???.net

>>53
52ではないのだが、データベース設計時にどんな処理や問い合わせが発生するかくらいの予想は
できるし普通する。52が言いたいのはそういうことじゃないかな？
データフローや処理方式をまったく考慮せずにデータ構造の分析だけでDB設計するケースの方が
まれだと思っているがどうなのだろう。

もっとも諸事情で予想がはずれまくることは結構ある（笑）。手戻りを避けたいのは誰でも一緒だ。

55 ：NAME IS NULL：2005/09/18(日) 01:24:50 ID:???.net

パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
幸せな人だw

56 ：NAME IS NULL：2005/09/18(日) 18:01:16 ID:???.net

53だけど

>>54
>52ではないのだが、データベース設計時にどんな処理や問い合わせが
>発生するかくらいの予想はできるし普通する。52が言いたいのはそういうこと
>じゃないかな？
そうかもね。

>データフローや処理方式をまったく考慮せずにデータ構造の分析だけで
>DB設計するケースの方がまれだと思っているがどうなのだろう。
データ構造の分析だけでDB設計をするというのは、どれだけデータ設計に
覚悟をもっている技術者が存在するかにかかっているのではないのかな。
どれだけ、データ構造が普通であろうがシステム開発目的をクリアしなければ
それは机上の空論であろう。
そのときに、処理方式を考慮しないということもないとは思うが、普通にきれいな
正規化をしたものを、崩すことによるデメリットも怖い。不要にバッチ処理を作ったり
して、翌日にならなければ、データが反映できないなど、パフォーマンスを悪化させても
やったりするのはいっぱい見ている。
データフローを考慮するというのは、どういうことを言っているのか、もうすこし、
解説願う。（いろいろ、思いつくので）

55>>
>パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
システムをパフォーマンスが問題で修正するなら、マシンを買い換えたほうが
安いならすればいい。マシンを買い換えたほうがDB設計をしなおして影響する
プログラムを調査してすべて修正してテストをしてリリースするほうが安いなら
そちらをすればいいと思うよ。 まぁ、人件費がかからないなら後者を選べばいい。
>幸せな人だw
おまえも、コストを考えない地位にいるみたいで気楽だねーｗ

57 ：NAME IS NULL：2005/09/18(日) 23:02:29 ID:???.net

文章をまとめるスキルが無いことは分かった

58 ：NAME IS NULL：2005/09/19(月) 07:57:28 ID:???.net

>57
スマソ
幼稚園からやり直すので、何年か持っていてくれ

59 ：NAME IS NULL：2005/09/19(月) 17:45:33 ID:???.net

ところで、もまいら正規化以前でDBの設計ってどー始める？

60 ：NAME IS NULL：2005/09/20(火) 09:13:51 ID:???.net

＞ところで、もまいら正規化以前でDBの設計ってどー始める？

何この最高に頭の悪い書き込み。ふざけてるの？

61 ：NAME IS NULL：2005/09/20(火) 09:52:00 ID:???.net

>>59
>>60
まあ、好意的に解釈すれば、正規化なんて設計の後半だからね。
まず実業務などからえんててーのちうしつから始まるわけで。

62 ：NAME IS NULL：2005/09/21(水) 02:11:44 ID:???.net

>>61
　　回答、ありがとう 59です。

　　＞実業務などからえんててーのちうしつから始まるわけで。
既存システムのようなものがない場合は、帳票を基にお願いして。
既存システムがある場合は、既存システムの説明書から、えんててーの
　　ちうしつをしてもらうような感じなのかな。

>>60
＞何この最高に頭の悪い書き込み。ふざけてるの？
　　まじめに判らなかったので聞いてみました。というのはＤＢ設計の
　　入門記事などでみると、ＤＢの正規化以前に未正規化状態の
　　表とかができているのが前提で記事が始まっていて、この表自体を
　　どこから持ってくるのか疑問に思っていました。
　　気分を害されたようでしたら、謝ります。

63 ：NAME IS NULL：2005/09/21(水) 02:44:44 ID:???.net

>59
参考
ttp://codezine.jp/a/article.aspx?aid=154

64 ：NAME IS NULL：2005/09/21(水) 03:19:55 ID:???.net

63>>
回答ありがとう59です。
参考ホームページを拝見しました。
この羽生さんの記事は、素人にもわかりやすくていいですね。
SQLの部分は、意味がよくわかりませんでしたが、そのほかの
設計に関しては概ね読むことが出来ました。

気になったのは、この文章の「はじめに」の中で書かれている、
データベース設計はスキルが身につきにくいという文意のこと
です。
この文章を読む限りシステム会社の人でもこのようなスキルを
あまり持っていないと言うことでしょうか。
羽生さんの記事自体初級で且つ第一回ということですので、
私も読むことが出来ましたが、この後の回では、段々専門的に
なっていくのかなと恐れています。
データベース設計は、全何回の連載記事かは、わかりませんが、
このとおりにやっていれば、何回かでデータベース設計が
出来るようになってしまうレベルのこと なんですよね？

システムを開発する会社に対して正直に言うと不信感が出てきて
ます。

ちょっと、急いでキー打ったので、読みにくい部分もあると思いますが
もし良かったら、判らないところとか教えていただければと思います

65 ：NAME IS NULL：2005/09/21(水) 07:21:14 ID:???.net

>>64
データベース設計は範囲が広いのでトータルでできる人間は少ないかもしれないですが、
部分的にならデータベースを扱うプログラマレベルでも理解してると思います。
この連載は単純で具体的な例でERDの説明をわかりやすくしてくれているようです。
こういうダイヤグラムを作ることは重要ですがこれもやはり設計の一部です。
ただダイヤグラムがあることで部分部分の担当者が相互に理解しやすくなるという
メリットがあります。たとえば私はそのページのERDをみてこんなことを思いました。
テイクアウトで顧客名と電話番号の管理は無理では。注文を注文用紙単位で管理する必要は無いか。
折角システム化するならタッチパネルでお客さんに直接入力させられないか。などなど・・・

66 ：NAME IS NULL：2005/10/03(月) 03:20:52 ID:???.net

右手が性器化した

67 ：NAME IS NULL：2005/10/11(火) 11:53:34 ID:???.net

皆さん、正規化ってちゃんとしてます？

正規化した気になっていても、第三正規化ができてないケースが多く感じるけど
みなさんのところではどうですか？

キーに関係ないリレーションの項目があったりするのを多くみした。

最近は、そんな項目つけないようにさせてるので、自分ではみないです。

68 ：NAME IS NULL：2005/10/11(火) 15:38:30 ID:???.net

ここはお前の日記帳です

69 ：NAME IS NULL：2005/10/13(木) 18:22:42 ID:CdlqOxne.net

>>49　のパターンで正規化する際に、
俺なら一番上の行のテーブルにtype列はつけないな。
主キー同士でexists演算やれば行抽出の段階では
索引しか物理読み取りしないのでパフォーマンス的にも問題ないと思うのだがどうだろう

70 ：NAME IS NULL：2005/10/29(土) 12:14:45 ID:zOZqpbV9.net

完全に近い形で正規化された設計を見てみたい(つдT)

71 ：NAME IS NULL：2005/10/30(日) 02:58:04 ID:???.net

完全に「近い」形か、難しいな。

72 ：NAME IS NULL：2005/10/30(日) 10:53:28 ID:???.net

>>70
完全なのは見たくないの？

とりあえず例となる問題を書いてよ。
「社員がいてー、社員には名前と生年月日があってー、社員は課に属していてー」云々。
わたしは、そういう問題が出されてからテーブル構成が出来ていく様子を見てみたい。

73 ：NAME IS NULL：2005/10/30(日) 10:57:03 ID:???.net

じゃあ、社員がいて名前と生年月日があって、課に属している

74 ：NAME IS NULL：2005/11/09(水) 15:37:35 ID:???.net

社員テーブル1つ

75 ：NAME IS NULL：2005/11/10(木) 01:16:33 ID:???.net

>74
課テーブルくらい作ってやれよ。寂しいだろ。

76 ：NAME IS NULL：2005/11/10(木) 12:40:37 ID:???.net

>>72
＞そういう問題が出されてから
問題に出されている条件が正確なら正規化は難しくないが、
現実だとその条件が正しいかどうか抜けが無いかどうかの検証が作業の大半をしめる。
例えば同時に複数の課に所属する可能性や、部付きや社長や役員など課に所属しない
人間はいないのか、いたらどうするかなど検討する必要がある。

77 ：NAME IS NULL：2005/11/10(木) 23:50:11 ID:???.net

社員テーブル
------------
社員ID
名前


部署テーブル
-----------
部署ID
部署名
親部署ID


所属テーブル
-----------
社員ID
所属部署ID
プライマリ所属部署?
付き?

78 ：NAME IS NULL：2005/11/10(木) 23:55:33 ID:???.net

>>77
お前がやっていることはネタにマジレスってやつだ

79 ：NAME IS NULL：2005/11/11(金) 11:07:24 ID:???.net

生年月日テーブルも作らなくちゃ


生年月日テーブル
-----------
生年月日ID
年
月
日

80 ：NAME IS NULL：2005/11/11(金) 16:52:46 ID:???.net

年テーブルと月テーブルと日テーブルも

81 ：NAME IS NULL：2005/11/11(金) 17:24:39 ID:???.net

じゃあ曜日テーブルも作ろうぜ

82 ：NAME IS NULL：2005/11/11(金) 21:41:39 ID:???.net

時分秒も・・・

83 ：NAME IS NULL：2005/11/11(金) 22:01:08 ID:???.net

>>82
いや、それはいらないな

84 ：NAME IS NULL：2005/11/11(金) 22:04:55 ID:???.net

名前文字テーブルも作らないと
----------
名前文字コード LONG PRIMARY KEY,
名前 IMAGE NOT NULL

社員名テーブル
----------
社員ID LONG PRIMARY KEY,
文字順序数 INT NOT NULL, -- 名前の文字を表示する順序
名前文字コード LONG NOT NULL FOREIGN KEY REFERENCES 名前文字テーブル(名前文字コード)

85 ：NAME IS NULL：2005/11/11(金) 22:11:56 ID:???.net

>>84
名前の読みはどうすればいいのだろう？
やっぱ、PCMかな。

86 ：NAME IS NULL：2005/11/11(金) 22:15:41 ID:???.net

>>83
そのつっこみ、今週で一番笑った

87 ：NAME IS NULL：2005/11/11(金) 23:29:09 ID:???.net

>>77

出直せ。

88 ：NAME IS NULL：2005/11/24(木) 11:31:47 ID:???.net

体重テーブルも必須だろ

体重テーブル
-----------
社員ID
体重

updateが多そうなので体重にindex付けるかどうか迷うが

89 ：NAME IS NULL：2005/11/24(木) 11:40:14 ID:???.net

>>88
以前の体重と比較できるように計測日フィールド入れないとダメだろ

90 ：NAME IS NULL：2005/11/26(土) 18:01:45 ID:???.net

http://www.doaplus.com/html/bun03_20051101.html
「正規化するとレスポンスが悪くなる」という「うわさ」は本当か？
百聞は一見にしかず。当分科会が実証実験を行いました。

91 ：NAME IS NULL：2005/11/26(土) 23:39:38 ID:???.net

非正規化したテーブルを何でジョインするんだw

92 ：NAME IS NULL：2005/11/27(日) 00:43:20 ID:???.net

確かに不思議屋根

93 ：NAME IS NULL：2005/11/27(日) 16:57:05 ID:???.net

>非正規形のDBを使っている技術者はJOINが遅くなることを体験しており、
>「正規化するともっと遅くなる」と誤解している。

比正規形のDBを使っている「技術者」だってよ。

94 ：NAME IS NULL：2005/11/27(日) 19:51:55 ID:???.net

欺術者偽術者疑術者擬術者戯術者好きなのドソー

95 ：NAME IS NULL：2005/11/27(日) 20:39:15 ID:???.net

俺も方法論的にはどっちかというとDOA派だけど、
>>90のようなアホなこと真面目にやってるから
古いって馬鹿にされるんだよな・・・

96 ：NAME IS NULL：2006/01/05(木) 06:21:42 ID:RI5QmBcj.net

販売系のシステムで、受注データ取り込み時に、
取引先の商品コードと自社の商品コードを1:1で変換する必要があるのだが、
連関（変換）マスタを作るのが面倒という理由で、
自社の商品マスタ内に取引先の商品コードをも持っていた。
当時の設計担当に聞いたところ
「取り込み時に取引先の商品コードが重複してたら警告を出すから問題はない
それにテーブルを増やすとPGが複雑になってバグが増えるだろ？」
と言っていたがしかし・・・・

個人的に変換系のマスタは相手方のキーを主キーにして、
自社コードを従属させていくしか手はないと思っているのだがどうなのだろうか。

97 ：NAME IS NULL：2006/01/05(木) 15:19:39 ID:p0LLZBlZ.net

俺も基本的には正規化されてた方がいいが、たまにパフォーマンス等のために
あえて正規化を崩すとかするらしいんだけど、
正規化するとパフォーマンスが極端に悪くなるようなデータ量の設計した事ないので、
そこらへんは自分で経験積んで判断するしかないと思う。
理論を最優先にするのもいいのかも知れんけど、俺は色々なことを考慮して方がいいと思う。
正規化しまくってパフォーマンス落ちすぎたら、システム全体から見ると問題だと思う。
まぁ、正規化しまくった当事者は満足かも知れないけど､他にひずみをおこしたら・・

98 ：NAME IS NULL：2006/01/07(土) 03:33:51 ID:???.net

複雑にするとバグがおきやすいってのは真だな。パフォーマンス上もシンプルな方がキャッシュとか効きやすいし。

99 ：NAME IS NULL：2006/01/07(土) 05:18:37 ID:???.net

>>96は思い込みが激しそうだなw

100 ：NAME IS NULL：2006/01/10(火) 21:22:34 ID:emDEfEEV.net

すみませんが、質問です。

ユーザの追加オプションを管理する、以下のようなテーブルがあります。

ユーザ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制約に埋め込みたくあり
ません。できれば正規化で対応したいのですが。