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

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

101 ：NAME IS NULL：2006/01/11(水) 01:19:44 ID:???.net

俺的には、テーブルの作り自体は現行で最善な感じがする。
マジックナンバーがいやなら、チェックはアプリケーションロジックでやるとか。

トータルコスト考えて、どこで妥協するかって話だと思う

102 ：100：2006/01/11(水) 12:25:56 ID:VpUtuDIC.net

>>101
やはりそう思われますか…。トータルコストを考えると、どんな用件に対して
も正規化が可能なわけではないということでしょうか。

マジックナンバーがイヤなのは、オプションのマスタテーブルのレコード追
加・削除に伴って、>>100のユーザテーブルのCHECK制約を書き換えなければな
らないからです。

オプションのマスタテーブルに、制限回数が必要かを示すフラグを、カラムと
して用意すれば、マジックナンバーに頼らなくても済みます。しかし、使用DB
がPostgreSQLなので、CHECK制約で外部テーブルを参照できないのです。

アプリの側でチェックすれば、外部テーブルを参照することもできます。しか
し、いかにも煩雑です。

うーん、やっぱり正規化を諦めるのはつらいなあ。

103 ：100：2006/01/11(水) 12:29:38 ID:???.net

外部テーブルという言い方は変ですね。単に、別テーブルという意味です。

http://www.postgresql.jp/document/pg734doc/reference/sql-createtable.html
>現在、CHECK 式には、副selectや現在の行の列以外の値を含むことはできません。

104 ：NAME IS NULL：2006/01/13(金) 01:03:49 ID:???.net

>100
オプション4,5 では何を指定しても使われないなら、NOT NULL にして4,5を挿入するときは適当に
0でも入れておけばいいんじゃないの? DEFAULT 0 とかつけてやったりして。

105 ：NAME IS NULL：2006/01/13(金) 03:04:52 ID:???.net

>>104
そうやっても 00001　1　0 という誤挿入を防ぐことはできない罠。

106 ：NAME IS NULL：2006/01/13(金) 06:31:18 ID:???.net

>105
0 がないとすると、残り1回のまま永久にオプションを使い続けられることにならない?

107 ：100：2006/01/13(金) 11:29:00 ID:TppsOzrm.net

>>105
説明不足ですみません。カラム「制限回数」は、ゼロを入れる予定は（NULLの
代用でない限り）ないんです。

オプションサービスが利用されると、別テーブル（利用状況記録テーブル）に
新規レコードが挿入されます。そのレコード数と制限回数を比較して、超過を
チェックしております。

だから、カラム「制限回数」の数字がだんだん減る、という使われ方ではあり
ません。

さらに言えば、この制限回数は、月ごとのトータル回数なので、現在月の利用
回数（レコード数）と、カラム「制限回数」を比較します。来月はまた同じ値
の「制限回数」と比較する必要がありますから、このカラムの値を減らしては
いけないんです。

以上、補足でした。

108 ：100：2006/01/13(金) 11:30:11 ID:???.net

あ、リンクを間違えました。× >>105 → ○ >>106

109 ：NAME IS NULL：2006/01/13(金) 19:37:09 ID:???.net

>>107
アプリで管理すればいいやんとは思うが正規化スレなので正規化で考えると、
ユーザID、オプションID、制限回数のち制限回数には回数とそれを使うかどうかの情報が含まれている。
この制限回数を使うかどうかの情報を分離して回数制限フラグと呼ぶこととする。
回数制限フラグはオプションID毎に決まっており推移的関数従属であるためそれを排除して第３正規系にする。
で答えはオプションIDマスタを作ってそこに制限回数フラグを持つべしということになる。

110 ：100：2006/01/13(金) 22:01:07 ID:TppsOzrm.net

>>109
ありがとうございます。
ただ、私は、>>102の後半に、かなり似た内容を書いておりまして、それと
どう違うのか、良くわかりません…。

111 ：NAME IS NULL：2006/01/14(土) 00:03:14 ID:???.net

>>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：2006/01/15(日) 14:40:37 ID:iP9+MlmJ.net

>>111
ありがとうございます。返答が遅くなってすみません。

NOT NULL制約を付けるということですが、これだけでは 00001　1　0 といった
誤挿入を防ぐことはできません。オプションID 1, 2, 3 に対しては、NULL と同
様に 0 も不適なのです。
ならば1以上のみを許容するようにすればいいかと言うと、今度はオプションID
4,5に対して、使われもしない数値を入力する義務ができてしまい、やはり良い
設計とは思えません。

本来ならcheck制約でもっとキメ細かい入力値のチェックをできたら良かったの
ですが、PostgreSQLの機能の制約でできませんでした。

ここで、check制約の代りに、トリガを使えば良い、というのは盲点でした。ト
リガというと更新系の動作をさせることしか頭にありませんでした。これならど
んな複雑なチェックでもできます。ありがとうございます。

なお、私はcheck制約と正規化を混同してはいません。check制約が使えないから、
正規化で対応したいと言っていたつもりでした。まずい説明ですみません。

113 ：100：2006/01/15(日) 14:42:47 ID:iP9+MlmJ.net

ところで、頂いたレスを読み返しているうちに、あることに気づき、そして正規
化のアイディアを思いつきました。

> 制限回数には回数とそれを使うかどうかの情報が含まれている。
とのことでしたが、もっと言えば、このユーザオプション管理テーブルの内容自
体に、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：2006/01/15(日) 19:51:17 ID:???.net

>>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：2006/01/16(月) 00:46:38 ID:???.net

初心者にありがちな考えすぎ

116 ：NAME IS NULL：2006/01/24(火) 10:05:52 ID:eUiSn8SR.net

すいませんが、教えてください。

とあるシステムを解析する事になったのですが、テーブルの設計で分からないところがあります。
内容は下記のようなテーブルで枝構造になっています。
部門テーブル
　部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：2006/01/24(火) 13:12:15 ID:???.net

>>116
歴史的経緯がいろいろありそうなテーブルですね。
課IDのところの説明を間違ってなければ、
課を複数の部に所属させることができるようにしようとした痕跡がありますね。
結局それは取りやめて部課連携テーブルは使ってない可能性が高いな。
（または課テーブルの部IDを使ってない可能性あり）
グループ＋部IDとグループIDでユニークで、課とグループはｎ：ｎの関係。
グループ連携テーブルはそのｎ：ｎの関係をあらわすためにある。

118 ：NAME IS NULL：2006/01/24(火) 14:32:17 ID:???.net

>>117
なるほど。どちらかというと熟考して出てきたテーブルではなく、過去からの成り行きでこのように
なっている感じなのですね。私が使うとき課とグループがn:nにはならないと思いますので、自分な
りにアレンジして再構築します。ありがとうございました。

119 ：NAME IS NULL：2006/01/24(火) 23:52:14 ID:???.net

おいおい、ちゃんとヒアリングしろよ・・・

120 ：NAME IS NULL：2006/03/06(月) 02:47:55 ID:???.net

正規化しないで作った事とかないんですが、どうしてもテーブル構成なんかを考えてる時間がないんです。
1テーブルでむりやり作っちゃうってのは実際のとこ「あり」ですかね？

121 ：NAME IS NULL：2006/03/06(月) 11:04:40 ID:???.net

>>120
あなたのその後の人生をそのシステムに捧げる覚悟があるならば「あり」かもしれない。

122 ：NAME IS NULL：2006/03/06(月) 23:05:20 ID:???.net

>>121
ないです。つか、保守とか以前にぽしゃる悪寒＞そのサイト

123 ：NAME IS NULL：2006/03/07(火) 00:48:26 ID:???.net

俺はありありだと思うなー。
とりあえずは動けば何でも良いよ

124 ：NAME IS NULL：2006/03/09(木) 23:59:15 ID:???.net

>>123
結局1テーブルで全部くんでしまった。
やたらとtextのフィールドが多い・・・
もうしらね。全部のフィールドを検索対象にしてやる。
やけくそでやれば終るもんだ。あとはcssまわりだけ。

125 ：NAME IS NULL：2006/03/10(金) 00:08:53 ID:???.net

>>124
自分でいいならいいんじゃね？

