09/06/22 22:31:06
正規化について質問です
第一正規化は繰り返しフィールドの排除があるかと思いますが、
たとえば
ＩＤ｜購入者｜商品１｜金額１｜商品２｜金額２｜商品３｜金額３｜商品４｜金額４
01｜ＡＡＡ.....｜ＴＶ１....｜10万...｜ＴＶ２....｜11万....｜ＴＶ３...｜12万....｜ＴＶ４....｜13万...
このような場合は
ＩＤ｜購入者
01｜ＡＡＡ
......と
ＩＤ｜商品｜金額
01｜ＴＶ１｜10万
01｜ＴＶ２｜11万
01｜ＴＶ３｜12万
01｜ＴＶ４｜13万
と２つに分けるかと思いますが
ＩＤ｜購入者｜販売担当者｜購入日｜配送日
の場合
購入者と販売担当者は人フィールドで、
購入日と配送日は日付フィールドなので
これらも繰り返しフィールドとみなせるのでしょうか？
224:NAME IS NULL
09/06/22 22:46:59 Ii7lYaDv
>>223
それって違うんでねーの？
たぶん
225:NAME IS NULL
09/06/22 23:11:29
>>223
そうみなしたければみなして良い。みなしたくなければみなさなくても良い。
正規化というのはそういったところを決定した後に行う操作だから。
226:NAME IS NULL
09/06/23 07:20:42
通常は繰り返しとはみなさない。
あなたの言うとおりなら、
ID、人種類、人ID、日付種類、日付
みたいなカオステーブルができあがってしまう。
エンティティをしぼりこむのは業務分析ありきだから上記のカオステーブルが絶対ないとは言わないが、通常はないと言える。
227:NAME IS NULL
09/06/24 21:28:15 FsaDUw2R
>>226
ありがとうございます
そうですよね
何かこれに関する情報がのっているサイトとかご存知でないですか？
これを正規化と豪語する人がいて、そうじゃないという説得材料にしたいのですけど
228:NAME IS NULL
09/06/25 18:47:46
簡単なデータで例を作ってみたら？
問題でれば、それで説明つく。
出なければ、そのデータでは、問題ないのかもしれないよ（その人は
それを言っているのかもしれない）。
229:NAME IS NULL
09/06/25 19:55:02 uVxmIhxY
>>228
今日、この件お話したら、納得してくれたようです
たまたま具体的なデータ例で、話をしてたら話の論点があって、ある程度解決作がみえてきました
具体的な例で話し合うのは重要かもしれませんね
230:NAME IS NULL
09/06/25 22:24:51
よかたねー
231:NAME IS NULL
09/06/27 04:19:07
(・∀・) 白くなっとるﾜﾛﾀｗｗｗｗ
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
●● URLﾘﾝｸ(wakuwaku.docomo.han-be.com)
232:NAME IS NULL
09/09/21 18:26:25 4bCDESCP
同じ表にmember_idとmember_nameの二つの列があって、
member_id ・・・社内の人間なら社員コード。社外の人はNULL
member_name ・・・社内の人間ならNULL。社外の人は名前
みたいになってるんだけど、これってもっといい方法があるよね？
社員コードは別の社員表にある。
233:NAME IS NULL
09/09/21 20:51:56
社員表(社員コード,社員名)
社外表（コード,名前）
メンバー表(メンバーID,・・・・・)
社員コード∈メンバーID
社員コード∈コード
select B.社員名,C.名前
from メンバー表 A left join 社員表 B ON A.メンバーID=B.社員コード left join 社外表 C ON A.メンバーID = C.コード
234:NAME IS NULL
09/12/24 17:18:39 ao0/KMLR
>>215
＞正規化について言及すると、それは正規形を崩してるだろ。
＞正規化手法は、”既約でない”関数従属を排除する為の射影である
＞必要があり・・・
＞ ：
＞要するに、１事実１箇所になってないと正規形とは言えないってこと。
＞だから、スナップショットは正規化違反ということさ。
超遅レスだが、>>214の見解は的確で合理的じゃね？
販売業務で商品の販売単価が日時や取引数量、その他に応じて変動する場合、売上伝票や
注文書に載せる明細の単価に対し、商品マスタの単価との間に従属性を認めては駄目だよな。
ゆえに業務の性格によっては正規化の対象とはならないだろう。
そして、注文を行った時点でのスナップショットこそが、正に売買契約と売上認識の「事実」。
つまり、一つの売上伝票や一つの注文書をもって「一事実、一箇所」と認識しなければ、寧ろ
不都合なシステム設計をする事になるよな。 だから、>>214は優良な実務経験者だと思うぞ。
ボイスコッドから高次の正規化は要注意だな。
それより対象業務をよく分析し、ER図等で得られた業務の大切な性格と特徴を損なわない正規化を
心掛け、顧客指向のITソリューションでメリットを提供することがプロフェッショナルの仕事だと思う。
235:NAME IS NULL
09/12/26 01:44:47 dn/wTtyt
ニコニコ動画のコメントやアマゾンのレビュー、youtubeのコメントなど
1対多の関係はどういうデータベースの構造になっているんでしょうか？
自分は以下の3パターンを考えたのですがどれも疑問が残ります。
案1：1つのレコードに動画番号とその動画に対する全てのコメント番号を収納する
動画1, コメント1コメント2コメント3コメント4
動画2, コメント1コメント2
欠点：・コメント数が有限になってしまうのではないか。
・複数のコメントが一つのコラムに収納されている場合、
１つのコメントの追加によってそのフィールド全体を更新しないといけないから
重いのではないか。
案2：コメント主導で動画番号を対応づける
コメント1, 動画1
コメント2, 動画2
コメント3, 動画1
コメント4, 動画3
欠点：動画を見る度にコメントの抽出をしないといけないから重いのではないか
案3：各動画毎にコメント用のテーブルを用意する
動画1のコメントテーブル：
コメント1
コメント2
コメント3
動画2のコメントテーブル：
コメント1
欠点(?)：動画の数だけテーブルを用意することになるけど、
自分はどうプログラミングするのか分からないです。
236:NAME IS NULL
09/12/26 02:51:10 rKp6qWLp
>>235
リレーショナルデータベースでのデータ設計は、プログラム言語のように構造体で
カタチを決めて配列やリスト構造を持たせていくデータ設計と違って、集合論理と
関連の概念で解決しないとダメなんだよ。
↓こんな風に持たせればそれらしくなるんじゃない？
237:NAME IS NULL
09/12/26 02:51:56 rKp6qWLp
【投稿動画テーブル】
動画ID 会員ID 投稿日時 動画データ ・・・
---------+----------+---------------+----------+---
sm1234567 nv1000000 2008/10/21 11:25 mov999999 ・・・
sm1234568 nv1300000 2009/01/13 18:31 mov888888 ・・・
sm1234569 nv2000000 2009/07/02 09:05 mov989898 ・・・
sm1234510 nv1000000 2009/12/25 23:41 mov010101 ・・・
： ： ： ：
【投稿コメントテーブル】
動画ID タイム コメント
---------+-----+-----------------
sm1234567 00:01 wktk
sm1234567 00:03 高画質
sm1234568 01:52 ああああああああ
sm1234567 00:08 ﾃﾗ画質ｗ
sm1234567 00:12 ｷﾀｰ!
sm1234510 00:02 ｗ
： ： ：
sm1234567 01:32 これはすごいな
sm1234567 01:40 たしかにｗ
sm1234569 03:02 おおおおおおおおっ！
sm1234567 01:59 うｐ主様、乙でした
238:NAME IS NULL
09/12/26 02:52:50
そもそもRDBかどうかも疑うべきだと思うけど。
239:NAME IS NULL
09/12/26 03:21:23 dn/wTtyt
>>237
ありがとうございます。
つまりそれは案2で、動画を見る度に
全てのコメントを収納した巨大な投稿コメントテーブルから
動画IDでコメントの抽出を行うんですよね？
それって重くないんでしょうか。
案3だと抽出処理が要らないんで軽いのかと思ったんですが
そんな大差はないのかな。。
240:NAME IS NULL
09/12/26 04:06:02
>>239
案ずるには及ばないと思うよ。インデックスとサーチのアルゴリズムは高度だから。
この程度のデータなら、RDBMSで数万件からの抽出でも、あっという間な筈。
あと他の方法となれば、制限を設けて自前のアルゴリズムで管理するしかないね。
WindowsならVC++やVC#、VBなどでサービスプログラムを組んで、Webページの
サーバーサイドから呼ぶとかね。
ハッシュアルゴリズムとか独自方式とか好きな技法でカスタムメイドできるよ。
241:NAME IS NULL
09/12/26 19:20:41
>>238
ニコニコはMYSQLだと聞いてる。
242:NAME IS NULL
09/12/26 22:13:20
>>238
現実的に考えて、RDB以外にないだろ。
243:NAME IS NULL
09/12/27 00:06:26
多くの工業科＆組込制御系育ちはRDBMSをなかなか理解できないらしい。
自分をCPUに見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。