【より良い】データモデリング【モデルを】

1 ：名無しさん＠お腹いっぱい。：03/07/07 01:41 ID:mnMZZn0T

データベース構築の上流工程であるモデリングについて語らうスレッドです。
モデル作成に関する質問、質問に対する回答、
作ったモデルの自慢、自慢されたモデルの批評など、
モデリングに関すること全般を扱います。

ソフトの使い方に関する話題、物理的なモデルの話題はご遠慮ください。
EX.
　このソフトで○○の機能は〜　→　ソフトウェア板へ
　○○の組み立てが完成して、これから塗装〜　→　模型・プラモ板へ

モデリングツール
　○SVG Cats
　製品情報 http://www.sage-p.com/svgcats.files/svgcats.htm
　DL http://www.vector.co.jp/soft/dl/win95/art/se251284.html
　SVG(ベクター画像をテキストで記述するデータフォーマット。要はXMLの一種)でモデル図を描画するツール

　●ER/Studio
　製品情報　http://www.jsys-products.com/product/erstudio/
　トライアル版DL http://www.jsys-products.com/download/trial/erstudio/

　●AllFusion ERwin Data Modeler
　製品情報 http://www.caj.co.jp/allfusion/erwin/data_modeler.htm
　トライアル版DL http://www.caj.co.jp/registration/allfusion/erwin_pm.htm
　
　●Rational Rose
　製品情報　http://www.rational.co.jp/products/rose/
　評価版請求 http://ops.rational.co.jp/CatalogHassou/f_req.html

　●Microsoft Visio Professional
　製品情報 http://www.microsoft.com/japan/Office/visio/evaluation/
　評価版配布請求 http://www.microsoft.com/japan/office/visio/evaluation/trial/

SVGビューア
　○SVG Viewerプラグイン
　http://www.adobe.co.jp/svg/　ダウンロードページ
　SVG画像を閲覧するためのプラグイン

452 ：NAME IS NULL：2006/09/17(日) 16:38:22 ID:???

勘でやる時点でだめだめな悪寒。

いろんなモデリングのシミュレーションソフトとかあれば設計時に検証しやすくて便利なのにな。

453 ：NAME IS NULL：2006/09/18(月) 11:28:44 ID:???

>>449
基幹ではないが、大手での採用例はあり。
和光市の某自動車メーカとか、麹町の某信販会社とか。
ただ、Ｔ字型を使ったプロジェクトで試行錯誤した経験者がいない状態で
本読んだだけでいきなり実地の大規模システムに適用しようとすると
多大な困難が待ち受けていそうな悪寒が…

454 ：ＴＭ使ってるよ：2006/09/20(水) 14:17:52 ID:6C6LnzZC

ＴＭ（Ｔ字形ＥＲ手法）は、CoddのRDBMに始まって、正規化だけでは解決しない問題を検討している間に、
業務系のシステムでは「コード体系」を使って分析するのが便利って便法を思いついたりしながら発展して
きましたが、根っこの部分ではオブジェクト指向におけるドメインモデリングと繋がっています。
なので、#453 の方が言われる様に、本を読んだだけで見よう見真似で始めるのは、少し辛いでしょう。
できれば、本人から習うことが可能なので、それが一番だと思います。
http://www.sdi-net.co.jp/ に行ってみましょう。

455 ：NAME IS NULL：2006/09/23(土) 17:10:07 ID:???

↑
ＨＰ見てみたけど、本当大丈夫なの？かなり素人っぽいＨＰで
すが。コンサルとかやってるんんだったらもうちょっとマシな
ＨＰにした方がいいような。。。
それに実績も書いてないし。>>453 の和光や麹町の会社ではどれだけ
ＴＭにより実績がでたのかな？
コンサルやるなら会社（？）の規模も知りたいなー

456 ：NAME IS NULL：2006/09/24(日) 12:10:14 ID:???

麹町では使ってはいるが「お絵かきソフト」程度の使われ方。
「Ｖｉｓｉｏの方が書きやすいじゃん」ってノリだから「ＴＭを
導入してビジネスの強み・弱み・・・」なんて程遠い状態。

