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

**NAME IS NULL** · 2005/05/15(日) 03:56:41

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

前スレ(dat落ち)

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

**136** · 2006/03/29(水) 13:07:11

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

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

**130** · 2006/03/30(木) 03:44:07

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

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

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

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

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

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

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

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

**NAME IS NULL** · 2006/03/31(金) 18:08:00

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

**NAME IS NULL** · 2006/03/31(金) 23:46:12

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

**NAME IS NULL** · 2006/03/32(土) 16:16:11

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

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

**NAME IS NULL** · 2006/04/02(日) 02:41:14

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

**NAME IS NULL** · 2006/04/02(日) 12:28:17

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

**NAME IS NULL** · 2006/04/02(日) 13:27:04

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

**144** · 2006/04/02(日) 19:07:03

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

**NAME IS NULL** · 2006/04/03(月) 13:32:44

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

**144** · 2006/04/03(月) 23:33:06

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

**白馬の玉子** ◆PqSzNbkqDo · 2006/04/12(水) 12:43:45

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

or

管理効率重視

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

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

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

**NAME IS NULL** · 2006/04/12(水) 14:11:14

s/頃し/犯し/

**NAME IS NULL** · 2006/04/12(水) 23:12:50

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

**NAME IS NULL** · 2006/04/17(月) 14:10:43

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

**NAME IS NULL** · 2006/05/11(木) 00:57:58

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

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

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

**NAME IS NULL** · 2006/05/11(木) 20:58:00

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

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

**NAME IS NULL** · 2006/05/13(土) 01:44:22

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

**NAME IS NULL** · 2006/05/13(土) 02:33:10

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

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

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

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

**NAME IS NULL** · 2006/05/31(水) 15:26:48

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

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

みんなどう？

**NAME IS NULL** · 2006/05/31(水) 21:56:00

好み次第

**NAME IS NULL** · 2006/06/01(木) 11:06:07

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

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

**NAME IS NULL** · 2006/06/06(火) 19:09:59

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

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

**NAME IS NULL** · 2006/06/06(火) 22:11:39

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

**NAME IS NULL** · 2006/06/20(火) 02:03:12

あ～～～！むずがゆい！

**NAME IS NULL** · 2006/10/12(木) 13:35:14

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

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

**NAME IS NULL** · 2006/10/22(日) 22:41:58

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

**NAME IS NULL** · 2006/11/15(水) 13:27:54

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

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

**NAME IS NULL** · 2007/01/04(木) 15:07:35

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

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

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

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

**NAME IS NULL** · 2007/01/04(木) 20:18:53

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

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

**NAME IS NULL** · 2007/01/04(木) 22:43:58

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

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

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

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

**167** · 2007/01/04(木) 23:32:40

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

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

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

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

**NAME IS NULL** · 2007/01/05(金) 06:42:50

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

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

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

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

**NAME IS NULL** · 2007/01/05(金) 07:25:49

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

**NAME IS NULL** · 2007/01/05(金) 23:07:34

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

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

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

**NAME IS NULL** · 2007/01/05(金) 23:18:39

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

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

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

**173** · 2007/01/06(土) 01:03:19

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

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

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

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

**NAME IS NULL** · 2007/01/13(土) 19:49:54

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

**NAME IS NULL** · 2007/01/13(土) 20:27:34

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

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

**NAME IS NULL** · 2007/01/13(土) 20:35:58

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

**NAME IS NULL** · 2007/01/13(土) 20:41:39

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

**NAME IS NULL** · 2007/01/15(月) 00:11:04

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

**NAME IS NULL** · 2007/09/25(火) 00:14:21

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

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

**NAME IS NULL** · 2007/10/13(土) 09:57:23

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

**NAME IS NULL** · 2007/10/21(日) 01:04:39

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

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

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

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

**NAME IS NULL** · 2007/10/21(日) 06:18:18

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

まぁ、分けるとしたら。

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

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

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

**183** · 2007/10/21(日) 12:48:09

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

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

**NAME IS NULL** · 2007/10/21(日) 13:52:49

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

**NAME IS NULL** · 2007/10/21(日) 14:21:27

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

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

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

という感じ。

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

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

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

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

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

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

**183** · 2007/10/21(日) 14:50:38

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

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

**NAME IS NULL** · 2007/10/21(日) 15:56:26

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