レコード数多くなければ全列の全走査でも
なんとかなるさｗ

126 ：124：2006/03/11(土) 01:53:53 ID:???.net

基本的なとこは組み上がったからUIまわりをajaxでかっこいくしてたら暗唱に乗り上げた。悔しいがヤメることにする。一日ロスしたorz

127 ：NAME IS NULL：2006/03/13(月) 00:18:21 ID:???.net

T字型ERって業務でやってる人居る？
ネットに全然情報ないし、本買わないといけないかな。

128 ：NAME IS NULL：2006/03/13(月) 23:00:16 ID:???.net

出向に行ったら表記法がT字型だったなあ。

表記法だけって感じだった・・・・おそまつだったなあ・・・。

129 ：NAME IS NULL：2006/03/14(火) 01:46:14 ID:???.net

なんか古臭い感じがするよね。

自分的には主キー、外部キー、カージナリティがちゃんと表現できれば必要十分。
ＥＲ図書くのは好きだけど、それだけじゃシステム動かないし
データモデリングに偏り過ぎてるのはなんだかねぇ・・・

130 ：NAME IS NULL：2006/03/18(土) 16:27:27 ID:B7S2rjh8.net

勉強中です。第二正規形と第三正規形を分ける理由が良く分かりません。
分かりやすく教えてください。

131 ：NAME IS NULL：2006/03/20(月) 10:08:38 ID:???.net

データベース理論的にはボイスコッド正規形との絡みとか色々あるから、
２と３を分けるのは必然だろうね

でも、実務上はそこまで意識しすることあまり無いね。
いつもなんとなく設計しちゃってる

132 ：NAME IS NULL：2006/03/20(月) 22:32:44 ID:???.net

俺もなんとなくやったら第3正規形になる。

133 ：NAME IS NULL：2006/03/22(水) 07:14:06 ID:???.net

漏れはなんとなくやると第6正規形になる。

134 ：NAME IS NULL：2006/03/22(水) 10:26:27 ID:???.net

オレもなんとなくやったら第百万光年正規形になる。

135 ：NAME IS NULL：2006/03/22(水) 19:26:57 ID:???.net

自分はなんとなくやったら正上位形になる。

136 ：NAME IS NULL：2006/03/29(水) 03:15:57 ID:???.net

>>130

遅レスなので下げる。
第2正規形から推移性関数従属を取り除いたら第3正規形になるよな。
じゃあ、推移性関数従属する非キー項目があるとと何が不味いんだ？
って考えてみな。

ま、結局、単純に言えば更新時にリレーションが消えたり、
データ多重持ちになったりと不整合が起こる可能性を増やしてしまうからだな。

137 ：NAME IS NULL：2006/03/29(水) 04:41:23 ID:???.net

>>136
レスありがとうございます。
ただ、私が知りたいのは、なぜ第三正規形にするか、ということではなく、
なぜ、第二正規形という形があるのかということです。
第一正規形から片っ端から関数従属を取り除くと第三正規形になると思うのですが、
その間に第二正規形を置いて第二と第三を区別する理由が良く分からんのです。

138 ：136：2006/03/29(水) 13:02:23 ID:mr4gMX+s.net

>>137
うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。

もしかして、第一正規形からスタートして第三正規形でゴール！
だから、第二正規形っていう中継点を通過する意味がわかんないよね、
一気にゴールでいいよね、とか思ってるのかな？

もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
あえて正規形を崩す場合もある。稀だと思うが。

で、名前をつけて区別するのは、それぞれの特徴を把握しておく事で、
上に述べた様な更新異常等の不都合に対抗する手を打っておく必要が
あるからだね。（もうこれは主にPGMでだけど）

ちなみに、余計な話だけどすべての関数従属をとりはずすと
ボイスコッドの正規形になるんじゃないかな？
第三正規形は候補キーの中の関数従属については容認してるはず。

間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。

139 ：136：2006/03/29(水) 13:07:11 ID:???.net

自己レスだけど、ちょいと言いたい事が足りてなかったかも。
３だとリレーションを保てない、２，１ならOK,なら１にすれば良くて、２の存在価値は
相変わらず不明、とか思われると遺憾かなと思って。

こうなるとやっぱり程度の問題で２の方が更新異常とかの面でまだベターだから、
せめてそこまでは正規化しましょうよ、という事になるのかも。
だから、やっぱり無駄ではないと思うんだけどな。

140 ：130：2006/03/30(木) 03:44:07 ID:???.net

度々レスありがとうございます。

>>138
> >>137
> うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。
> もしかして、第一正規形からスタートして第三正規形でゴール！
> だから、第二正規形っていう中継点を通過する意味がわかんないよね、
> 一気にゴールでいいよね、とか思ってるのかな？

正にそんな感じで思っていました。

> もちろん、設計上は第三正規形を目指して正規化しろとは言われるが、
> 各正規形にはそれぞれ特徴があって、例えば第二正規形でないと
> リレーションをすべて保持できない、とかそういうケースもある（時系列の保持だか、期間の管理だか）
> また実装時の動作速度を考えて（JOINより多重持ちの方が早いとか）で
> あえて正規形を崩す場合もある。稀だと思うが。

ここらへんの話を詳しく知りたいと思っています。
ヒントをもらったので調べてみます。

> ちなみに、余計な話だけどすべての関数従属をとりはずすと
> ボイスコッドの正規形になるんじゃないかな？
> 第三正規形は候補キーの中の関数従属については容認してるはず。
> 間違いがあったら、どなたか指摘、訂正してくださいませ。よろしく。

そうなんですか、勉強不足でした。調べてみます。

ありがとうございました。

141 ：NAME IS NULL：2006/03/31(金) 18:08:00 ID:???.net

>>140
テクニカルエンジニア DB の参考書とか読んでみるといいよ。
こういうDBの理論とかの専門書って少ないし高いし・・・

142 ：NAME IS NULL：2006/03/31(金) 23:46:12 ID:???.net

テクニカル DB 保持者ですが設計の経験がほとんどありません、逝ってきます。

143 ：NAME IS NULL：2006/03/32(土) 16:16:11 ID:45VqWbwv.net

テクデの勉強ってＤＢだけじゃなくて、業務知識のストックにも
なるところが実務向きでいいと思うんだよねー。
なんか、自分の周りではあんまり知られてない試験なんですが。

大規模システムとかやってると、色んな業務形態に触れる
ことが少ないと思うので、こういう試験を通して、自分の未経験分野の
業務知識をつけてくのって、試験受かる受からないに無関係で
重要だと思います。

144 ：NAME IS NULL：2006/04/02(日) 02:41:14 ID:???.net

そんなに大きな案件ではなくて、クライアントが言うことばかりでかくて、
たとえば、データは何十万件になるとか、そのくせ、仕様はなんにも決まってなくて時間がない、
その上、実際は1年もしないうちに放置状態になるのが目に見えてるような案件だったら、
DB設計なんかくそ真面目に考えてるより、冗長になっても1テーブルで済ませちゃうってやり方が
我が社ではスタンダードなんですが、これってとんでもないことなんでしょうか？

145 ：NAME IS NULL：2006/04/02(日) 12:28:17 ID:???.net

普通。
受託案件は自分がメンテするわけじゃないからなんでもありですよ。

146 ：NAME IS NULL：2006/04/02(日) 13:27:04 ID:???.net

>>144
それって逆に開発が鬱陶しくならんか？

147 ：144：2006/04/02(日) 19:07:03 ID:???.net

>>145
やりにげ、って感じですかね？
>>146
作り始めてからあれこれ口出されるのにいちいち対応するなら冗長でも1テーブルのほうが楽では？
変なとこで却下されたりすると、正規化してるのが足かせになってよけい面倒なことになってる希ガス

148 ：NAME IS NULL：2006/04/03(月) 13:32:44 ID:???.net

確かに正規化しすぎると変更に弱くなるね。
ってか、DB構造見ていじわるしてるのか、という変更ばかり発生する不思議。
うちではその辺、設計者の腕（技術＋業務知識）の見せ所なわけですが。

149 ：144：2006/04/03(月) 23:33:06 ID:???.net