457 ：NAME IS NULL：2006/09/24(日) 20:16:59 ID:???

>>455
WebPages見てそういう感想抱いたのなら、ＴＭとは出会わなかったことにした方が多分幸せになれる。
いや、煽りや皮肉ではなく、本音ベースの話。
感覚的な「合う」「合わない」っていうのは結構重要な要素かと。

458 ：NAME IS NULL：2006/09/25(月) 00:31:01 ID:???

ＨＰ見たけど「1,000,000 ステッフ゜ 規模の システム であれば、10数名で、6 ヶ月以内に導入する。」
ってのは凄いなー。
事例とかあるといいけどね。

459 ：NAME IS NULL：2006/09/25(月) 01:10:08 ID:???

優秀なエンジニアが集まればとか、そのための費用を出せるならとか前提条件いっぱいだろ？
まあ優秀なエンジニア集めれば、別に何でも短納期でできそうな悪寒。
そういう論点のすり替えをして一儲けするのがコンサルと言えばそうだけど。

460 ：NAME IS NULL：2006/09/25(月) 10:26:51 ID:???

>>458
ステップってコード量だよねぇ？
でコンサルが開発するわけじゃないだろうし、有効なメトリクスなのかね？
コンサルとしてはそういうところ大事だと思うんだが。

461 ：NAME IS NULL：2006/09/26(火) 00:04:22 ID:???

画面数とかテーブル数とかユースケース数とかでないとピンと来ない

462 ：yossy：2006/09/26(火) 00:38:05 ID:3/C3qjqe

皆様始めまして。
DBDesigner4の使い勝手が良かったので日本語化してみました（需要アルカナ・・・）
http://dbdesigner.iimp.jp/
使ってみてご意見いただければと存じ上げます。
Delphiはあまり使ったことがないので安定度が下がっているかもしれません。。
あと、、まだWindows版しかコンパイルしていないです・・・。
Linuxはあまり慣れていないもので。。すみません。。。

463 ：NAME IS NULL：2006/10/02(月) 23:45:41 ID:???

>447

主キーベースのERDを作成する段階では、ナチュラルキーでモデリングし始め、
全属性ERDを作成する段階で、最終的にサロゲートキーに再設計してる。
（最初はナチュラルキーの方がわかりやすいので・・・）

全部サロゲートキーにしてる理由は、
（１）安定性の確保
　　：将来のシステム改善などでの主キー属性の設計変更を、極力抑える。
　　　（候補キー自体が安定していることが前提なのに、変わることあるから・・・）
（２）データへのアクセスコストを抑えたい
　　：ナチュラルキーだと３つ以上のコンポジットとなってしまう場合がある（特に連関エンティティ）
（３）ポリシーの統一
　　：全エンティティを同じポリシーで設計するため全部サロゲートキー

なんて言い訳でサロゲートキーにしてる。

464 ：NAME IS NULL：2006/10/02(月) 23:56:56 ID:???

>>463
>候補キー自体が安定していることが前提なのに、変わることあるから・・・
間違えた。
候補キー　-> 主キー

465 ：NAME IS NULL：2007/05/12(土) 18:00:45 ID:???

保守age

466 ：NAME IS NULL：2007/05/15(火) 19:54:55 ID:/Spdz0dJ

FFの武器を管理したいと思っています。
次回のバージョンアップで他のシリーズも同一のテーブルで管理できるようにしたいです。

現在
武器 (武器ID, 攻撃力, 入手場所)

案1
武器テーブルにシリーズNoを追加して、シリーズNo＋武器IDを主キーにする。
シリーズNo | 武器ID
FF1 | 001
FF1 | 002
FF2 | 001
FF3 | 001
...

案2
武器テーブルにシリーズNoを追加して、武器IDは主キーのまま通し番号とする
武器ID | シリーズNo
001 | FF1
002 | FF1
003 | FF2
004 | FF3

案1だと枝番の作成がめんどうなのですが、きれいにナンバリングされる。
案2だとキーの作成は簡単だが、データの入力順を間違えると気持ち悪いナンバリングになってしまう。

どのような場合にどちらがいいか教えてください。

467 ：NAME IS NULL：2007/05/15(火) 23:21:27 ID:???

