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

1 ：05/05/15 〜 最終レス ：11/09/10

正規化について語りましょう。
前スレ(dat落ち)
頼むから正規化しろよ
http://pc8.2ch.net/test/read.cgi/db/1060690405/

2 ：

過疎板で深夜の2(σﾟ∀ﾟ)σGets!!
>>1 乙です。
アクセスログのようなもので、IPアドレスを記録するときに、
ホストネームも逆引きして別カラムに記録すると、
これも正規化崩しかな?

3 ：

>>2
yes

4 ：

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

5 ：

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

6 ：

>>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 ：

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

8 ：

ググったらここしかでてこなかった
http://www.fms-fms.com/gen_coinfo_ogn.htm
2001年 ITI社と日本初のDB自動正規化ツール「IT_DOA .RAD 」で販売提携
で、たどったらこれだった
http://www.it-rad.net/product.html
ほかは見ないねえ・・・

9 ：

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

10 ：

sage

11 ：

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

12 ：

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

13 ：

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

14 ：

SELECT count(女ID) FROM 女;

15 ：

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

16 ：

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

17 ：

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

18 ：

SELECT cunt(女ID) FROM 女;

19 ：

>>18
SELECT 女.cunt FROM 女;

20 ：

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

21 ：

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

22 ：

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

23 ：

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

24 ：

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

25 ：

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

26 ：

上げてしまった・・・orz

27 ：

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

28 ：

Normalization!!

29 ：

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 ：

テーブルの構成の仕方で質問です。
個人テーブル
|　名前　|　趣味コード　|
【例】
|　山田太郎　|　2　|
こんなテーブルがあります。この趣味コードというところに数字が入ります。
この「趣味」に関する部分をどう管理するかで悩んでます。
趣味コードテーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　1　|　読書　|　1　|
|　2　|　つり　|　2　|
|　3　|　キャンプ　|　2　|
|　3　|　サーフィン　|　3　|
趣味カテゴリコードテーブル
|　趣味カテゴリコード　|　カテゴリ名　|
【例】
|　1　|　インドア　|
|　2　|　アウトドア　|
|　3　|　スポーツ　|
「趣味」というものを、カテゴライズする必要があります。
しかし、運用当初から、「趣味」「カテゴリー」をすべて定義し尽くすのは無理ですし、どちらも自由に増やしたり、カテゴリを細分化して、「趣味」が属する「カテゴリ」を変更したり出来るようにしたいです。
基本的に上記のようなテーブル構成が無難だと思うんですが気分的には「カテゴリごとに趣味テーブル」を作ってしまったほうが気持ちよい気もするんです。
例えば
アウトドア趣味テーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　2　|　つり　|　2　|
|　3　|　キャンプ　|　2　|
こうして分けたほうが良さそうな気がするけど、クエリーとかは面倒なことになりそうな悪寒。
やっぱり、趣味はカテゴリに関係なく一つのテーブルに必要になった時点で追加。
趣味カテゴリも同じく、必要になった時点で追加、ってほうほうが良いんでしょうか？
要点をまとめると、カテゴリという属性を持つ趣味というレコードををただひたすら一つのテーブルにいれていいものか？ってとこです。

31 ：

正規化ってやることのメリットが
イマイチわからないんですが、
どんなメリットが待ち構えているのでしょうか？
私的には、ロックの単位が最小限に抑えられるとは思っていますが、
SQLが複雑になったりしますし、パフォーマンス的にもいい方向に
向かうとは思えません。
識者方のご意見を頂戴したいです。

32 ：

>30
()…主キー制約、[]->…外部キー制約、| 列のデリミタ
個人テーブル ： (名前) | [趣味コード]->趣味テーブル.趣味コード
趣味テーブル ： (趣味コード) | 趣味名
趣味分類テーブル ：
　 　[(趣味コード)]->趣味テーブル.趣味コード | [(趣味カテゴリコード)]->趣味カテゴリテーブル.趣味カテゴリコード
趣味カテゴリテーブル ： (趣味カテゴリコード) | 趣味カテゴリ名
趣味分類テーブルを連関テーブルとして用意すれば、趣味もカテゴリも別個に管理できる。
そしてひとつの趣味をいくつかのカテゴリに入れることもできる。カテゴリと趣味が一対多なら
前者でよいかと。テーブルを分けるのはお勧めしない。複数カテゴリにまたがる処理を
書きづらくなると思われ。
>31
更新・削除・追加時のデータの異常をなくすため。非正規形の表を見たいならViewをつかえば
SQLもすっきりだ。
正規化の段階を進めると遅くなるのは仕方がない。どうしてもパフォーマンスを得たいなら、
正規化の段階を減らしても異常が発生しない程度に正規化崩しをするのもテクニック。
正規化できないから崩れているのをテクニックと言い張るのは論外。

33 ：