それでいいと思う

**183** · 2007/10/21(日) 18:18:38

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

**NAME IS NULL** · 2007/10/26(金) 11:24:48

許可マスタ

項目名　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定義もうやだー

**NAME IS NULL** · 2007/10/27(土) 09:58:27

lol

**NAME IS NULL** · 2007/11/01(木) 01:20:19

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

**NAME IS NULL** · 2007/11/12(月) 21:07:31

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

**NAME IS NULL** · 2007/11/12(月) 21:36:34

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

**NAME IS NULL** · 2007/11/12(月) 21:39:15

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

**NAME IS NULL** · 2007/11/13(火) 11:47:27

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

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

**FEQoQDjgtx** · 2007/11/14(水) 04:53:31

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

**NAME IS NULL** · 2007/11/17(土) 22:12:21

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

**NAME IS NULL** · 2007/11/18(日) 08:52:47

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

でも正規化自体は賛成。

**NAME IS NULL** · 2007/11/18(日) 09:52:01

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

**NAME IS NULL** · 2007/11/20(火) 02:00:19

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

**NAME IS NULL** · 2007/11/20(火) 14:01:50

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

**NAME IS NULL** · 2007/11/20(火) 17:12:39

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

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

**あぼーん** · NG

あぼーん

**NAME IS NULL** · 2007/11/20(火) 22:25:34

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

**NOMO ESTAS NENIO** · 2007/11/22(木) 07:49:11

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

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

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

**NAME IS NULL** · 2007/11/22(木) 08:26:10

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

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

**NAME IS NULL** · 2007/11/22(木) 12:59:43

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

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

**NAME IS NULL** · 2007/11/22(木) 20:09:17

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

**あぼーん** · NG

あぼーん

**NAME IS NULL** · 2007/11/23(金) 23:15:27

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

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

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

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

**NAME IS NULL** · 2007/11/23(金) 23:19:50

212の続き

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

**NOMO ESTAS NENIO** · 2007/11/24(土) 03:30:10

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

**NAME IS NULL** · 2007/11/28(水) 01:35:19

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

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

よろしく

**NAME IS NULL** · 2008/04/04(金) 08:17:59

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

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

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

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

**NAME IS NULL** · 2008/04/04(金) 20:25:32

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

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

**NAME IS NULL** · 2008/04/04(金) 22:06:03

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

**NAME IS NULL** · 2008/04/05(土) 08:22:30

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

**NAME IS NULL** · 2008/04/14(月) 13:44:48

JOINのコストって高いね。

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

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

**NAME IS NULL** · 2009/04/11(土) 21:06:53

>>220
釣れますか？

**NAME IS NULL** · 2009/06/10(水) 17:33:31

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

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

**NAME IS NULL** · 2009/06/22(月) 22:31:06

正規化について質問です

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

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

このような場合は

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

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

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

**NAME IS NULL** · 2009/06/22(月) 22:46:59

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

**NAME IS NULL** · 2009/06/22(月) 23:11:29

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

**NAME IS NULL** · 2009/06/23(火) 07:20:42

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

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

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

**NAME IS NULL** · 2009/06/24(水) 21:28:15

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

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

**NAME IS NULL** · 2009/06/25(木) 18:47:46

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

**NAME IS NULL** · 2009/06/25(木) 19:55:02

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

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

**NAME IS NULL** · 2009/06/25(木) 22:24:51

よかたねー

**NAME IS NULL** · 2009/06/27(土) 04:19:07

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

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

**NAME IS NULL** · 2009/09/21(月) 18:26:25

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

**NAME IS NULL** · 2009/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.コード

**NAME IS NULL** · 2009/12/24(木) 17:18:39

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

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

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

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

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

**NAME IS NULL** · 2009/12/26(土) 01:44:47

ニコニコ動画のコメントやアマゾンのレビュー、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
欠点(?)：動画の数だけテーブルを用意することになるけど、
　　　　自分はどうプログラミングするのか分からないです。

**NAME IS NULL** · 2009/12/26(土) 02:51:10

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

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

**NAME IS NULL** · 2009/12/26(土) 02:51:56

【投稿動画テーブル】
　動画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　うｐ主様、乙でした

**NAME IS NULL** · 2009/12/26(土) 02:52:50

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

**NAME IS NULL** · 2009/12/26(土) 03:21:23

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