5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :NAME IS NULL:2005/05/15(日) 03:56:41 ID:43QLdn9b
正規化について語りましょう。

前スレ(dat落ち)

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


2 :NAME IS NULL:2005/05/15(日) 04:21:00 ID:???
過疎板で深夜の2(σ゚∀゚)σGets!!

>>1 乙です。

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

3 :NAME IS NULL:2005/05/15(日) 04:25:33 ID:???
>>2
yes

4 :2:2005/05/15(日) 04:40:59 ID:???
>>3
だよな('A`)

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

5 :NAME IS NULL:2005/05/15(日) 05:39:58 ID:???
>>4
そういう場合はIP/HostNameテーブルに期間カラムを設ける。

6 :2:2005/05/15(日) 07:47:51 ID:???
>>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:???
自動正規化ツールってありますか?

8 :NAME IS NULL:2005/05/17(火) 11:09:06 ID:???
ググったらここしかでてこなかった
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:???
Microsoft の Access についてなかったっけ?簡単な奴が。

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

11 :NAME IS NULL:2005/05/28(土) 12:51:06 ID:GrEiaLyo
自動なんたらツールって嫌!
そんなのがあったら俺の仕事無くなっちゃうよ!

12 :NAME IS NULL:2005/05/28(土) 13:13:19 ID:???
今まで寝た女のあらゆるデータをカテゴライズしてDBにしたいのだが。。


13 :NAME IS NULL:2005/05/28(土) 14:26:58 ID:???
女(女ID)
カテゴリ(カテゴリID, カテゴリ名)
あらゆるデータ(女ID, カテゴリID, データ)

14 :NAME IS NULL:2005/05/28(土) 17:18:20 ID:???
SELECT count(女ID) FROM 女;

15 :NAME IS NULL:2005/05/28(土) 17:23:15 ID:???
レコードが選択されませんでした・・・

16 :NAME IS NULL:2005/05/28(土) 22:04:23 ID:???
二年近くかけてやっと第二正規形か。
第五正規形になるのはいつの日か…

17 :NAME IS NULL:2005/05/28(土) 22:05:55 ID:???
しかも第一は落ちただけだしな

18 :NAME IS NULL:2005/05/29(日) 07:55:28 ID:???
SELECT cunt(女ID) FROM 女;


19 :NAME IS NULL:2005/05/29(日) 13:16:10 ID:???
>>18
SELECT 女.cunt FROM 女;

20 :NAME IS NULL:2005/05/29(日) 19:48:22 ID:???
select distinct cunt(女ID) as count from 女 group by 女ID;
これで決定か?

21 :NAME IS NULL:2005/05/29(日) 19:49:09 ID:???
>>20
大事なことを書き忘れた。
因みにMysql4.1.11です。

22 :NAME IS NULL:2005/06/07(火) 15:29:45 ID:???
正規化工数ってナンディスカ?
いやここで聞くのも間違ってる気がするけど誰か知ってたら教えてアモーレ

23 :NAME IS NULL:2005/06/17(金) 02:41:50 ID:???
春のDB落ちた。午後Tあと15点だった。

24 :NAME IS NULL:2005/07/09(土) 02:15:52 ID:???
Access好きはIDって列にPrimary Keyつければいいってもんじゃない事を
肝に銘じておいてくださーい!!DBAの敵ですよー!!

25 :NAME IS NULL:2005/07/09(土) 07:28:02 ID:Ussu/qQy
>>24
意味不明ですが覚えておきます。

26 :NAME IS NULL:2005/07/09(土) 07:28:18 ID:???
上げてしまった・・・orz

27 :NAME IS NULL:2005/07/11(月) 02:30:15 ID:???
あー、>>24を読んだだけであの歌が頭から離れないー!

28 :NAME IS NULL:2005/07/19(火) 10:27:19 ID:???
Normalization!!

29 :NAME IS NULL:2005/07/20(水) 05:28:41 ID:???
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
テーブルの構成の仕方で質問です。

個人テーブル
| 名前 | 趣味コード |
【例】
| 山田太郎 | 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
正規化ってやることのメリットが
イマイチわからないんですが、
どんなメリットが待ち構えているのでしょうか?

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

32 :NZ(NULL,NULL):2005/07/25(月) 00:53:04 ID:???
>30
()…主キー制約、[]->…外部キー制約、| 列のデリミタ
個人テーブル : (名前) | [趣味コード]->趣味テーブル.趣味コード
趣味テーブル : (趣味コード) | 趣味名
趣味分類テーブル :
   [(趣味コード)]->趣味テーブル.趣味コード | [(趣味カテゴリコード)]->趣味カテゴリテーブル.趣味カテゴリコード
趣味カテゴリテーブル : (趣味カテゴリコード) | 趣味カテゴリ名

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

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

33 :NAME IS NULL:2005/07/25(月) 01:29:47 ID:4Te3/qIT
>>32
レスありがとうございます。
趣味は、複数のカテゴリに属する必要はない。
個人は複数の趣味を持つ事はない。
この前提で考えております。
「連関テーブル」というのは、ちょっと初めて聞く言葉です。
おそらく、趣味レコードの趣味カテゴリコードから参照して、カテゴリ名を引っ張りだすためのテーブルと認識しておりますが、これでよいですか?
個人が親なら、趣味は子、趣味カテゴリは孫、みたいな。

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

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

34 :NAME IS NULL:2005/07/25(月) 12:33:28 ID:???
>>31

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



35 :NAME IS NULL:2005/07/25(月) 13:41:24 ID:???
個人と趣味、趣味と趣味カテゴリがそれぞれ1:1対応なら、いっそ

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

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

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

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


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

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

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


39 :NAME IS NULL:2005/07/28(木) 10:23:52 ID:KXoQY93/
>>24
一見、あなたの意見があっていると思う人もいると思うが、実はAccessのほうが現実的な正解だったりする。
但し、それを理解してないでとりあえずID=主キーとする人は間違いだけど。

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

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

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

41 :NAME IS NULL:2005/07/29(金) 21:57:57 ID:???
明日正規化のテストでそうだな

42 :NAME IS NULL:2005/08/04(木) 14:33:24 ID:???
しょ、正気か?

43 :NAME IS NULL:2005/08/05(金) 17:21:46 ID:???
>31
今、どんな教え方しているのか知らないのだが、正規化した後に
パフォーマンス等を考慮に入れて、最後に正規化を崩すてのが
DB設計の手順にあった。

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

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

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

45 :NAME IS NULL:2005/08/30(火) 01:16:26 ID:???
非正規化は正規化→崩すのステップを踏襲する必要は無いんだぜ!
そんなの教科書でそう書いてるだけで、実際にやったらアホだよ。

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

46 :NAME IS NULL:2005/08/31(水) 00:55:52 ID:???
非正規化は非正規形と化すってことだろ
元々が非正規形なら非正規化は不要な
んだから非正規化をするということは元
の正規形がないとおかしいんジャマイカ?
非正規放置ならわかるけど

47 :NAME IS NULL:2005/08/31(水) 11:28:41 ID:???
まあそりゃそうだ。

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

48 :NAME IS NULL:2005/09/07(水) 11:42:05 ID:???
正規化について質問です。

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

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

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

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


49 :NAME IS NULL:2005/09/07(水) 12:03:01 ID:???
id,製品名,購入日,メーカーid,type

typePC
id,CPU clock,メモリ容量

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

type携帯電話
id,電話番号

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

51 :NAME IS NULL:2005/09/07(水) 18:10:22 ID:???
>49のパターンにした場合、実際のアプリでSELECTする時SQLが複雑になったりしませんか?

52 :NAME IS NULL:2005/09/07(水) 22:16:49 ID:???
状況による。

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

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

53 :NAME IS NULL:2005/09/17(土) 16:52:19 ID:???
>52へよくわからん。おせーてくれ。
>データ量、カラム数、表示で使うSQLの種類などから総合的に判断する。
>JOINのパフォーマンスが問題になるケースではテーブルを一個にする。

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

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

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

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

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

55 :NAME IS NULL:2005/09/18(日) 01:24:50 ID:???
パフォーマンスをすべてマシンスペックで解決するつもりなんかね。
幸せな人だw

56 :NAME IS NULL:2005/09/18(日) 18:01:16 ID:???
53だけど

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

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

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

57 :NAME IS NULL:2005/09/18(日) 23:02:29 ID:???
文章をまとめるスキルが無いことは分かった

58 :NAME IS NULL:2005/09/19(月) 07:57:28 ID:???
>57
スマソ
幼稚園からやり直すので、何年か持っていてくれ

59 :NAME IS NULL:2005/09/19(月) 17:45:33 ID:???
ところで、もまいら正規化以前でDBの設計ってどー始める?


60 :NAME IS NULL:2005/09/20(火) 09:13:51 ID:???
>ところで、もまいら正規化以前でDBの設計ってどー始める?

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

61 :NAME IS NULL:2005/09/20(火) 09:52:00 ID:???
>>59
>>60
まあ、好意的に解釈すれば、正規化なんて設計の後半だからね。
まず実業務などからえんててーのちうしつから始まるわけで。

62 :NAME IS NULL:2005/09/21(水) 02:11:44 ID:???
>>61
  回答、ありがとう 59です。

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

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

63 :NAME IS NULL:2005/09/21(水) 02:44:44 ID:???
>59
参考
ttp://codezine.jp/a/article.aspx?aid=154

64 :NAME IS NULL:2005/09/21(水) 03:19:55 ID:???
63>>
回答ありがとう59です。
参考ホームページを拝見しました。
この羽生さんの記事は、素人にもわかりやすくていいですね。
SQLの部分は、意味がよくわかりませんでしたが、そのほかの
設計に関しては概ね読むことが出来ました。

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

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

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

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

66 :NAME IS NULL:2005/10/03(月) 03:20:52 ID:???
右手が性器化した

67 :NAME IS NULL:2005/10/11(火) 11:53:34 ID:???
皆さん、正規化ってちゃんとしてます?

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

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

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

68 :NAME IS NULL:2005/10/11(火) 15:38:30 ID:???
ここはお前の日記帳です

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

70 :NAME IS NULL:2005/10/29(土) 12:14:45 ID:zOZqpbV9
完全に近い形で正規化された設計を見てみたい(つдT)

71 :NAME IS NULL:2005/10/30(日) 02:58:04 ID:???
完全に「近い」形か、難しいな。

72 :NAME IS NULL:2005/10/30(日) 10:53:28 ID:???
>>70
完全なのは見たくないの?

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

73 :NAME IS NULL:2005/10/30(日) 10:57:03 ID:???
じゃあ、社員がいて名前と生年月日があって、課に属している

74 :NAME IS NULL:2005/11/09(水) 15:37:35 ID:???
社員テーブル1つ

75 :NAME IS NULL:2005/11/10(木) 01:16:33 ID:???
>74
課テーブルくらい作ってやれよ。寂しいだろ。

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

77 :NAME IS NULL:2005/11/10(木) 23:50:11 ID:???
社員テーブル
------------
社員ID
名前


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


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

78 :NAME IS NULL:2005/11/10(木) 23:55:33 ID:???
>>77
お前がやっていることはネタにマジレスってやつだ

79 :NAME IS NULL:2005/11/11(金) 11:07:24 ID:???
生年月日テーブルも作らなくちゃ


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




80 :NAME IS NULL:2005/11/11(金) 16:52:46 ID:???
年テーブルと月テーブルと日テーブルも

81 :NAME IS NULL:2005/11/11(金) 17:24:39 ID:???
じゃあ曜日テーブルも作ろうぜ

82 :NAME IS NULL:2005/11/11(金) 21:41:39 ID:???
時分秒も・・・

83 :NAME IS NULL:2005/11/11(金) 22:01:08 ID:???
>>82
いや、それはいらないな

84 :NAME IS NULL:2005/11/11(金) 22:04:55 ID:???
名前文字テーブルも作らないと
----------
名前文字コード 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:???
>>84
名前の読みはどうすればいいのだろう?
やっぱ、PCMかな。

86 :NAME IS NULL:2005/11/11(金) 22:15:41 ID:???
>>83
そのつっこみ、今週で一番笑った

87 :NAME IS NULL:2005/11/11(金) 23:29:09 ID:???
>>77

出直せ。

88 :NAME IS NULL:2005/11/24(木) 11:31:47 ID:???
体重テーブルも必須だろ

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

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

89 :NAME IS NULL:2005/11/24(木) 11:40:14 ID:???
>>88
以前の体重と比較できるように計測日フィールド入れないとダメだろ

90 :NAME IS NULL:2005/11/26(土) 18:01:45 ID:???
http://www.doaplus.com/html/bun03_20051101.html
「正規化するとレスポンスが悪くなる」という「うわさ」は本当か?
百聞は一見にしかず。当分科会が実証実験を行いました。

91 :NAME IS NULL:2005/11/26(土) 23:39:38 ID:???
非正規化したテーブルを何でジョインするんだw

92 :NAME IS NULL:2005/11/27(日) 00:43:20 ID:???
確かに不思議屋根

93 :NAME IS NULL:2005/11/27(日) 16:57:05 ID:???
>非正規形のDBを使っている技術者はJOINが遅くなることを体験しており、
>「正規化するともっと遅くなる」と誤解している。

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


94 :NAME IS NULL:2005/11/27(日) 19:51:55 ID:???
欺術者偽術者疑術者擬術者戯術者好きなのドソー

95 :NAME IS NULL:2005/11/27(日) 20:39:15 ID:???
俺も方法論的にはどっちかというとDOA派だけど、
>>90のようなアホなこと真面目にやってるから
古いって馬鹿にされるんだよな・・・

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

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

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



98 :NAME IS NULL:2006/01/07(土) 03:33:51 ID:???
複雑にするとバグがおきやすいってのは真だな。パフォーマンス上もシンプルな方がキャッシュとか効きやすいし。

99 :NAME IS NULL:2006/01/07(土) 05:18:37 ID:???
>>96は思い込みが激しそうだなw

100 :NAME IS NULL:2006/01/10(火) 21:22:34 ID: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:2006/01/11(水) 01:19:44 ID:???
俺的には、テーブルの作り自体は現行で最善な感じがする。
マジックナンバーがいやなら、チェックはアプリケーションロジックでやるとか。

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

102 :100:2006/01/11(水) 12:25:56 ID:VpUtuDIC
>>101
やはりそう思われますか…。トータルコストを考えると、どんな用件に対して
も正規化が可能なわけではないということでしょうか。

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

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

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

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


103 :100:2006/01/11(水) 12:29:38 ID:???
外部テーブルという言い方は変ですね。単に、別テーブルという意味です。

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


104 :NAME IS NULL:2006/01/13(金) 01:03:49 ID:???
>100
オプション4,5 では何を指定しても使われないなら、NOT NULL にして4,5を挿入するときは適当に
0でも入れておけばいいんじゃないの? DEFAULT 0 とかつけてやったりして。

105 :NAME IS NULL:2006/01/13(金) 03:04:52 ID:???
>>104
そうやっても 00001 1 0 という誤挿入を防ぐことはできない罠。


106 :NAME IS NULL:2006/01/13(金) 06:31:18 ID:???
>105
0 がないとすると、残り1回のまま永久にオプションを使い続けられることにならない?

107 :100:2006/01/13(金) 11:29:00 ID:TppsOzrm
>>105
説明不足ですみません。カラム「制限回数」は、ゼロを入れる予定は(NULLの
代用でない限り)ないんです。

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

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

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

以上、補足でした。


108 :100:2006/01/13(金) 11:30:11 ID:???
あ、リンクを間違えました。× >>105 → ○ >>106

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

110 :100:2006/01/13(金) 22:01:07 ID:TppsOzrm
>>109
ありがとうございます。
ただ、私は、>>102の後半に、かなり似た内容を書いておりまして、それと
どう違うのか、良くわかりません…。


111 :NAME IS NULL:2006/01/14(土) 00:03:14 ID:???
>>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

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

> 制限回数には回数とそれを使うかどうかの情報が含まれている。
とのことでしたが、もっと言えば、このユーザオプション管理テーブルの内容自
体に、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:???
>>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:???
初心者にありがちな考えすぎ

116 :NAME IS NULL:2006/01/24(火) 10:05:52 ID: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:2006/01/24(火) 13:12:15 ID:???
>>116
歴史的経緯がいろいろありそうなテーブルですね。
課IDのところの説明を間違ってなければ、
課を複数の部に所属させることができるようにしようとした痕跡がありますね。
結局それは取りやめて部課連携テーブルは使ってない可能性が高いな。
(または課テーブルの部IDを使ってない可能性あり)
グループ+部IDとグループIDでユニークで、課とグループはn:nの関係。
グループ連携テーブルはそのn:nの関係をあらわすためにある。

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


119 :NAME IS NULL:2006/01/24(火) 23:52:14 ID:???
おいおい、ちゃんとヒアリングしろよ・・・

120 :NAME IS NULL:2006/03/06(月) 02:47:55 ID:???
正規化しないで作った事とかないんですが、どうしてもテーブル構成なんかを考えてる時間がないんです。
1テーブルでむりやり作っちゃうってのは実際のとこ「あり」ですかね?

121 :NAME IS NULL:2006/03/06(月) 11:04:40 ID:???
>>120
あなたのその後の人生をそのシステムに捧げる覚悟があるならば「あり」かもしれない。


122 :NAME IS NULL:2006/03/06(月) 23:05:20 ID:???
>>121
ないです。つか、保守とか以前にぽしゃる悪寒>そのサイト

123 :NAME IS NULL:2006/03/07(火) 00:48:26 ID:???
俺はありありだと思うなー。
とりあえずは動けば何でも良いよ

124 :NAME IS NULL:2006/03/09(木) 23:59:15 ID:???
>>123
結局1テーブルで全部くんでしまった。
やたらとtextのフィールドが多い・・・
もうしらね。全部のフィールドを検索対象にしてやる。
やけくそでやれば終るもんだ。あとはcssまわりだけ。

125 :NAME IS NULL:2006/03/10(金) 00:08:53 ID:???
>>124
自分でいいならいいんじゃね?

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

126 :124:2006/03/11(土) 01:53:53 ID:???
基本的なとこは組み上がったからUIまわりをajaxでかっこいくしてたら暗唱に乗り上げた。悔しいがヤメることにする。一日ロスしたorz

127 :NAME IS NULL:2006/03/13(月) 00:18:21 ID:???
T字型ERって業務でやってる人居る?
ネットに全然情報ないし、本買わないといけないかな。

128 :NAME IS NULL:2006/03/13(月) 23:00:16 ID:???
出向に行ったら表記法がT字型だったなあ。

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

129 :NAME IS NULL:2006/03/14(火) 01:46:14 ID:???
なんか古臭い感じがするよね。

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

130 :NAME IS NULL:2006/03/18(土) 16:27:27 ID:B7S2rjh8
勉強中です。第二正規形と第三正規形を分ける理由が良く分かりません。
分かりやすく教えてください。

131 :NAME IS NULL:2006/03/20(月) 10:08:38 ID:???
データベース理論的にはボイスコッド正規形との絡みとか色々あるから、
2と3を分けるのは必然だろうね

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

132 :NAME IS NULL:2006/03/20(月) 22:32:44 ID:???
俺もなんとなくやったら第3正規形になる。

133 :NAME IS NULL:2006/03/22(水) 07:14:06 ID:???
漏れはなんとなくやると第6正規形になる。

134 :NAME IS NULL:2006/03/22(水) 10:26:27 ID:???
オレもなんとなくやったら第百万光年正規形になる。

135 :NAME IS NULL:2006/03/22(水) 19:26:57 ID:???
自分はなんとなくやったら正上位形になる。

136 :NAME IS NULL:2006/03/29(水) 03:15:57 ID:???
>>130

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

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

137 :NAME IS NULL:2006/03/29(水) 04:41:23 ID:???
>>136
レスありがとうございます。
ただ、私が知りたいのは、なぜ第三正規形にするか、ということではなく、
なぜ、第二正規形という形があるのかということです。
第一正規形から片っ端から関数従属を取り除くと第三正規形になると思うのですが、
その間に第二正規形を置いて第二と第三を区別する理由が良く分からんのです。

138 :136:2006/03/29(水) 13:02:23 ID:mr4gMX+s
>>137
うーん、正規形についてなんかちょいと誤解があるような気がするんだけど・・。

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

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

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

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

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

139 :136:2006/03/29(水) 13:07:11 ID:???
自己レスだけど、ちょいと言いたい事が足りてなかったかも。
3だとリレーションを保てない、2,1ならOK,なら1にすれば良くて、2の存在価値は
相変わらず不明、とか思われると遺憾かなと思って。

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

140 :130:2006/03/30(木) 03:44:07 ID:???
度々レスありがとうございます。

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

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

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

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

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

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

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

141 :NAME IS NULL:2006/03/31(金) 18:08:00 ID:???
>>140
テクニカルエンジニア DB の参考書とか読んでみるといいよ。
こういうDBの理論とかの専門書って少ないし高いし・・・

142 :NAME IS NULL:2006/03/31(金) 23:46:12 ID:???
テクニカル DB 保持者ですが設計の経験がほとんどありません、逝ってきます。

143 :NAME IS NULL:2006/03/32(土) 16:16:11 ID:45VqWbwv
テクデの勉強ってDBだけじゃなくて、業務知識のストックにも
なるところが実務向きでいいと思うんだよねー。
なんか、自分の周りではあんまり知られてない試験なんですが。

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


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

145 :NAME IS NULL:2006/04/02(日) 12:28:17 ID:???
普通。
受託案件は自分がメンテするわけじゃないからなんでもありですよ。

146 :NAME IS NULL:2006/04/02(日) 13:27:04 ID:???
>>144
それって逆に開発が鬱陶しくならんか?

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

148 :NAME IS NULL:2006/04/03(月) 13:32:44 ID:???
確かに正規化しすぎると変更に弱くなるね。
ってか、DB構造見ていじわるしてるのか、という変更ばかり発生する不思議。
うちではその辺、設計者の腕(技術+業務知識)の見せ所なわけですが。

149 :144:2006/04/03(月) 23:33:06 ID:???
>>148
そっちの方への拡張性を考慮して組んだりするとそのマスターまったく要らなくなったりとかw
なんで、足かせになるような仕様を要求しといて、それに対する対処がやっと済んだころに却下になるんだ?
もしかして、もうすごいスキルを持った嫌な奴なのかもしれん

150 :白馬の玉子 ◆PqSzNbkqDo :2006/04/12(水) 12:43:45 ID:???
スピードパフォーマンス重視

or

管理効率重視

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

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

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


151 :NAME IS NULL:2006/04/12(水) 14:11:14 ID:???
s/頃し/犯し/

152 :NAME IS NULL:2006/04/12(水) 23:12:50 ID:???
非正規化するのも、必ずしもパフォーマンスだけが目的ではないしね。
初心者の頃はマスター系とトランザクション系の区別さえつかんかったなぁ・・・

153 :NAME IS NULL:2006/04/17(月) 14:10:43 ID:???
T/R系は目的上、正規化しちゃマズい場合もあるし

154 :NAME IS NULL:2006/05/11(木) 00:57:58 ID:DgrOFV3I
誰か第5正規形を直観的に教えてください...

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

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

155 :NAME IS NULL:2006/05/11(木) 20:58:00 ID:???
>>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:???
>>155
どうもありがと。なんとなく解かりました。
でもこれ、多値従属性の定義の説明が若干間違ってるねえ。

157 :NAME IS NULL:2006/05/13(土) 02:33:10 ID:???
? んー、やっぱ良く解かってないかも。

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

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

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

158 :NAME IS NULL:2006/05/31(水) 15:26:48 ID:???
正規化のことじゃなぃんだけんども

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

みんなどう?


159 :NAME IS NULL:2006/05/31(水) 21:56:00 ID:???
好み次第

160 :NAME IS NULL:2006/06/01(木) 11:06:07 ID:???
ここで議論が。止まってるけど。

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


161 :NAME IS NULL:2006/06/06(火) 19:09:59 ID:???
たしかに最初は律儀にリレーション設定してたけど、漏れも
クエリなんかでその都度繋げるし、参照整合性が邪魔になる時もあるし
同じマスターテーブル(一側ね)を複数繋げるときも邪魔。

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


162 :NAME IS NULL:2006/06/06(火) 22:11:39 ID:???
データインポートするときとかうざいよね>リレーション
まぁ、インポート時は無視するオプションとかもDBによってはあるけど

163 :NAME IS NULL:2006/06/20(火) 02:03:12 ID:???
あ〜〜〜!むずがゆい!

164 :NAME IS NULL:2006/10/12(木) 13:35:14 ID:LD5ggMeq
平成の大合併で住所変更。顧客マスタの住所と住所マスタの住所の整合性がとれてない。。

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

165 :NAME IS NULL:2006/10/22(日) 22:41:58 ID:???
運用部員がマニュアルで作業するときには制約はあったほうがいい。
制約を回避するINSERT、UPDATEを書けるようになれ

166 :NAME IS NULL:2006/11/15(水) 13:27:54 ID:???
>155
アクセのレベルを疑うような記事だな。
BC正規化なんて、ひどい。つか、事例悪過ぎ。

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

55 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)