モデリングのスタイル：意味論と統辞論 - 設計者の発言
ＤＯＡ（データ中心アプローチ。ＤＢシステム設計においてＤＢ構造の検討を優先させる手法）の考え方では、それぞれのテーブル（エンティティタイプ）について、「リソース」か「イベント」かを区別するやり方が主流である。 主流派の向こうを張ろうってわけでもないのだが、筆者はデータモデリング手法の前提としてそれらを区別しない。なぜかというと、それらの区別が各テーブルの「絶対的な特性」ではなく、「相対的な傾向」でしかないと考えるからだ。ある文脈ではイベントとみなされるテーブルが、別の文脈ではリソース的なものに見えるなんてことが実際にはある。 たとえば、イベントの代表であるような「受注」や「売上」も、一定期間向けキックバックの計算過程においては、「顧客」同様にリソース的なものとして見える。また、リソースの代表であるような「品目」も、品目分類や商品企画を云々するモジュールにおいてはイベント的なものに見える。
distributed-design
１．概要 １．１ 提案する設計方法の考え方 現在、ビジネス・アプリケーションの分析、設計方法としてよく利用されているのは構造化設計とオブジェクト指向設計である。構造化設計技法は、1970年代にソフトウェアの設計に工学的な手法を取り入れ、標準的なルールに基づいて仕様を記述するという重要な役割を果たし、既に長い間開発現場で利用されてきた。一方、オブジェクトの概念が導入されたのは、1980年代の後半からである。当初は、AdaやSmalltalkによるオブジェクト指向言語による設計のために利用され、純粋にオブジェクトを中心に設計する手法が提案された。この方法は、現実世界に存在するモノがコンピュータの中で構築したオブジェクトの写像と捉えることによって、両者が自然に対応づけられ、GUI(Graphic User Interface)などを用いたシステムでは非常に有効な設計方法として利用された。 ところ
「関連クラス」をデータモデルで解き明かす（前編） - 設計者の発言
ＵＭＬのクラス図に登場する「関連クラス」はわかりにくい。オブジェクト図を描いてもなかなか直感的にイメージできない難物だが、同じ内容のデータモデルと突き合わせることで意味が明確になる。その過程で、データモデリングにおいて識別子を重要視することの意義もわかってくる。 ◆参照関係 まずは「関連クラス」が関係しないノーマルなパターンで見よう。データモデルでの「参照関係」の例と、それに対応するクラス図だ。 データモデルのほうがデータ項目が多いが、それはデータモデリングにおいては「識別子（データモデルで水色に示されている項目）」をエンティティの認識単位とするためだ。だから、データモデリングにおいてエンティティを一覧する作業は、有効な識別子を一覧する作業そのものと言っていい。 いっぽう、クラス図において識別子にもとづくユニーク性は問題にされないため、データモデルで認識されるような識別子が載っていないこと
★DOAとXEAD Driverに関する私的な想い
データ指向設計（DOA)でテーブルと機能の仕様書を作成するだけで、 プログラミングせずに業務システムが動く というツールが ＸＥＡＤ Ｄｒｉｖｅｒ です。 夢のようなツールだと感じられるでしょうが、実は渡辺氏の最初の出版作である「 業務別データベース設計のためのデータモデリン...
システムの仕様情報を正規化する - 設計者の発言
「DB構造の正規化」は業務システム設計の眼目である。それはデータ項目間の関数従属性をDB構造に反映させるために必要な配慮であり、これを怠ると、データの矛盾やアプリの複雑化にともなう保守性の低下といったさまざまな問題が生じる。いわゆる「正規化崩し」を行うにせよ、基準となる正規形の認識なしでは失敗する。以上は事実として広く知られるようになった。 ところが「システムの仕様情報」を正規化することの重要性はほとんど認識されていない。従来の仕様書の分厚い束には、記述の重複やそれゆえの矛盾があちこちに埋まっている。DB構造だけでなく仕様情報の構造についても、関数従属性にしたがって"one fact in one place"の形に正規化される必要がある。何のためか。矛盾を除くとともに、仕様の作成・保守コストを最小化するためだ。 たとえば「テーブルＴ」のフィールドとして「XX単価」と「XX数量」があって、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF] 椿正明のDOA人生40年