>>148
そっちの方への拡張性を考慮して組んだりするとそのマスターまったく要らなくなったりとかw
なんで、足かせになるような仕様を要求しといて、それに対する対処がやっと済んだころに却下になるんだ？
もしかして、もうすごいスキルを持った嫌な奴なのかもしれん

150 ：白馬の玉子 ◆PqSzNbkqDo ：2006/04/12(水) 12:43:45 ID:???.net

スピードパフォーマンス重視

or

管理効率重視

この二極化しかないと思うんですが。

それぞれに応じて、正規化なんて、教科書どおりにやる必要、
取捨選択すればOKっすよ。

現場で仕事もしたことないOraMasの女とかが、
正規化を演説してたりするんだよなぁ・・・・頃したくなる・・・・。

151 ：NAME IS NULL：2006/04/12(水) 14:11:14 ID:???.net

s/頃し/犯し/

152 ：NAME IS NULL：2006/04/12(水) 23:12:50 ID:???.net

非正規化するのも、必ずしもパフォーマンスだけが目的ではないしね。
初心者の頃はマスター系とトランザクション系の区別さえつかんかったなぁ・・・

153 ：NAME IS NULL：2006/04/17(月) 14:10:43 ID:???.net

T/R系は目的上、正規化しちゃマズい場合もあるし

154 ：NAME IS NULL：2006/05/11(木) 00:57:58 ID:DgrOFV3I.net

誰か第５正規形を直観的に教えてください．．．

事例を示して、ほら第５正規形じゃないと異状が起きるでしょ？というのは良くあるけど
なんで異状が起きるのか構造的に理解できません。

出来れば結合従属性の概念も。
字面のままの定義は分かるけど、何がどう「従属」してるのかサッパリ。

155 ：NAME IS NULL：2006/05/11(木) 20:58:00 ID:???.net

>>154
絶妙のタイミングでこんな記事が・・・
http://www.atmarkit.co.jp/fdb/rensai/db_enginer03/db_enginer03_1.html

これ書いたのお前じゃないの？w

156 ：NAME IS NULL：2006/05/13(土) 01:44:22 ID:???.net

>>155
どうもありがと。なんとなく解かりました。
でもこれ、多値従属性の定義の説明が若干間違ってるねえ。

157 ：NAME IS NULL：2006/05/13(土) 02:33:10 ID:???.net

？ んー、やっぱ良く解かってないかも。

「すべての情報がそろわないと登録できない」という制約は
別に結合従属性だろうがなかろうが、
ぜんぶの属性がキーであるなら、どんな関係でも当てはまるよね？

何か問題をすり変えられた気分です。
ほかの解説でも、同じなのですが。

結合従属性を持つ関係は、
どういう冗長性があって／どうして情報無損失で分解可能なのか
．．．ってのがやっぱり解らんです。

158 ：NAME IS NULL：2006/05/31(水) 15:26:48 ID:???.net

正規化のことじゃなぃんだけんども

リレーションの設定って要るの？
たしかにキーや関係の確認のためにあれば便利だけど、
自分で設計してるもんだから、リレーションを絡めた処理は
ＶＢＡで素で組む。困ったことないんだよ。

みんなどう？

159 ：NAME IS NULL：2006/05/31(水) 21:56:00 ID:???.net

好み次第

160 ：NAME IS NULL：2006/06/01(木) 11:06:07 ID:???.net

ここで議論が。止まってるけど。

制約っていらなくね？
http://pc8.2ch.net/test/read.cgi/db/1087483786/l50

161 ：NAME IS NULL：2006/06/06(火) 19:09:59 ID:???.net

たしかに最初は律儀にリレーション設定してたけど、漏れも
クエリなんかでその都度繋げるし、参照整合性が邪魔になる時もあるし
同じマスターテーブル（一側ね）を複数繋げるときも邪魔。

設定しないほうが、他人が見たときＤＢの仕組みが分かれにくいから
いじられるの阻止するのにもいいし。

162 ：NAME IS NULL：2006/06/06(火) 22:11:39 ID:???.net

データインポートするときとかうざいよね＞リレーション
まぁ、インポート時は無視するオプションとかもDBによってはあるけど

163 ：NAME IS NULL：2006/06/20(火) 02:03:12 ID:???.net

あ〜〜〜！むずがゆい！

164 ：NAME IS NULL：2006/10/12(木) 13:35:14 ID:LD5ggMeq.net

平成の大合併で住所変更。顧客マスタの住所と住所マスタの住所の整合性がとれてない。。

正規化してねーと、こんなことになる。。今日中に終わるかな。。

165 ：NAME IS NULL：2006/10/22(日) 22:41:58 ID:???.net

運用部員がマニュアルで作業するときには制約はあったほうがいい。
制約を回避するINSERT、UPDATEを書けるようになれ

166 ：NAME IS NULL：2006/11/15(水) 13:27:54 ID:???.net

>155
アクセのレベルを疑うような記事だな。
BC正規化なんて、ひどい。つか、事例悪過ぎ。

ものすごい遅レスなんで下げる。

167 ：NAME IS NULL：2007/01/04(木) 15:07:35 ID:Sogkk2is.net

すみません質問させて下さい。

共通の商品マスタ（キーは商品コードのみ）をシステムで使用していて桁数や採番ルール等で新たに
商品コードを使いまわすというのは皆さん普通にやりますか？各サブシステムには過去のデータ
が残っていて当然使いまわす前の商品コードも保持されています。ただしDBでリレーションシップが
組まれている訳ではありません。採番ルールを変えて新たな商品コードを取る事も可能です。

過去データを参照するのであればマスタデータを削除、使い回しをする行為は厳禁だと思ってます。（←ここら辺が大きな勘違い？？？）

自分的には採番ルールを変えるのが妥当だと思うんですが。皆さんはどう思われますか？
何分あまり経験が無いもので一般的にはどうしているのかわかりません。
皆さんの意見を聞かせて下さい。宜しくお願い致します。

168 ：NAME IS NULL：2007/01/04(木) 20:18:53 ID:???.net

内容が漠然としすぎている気がするが、藻前が設計するんなら
藻前の好きにすればいいと思うが･･･。

つか、DBでリレーションされていないのに商品マスタがどーこーって話を
聞く時点で相当にアレな設計な印象をうけるのだが･･･。

169 ：NAME IS NULL：2007/01/04(木) 22:43:58 ID:???.net

物理設計でリレーションシップなしは普通。

それ以前に「リレーション」とかいってる>168の方が
ちょっとなんだかなあという気がするんだが。

コードを使いまわして全く別の商品に割り当てるなんて
信じられない世界だけど、お客さんがそうしたいってなら
しょうがないんじゃないの？お客さん都合を実現するのが
システムなんだから。

お客さん都合でどうなるかわからんコードをキーにするのが悪いよ。
やるとしたら、コードと有効期日FromとToかなんかを複合キーにするしか
ないんじゃないですかね。

170 ：167：2007/01/04(木) 23:32:40 ID:???.net

>>168
>>169
ご意見ありがとうございます。
しかし、システムを引き継いだ時点でそういった仕組みで稼動しており
どうにもならない状態だったもので・・・作り直すと結構莫大な工数となりますし。。。

>コードを使いまわして全く別の商品に割り当てるなんて
>信じられない世界だけど

自分が聞きたかったのはこの言葉かもしれません。
お客様もコードが重複する事の弊害も考えずに削除使いまわしを口のにされている模様ですので
コードの桁数を増やし100年位は重複せずにすむ採番ルールを採用する方向で進めて
いくべきだと思いました。

本当にありがとうございました。

171 ：NAME IS NULL：2007/01/05(金) 06:42:50 ID:???.net

＞物理設計でリレーションシップなしは普通

物理だろうが論理だろうがリレーションシップがないんなら
そりゃExcelやCSVやCOBOLerな印象があるな。

設計者の理想であるクソ長い商品コードを使うか？か
顧客の要望の通り、過去の番号と重複するけど短い商品コードを使うか？
ってのはそれぞれの事情があるからなぁ。

まあ単に顧客が最初のクソ設計になれてしまったんだろうが。

172 ：NAME IS NULL：2007/01/05(金) 07:25:49 ID:???.net