>>32
レスありがとうございます。
趣味は、複数のカテゴリに属する必要はない。
個人は複数の趣味を持つ事はない。
この前提で考えております。
「連関テーブル」というのは、ちょっと初めて聞く言葉です。
おそらく、趣味レコードの趣味カテゴリコードから参照して、カテゴリ名を引っ張りだすためのテーブルと認識しておりますが、これでよいですか？
個人が親なら、趣味は子、趣味カテゴリは孫、みたいな。
どちらにしても、趣味をカテゴリごとに別のテーブルに分けるのはあんまり良くなさそうな気がしてきました。
人間にとって解りやすいテーブル構成と、プログラムを組んだり、処理の効率がよいテーブル構成はまた違うというのが、むずかしいとこですね。
趣味は、趣味テーブルにひたすらぶち込む。
この場合の趣味のキーは、自動連番にしちゃってよいですよね？

34 ：

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

35 ：

個人と趣味、趣味と趣味カテゴリがそれぞれ1:1対応なら、いっそ
趣味コードテーブル
|　趣味コード　|　趣味名　|　趣味カテゴリコード　|
【例】
|　1　|　"なし"　|　1　|
趣味カテゴリコードテーブル
|　趣味カテゴリコード　|　カテゴリ名　|
【例】
|　1　|　"なし"　|
|　2　|　"その他"　|
こんな行を用意しておくとか。
趣味のない人は、ひとまず趣味コードを 1 (なし) にする。
未分類の趣味は、ひとまず趣味分類コードを 2 (その他) にすると。
あとは趣味が見つかったり趣味が分類できたときにUPDATE。

36 ：

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

37 ：

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

38 ：

>>37
ビデオと普通のビデオのライブラリを分類するのも悩むもの。
たとえばこんなカテゴリ。
看護婦 痴漢 史劇 投稿
顔射 痴漢痴女 時代劇 日本の音楽
逆ナンパ 痴女 美少女
逆 複数プレイ
巨 潮吹き 女教師 文芸
巨 伝記 女子校生 未公開フィルム
巨美 投稿 女優物 野外
近親
西部劇 陵辱 戦争 恋愛
素人 素人ナンパ
裏と表があるとなおややこしい。　しかも、オムニバスだったたどうする？
悩みはつきないものです。

39 ：

>>24
一見、あなたの意見があっていると思う人もいると思うが、実はAccessのほうが現実的な正解だったりする。
但し、それを理解してないでとりあえずID=主キーとする人は間違いだけど。
論理的な主キーとDB実装上の主キーは分離すべき。
論理はビジネスの変革で変わる恐れがあるから。
主キー＝ID、論理キー＝ユニークでの実装が柔軟対応への道。

40 ：