>466
複合キー列への外部キー設定は列が増えてしまって、
子表が増えるほど面倒になるから案2がいいなぁ。どうせ
武器IDなんてもとより意味のあるものじゃないんだし。


もういっそ武器IDは乱数を採番するようにしちゃえば気にならないよ。

468 ：NAME IS NULL：2007/05/16(水) 03:44:39 ID:???

1の方がデータ移行は楽そうだな。
最近の流行は2か。アプリケーションフレームワーク的に２のようになってないとあかんものがあるな。

武器リストだと表示順ってのも気にしたいだろうから、
１のテーブルにさらにid列を一つ追加して、
武器IDは表示順的な意味を持たせるのもありかも

469 ：NAME IS NULL：2007/07/08(日) 18:42:56 ID:???

MySQLのDBDesignerに相当するpostgresqlのツールってありますか？
それとも、postgresqlをodbcで接続して、DBDesignerを使っても、幸せになれますか？

470 ：NAME IS NULL：2007/08/07(火) 20:28:30 ID:bIEMzxGi

このスレでも何回か見かけるが、簿記の知識がSEにも要求される場合がある。
独学で簿記を勉強しようとすると、書籍を購入して勉強となりがちだが、
項目が羅列してあり説明は最小限のような簿記の書籍ではなかなか理解は進まない(俺だけか)。
簿記の書籍は不親切であり、そのために資格学校が存続できてる気がする。
資格学校に通わなくても資格学校の通信教育等もあるし、それもそんなに高くはない。

さらに講義形式の勉強で一番手軽なのは、資格学校が出版しているDVDビデオの教材がある。
例えば、以下のような教材がある。

合格テキスト講義DVD日商簿記3級 商業簿記 Ver.4.0(10,500円)
DVD6枚組 TAC出版

俺は本屋で買ったが、amazonにもある。講師は違うが2級もある。
これと対になってる書籍(テキスト)も別に売ってるが、なくても特に困らない。
DVDの講義なので、好きなときに何回でも見れる。
これを見てしまうと、いかに市販の書籍で学ぶことが能率が悪いかということがよく分かる。
おそらく簿記の勉強は書籍ではなくて人の話を聞いて学ぶのが一番よいのでは
ないかと思う。「要はこういうこと」みたいな言葉やくどいぐらいの説明は
なかなか書籍には載りにくい。このDVDのテキストも同じ欠点がある。

例えば減価償却累計額について簿記上の具体例を含めて詳しい説明を書籍で
探そうとすると結構大変だと思う。また、講師がしゃべってくれるわけで漢字の
読み方も問題なくなる。この3級の講師は大変よいと思う。きっちりとよく話してくれている。

スレ違いすまん。

471 ：NAME IS NULL：2007/08/08(水) 00:35:59 ID:???

まぁ、SEが片手間に勉強するのにむいた教材は確かに少ないかもしれんけど、
たかが3級レベルで分かりやすいも分かりにくいも無いと思うんだが・・・

472 ：NAME IS NULL：2007/08/08(水) 21:18:53 ID:???

まったくその通り。10日でわかるとかそういうので十分、
実際は1週間足らず勉強してケアレスミスで落として
90点代後半取れた。

473 ：NAME IS NULL：2007/08/09(木) 22:20:09 ID:MI2mCbx1

初心者です。
物理データモデルの「内部スキーマ」とは、具体的にRDBMSで
いうところの、どのようなオブジェクトなのでしょうか？

どなたか御教授ねがいます。

474 ：NAME IS NULL：2007/08/10(金) 02:23:03 ID:???

テーブルとかカラムとか

475 ：NAME IS NULL：2007/08/10(金) 22:15:11 ID:???

>>473
ANSI/SPARC ３層スキーマのことなら、
概念スキーマ：テーブル
外部スキーマ：VIEW
内部スキーマ：物理ファイル定義（oracleだとセグメントかな）

476 ：473：2007/08/11(土) 00:56:13 ID:Fq8lPKBO

>>475さん
ありがとうございます。
ANSI/SPARC ３層スキーマに関してですが、SQL Server 2000
について「内部スキーマ」なるものが、どのようなオブジェクトを
指すのかご存知なら教えていただけますか？