お客さんが既に使ってるコードにはデータベース的な厳密さはないが、
手作業上の必要や業務上のノウハウが詰まってることが多いから簡単にはなくせない。
多くの場合サロゲートキーモデルが有効であることが多く、
主キーはシステム側でユニークで長いのを振り、旧来のコードは属性として使用する。
例えば在庫などに張るシールなどでは後者を大きめに表示した上で両方のコードを印刷している。

173 ：NAME IS NULL：2007/01/05(金) 23:07:34 ID:???.net

>>171
まあまあ、COBOLerとか言う前に現実を見よう。
制約っていらなくね？スレでも議論になったくらい
参照整合制約ありなしは結構二分されてるよ。

あり派は実装を見れば設計の意図が判るって意見があった。
なし派は制約つけるとデータメンテが面倒になるからって意見があった。
特に開発段階でテストデータガンガン入れたりする場合とかだね。
どっちも気持ちは判る。

まあつけない派は現場の現実解って感じではあるなあ。
バッドノウハウというか。

174 ：NAME IS NULL：2007/01/05(金) 23:18:39 ID:???.net

>>173
いわんとする事はわかるが、だから>>171はCOBOLerと揶揄しているのだろう。
そして、必要最低限のテストもしない人種はCOBOLerに多いな。

職場にもよるが現代(?)のSQLやらJava寄りの人種は
テスト用のツールを用意＆作成したりして、テストのシナリオも
作って開発するけど、ExcelなVB厨やCOBOLerは
あんましそういう概念ないよな。ひたすら手で打鍵とか言うし。

現場の現実解と言えばそうなんだが、COBOLerはあんまし学習能力とか
向上心とかない連中の思想だと思う。

175 ：173：2007/01/06(土) 01:03:19 ID:???.net

うーむ、確かに現実解てのは耳障りがよくて
要するに向上心の欠如じゃないかといわれると
ぎゃふんだなあ。

まあ制約に関しては話題がずれちゃった感があるので
ぎゃふんってことでゆるして。

で、制約いらないスレはこっち。止まってるけど。
http://pc10.2ch.net/test/read.cgi/db/1087483786/l50

>171の、クソ設計にお客さんが慣れちゃって
見直しさせてくれないってのは、判るよー判る。
これも向上心の欠如っていやそうか。

176 ：NAME IS NULL：2007/01/13(土) 19:49:54 ID:xq5OSR3p.net

主キーが倍精度変数って別におかしくないですか？
主キーは文字変数であるのが望ましいと思っているのですが･･･

177 ：NAME IS NULL：2007/01/13(土) 20:27:34 ID:???.net

倍制度でも検索が遅くないならいいんじゃね？

ただ、そんな計算結果みたいなフィールドを主キーにする設計の方がおかしいと思うけど。

178 ：NAME IS NULL：2007/01/13(土) 20:35:58 ID:???.net

>>176
numberならアリかも知れんが、doubleみたいな近似値はありえん。

179 ：NAME IS NULL：2007/01/13(土) 20:41:39 ID:???.net

64bit整数やdecimal(number)系で桁数の多い場合の主キーで、
それを扱えない言語から利用する場合やむなく実数変数を宛がう事があり
この場合は困ることがある。

180 ：NAME IS NULL：2007/01/15(月) 00:11:04 ID:???.net

MSSQL の DATETIME を主キーのタプルに組みこんだらVBAがミリ秒の
分解能を扱えず逝きかけた当方が通りますよ。

181 ：NAME IS NULL：2007/09/25(火) 00:14:21 ID:Cvnl8sn8.net

SQLから誘導されてきました

ずいぶん初歩的な質問で悪いんですが合併律、分解律、擬推移律の成り立ちを証明したいんですが…
アームストロングの公理系で調べても成り立つとしか書いてないもので…
だれか証明のプロセスを説明していただけないでしょうか？

182 ：NAME IS NULL：2007/10/13(土) 09:57:23 ID:???.net

MySQLに natural join ってあったのな。
今頃知った俺ギザ間抜け

183 ：NAME IS NULL：2007/10/21(日) 01:04:39 ID:6GmbKqtg.net

初心者です、質問です。（他スレで聞いたらここで質問するよういわれました）
Mysqlでテーブル作ってて、フィールド数が90くらいになりそうです。それで問題ないのか知りたいです。
正規化する必要があるのかどうかを知りたいんです。

テーブルは、ライブの情報を扱うものです。なので登録情報は
開催日、開始時間、料金、イベント情報etcの基本情報と
出演者名、出演者のURL、演奏楽器etc　の出演者情報になります。
出演者はイベントごとに1〜10人に分かれて不安定なので正規化・分離するなら
この部分かなぁと思うんですが、、　
それともこの程度なら同じテーブルに入れてもいいのか、判断しかねてます

正規化（テーブルの分離）する場合、登録フローとしては、基本情報の登録時に
自動インクリメントでイベントIDを生成し、それを主キーとして参加者テーブルへの
参加者を登録することになるかと考えています。

正規化する必要あるでしょうか？　初心者の為判断しかねています。
登録ごとにテーブルに空欄があったりなかったりというのが
マズイような気がしてそれが気になります。　お暇な方、回答お願いします。

184 ：NAME IS NULL：2007/10/21(日) 06:18:18 ID:???.net

今はイベントテーブルに出演者やそれに付随するフィールドが
それぞれ10個ずつあるような作りになってるの？

まぁ、分けるとしたら。

イベント(id, 開始時間、料金etc)→出演(イベントid, 出演者id)→出演者(id, 出演社名、URL、吹奏楽器etc)

って感じで新たにテーブル2つ作るような感じかな。

フィールドが90個っての自体はギリギリ許容範囲かなという気もするけど、
同じ出演者が当然何回も出てくると思うんで、
出演者情報はテーブル分けて、別に管理すべきだろうね。
それでかなりシンプルに成りそうだし

185 ：183：2007/10/21(日) 12:48:09 ID:???.net

詳しい説明ありがとうございます。ホントに助かります。
アドバイスいただいた中で、出演者情報（名前とURLと楽器、プロフ文etc）にあたる部分は
実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
必ずしも登録してるものと一致するとは限らない可能性もあるので、
イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。
さらに言うと、出演者テーブルへの登録件数（演奏家の人数）が少ないうちは、
プレイヤIDをイベントテーブルに登録するというプロセス自体が機能しないのではという
危惧もあり、無駄にフィールド数が増えてるんです。

1)一覧から参照する（出演者テーブルをリスト表示後、各プレイヤ参照ボタン押す）→IDを入力
2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
みたいな感じで。
なので、１イベントあたり最大10人てのを全部登録したとしても、プレイヤ用フィールドのうち
半分（リスト参照して入力用or手動入力のいずれか）のフィールドは必然的に空欄になるんです
これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
仕方ないよですむならこのままやっちゃおうと思うんですが　　どうなんでしょう？
プロじゃないんで経験則が働きません…

186 ：NAME IS NULL：2007/10/21(日) 13:52:49 ID:???.net

ユーザーインターフェースとテーブルは別だぞ。

187 ：NAME IS NULL：2007/10/21(日) 14:21:27 ID:???.net

> 実は別に用意してるんですが、イベント登録するにあたって、当日演奏する楽器が
> 必ずしも登録してるものと一致するとは限らない可能性もあるので、
> イベントテーブルに（名前、楽器、URLを）ガッチャンコしてるんです。

イベントごとに楽器が違うということであれば、
楽器は中間テーブルに持てばよいね。
>>184でいくと

出演(イベントid, 出演者id, 楽器)

という感じ。

> 2) 1)が出来ない場合（お目当ての出演者がリストに未登録の時）は名前・URLを直接入力してください
> みたいな感じで。

必ずしも全ての出演者が登録される必要は無いってことだね。
それなら上の中間テーブルで

出演(イベントid, 出演者id, 楽器、名前、URL)

みたいにしたらいいかもね。
出演者idは空白可で。

> これがムダでヘタクソなやり方なのか、それとも仕方ないと判断していいものなのか…
> 仕方ないよですむならこのままやっちゃおうと思うんですが　　どうなんでしょう？

無駄でヘタクソなやり方だとは思うけど、
サイズ的に管理しきれないほどでもないから、
今のままでもいいんじゃないかという気はする

