マスタの履歴管理パターン（その１） - Xupper技術サポート部のページ
久しぶりにデータモデルの話題です。 ここでは、マスタの履歴管理について、いくつかのパターンを挙げて説明したいと思います。 ■履歴保存用のエンティティを追加し管理（パターン１） 商品エンティティのキーに適用開始年月日を保持し、変更があったタイミングでレコードを追加することにより商品の変更履歴を管理します。 【図１】 ①ある１レコードについて、ある時点の全ての属性の値を、履歴として管理することになります。 ②参照するトランザクション（受注明細）に履歴（商品履歴）の識別子を持たないため、履歴情報が存在する状態で、過去のマスタ情報を参照するためには、受注.受注日と商品履歴.変更日付で検索する等が必要となります。 ■履歴保存用のエンティティを追加し管理（パターン２） パターン１のバリエーションですが、履歴管理用のエンティティのキーを「履歴管理用SEQ」とします。 【図２】 この場合は、参照するトラン
capsctrl - T字形ER手法（TM）
お絵かき（構文論）のみに終始している。 その人の価値観で異なるお絵かきをしている。 30年前のインデックス（によるファイルアクセス）の概念でデータベース設計を行っている。 1つの手法を使って、「事業解析」「データ構造設計」「プログラムのI/O化」の3つを同時に実現する。 ここでモデル（データ構造）とは 指示規則（意味論）＋生成規則（構文論） TM構文論 TM'（ダッシュ）意味論 TMの限界 コード体系が悪すぎたらモデルにも影響してしまう。 「プログラムのI/O化」といっても良くて70%の実現。 モデルはプログラムに対して強制力がない NESTED-IFが出たらプログラムを中止させること NULLの存在を認めている コッドの関係モデルは、ドメインの直積でタプルのセットを構築する。 その場合、nullの入ったタプルが存在することになってしまう。 nullの正確な意味は、不定(undefined
関数従属性は統辞論的（シンタックス的）か - 開発思考実験日記
モデリングのスタイル：意味論と統辞論について 上記でERモデルを作成する方法として、『関数従属性』を利用する方法と『リソース・イベントを区別』する方法について言及されています。 いくつか気になる点があり、その中でも「関数従属性」が「統辞論的な枠組み」としている点について、以前から関数従属性の判断は案外難しいと感じていたので興味もあって少し考えてみました。 ここでは、ある属性が関数従属しているかの判断を統辞論的（シンタックス的）にできるということをいっているのか、関数従属が判断された属性をシンタックス的に正規化できるとしているのか良く分からなかったのですが、前者については従属しているかの判断はケースごとに違う可能性があり意味的な判断が必要だと思っています。 ER図を作成する上ではもちろん前者・後者両方行う必要があり、関数従属性は統辞論的（シンタックス的）とするのであれば、ある属性が関数従属し
モデリングのスタイル：意味論と統辞論 - 設計者の発言
ＤＯＡ（データ中心アプローチ。ＤＢシステム設計においてＤＢ構造の検討を優先させる手法）の考え方では、それぞれのテーブル（エンティティタイプ）について、「リソース」か「イベント」かを区別するやり方が主流である。 主流派の向こうを張ろうってわけでもないのだが、筆者はデータモデリング手法の前提としてそれらを区別しない。なぜかというと、それらの区別が各テーブルの「絶対的な特性」ではなく、「相対的な傾向」でしかないと考えるからだ。ある文脈ではイベントとみなされるテーブルが、別の文脈ではリソース的なものに見えるなんてことが実際にはある。 たとえば、イベントの代表であるような「受注」や「売上」も、一定期間向けキックバックの計算過程においては、「顧客」同様にリソース的なものとして見える。また、リソースの代表であるような「品目」も、品目分類や商品企画を云々するモジュールにおいてはイベント的なものに見える。
2007-08-24
昨日のエントリについてさらに考えていたのだが、次の三つの切り口で整理できるのではないだろうかと思いはじめた。 内的な性質 or 外的な性質 静的な情報 or 動的な情報 区分の内容が排他的か否か（組み合わせが発生するか否か） まずひとつ目の内的な性質か外的な性質かだが、これによってエンティティ間に依存性を持たせるかが決まる。次に静的か動的かによってその項目に履歴が必要かいなかが決まる。そして三つ目、区分の組み合わせがあるか否かによって単項目にできるか交差エンティティを用意しなければならないかが決まる（本当は配列がいいけど……）。 で、それぞれの場合でどのようなテーブル構成にするかだが……疲れたのでまた明日(w 某会計パッケージにて貸借対照表の利益計算に資本と負債＋資本の貸借差額を使っていないので、どうしてなのかと聞いたら、全社で見たらきちんと利益が計算できるが部署別だと資本がないなどの理由
2007-08-22
Traditionalなデータベース設計を行う上でいわゆる区分と呼ばれるものがあるわけだが、ひとえに区分といっても一概に言えないのかもしれないなどと考えるにつれ、とりあえず整理してみるのが良いんじゃないかと思い始めた。 というわけで、とりあえず作ってみたのがこれ。 種類(type)：性質に従って分けること。変化しない。 分類(category)：基準に従って似たものどうしにまとめて分けること。中長期的には変化する。 継承(class)：性質に従って体系付けること(is-a)。変化しない。 属性(attribute)：所有する性質(has-a)。変化しない。 状態(state)：現在の状態。短期間で動的に変化する。 うーむ、微妙だ。英単語本来の意味で言えばclassは継承関係を表すものというよりは階級を表すものらしいのだが、ここではプログラミング言語的な解釈によった（おそらくclassifi
在庫テーブルの存在意義というか、DBの現在データと履歴データの違いというか。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） あるところで、こういう話を聞いたことがある。 「在庫テーブルは不要である。入庫データと出庫データの総和にすぎないから」 これは、極論だけど、（創業時からの入庫データの総和ー出庫データの総和など、求められるわけではないので）仮に、求められたとしても（つまり、創業時データから保持できる巨大なDBと、総和を求められる超高速計算機があったとして）、果たして、そうなのか？ 入庫データと出庫データから、在庫を求めた場合、在庫を求めた瞬間は、現在値（現在の在庫数）です。でも、求めた瞬間に、過去の値になります。 そのあとに、出庫されたり、入庫されたりするかもしれないので・・ たとえば、在庫が２個あったら、出庫して、商品を発送する。 なかったら、注文自体をキャンセルするということを考える。 このと
予算システムのデータベース設計 - A.R.N [日記]
はぶ式で行くと「予算策定」というイベントがあって、みんながその予算策定というイベントを次々と実施していくような感じになるのだろうか。部署の担当者が予算入力をする度に予算策定というエンティティにレコードが一行増えるわけだ。 うーむ、さすがにそれは違和感があるな。 予算策定のイメージから言えば、どちらかというとひとつの壁にみんなで落書きしてひとつの絵を作りましょうみたいな感覚なので、個別のイベントがパカパカ起きるのとは違うような気もするのだよなぁ…… もしかして社長が予算策定というイベントを実行し、ワークフロー上にその中身が回されながら埋められていくと考えるべきなのかな。そう考えると、会社で予算策定の号令がかけられたら予算策定というエンティティにレコードが一行追加されることになる。
![予算システムのデータベース設計 - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/9775fba61edc235eb16ef6b91d49f56db0b4b136/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064324350%2F1555805081)
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
A.R.N [日記] - ID付与は設計技法ではなく実装技法
なのではないかと主張してみるテスト。 ここではぶ先生に否定されてしまうと、私は第三勢力アクシズとして動かなければならんのですが、男のハマーンはいやですか（←いやです） 論拠は二つ。 どのようなモデルでも誘導的にID方式に変更できる はぶ先生がidとはROWIDのことだ、と言っているように単にRDBMS上にオブジェクトモデルと相似の構造（ポインタによるリレーション）を作るだけなんだから、当たり前の話ではある。複合主キー派の方は、全部サロゲートキーにするなんて！ という反応を見せるわけだけど、ID派の言うIDとサロゲートキーは似て非なるものなのだと思う。旧来の主キーの役割はユニークキーが担うだけの話なわけだし。T-ERで論理モデルを作成した後に、IDを主キーにして作って、参照先をIDにするようにモデルを修正するだけでT-ER的に正しくなおかつID方式のモデルが出来上がる。モデリング技法によらな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 基礎からのデータベース設計 (DB Press): 栄司,高橋, 美紀,飯室: 本
Amazon.co.jp: ERモデリングvs.UMLモデリングデータベース概念設計: 真野正: 本
ルーツ本 - 今年も僅かだはぶにっき
はてなブログ | 無料ブログを作成しよう