07/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定義もうやだー
192:NAME IS NULL
07/10/27 09:58:27
lol
193:NAME IS NULL
07/11/01 01:20:19 zMKsxNgF
こんなスレもある。
ｽﾚﾘﾝｸ(prog板)
194:NAME IS NULL
07/11/12 21:07:31
会社コードと会社名だけのテーブルに正規化する価値ってあるかな？
JOINのコストが恐ろしく無駄な気がするんだけど。
195:NAME IS NULL
07/11/12 21:36:34
>>194
「カイシャメイ」 も追加しろ。
196:NAME IS NULL
07/11/12 21:39:15
そうやってマスタでも管理してトリガで更新したいって提案したら不安な顔をされた。
こういうのはバットプラクティスだったのかな？
197:NAME IS NULL
07/11/13 11:47:27
>>194
会社なら(>>195のいうように)ふりがなとか所在地とか取引状況とか、付帯情報が後から湧いてきそうだから、俺ならマスタにする。
joinのコストがCPUを指してるなら「誤差の範囲ですよ」、開発時のタイプ量を指してるなら「ビュー用意しとくんで」。
つい最近だと、印紙種類(収入印紙と登記印紙)をどうしようか迷った。
「そんなもん、増えた時にシステムの対応が必要だったら、データ増やすだけじゃむりだから(アプリに手を入れるから)」
という理由で、これはマスタ可しなかった。
198:FEQoQDjgtx
07/11/14 04:53:31
gBMpor <a href="URLﾘﾝｸ(sflntwpuclbo.com) [url=URLﾘﾝｸ(vtoysuqfixvo.com) [link=URLﾘﾝｸ(iarrmvwkbpot.com) URLﾘﾝｸ(poyhgemjrdue.com)
199:NAME IS NULL
07/11/17 22:12:21
>>194
今の時代、会社名などいくらでも変わる可能性がある。
当然、正規化するべき。
200:NAME IS NULL
07/11/18 08:52:47
>>199
過去のデータで帳票を出す場合、
昔の名前で出なくなるな。
でも正規化自体は賛成。
201:NAME IS NULL
07/11/18 09:52:01
取引当時の社名を出力しなければならないという要件があるなら
そう作ればいいだけで、正規化の有無とは関係ない。
202:NAME IS NULL
07/11/20 02:00:19
いや、それも本とかでは正規化（というか非正規化）の文脈で語られてるよ
203:NAME IS NULL
07/11/20 14:01:50
社名の変更ならその程度で済むかもしれんが、合併とかどうするよ
204:NAME IS NULL
07/11/20 17:12:39
合併したら新会社としてデータを起こすとか。
どうせ与信だなんだ大きく変更になるだろうし。
ただ旧組織との紐付けが必要か否かだなあ。
合算して昨年実績としたい、みたいな。
205:あぼーん
あぼーん
あぼーん
206:NAME IS NULL
07/11/20 22:25:34
社名と日付を用意するなんてわざわざしなくても
社名変更だろうが合併だろうが別会社として扱えばいい
207:NOMO ESTAS NENIO
07/11/22 07:49:11
>194
(1)取引当時の「社名」を「会社コード」と一緒に「取引テーブル」に書き写せばいい。
社名変更して「会社テーブル」の社名列を更新しても取引記録を打ち出すときは旧社名で出るし、
その会社との取引履歴を出すときにはコードで引けば社名変更に関わりなくすべての履歴を
引き出せる。
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
(3)「会社系統テーブル{旧会社コード, 新会社コード}」を設けて、社名変更後は「社名レコード」に
レコードを追加して、旧会社のコードと新会社のコードを「会社系統テーブル」に記録するように
すれば、履歴を多対多の関連で残せるので会社合併・分社があっても追跡ができる。
208:NAME IS NULL
07/11/22 08:26:10
(2)もしくは、「会社テーブル」に「旧会社コード」を設けて、社名変更後はレコードを追加して
別の会社として扱うようにするとか。こうすると新会社分、旧会社分の履歴だけを取り出すときに
便利になるし、旧会社の名前も残せる。
２回以上社名変更や合併を繰り返した場合でも大丈夫でしょうか？
209:NAME IS NULL
07/11/22 12:59:43
207じゃないけど、2回以上でも問題ないだろ、単なるリンクリストなんだから
リンクが1レベルしかできないリンクリストなんてないじゃん
ただ、「この会社名の通用期間」みたいなものを設けて、特定の日付がどの通用期間に含まれるかチェックするとか、面倒だよ
210:NAME IS NULL
07/11/22 20:09:17
吸収された後でまたスピンアウトみたいな離れ業はあるのだろうか
法的には関連性が切れてるだろうから、新しく起こせばいいのかな？
211:あぼーん
あぼーん
あぼーん
212:NAME IS NULL
07/11/23 23:15:27
>>207
（スレタイ）「頼むから正規化しろよ 第二正規形」
おそらく「取引テーブル」の候補キーは、「会社コード」以外の属性も含まれると
考えられ、
「取引テーブル」の「会社名」は、
「取引テーブル」の「会社コード」にのみ関数従属する為、
「取引テーブル」の候補キーの一部に関数従属することとなる。
よって、その「取引テーブル」は、第二正規形とならない。
ではどうするかというと、「会社テーブル」を履歴で作れば良い。
会社テーブル [ *会社コード、*適用開始日、会社名]（*が主キー）
>>209
新旧「会社コード」もありだろうけど、実装を考えると、
SQLでリンクリストを検索するより、
適用日付で検索した方が明らかにラク。
「取引テーブル」という名前から想像すると、「取引日」という属性を
持ってるだろから、「会社コード」「取引日」と「会社コード」「適用開始日」で
JOINするだけ。
213:NAME IS NULL
07/11/23 23:19:50
212の続き
もともとJOINのコストが無駄という話しからだったが、
その程度のJOINコストが無駄というのは、どんなハード使ってるんだ、
という話しだと思う。
214:NOMO ESTAS NENIO
07/11/24 03:30:10
>212
取引テーブルに会社名列を持たせる設計の場合、取引テーブルの会社名はスナップショット
として持たせるものであり、正規形を崩すものではない。正規形を崩す設計ならば、そもそも
会社テーブルを持たず会社の管理はすべて取引テーブルの中というようになる。
たとえば、商品販売明細テーブルに商品単価を転写するのと同じこと。商品単価を商品テーブル
から引いてくる設計にすると、商品の単価が変わったときに過去の売り上げまで全部書き換わるのを
防ぐためのよく知られた手法を、取引テーブルにおける会社名の持たせ方に応用したものだ。
215:NAME IS NULL
07/11/28 01:35:19
>>214
正規化について言及すると、それは正規形を崩してるだろ。
正規化手法は、”既約でない”関数従属を排除する為の射影である
必要があり、第二正規化された射影を結合することによって、
元の第一正規形の集合が得られる必要がある。
要するに、１事実１箇所になってないと正規形とは言えないってこと。
だから、スナップショットは正規化違反ということさ。
商品単価の話はJOINのコストが気にならないのであれば、
会社名と同様、履歴化して正規化すれば良かろう。
ただ、商品明細のように会社名に比べてデータ量が多く、
マシンの性能とJOINのコストバランスを考えると、
正規化崩して、明細にスナップショットを持たせた方が
良かったというだけだろ。
よろしく
216:NAME IS NULL
08/04/04 08:17:59
依頼とは別でアンケートの集計もお手伝いすることになったんだが、
先輩がエクセル表で
店舗ID 店舗名 質問1 質問2のA 質問2のB 質問2のA 質問2のB・・・
--------------------------------------------------------------------
ってな表を作っていた。
(質問2のAは複数回答有りで、2のBは複数回答した数だけ答えるアンケート。)
データを打ち込む人は、列が足りなかったら足していってた。
何万レコード分もあるから、普通に打つのさえ大変なのに…。
一緒に仕事したことないが、開発やってる時は多分できてることを
雑務になるとできないという不思議…。
いや、開発の時もできてるかどうか知らないが…。
217:NAME IS NULL
08/04/04 20:25:32
> 一緒に仕事したことないが、開発やってる時は多分できてることを
どういうこと？
SPSSとかで集計するときのマルチアンサーのフォーマットって
先輩がやってるようなのが一般的だと思うが
218:NAME IS NULL
08/04/04 22:06:03
先輩は勉強しはじめたばかりだから、
そんな仕事はしてない
219:NAME IS NULL
08/04/05 08:22:30
統計で言うオカレンスとデータベースのタプルは似て非なるものだということだよ。
220:NAME IS NULL
08/04/14 13:44:48
JOINのコストって高いね。
正確に言えば、検索キーワードとソートが必要な検索で
JOINを行うと、インデックスがどれか一つにしか使えないから遅い。
検索キーワードがlikeだったりするとさらに最悪。
非正規化したほうが良い。
221:NAME IS NULL
09/04/11 21:06:53
>>220
釣れますか？
222:NAME IS NULL
09/06/10 17:33:31
>>220
クラウド革命でITエンジニアは監獄行きです
URLﾘﾝｸ(d.hatena.ne.jp)
Google App Engine担当者に聞いた
クラウド環境ではデータベースは「非正規化」して使う？
URLﾘﾝｸ(www.atmarkit.co.jp)
223:NAME IS NULL
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に見立てたプログラム実行ロジックで考えてしまう癖が抜けなくて、
データの順番や個数、アドレス問題はポインタで解決済みの早見表として
オンメモリですべてを掌握していないと納得できないという。
役割分担や分散処理が苦手で、すべて自分のプログラムだけでやろうとする。
そして孤高だったりする。