188 ：183：2007/10/21(日) 14:50:38 ID:???.net

>>187
なるほど、凄く勉強になりました
イベント基本情報テーブルと、中間テーブルに分ける場合は、
インターフェース的には　基本情報の登録→そのイベントIDを拾って→出演者登録
って流れにすればいいんでしょうか？　出来れば10人以上にも対応したいんで、
ソッチのやり方で理解した方がいいですよねぇ

>>186
＞ユーザーインターフェースとテーブルは別だぞ。
おっしゃるとおり、その部分の理解が薄いんです。
いろいろ勉強してみます。ありがとうございました。

189 ：NAME IS NULL：2007/10/21(日) 15:56:26 ID:???.net

> インターフェース的には　基本情報の登録→そのイベントIDを拾って→出演者登録

それでいいと思う

190 ：183：2007/10/21(日) 18:18:38 ID:6GmbKqtg.net

わかりました、どうもありがとうございました。

191 ：NAME IS NULL：2007/10/26(金) 11:24:48 ID:???.net

許可マスタ

項目名　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：2007/10/27(土) 09:58:27 ID:???.net

lol

193 ：NAME IS NULL：2007/11/01(木) 01:20:19 ID:zMKsxNgF.net

こんなスレもある。
http://pc11.2ch.net/test/read.cgi/prog/1179927770/

194 ：NAME IS NULL：2007/11/12(月) 21:07:31 ID:???.net

会社コードと会社名だけのテーブルに正規化する価値ってあるかな？
JOINのコストが恐ろしく無駄な気がするんだけど。

195 ：NAME IS NULL：2007/11/12(月) 21:36:34 ID:???.net

>>194
「カイシャメイ」 も追加しろ。

196 ：NAME IS NULL：2007/11/12(月) 21:39:15 ID:???.net

そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな？

197 ：NAME IS NULL：2007/11/13(火) 11:47:27 ID:???.net