宜しくお願いします。

477 ：NAME IS NULL：2007/08/11(土) 09:26:15 ID:???

>>476
内部スキーマについて、oracleだとセグメントって書いたけど、
データベース上の特定のオブジェクトや構造を指している
というよりも、索引からセグメントからデータファイルまでの
物理構造のことを指してる。
SQL Serverは詳しくないのだけど、同じようにセグメント
（oracleでは表領域に相当）からデータベースデバイス？までの
物理構造のことを指しているのではないかな。

478 ：NAME IS NULL：2007/11/19(月) 21:31:13 ID:YgXjo0NC

次のケースの一般的なデータモデルをご教授ください。
長文で申し訳ありませんが宜しくお願いします。

<前提条件>
製造業向けの部品加工を想定(在庫関連の処理は無し）
製品･部品･工程･実績の４つのエンティティがあるとして、、、

製品 … 製品というよりは製造指示Noのようなもの
部品 … 製品を構成する部品です。(※一般的なBOMのような親品目,子品目を再帰で保持するような複雑な構造ではない)
工程 … 部品を加工するための加工工程手順です。(手順1:旋盤, 手順2:マシニング...)
実績 … 加工工程に対する実績(労務費、労務時間)

４つのエンティティの関連は次のような階層構造を考えています。
(※この考え方がおかしい場合はご指摘ください)

　製品 → 部品 → 工程 → 実績
(1:n) (1:n) (1:n)

部品には材料や購入品といった部品区分があり、データ属性が異なるため、
部品をスーパータイプ、材料･購入品をサブタイプで持たせようと思っています。
　製品 → ＋部品(部品id(PK), 部品区分...) → 工程 → 実績
｜
＋材料(部品id(PK), 仕入先cd(FK), 寸法...)
　 ＋購入品(部品id(PK), 仕入先cd(FK), 購入品品番(FK)...)

*** 質問１***
各エンティティの主キー(PK)をどのように設けるのが一般的なのでしょうか？
上記のようなデータ構造の場合の一般的な主キーの設け方をご教授ください。
今考えているのが�@と�Aの方法です。

�@各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる。
製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 製品id(FK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 製品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 製品id(FK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 製品id(FK), 部品id(FK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

�A各エンティティの主キー(PK)を複合キーで持たせる。
製品: {製品id}(PK), 製造指示No, 型番...
部品: {製品id, 部品id}(PK), 部品区分, 部品cd, 部品数...
材料: {製品id, 部品id}(PK), 仕入先cd(FK), 寸法...
購入品: {製品id, 部品id}(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: {製品id, 部品id, 工程id}(PK), 工程cd, 工程手順No, 標準時間, 数量...
実績: {製品id, 部品id, 工程id, 実績id}(PK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

そもそも考え方がおかしい場合はご指摘ください。

479 ：NAME IS NULL：2007/11/19(月) 21:32:24 ID:YgXjo0NC

続きです。
*** 質問２***
次の原価をリアルタイムで把握したい場合には原価データをどのように保持するのが一般的なのでしょうか？
(※ここでは外注費は無いもとする)

　1.製品別原価(製品別の材料費計＋購入品費計＋労務費計)
　2.部品別原価(部品別の材料費計＋購入品費計＋労務費計)
　3.工程別原価(工程別の労務費計)

考えているのは次のとおりです。

�@製品エンティティに"材料費計", "購入品費計", "労務費計"のデータ項目を持たせる。
�A部品のスーパータイプエンティティに"材料費計", "購入品費計", "労務費計" のデータ項目を持たせる。
�B工程エンティティに"労務費計"のデータ項目を持たせる。

各計データの更新はトリガーやストアドにて行う


そもそも考え方がおかしい場合はご指摘ください。
以上、宜しくお願いします。

480 ：NAME IS NULL：2007/11/20(火) 02:27:57 ID:???

質問１

正規化をきちんとするなら、�@の材料と購入品には製品idは入らないはず。
俺なら他のテーブルとの一貫性を保つために

材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...

とする。でも、部品idにユニーク制約をつけなきゃいけないのでそこを手間と感じるかどうか。

�@か�Aかはどっちでもいいけど、最近は�@が主流。
処理側のフレームワークと言うかプログラムロジックに便利な方を選択。

質問２

集計用のテーブルを別に作るべき。
完全なリアルタイムにせずに、例えば１０分ごとに集計バッチをまわすとか、
Oracleならマテビューを使うとかする

481 ：NAME IS NULL：2007/11/20(火) 14:49:55 ID:/GHn6NrO

>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問１について
なるほど、確かにデータ編集時に、複合主キーより単独主キーでアクセスした方が
SQL文も簡単に記述でき、何かと便利が良さそうですね。

教えて頂いた方法で実装しようと思うのですが、
�@の方法(各エンティティに単独の主キー(PK)を設けて、親への参照キー(FK)をそれぞれ持たせる)で
きちんとした正規化を行う場合、工程の製品id(FK) と 実績の製品id(FK), 部品id(FK)も要らなくなり、
次のようになるはず？(１階層上の親id のみ 持たせる)
この理解で問題ないでしょうか？

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 材料id(PK), 部品id(FK), 仕入先cd(FK), 寸法...
購入品: 購入品id(PK), 部品id(FK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

もしくは、材料id, 購入品id は持たず、次のようにする。

製品: 製品id(PK), 製造指示No, 型番...
部品: 部品id(PK), 製品id(FK), 部品区分, 部品cd, 部品数...
材料: 部品id(PK), 仕入先cd(FK), 寸法...
購入品: 部品id(PK), 仕入先cd(FK), 購入品品番(FK)...
工程: 工程id(PK), 部品id(FK), 工程cd, 工程手順No, 標準時間, 数量...
実績: 実績id(PK), 工程id(FK), 加工状況flg, 数量, 作業者cd, 機械cd, 着手日, 労務費, 労務時間...

482 ：NAME IS NULL：2007/11/20(火) 14:51:01 ID:/GHn6NrO

続きです。
>>480
遅くなりまして申し訳ございません。
レスありがとうございました。

質問２について
やはり集計用の別テーブルを設けた方がいいのですね。
今回のケースで集計テーブルを用いるとすれば、次のような感じでよろしいですか？
集計元テーブルと集計先テーブルは(１：１の関係）になる。
また本来は集計テーブルに主キーの項目として集計日を含むと思うのですが、
今回は集計日が要らないので外します。

製品: 製品id(PK)... → 製品別原価: 製品id(PK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品id(PK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程id(PK), 労務費計...

もしくは、集計テーブルにも単独主キーを設けて、次のようにする。

製品: 製品id(PK)... → 製品別原価: 製品別原価id(PK), 製品id(FK), 材料費計, 購入品費計, 労務費計...
部品: 部品id(PK)... → 部品別原価: 部品別原価id(PK), 部品id(FK), 材料費計, 購入品費計, 労務費計...
工程: 工程id(PK)... → 工程別原価: 工程別原価id(PK), 工程id(FK), 労務費計...


以上、質問ばかりで申し訳ございませんが
宜しくお願いします。

483 ：NAME IS NULL：2007/11/20(火) 20:40:10 ID:wWhiZNbu

パソコンショップならここ！！
http://want-pc.com

484 ：kmyPJqxBGr：2007/11/20(火) 21:35:11 ID:???

6ehkeP <a href="http://dphojlgmqyum.com/">dphojlgmqyum</a>, [url=http://dciuxyoglilw.com/]dciuxyoglilw[/url], [link=http://jupungwigput.com/]jupungwigput[/link], http://tltjzxqojqqo.com/

485 ：YDdMTWcmpUvtToARj：2007/11/20(火) 21:57:55 ID:???

aVR2l3 <a href="http://mxmpbpvmprfm.com/">mxmpbpvmprfm</a>, [url=http://yrgjgiqgeori.com/]yrgjgiqgeori[/url], [link=http://xppokryehkqp.com/]xppokryehkqp[/link], http://pnlqzfhrtylu.com/

486 ：NAME IS NULL：2007/11/21(水) 00:24:58 ID:???

>>481
OKと思われ。

>>482
OKと思われ。まぁ、こっちは単独主キー無くてもいいかも知れんが

487 ：NAME IS NULL：2007/11/21(水) 10:43:07 ID:???

>>486
レスありがとうございました。
これでスッキリしましたので先に進めそうです！！

488 ：kkEaqflyQ：2007/11/23(金) 04:52:59 ID:???

http://ublog.union.edu/elpinner/88 buy zovirax

489 ：kAXUAXtktXfWiAc：2007/11/23(金) 10:57:18 ID:???

http://iqlveq.cn cheap mp3 downloads

490 ：XRXQZTpLvYJra：2007/11/23(金) 12:14:42 ID:???

http://itdvmb.cn mp3 player downloads

491 ：qgNOgKJitye：2007/11/23(金) 21:16:42 ID:???

http://kgnsye.cn/imax-california.html Imax california
http://kgnsye.cn/california-dept-of-corporation-htm.html California dept of corporation htm
http://kgnsye.cn/single-family-homes-carlsbad-california.html Single family homes carlsbad california
http://kgnsye.cn/archangel-tattoo-design.html Archangel tattoo design
http://kgnsye.cn/blue-book-pricings-for-atv.html Blue book pricings for atv

492 ：vnlCkSByPPMG：2007/11/25(日) 00:46:56 ID:???

http://bfsnbw.cn/mp34 free memory

493 ：NAME IS NULL：2008/02/10(日) 12:22:27 ID:???

MySQL4.1、5.0でも　DBDesignerは使えますか？

>>384 に同じ現象が書かれているのですが・・・
バージョンアップされてないからなぁ＾＾；

494 ：NAME IS NULL：2008/05/23(金) 04:29:26 ID:P38jVWZR

A C

495 ：VQiYlHzPZa：2008/06/01(日) 13:42:47 ID:???

n1ywUN <a href="http://vdgsdgcxvewl.com/">vdgsdgcxvewl</a>, [url=http://ltldczvyogvo.com/]ltldczvyogvo[/url], [link=http://dznjgohehaza.com/]dznjgohehaza[/link], http://whxrulsmcetw.com/

496 ：NAME IS NULL：2008/07/07(月) 17:23:41 ID:???

住所録のデータベースのモデルです。
取引先の会社とその担当者、お客様とその家族、
と、全部で4つのテーブルを作成しました。
それぞれのテーブルには、名前や電話や住所などの
列を並べました。

そこで疑問になったのが。
取引先の住所と担当者の住所は、共通する事もある（し違う事もある）。
家族の住所と個人の住所は、共通する事もある（し違う事もある）。
と、考えると。
住所部分のみでテーブルを作成して、4つのテーブルから
参照した方がいいのかな？とも思ったのですが、いかがでしょう？

497 ：NAME IS NULL：2008/07/07(月) 22:08:49 ID:???

そうね。それなら取引先が複数住所もってるケースにも対応できるね

498 ：NAME IS NULL：2008/07/07(月) 22:38:19 ID:???

取引先が複数住所を持ってるケースは考えていませんでしたが。
確かにおっしゃる通りで、良さそうですね。

また、営業所が移転した場合や家族が引っ越しした時に、
同じ住所テーブルを示していれば、個人の住所も一括で
修正されますね。ありがとうございました。

499 ：NAME IS NULL：2008/09/06(土) 12:04:21 ID:???

1レコードに開始/終了時刻を持って「状態」を記録するメリットって何？
開始/終了イベントテーブルにそれぞれ発生時刻を記録するほうがいいと思うんだけど

500 ：NAME IS NULL：2008/09/08(月) 00:51:51 ID:???

>>499
イベントテーブルにそれぞれ記録するほうがいいのは
たとえばどんな時でしょうか？

501 ：NAME IS NULL：2008/09/08(月) 23:23:38 ID:???

>>499
抽出したエンティティの意味的な違いに優劣はないから実用上のメリットで言うと、
所要時間を求めるようなクエリでjoinを節約できるとか。
逆に挿入/更新でコストはかかっているわけで、メリット/デメリットともに
事前集計表と似たようなもの。