>39
現実には ID=主キーにして、論理キーとなるべき列に UNIQUE がついてないデータベースの
なんと多いことか…。わかってる人が作ると Access でもそれなりに安定してて速いけど、
中途半端にかじった素人や似非プロが作ると数百件のデータ表示に数分とか一日の使用で
フォームの入ったMDBが数十MB増えるとかざらだし。
　確かに Access は簡単にデータベースアプリが作れるけど、候補キーに UNIQUE つけてないとか
INDEX 闇雲につけて Recordset.Find しか使ってないとかID-PASSWORDテーブルなるものを作って
平文でパスワードを格納して簡易ユーザ認証機能をつけるとか(テーブルエクスポートで丸見え)
珍妙なアプリだらけで(´･ω･`)ｼｮﾎﾞｰﾝ。さらにこれが害虫して作ってもらったものだとわかるともうね。

41 ：

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

42 ：

しょ、正気か？

43 ：

>31
今、どんな教え方しているのか知らないのだが、正規化した後に
パフォーマンス等を考慮に入れて、最後に正規化を崩すてのが
ＤＢ設計の手順にあった。
データ件数や、対象にたどり着くまでの参照回数、使用頻度等
正規化を崩す条件が出来上がるシステムを知っている必要が
あるので、文書化されたもには少ないのかも。
ちなみにこの手順を行っている最中に
「実は同じ物でない項目が正規化されて省かれていた」
「正規化されるべき物が新たに見つかった」
等のミスを発見することが多かった。

44 ：

　

45 ：

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

46 ：

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

47 ：

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

48 ：

正規化について質問です。
PCテーブル
(id, 製品名, 購入日, メーカーid, CPU clock, メモリ容量)
ディスプレイテーブル
(id, 製品名, 購入日, メーカーid, サイズ, 解像度)
携帯電話テーブル
(id, 製品名, 購入日, メーカーid, 電話番号)
このように一部共通で、他のデータは内容も数も違うデータを管理したいんで
すが、これをもっと綺麗にまとめる方法があったら教えて下さい。

49 ：

id,製品名,購入日,メーカーid,type
typePC
id,CPU clock,メモリ容量
typeディスプレイ
id,サイズ,解像度
type携帯電話
id,電話番号

50 ：

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

51 ：

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

52 ：

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

53 ：

>52へよくわからん。おせーてくれ。
>データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
>JOINのパフォーマンスが問題になるケースではテーブルを一個にする。
君の考え方は、SQLが明確になってから、DB設計をするのか？？
まぁ、状況によるようだがｗ
パフォーマンスが問題でDB設計しなおすなら、マシンを買い替えたら・・・
人件費よりよっぽど安いよ。

54 ：

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

55 ：

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

56 ：

53だけど
>>54
>52ではないのだが、データベース設計時にどんな処理や問い合わせが
>発生するかくらいの予想はできるし普通する。52が言いたいのはそういうこと
>じゃないかな？
そうかもね。
>データフローや処理方式をまったく考慮せずにデータ構造の分析だけで
>DB設計するケースの方がまれだと思っているがどうなのだろう。
データ構造の分析だけでDB設計をするというのは、どれだけデータ設計に
覚悟をもっている技術者が存在するかにかかっているのではないのかな。
どれだけ、データ構造が普通であろうがシステム開発目的をクリアしなければ
それは机上の空論であろう。
そのときに、処理方式を考慮しないということもないとは思うが、普通にきれいな
正規化をしたものを、崩すことによるデメリットも怖い。不要にバッチ処理を作ったり
して、翌日にならなければ、データが反映できないなど、パフォーマンスを悪化させても
やったりするのはいっぱい見ている。
データフローを考慮するというのは、どういうことを言っているのか、もうすこし、
解説願う。（いろいろ、思いつくので）
55>>
>パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
システムをパフォーマンスが問題で修正するなら、マシンを買い換えたほうが
安いならすればいい。マシンを買い換えたほうがDB設計をしなおして影響する
プログラムを調査してすべて修正してテストをしてリリースするほうが安いなら
そちらをすればいいと思うよ。 まぁ、人件費がかからないなら後者を選べばいい。
>幸せな人だw
おまえも、コストを考えない地位にいるみたいで気楽だねーｗ

57 ：

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

58 ：

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

59 ：

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

60 ：

＞ところで、もまいら正規化以前でDBの設計ってどー始める？
何この最高に頭の悪い書き込み。ふざけてるの？

61 ：

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

62 ：

>>61
　　回答、ありがとう 59です。
　　＞実業務などからえんててーのちうしつから始まるわけで。
既存システムのようなものがない場合は、帳票を基にお願いして。
既存システムがある場合は、既存システムの説明書から、えんててーの
　　ちうしつをしてもらうような感じなのかな。
>>60
＞何この最高に頭の悪い書き込み。ふざけてるの？
　　まじめに判らなかったので聞いてみました。というのはＤＢ設計の
　　入門記事などでみると、ＤＢの正規化以前に未正規化状態の
　　表とかができているのが前提で記事が始まっていて、この表自体を
　　どこから持ってくるのか疑問に思っていました。
　　気分を害されたようでしたら、謝ります。

63 ：

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

64 ：

63>>
回答ありがとう59です。
参考ホームページを拝見しました。
この羽生さんの記事は、素人にもわかりやすくていいですね。
SQLの部分は、意味がよくわかりませんでしたが、そのほかの
設計に関しては概ね読むことが出来ました。
気になったのは、この文章の「はじめに」の中で書かれている、
データベース設計はスキルが身につきにくいという文意のこと
です。
この文章を読む限りシステム会社の人でもこのようなスキルを
あまり持っていないと言うことでしょうか。
羽生さんの記事自体初級で且つ第一回ということですので、
私も読むことが出来ましたが、この後の回では、段々専門的に
なっていくのかなと恐れています。
データベース設計は、全何回の連載記事かは、わかりませんが、
このとおりにやっていれば、何回かでデータベース設計が
出来るようになってしまうレベルのこと なんですよね？
システムを開発する会社に対して正直に言うと不信感が出てきて
ます。
ちょっと、急いでキー打ったので、読みにくい部分もあると思いますが
もし良かったら、判らないところとか教えていただければと思います

65 ：

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

66 ：

右手が性器化した

67 ：

皆さん、正規化ってちゃんとしてます？
正規化した気になっていても、第三正規化ができてないケースが多く感じるけど
みなさんのところではどうですか？
キーに関係ないリレーションの項目があったりするのを多くみした。
最近は、そんな項目つけないようにさせてるので、自分ではみないです。

68 ：

ここはお前の日記帳です

69 ：

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

70 ：

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

71 ：

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

72 ：

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

73 ：

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

74 ：

社員テーブル1つ

75 ：

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

76 ：

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

77 ：

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

78 ：

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

79 ：

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

80 ：

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

81 ：

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

82 ：

時分秒も・・・

83 ：

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

84 ：

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

85 ：

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

86 ：

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

87 ：

>>77
出直せ。

88 ：

体重テーブルも必須だろ
体重テーブル
-----------
社員ID
体重
updateが多そうなので体重にindex付けるかどうか迷うが

89 ：

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

90 ：

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

91 ：

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

92 ：

確かに不思議屋根

93 ：

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

94 ：

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

95 ：

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

96 ：

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

97 ：

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

98 ：

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

99 ：

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

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