>>194
会社なら(>>195のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。

つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。

198 ：FEQoQDjgtx：2007/11/14(水) 04:53:31 ID:???.net

gBMpor <a href="http://sflntwpuclbo.com/">sflntwpuclbo</a>, [url=http://vtoysuqfixvo.com/]vtoysuqfixvo[/url], [link=http://iarrmvwkbpot.com/]iarrmvwkbpot[/link], http://poyhgemjrdue.com/

199 ：NAME IS NULL：2007/11/17(土) 22:12:21 ID:???.net

>>194
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。

200 ：NAME IS NULL：2007/11/18(日) 08:52:47 ID:???.net

>>199
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。

でも正規化自体は賛成。

201 ：NAME IS NULL：2007/11/18(日) 09:52:01 ID:???.net

取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。

202 ：NAME IS NULL：2007/11/20(火) 02:00:19 ID:???.net

いや、それも本とかでは正規化（というか非正規化）の文脈で語られてるよ

203 ：NAME IS NULL：2007/11/20(火) 14:01:50 ID:???.net

社名の変更ならその程度で済むかもしれんが、合併とかどうするよ

204 ：NAME IS NULL：2007/11/20(火) 17:12:39 ID:???.net

合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。

ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。

205 ：あぼーん：あぼーん.net

あぼーん

206 ：NAME IS NULL：2007/11/20(火) 22:25:34 ID:???.net

社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい

207 ：NOMO ESTAS NENIO：2007/11/22(木) 07:49:11 ID:???.net

>194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
　社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。

(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。

(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。

208 ：NAME IS NULL：2007/11/22(木) 08:26:10 ID:???.net

(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。


２回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか？

209 ：NAME IS NULL：2007/11/22(木) 12:59:43 ID:???.net

207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん

ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ

210 ：NAME IS NULL：2007/11/22(木) 20:09:17 ID:???.net

吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな？

211 ：あぼーん：あぼーん.net

あぼーん

212 ：NAME IS NULL：2007/11/23(金) 23:15:27 ID:???.net

>>207
（スレタイ）「頼むから正規化しろよ　第二正規形」

おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。

ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名]（*が主キー）

>>209
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。

213 ：NAME IS NULL：2007/11/23(金) 23:19:50 ID:???.net

212の続き

もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。

214 ：NOMO ESTAS NENIO：2007/11/24(土) 03:30:10 ID:???.net

>212
　取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
　たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。

215 ：NAME IS NULL：2007/11/28(水) 01:35:19 ID:???.net

>>214
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、１事実１箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。

商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。

よろしく

216 ：NAME IS NULL：2008/04/04(金) 08:17:59 ID:???.net

依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で

店舗ID　店舗名　質問1　質問2のA　質問2のB　質問2のA　質問2のB・・・
--------------------------------------------------------------------

ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。

一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。

217 ：NAME IS NULL：2008/04/04(金) 20:25:32 ID:???.net

> 一緒に仕事したことないが、開発やってる時は多分できてることを

どういうこと？
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが

218 ：NAME IS NULL：2008/04/04(金) 22:06:03 ID:???.net

先輩は勉強しはじめたばかりだから、
そんな仕事はしてない

219 ：NAME IS NULL：2008/04/05(土) 08:22:30 ID:???.net

統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。

220 ：NAME IS NULL：2008/04/14(月) 13:44:48 ID:???.net

JOINのコストって高いね。

正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。

検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。

221 ：NAME IS NULL：2009/04/11(土) 21:06:53 ID:???.net

>>220
釣れますか？

222 ：NAME IS NULL：2009/06/10(水) 17:33:31 ID:???.net

>>220
クラウド革命でITエンジニアは監獄行きです
ttp://d.hatena.ne.jp/kazunori_279/20090610/1244599829

Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う？
ttp://www.atmarkit.co.jp/news/200906/09/gae.html

223 ：NAME IS NULL：2009/06/22(月) 22:31:06 ID:???.net

正規化について質問です

第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば

ＩＤ｜購入者｜商品１｜金額１｜商品２｜金額２｜商品３｜金額３｜商品４｜金額４
01｜ＡＡＡ.....｜ＴＶ１....｜10万...｜ＴＶ２....｜11万....｜ＴＶ３...｜12万....｜ＴＶ４....｜13万...

このような場合は

ＩＤ｜購入者
01｜ＡＡＡ
......と
ＩＤ｜商品｜金額
01｜ＴＶ１｜10万
01｜ＴＶ２｜11万
01｜ＴＶ３｜12万
01｜ＴＶ４｜13万

と２つに分けるかと思いますが

ＩＤ｜購入者｜販売担当者｜購入日｜配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか？

224 ：NAME IS NULL：2009/06/22(月) 22:46:59 ID:Ii7lYaDv.net

>>223
それって違うんでねーの？
たぶん

225 ：NAME IS NULL：2009/06/22(月) 23:11:29 ID:???.net

>>223
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。

226 ：NAME IS NULL：2009/06/23(火) 07:20:42 ID:???.net

通常は繰り返しとはみなさない。
あなたの言うとおりなら、

ID、人種類、人ID、日付種類、日付

みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。

227 ：NAME IS NULL：2009/06/24(水) 21:28:15 ID:FsaDUw2R.net

>>226
ありがとうございます
そうですよね

何かこれに関する情報がのっているサイトとかご存知でないですか？
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど

228 ：NAME IS NULL：2009/06/25(木) 18:47:46 ID:???.net

簡単なデータで例を作ってみたら？
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ（その人は
それを言っているのかもしれない）。

229 ：NAME IS NULL：2009/06/25(木) 19:55:02 ID:uVxmIhxY.net

>>228
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました

具体的な例で話し合うのは重要かもしれませんね

230 ：NAME IS NULL：2009/06/25(木) 22:24:51 ID:???.net

よかたねー

231 ：NAME IS NULL：2009/06/27(土) 04:19:07 ID:???.net

　(・∀・)　白くなっとるﾜﾛﾀｗｗｗｗ


●● 　　http://wakuwaku.docomo.han-be.com/4522154.jpg
●● 　　http://wakuwaku.docomo.han-be.com/55426555.gif

232 ：NAME IS NULL：2009/09/21(月) 18:26:25 ID:4bCDESCP.net

同じ表にmember_idとmember_nameの二つの列があって、
member_id　　・・・社内の人間なら社員コード。社外の人はNULL
member_name　・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね？
社員コードは別の社員表にある。

233 ：NAME IS NULL：2009/09/21(月) 20:51:56 ID:???.net

社員表(社員コード,社員名)
社外表（コード,名前）

メンバー表(メンバー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：2009/12/24(木) 17:18:39 ID:ao0/KMLR.net

>>215
＞正規化について言及すると、それは正規形を崩してるだろ。
＞正規化手法は、”既約でない”関数従属を排除する為の射影である
＞必要があり・・・
＞　　　：
＞要するに、１事実１箇所になってないと正規形とは言えないってこと。
＞だから、スナップショットは正規化違反ということさ。

超遅レスだが、>>214の見解は的確で合理的じゃね？

販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。

そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。　だから、>>214は優良な実務経験者だと思うぞ。

ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。

235 ：NAME IS NULL：2009/12/26(土) 01:44:47 ID:dn/wTtyt.net

ニコニコ動画のコメントやアマゾンのレビュー、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：2009/12/26(土) 02:51:10 ID:rKp6qWLp.net

>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。

↓こんな風に持たせればそれらしくなるんじゃない？

237 ：NAME IS NULL：2009/12/26(土) 02:51:56 ID:rKp6qWLp.net

【投稿動画テーブル】
　動画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：2009/12/26(土) 02:52:50 ID:???.net

そもそもRDBかどうかも疑うべきだと思うけど。

239 ：NAME IS NULL：2009/12/26(土) 03:21:23 ID:dn/wTtyt.net

>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。

240 ：NAME IS NULL：2009/12/26(土) 04:06:02 ID:???.net

>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。

あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。

241 ：NAME IS NULL：2009/12/26(土) 19:20:41 ID:???.net

>>238
ニコニコはMYSQLだと聞いてる。

242 ：NAME IS NULL：2009/12/26(土) 22:13:20 ID:???.net

>>238
現実的に考えて、RDB以外にないだろ。

243 ：NAME IS NULL：2009/12/27(日) 00:06:26 ID:???.net

多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。

役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。

244 ：NAME IS NULL：2010/01/20(水) 21:17:11 ID:X+55Zxtj.net

>>242
動画番号に対して固定長（古いコメントは消えるので）のコメント領域を返すkey-valueじゃだめ？

245 ：NAME IS NULL：2010/01/21(木) 08:45:08 ID:???.net

>>244
現時点のいろんな意味で、その実装に
もっとも適しているのがRDBだろ。

246 ：NAME IS NULL：2010/01/21(木) 18:56:38 ID:???.net

>>245
non-Relationalなkey-valueで済むなら、そのほうがスケーラビリティとかパフォーマンスで有利では。

247 ：NAME IS NULL：2010/01/21(木) 20:03:46 ID:???.net

それだと重くならないかとか・・・、固定長の領域を返せばとか・・・って、ちょっと違うんじゃね？

なぜ動画投稿コミュニティサイトのような規模のシステム全体を、同じCPUとメモリの配下で
動作する単一のプログラムやプロセスとして考えるんだよ。スレ的にも当然RDBMSを使い、
サブシステムごとに分散処理だろｗ

248 ：NAME IS NULL：2010/01/22(金) 04:17:32 ID:???.net

結構昔だけどYouTubeなんかはBigTable使い始めたってどっかで読んだ。

249 ：NAME IS NULL：2010/01/22(金) 15:53:53 ID:???.net

>>247
>同じCPUとメモリの配下で動作する単一のプログラムやプロセスとして考える
何のことを言ってるのかちょっと分かんないです><

250 ：NAME IS NULL：2010/04/09(金) 23:50:09 ID:???.net

4月1日からDBの仕事するようになって1週間だが、早くもタイトル通りの叫び声あげたくなった。
これが現場のDBって奴なのか……

251 ：NAME IS NULL：2010/04/14(水) 18:37:37 ID:???.net

既存なら泣く
設計中なら正規化を押し通せ

252 ：NAME IS NULL：2010/04/15(木) 05:02:26 ID:???.net

設計は完全に終ってる。
既にシステムの一部は稼働していて、リリースまでに間に合わなかった機能を実装している段階だ。

253 ：NAME IS NULL：2010/04/23(金) 15:29:57 ID:???.net

自分の視野が世界の全て病

254 ：NAME IS NULL：2010/07/07(水) 22:36:04 ID:/39YW+Cp.net

正規化について勉強を始めたのですが
一人の人に複数の趣味のフィールドを持たせたい場合は
どうするべきでしょうか
shumi1,shumi2のようなカラムを作るのは非正規と理解しています。
趣味のテーブルを分けて、shumi_idという外部キーでやるとした場合

name shumi
kiteretu 1
kiteretu 2

の様に重複するフィールドが出てくるので正規化はされていない
と思っています。どうすればよいのか教えてください。

255 ：NAME IS NULL：2010/07/07(水) 23:10:47 ID:???.net

第4正規形になるね。
正規形を崩すかBCNFにしてFKで整合性を取るかじゃないかな

256 ：NAME IS NULL：2010/07/08(木) 12:20:56 ID:???.net

>>254
普通に第二正規形ではない。例えばリレーションpersonが以下の
ようであるとして、

person(person_id, name, gender, shumi_id)

で仮に一人の人が複数の趣味を持つとすると、このリレーション
の候補キーは(person_id, shumi_id)になる。
でもnameやgender(性別)といった非キー属性はperson_idにだけ
関係従属する。

person_id -> name
person_id -> gender

テーブルの候補キーに完全関数従属していないので非第二正規形。
これを第二正規形にするには、部分従属する非キー属性nameと
genderを別のリレーションに分ける。

person(person_id, shumi_id)　候補キーperson_id, shumi_id
person2(person_id, name, gender)　候補キーperson_id

まぁ実際は後者のリレーション名をpersonにして前者は
person_shumiとかにすると思うけれどもね。

257 ：NAME IS NULL：2010/07/08(木) 21:10:32 ID:???.net

>>255
>>256
ありがとうございます。
なんとか理解できそうなので、続けてサンプルを見まくります。

258 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/09/03(金) 17:24:39 ID:zlBbPnBj.net

web土方でSQLもろくに使えねえし設定もできねえし
正規化もろくにできてねえし
お前ばかなの？しぬの？
っていったら

得意気に黒い画面だして　ポストグレ起動して手動でinsertやりまくって追加してた

脳味噌がかわいそうだった

かわいそすぎて泣いた

259 ：NAME IS NULL：2010/09/14(火) 03:05:12 ID:???.net

>>258
何を言っているのかよくわかりません。
あなたもかわいそうな人に見えます。

260 ：NAME IS NULL：2010/10/28(木) 15:47:02 ID:???.net

5年くらい昔であろうか？
有名なSlerが受注した外資系企業のシステムで開発者を200人以上集めた。
Oracleのバージョンは忘れた。

既にメンバーからはずれた人が設計したという500列だったかの
ワークテーブルなるのものがあって、正規化した各テーブルから
データをかき集めてワークテーブルでまとめて更新。

新たに参加したメンバーは必ずこの仕様ではプログラムは書けない、
ワークテーブルも削ろう、と進言したが、現テーブル設計担当は
ぐずぐずしているだけでまったく動かず。

動的SQLを多用しないとプログラムを書けず、当然プログラム・バグが
多発。残業・徹夜してもバグの原因がなかなかわからず。

結局、社長命令でシステム開発は中止。
改めて開発予算を確保してテーブル設計からやり直すことに。

得るものは何もない、むなしい仕事だった。
テーブル設計担当を大雪山に生き埋めにしてやりたかった。

正規化は大切だぞ。

261 ：NAME IS NULL：2010/10/28(木) 23:36:12 ID:???.net

>>260
ああ、解るわー。

その500列を作った技術者は、コボラーじゃないか？
あと列の名前も意味の無いコードで定義されていたりした？

コボラーにテーブル設計をやらせては駄目だよな。

262 ：NAME IS NULL：2010/10/29(金) 02:16:04 ID:???.net

物理名は英字＋数字の連番な

263 ：NAME IS NULL：2010/11/09(火) 02:22:59 ID:???.net

アラフォーCガリガリプログラマなんだけど、担当者が逃げたASP.NETのシステムを
見ることになってそのままDBの勉強始めたんだけど、DBってこんなに面白かったんだね
正規化とか考えてると楽しい
DBの講習会とか「興味ない」とサボってたのを後悔した

ただSQLはつまらんね
なんでこう、表示、更新、追加でこんなに文法違うんだよ
考えたやつ、頭おかしいだろ

264 ：NAME IS NULL：2010/11/09(火) 02:28:31 ID:???.net

COBOL文化の人って、CHAR型好きだよね。
枝番 … EDA CHAR(2) とか。

あと制約付けるのが嫌いで、FETCHが好き。

265 ：Perl忍者 ◆M5ZWRnXOj6 ：2010/11/12(金) 17:39:54 ID:LqoipeIo.net

正規化してないバカが作ったやつのWEBアプリが
すべてそのままデータぶち込んでてプライマリーすらわかってねーみたいで
頭おわってんなっておもったわ

SQLも理解できないカスグラマも世の中たくさんいるしな
WEBバカはかすばっかりだよ
とくに3キモ言語使ってるやつらな

266 ：NAME IS NULL：2010/11/13(土) 08:35:08 ID:???.net

一方で、DWH見て「ぜんぜん正規化とか理解してない、これ設計したのコボラだろwww」
みたいなこと言う奴もいたりするけどな。

267 ：NAME IS NULL：2010/11/13(土) 18:03:03 ID:???.net

>>266
オレの事か？

本気でコボラーにはテーブル設計して貰いたくないと感じてる。

268 ：NAME IS NULL：2010/11/13(土) 18:43:10 ID:WUzshbar.net

>>267
何もわかってないw

269 ：NAME IS NULL：2010/11/13(土) 21:52:14 ID:???.net

「コボラー」よりRDBをわかっているというのが唯一の自慢な人は所詮そんなもんw

270 ：NAME IS NULL：2010/11/13(土) 23:05:36 ID:???.net

DWHってなんぞやと検索したら納得

>>267
何もわかってないｗｗ

271 ：NAME IS NULL：2010/11/14(日) 23:37:21 ID:???.net

いやいやいや！
DWHは、正規化が完了してから正規化崩しを行っていくんだろ。

コボラーの奴は、正規化が不完全な状態から正規化崩しを行うからｇｄｇｄなテーブル設計になるんだって。

272 ：NAME IS NULL：2010/11/15(月) 00:29:36 ID:???.net

もっと流れよめ

273 ：NAME IS NULL：2010/11/15(月) 02:12:21 ID:???.net

頭が悪いのに付ける薬はないってことだ

274 ：NAME IS NULL：2010/11/15(月) 08:06:17 ID:???.net

>>271
マジレスすると、DWHではそのような方法はとらない。
そもそも正規化というのが更新異常を防ぎデータの一貫性を保つための考え方である以上、
個々に更新を行わず、ETLであらかじめ一貫性を整えたデータを一括してロードするDWHには
必要のないもの。

275 ：NAME IS NULL：2010/12/12(日) 00:35:52 ID:???.net

性器化の意義：項目間の相関性を極小にし記憶効率を改善する。性器化のしすぎは
多くの場合検索性を損ね、時には信頼性も下げる場合がある。

非性器化の意義：項目間の従属性を許可する。記憶効率は下がるが、多くの場合に
検索性が向上し、時には信頼性が向上する場合がある。

276 ：NAME IS NULL：2010/12/16(木) 19:18:29 ID:???.net

>>275
アホちゃう？

277 ：NAME IS NULL：2011/03/01(火) 14:42:43.26 ID:???.net

パーでんねん

278 ：NAME IS NULL：2011/08/09(火) 17:16:40.70 ID:???.net

第一正規化まで終わってる、つまり１枚の大きなテーブル（4Gくらい）があるんですが、自動でその後の正規化をやってくれるソフトってないですか？
知っている人がいたら教えて下さい。

279 ：NAME IS NULL：2011/09/02(金) 19:31:02.37 ID:XFcjaMI+.net

検索用にタグ機能を作りたいんですけど
どんなテーブル構造にするのが一般的ですか？

｜　記事ID　｜　タグ　｜
で記事IDを重複キーにするか

｜　記事ID　｜　タグ１　｜　タグ２　｜　タグ３　｜　・・・　｜
で記事IDをユニークキーにするか

タグの上限は未定です

280 ：NAME IS NULL：2011/09/08(木) 18:42:15.74 ID:???.net

>>279
要件次第だが

｜　記事ID　｜　タグ　｜

で記事IDとタグを主キーにするかな

281 ：NAME IS NULL：2011/09/10(土) 19:46:26.54 ID:???.net

>>279
> ｜　記事ID　｜　タグ１　｜　タグ２　｜　タグ３　｜　・・・　｜
> で記事IDをユニークキーにするか
おいおい第一正規形にすらなってないぞ

282 ：NAME IS NULL：2012/08/09(木) 02:11:16.27 ID:57EvxVv2.net

保守age

283 ：NAME IS NULL：2012/10/30(火) 13:13:15.70 ID:g6duZ5Cb.net

保守

284 ：NAME IS NULL：2014/04/28(月) 11:28:23.67 ID:???.net

テーブル設計（正規化）のアドバイスをお願いします。
メインテーブルがあり、フィールド数は全部で70程です。
主キーに対して従属はない状態（第二正規化）なのですが、
レコードが同じ内容で繰り返される各フィールドをテーブルに切り出す（第三正規化？）と35もマスタテーブルが出来てしまったのですが、
このテーブルとトランザクションテーブルをリレーションシップしてからクエリで全てのフィールドを再度結合する場合、
結合線もすごい数になってしまいますが、このような状態（数）は正規化出来ていないことになるのでしょうか？
各マスタテーブルは主キーとフィールドが一つのものばかりです。

285 ：NAME IS NULL：2015/04/21(火) 21:23:14.43 ID:pQzWEcgh.net

☆ 日本の核武装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html

☆ 日本国民の皆様方、2016年7月の『第２４回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆

286 ：NAME IS NULL：2015/05/11(月) 22:46:52.65 ID:???.net

>>284
まず主キーはサロゲートキー？それともナチュラルキー？
後からサロゲートキー適当に足して主キーとか言ってないよね？

287 ：NAME IS NULL：2017/04/20(木) 13:52:29.39 ID:???.net

保守

288 ：NAME IS NULL：2017/05/15(月) 15:03:35.69 ID:???.net

日本トップクラスの企業の次期案件下請けしてるけどテーブル定義マジでゴミ
コミュ力ある奴ばかりで技術力ある奴がマネージャークラスに居ないんだろうな
日本終わってるわ

289 ：NAME IS NULL：2017/11/23(木) 09:48:07.38 ID:???.net

necや富士通など大手メーカー系sierの業務系案件でまともな設計のプロジェクトなんて存在するの？？？

290 ：NAME IS NULL：2017/12/29(金) 11:59:02.29 ID:dtNZwIie.net

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

N46QAZV1AG

291 ：NAME IS NULL：2023/02/03(金) 15:21:39.24 ID:???.net

(´・∀・｀ )ｱﾗﾏｧ

292 ：NAME IS NULL：2023/03/14(火) 13:11:10.87 ID:ci3DM14kK

ミサイ儿云々た゛のワクチン云々た゛のクソ自民公明の白々しい税金泥棒っぷりに反吐が出るよな
私利私欲のために━部の賄賂癒着業者と税金泥棒して騷音に温室効果カ゛スにコ口ナにとまき散らして海水温上昇させて
かつてない量の水蒸気発生させて．曰本と゛ころか世界中で土砂崩れに洪水、暴風、大雪，猛暑，干は゛つ，森林火災にと災害連發
ワクチン打ったハ゛カのほうか゛ウイルス拡散率が高い統計すらアーア―聞こえないやって国民を殺害する氣満々て゛入国緩和に全国地球破壞支援
防衛という名目て゛増税して使途不明金着服して私腹を肥やす目的て゛，曰本に原爆落とした世界最惡のならず者国家とともに
軍事演習だなんだと北朝鮮挑発して，地球の外を飛ふ゛ミサイルを上空だのと表現した挙句に鉄道まて゛止めて
『ミサヰル迷惑た゛な」た゛のとハ゛力丸出しのインタヒ゛ュ─まて゛報道するキチガイ洗腦國家
こんな茶番を平氣て゛やってる世界最悪の腐敗テ□組織自民公明にいまた゛に政権やらせてるΝРСふ゜りに北朝鮮人民まて゛ヒ゛ックリた゛ろ

創価学會員は，何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まで出てる世界最悪の殺人腐敗組織公明党を
池田センセーが口をきけて容認するとか本氣て゛思ってるとしたら侮辱にもほどがあるぞ！
https://i.imgur.com/hnli1ga.jpeg

293 ：NAME IS NULL：2023/04/28(金) 21:26:08.51 ID:YV86GVgUk

世代による公平も憲法の下の平等も知らない．しつこい不公平促進ハ゛力税金泥棒立憲って．もはや莫大な税金で開いてる国會にヰラネ−だろ
何か゛子供給付財源カ゛‐だ，資本家階級ヰオン岡田か゛私腹を肥やすために未来の家畜か゛ほしいだけなんた゛ら岡田から徴収した金て゛やれや寄生蟲
日銀に金刷らせて株買わせて圧倒的格差と優越的地位の濫用社会にしておいて価格転嫁カ゛‐とか．何ひとつ価値生産しない公務員だの大企業
従業員た゛の税金泥棒に莫大な金銭給付してるしわ寄せが中小零細にゆくのは当然た゛ろうに，外形課税て゛もして大企業を全滅させるのか゛筋だろ
クソ航空機によって勉強妨害技術後進国気候変動災害連發物価暴騰してる中，食料自給率ガーとか人□減少させて緩和させるしかないものを
ー部の貧乏人の孑をネタに騷いだり氷河期に謝れた゛のほさ゛いて金銭強奪の布石を打ってみたり，社会全体で子育てなら赤の他人から金銭強奪
して社会分断引き起こして犯罪惹起するのて゛はなく，てめえの意思て゛産み落としておいて孑育て罸た゛のほざいてる虐待系クズを豚箱に入れて
親権も児童手当も廃止して．余裕ある家にあちこち寝泊まり飲み食い好きなもの買ってもらう斡旋をすることか゛理にかなった解決方法だろ

創価学会員は．何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まで出てる世界最惡の殺人腐敗組織公明党を
池田センセ一が□をきけて容認するとか本気で思ってるとしたら侮辱にもほと゛があるそ゛！
ｈΤтРｓ：／／ｉ，ｉｍｇｕｒ，сοｍ／hnli1ga.jpeg

294 ：NAME IS NULL：2023/08/26(土) 04:31:09.15 ID:gOkxdsuj5

男のクセに歌とか歌う時点で身の毛がよた゛つほどキモチワルイものを枕営業がどうたら耳を疑うな、炎上商法だろうけど．遠い国の争い同様
どうでもいい話だが、国連のショタコン担当が人権か゛と゛うたらノコノコ地球破壊しながら介入しにきて，そんなことだから国連はクソの役にも
立たない何ひとつ価値生産て゛きない税金泥棒集団だと言われんだろ、家でオ├ナしくしている者の生活と゛ころか地球まて゛破壊しながら人を殺し
まくって私腹を肥やしてるテ囗リス├放置しておいて．わざわざ出向いて何か巻き込まれてるハ゛カの人権ガーとか救いようがないな、力による
一方的な現状変更によって大量破壊兵器であるクソ航空機倍増させて閑静な住宅地から都心まで騷音まみれにして静音が生命線の知的産業壞滅
させて子供の学習環境破壞して、鉄道の3０倍以上もの莫大な温室効果ガスまき散らして気侯変動させて海水温上昇させて，かつてない量の
水蒸気を日本列島に供給させて土砂崩れ、洪水、暴風、突風、灼熱地獄にと住民の生命と財産を徹底的に破壊して世界最惡の脱炭素拒否のテロ
国家に送られる化石賞連続受賞にバカ丸出しプ囗パガンダ放送で国民を洗腦し続けるテロ政府にABCD包囲網のような制裁を科すのが先だろ
［羽田)ttps://www.call4.jp/info.рhР?typе=items&id=I０000062 , ttps://haneda-project.jimdofree.com/
(成田)тtps://n-souonhigaisosyoudan.amеbaownd.com／
(テロ組織］ttps:/／i.imgur.com/hnli1ga.jpeg

295 ：NAME IS NULL：2023/09/26(火) 19:06:54.01 ID:???.net

関わりのないことだ

296 ：NAME IS NULL：2023/09/29(金) 00:10:13.25 ID:???.net

なんかさ、人生って意味不明だな。

297 ：NAME IS NULL：2023/10/28(土) 09:41:12.21 ID:C6amQB/fK

お前らから強奪した血税30億以上→アジア開発銀行気候変動対策費→世界最悪の殺人組織公明党強盗殺人の首魁斉藤鉄夫ら國土破壊省と癒着
して力による―方的な現状変更によって都心まて゛数珠つなぎでクソ航空機飛は゛して莫大な温室効果カ゛スまき散らして気候変動させて土砂崩れに
洪水、暴風、熱中症にと災害連発させて大勢殺害して住民の私権侵害して知的産業に威力業務妨害して私腹を肥やす史上最悪の強盗殺人テロを
繰り返す前代未聞の地球破壊テロリス├クソ航空関係者ウハウハ→民主主義とは力によって勝ち取るものだという世界の常識すら知らない
お前らひたすら奪われ無駄に燃やされた石油で物価まで暴騰、コロナまき散らされて死亡、白々しくマッチポンプテ囗リストが運んた゛
ウイルスと称する毒物打って死亡、後遺症て゛も苦しみまくっていなか゛らいまだに立ち上がらないとか北朝鮮人民までドン引きた゛ぞ
私利私欲のためた゛けに存在している税金泥棒クソ公務員は撲滅すべき国民の敵だという正しい理解と行動をしよう!
(羽田)ttps://www.call4.jp/info.php?tyРe=items&id＝I000０062 , ttps://haneda-ｐrojecｔ.jimdofree.Com／
(成田)Τtps://n-souonhigaisosУoudan.amebaownd.com／
(テロ組織)tｔps://i.imgur.com／hnli1ga.jpeg

298 ：NAME IS NULL：2023/10/28(土) 15:07:57.56 ID:0rbfA8ZWd

リスキリング(笑)とかほざいて税金泥棒どもか゛新たな利権のネタ披露しまくっててハ゛力丸出した゛よな
曰本中航空騷音まみれにして私権侵害して勉強妨害してアプリのひとつも作れないカ゛ヰシ゛た゛らけにして
知的産業に威カ業務妨害して壊滅させたてめえら何ひとつ価値生産て゛きない地球に湧いた害虫の税金泥棒こそ小学生からやり直せや
小学生以下の無能公務員どもが利権拡大させて私腹を肥やす目的て゛マイナンハ゛━だのと個人情報収集して漏えいさせてやがるし
自力て゛開発もて゛きす゛グ―グ儿依存サイ├しか作れないナマポ集団NTTだのによるセキュリティの欠片もないポンコツサイトた゛らけ
都心まて゛数珠つなき゛て゛私権侵害してコロナに温室効果カ゛スにとまき散らして気候変動災害連發させて人を殺す強盜殺人推進して
ヱネ価格に物価にと暴騰させて健常者の人生を破壊するこうした他人の権利を強奪して私腹を肥やすテ囗リス├を根絶やしにするのか゛先た゛ろ
つかアプリとか小学生て゛も独学て゛作れるわけた゛か゛税金もらわなきゃアプリの使い方すら習得て゛きないとかマシ゛小学生やれよ税金泥棒
(羽田)ttps://www.call4.jp/info.php?type=items&id=I0000062 , ttps://haneda-project.jimdofree.com/
(成田)ttps://n-souonhigaisosyoudan.amebaownd.com/
(テ口組織)ttps://i.imgur.com/hnli1ga.jpeg