データモデルのまとめ情報

データモデル』の解説

データ・モデルは、班・要員間の意思疎通のための事業データを文書化し、組織化し、そして特にどのようにデータを格納し利用するかの、応用ソフト設計のための計画として使うソフトウエア工学の一つの抽象モデルである。

Hoberman (2009)によれば、「データ・モデルは、組織内での意思疎通を改善し、それによってより柔軟で安定したアプリケーション環境に導く、真の情報の部分集合を正確に説明するシンボルとテキストの集合を使う、事業とIT専門家の両方のための、道筋を見つける道具である。」

データ・モデルは、データまたは構造化データの構造を明示的に決める。データモデルの代表的な応用は、データベース・モデル情報システム の設計、及びデータの交換を可能にすることを含む。通常データ・モデルは、データ・モデリング言語によって規定する。

コミュニケーション精度は、データ・モデルがデータを使い交換する応用へもたらす2つの主要な利益である。データ・モデルは、異なる背景と異なる経験水準からなる事業要員がお互い意思疎通する媒体である。

精度は、データ・モデルにおける用語と規則をただ1つの方法で解釈することができ、そして曖昧さが無いことを仮定する。]]

データ・モデルの主な目的は、データの定義とフォーマットを提供することによって、情報システムの開発を支援することである。West とFowler (1999)によれば、「もしこれがシステムを通して一貫して行われたら、そこでデータの互換性が達成されうる。もし同じデータ構造がデータの格納やアクセスに使われるなら、そこで異なるアプリケーションがデータを共有できる。これの結果は上で示される。しかしながら、システムとインタフェースは、しばしば、構築し、運用し、そして維持するため、それらがあるべきより多くのコストを費やす。それらは、事業を支援するよりむしろ制約するかもしれない。1つの大きな原因は、システムとインタフェースに実装されるデータ・モデルの品質が貧弱だったことである。」。

  • 概念スキーマ : モデルのスコープである、1つのドメインの意味を記述する。たとえば、それは1つの組織あるいは産業の関心領域のモデルかもしれない。これは、そのドメインにおける重要なものの種類を表現するエンティティ・クラスと、一対のエンティティ・クラス間の関連について関連からなる。概念スキーマは、そのモデルを使って表されうる、事実と命題の種類を特定する。そのセンスで、それは、そのモデルのスコープによって限定される1つのスコープの、1つの人工的'言語'で許される表現を定義する。概念スキーマの利用は、事業ユーザーと共に強力なコミュニケーション・ツールとなるよう進化する。しばしば、「主題領域モデル (SAM) 」または「ハイレベル・データ・モデル (HDM)」と呼ばれるこのモデルは、事業ユーザーが全体的アプリケーション開発または事業体イニシアティブの一部として、コア・データ概念、ルール、及び定義をコミュニケートするのに使われる。オブジェクトのいくつかは、少なくかつ主要な概念に焦点を当てるべきである。大変大きな組織や複雑なプロジェクトのため、モデルは2ページ以上にまたがるかもしれないが、1ページにこのモデルを限定しようと試みる必要がある。
  • 論理スキーマ : 特定のデータ操作技術によって表現されるような、意味論を記述する。これは、他のものの間の、テーブル及びカラム、オブジェクト指向クラス、及びXMLタグの解説からなる。
  • 物理スキーマ : データが格納される物理的手段を記述する。これは、パーティション、CPU、表空間、あるいはそのようなことに係わる。

ANSIによれば、このアプローチの重要性は、3つの観点がそれぞれ相対的に独立であることを可能にすることである。格納技術は、論理的あるいは概念モデルのいずれにも影響することなく変更できる。テーブル/カラム構造は、概念モデルに(必要なら)影響することなく変更できる。いずれの場合も、もちろん、その構造は他のモデルとの一貫性を残さなければならない。テーブル/カラム構造は、エンティティ・クラスや属性の直接変換からは異なるかもしれないが、しかし、それは究極的に概念エンティティ・クラス構造の目的の外で扱わなくてはならない。多くのソフトウエア開発プロジェクトの初期段階は、の設計を強調する。このような設計は、で詳細化される。その後段で、このモデルは、に変換されるかもしれない。しかしながら、概念モデルを直接実装することも可能である。

歴史

情報システムのモデリングにおける最も初期の業績の1つは、「情報を規定する正確で抽象的な方法とデータ処理問題の時間的特徴」を論じた、Young と Kent (1958) によって為された。彼らは、「ハードウエアのあらゆる部分を取り巻く問題のためのに可能となるべき1つの表記法」を作ることを望んだ。彼らの作業は最初、異なるハードウエア・コンポーネントを使う異なる代替的実装を設計するための、1つの抽象仕様と不変の基盤を作る努力であった。情報システム・モデリングにおける次のステップは、「データ処理のシステム・レベルで、マシン独立の問題定義言語の正しい構造」を開発すると言う、本質的にYoung と Kentと同じことを目指した、1959年に編成されたIT業界コンソーシアムである、CODASYLによって行われた。これが1つの特定な情報システムの情報代数学 (Information_algebra) の開発に導いた 1960年代の終わりに向けて、エドガー・F・コッドは、彼のデータ編成の理論を練り、一階述語論理に基づいたデータベース管理のためのリレーショナル・モデルを提案した。

1970年代に実体関連モデルが、1976年にピーター・チェンによって初めて提案され、概念データ・モデルの新しいタイプとして出現した。実体関連モデルは、データベースに格納される情報ニーズや情報のタイプを記述するための、 要求分析中の情報システム設計の最初のステージで使われた。この技術は、あらゆる概念体系 、すなわち、一定の関心の領域のための、概念の全貌と分類とそれらの関連、を記述できる。

1970年代、G.M. Nijssen は、「自然言語情報分析手法」(NIAM) を開発し、そして1980年代にそれを発展させたオブジェクト役割モデリング (ORM) を Terry Halpin と一緒に開発した。

Jan L. Harrington (2000)によれば、更に1980年代に、「オブジェクト指向パラダイムの開発が、我々がデータとデータに作用する手続きを見る方法に基本的な変化をもたらした。伝統的に、データと手続きは:データベースにデータとそれらの関連、アプリケーション・プログラムに手続きをと、別々に格納されていた。オブジェクト指向では、しかしながら、そのデータと共にエンティティの手続きを組み合わせた。」

データベース・モデル

データベース・モデル (database model)は、どのようにデータベースが構造化され、使われるかを記述する理論または仕様である。いくつかのそのようなモデルは提案されてきた。広く知られたモデルは以下を含む:

Image:FigFileConvert000a.svg|フラット・モデル

Image:Hierarchisches Datenbankmodell.svg|階層型データモデル

Image:Network DB model.svg|ネットワーク型データモデル

Image:Relational model concepts.png|リレーショナル・モデル

これは、厳密にはデータ・モデルとして認められないかもしれない。フラット(またはテーブル)モデルは、与えられたカラムの全要素が、同じような値であり、そして1つの行の全要素が互いに関連していると想定される、データ要素の単一の2次元配列で構成される。
  • 階層型データモデル: このモデルにおけるデータは、それぞれ同じレベルのリストに特定の順序でレコートを保持するネスト化と並び替えフィールドを記述するそれぞれのレコードへの単純な上昇リンクを暗示する、ツリー構造に組織化される。
  • ネットワーク型データモデル:このモデルは、レコードとセットと呼ばれる、2つの基本的概念を使うデータを組織化する。レコードはフィールドを含み、セットはレコード間の、1は所有者、多はメンバーである、1対多の関連を定義する。
  • リレーショナル・モデル: は、一階述語論理に基づくデータベース・モデルである。その中核アイデアは、とりうる値と値の組み合わせへの制約を記述する、有限の述語変数を超える述語の集合としてデータベースを記述することである。

Image:Company codm.gif|概念指向モデル (Concept-oriented model)

Image:Star-schema.png|スタースキーマ

  • 概念指向モデル (Concept-oriented model) : リレーショナル・データベース・モデルと類似するが、オブジェクト、クラス、及び継承が、データベース・スキーマと問い合わせ言語で直接サポートされる。
  • スタースキーマは、データ・ウエアハウス・スキーマの最もシンプルなスタイルである。スタースキーマは、いくつかの「事実テーブル」(おそらく1つのみであり、その名前を正当化する)がどんな数の「次元テーブル」を参照する。 スタースキーマは、重要な雪形スキーマの特別なケースと考えられる。

データ構造ダイアグラム

thumb

データ構造ダイアグラム (DSD) は、エンティティとそれらの関連、及びそれらを拘束する制約 (constraints) を文書化する図式表記法を提供するよって、概念データモデルを記述するため使われる1つのダイアグラムでありデータ・モデルである。DSDの基本的図形要素は、エンティティを表すボックスと、関連を表すである。データ構造ダイアグラムは、複雑なデータ・エンティティを文書化するため最も有用である。

データ構造ダイアグラムは、実体関連モデルの1つの拡張である。DSDで、関連が、エンティティ群を束ねる制約を規定する属性から構成されるボックスとして描かれる一方で、属性は、エンティティの、外側でなく、内側で規定される。実体関連モデルは、堅牢である一方で、関連同士の制約を規定する方法を提供せず、そして、いくつかの属性を持つエンティティを表現するとき視覚的に扱い難くなる。DSDは、DSDが1つのエンティティ内での要素の関連に焦点を当て、そしてユーザーに各エンティティ間のリンクと関連を完全に見せることができるのに対して、実体関連モデルでは異なるエンティティ間の関連に焦点を当てる点で、異なる。

データ構造ダイアグラムを表現するため、多重度 (cardinality) を定義する方法に顕著な違いを伴う、いくつかのスタイルがある。選択は、鏃 、逆向き鏃 (鳥足) 、あるいは多重度の数値表現の間に存在する。

thumb

実体関連モデル (ERM)

実体関連モデルは、構造化されたデータを表現するためソフトウエア工学で使われる、1つの抽象概念スキーマ(または、意味的データモデル (semantic data model) )である。実体関連モデルのため使われるいくつもの表記法が存在する。

地理的データ・モデル

地理情報システムにおけるデータモデル (data model) は、データとして地理的オブジェクトまたは地表を表現するための数学的概念である。たとえば、

  • ベクターデータ・モデルは、点、線、及び多角形の集合として地形を表現する;
  • ラスターデータ・モデルは、数値を格納するセル・マトリックスとして地形を表現する;
  • そして不規則三角網 (TIN) データ・モデルは、連続、非重複の三角形のセットとして地形を表現する。

Image:Groups relate to the process of making a map.jpg|地図作成プロセスに関係するグループ

Image:NGMDB data model application.jpg|NGMDB データ・モデル・アプリケーション。

図は、今日のデータ・モデルが開発され、そして使われる方法を描いている。概念データモデル (conceptual data model) は、開発されているアプリケーションのためのデータ要求に基づき、おそらくアクティビティ・モデルの文脈で開発される。そのデータモデルは通常、エンティティ・タイプ、属性、関連、完全性ルール、及びそれらのオブジェクトの定義から成る。これは、そこでインタフェースまたはデータベース設計のためのスタート・ポイントとして使われる

  1. データ・モデル理論、すなわち、どのようにデータが構造化されそしてアクセスされるかの形式的な記述。
  2. データ・モデルインスタンス、すなわち、ある特定なアプリケーションのための特定なデータ・モデルインスタンスを生成するためにデータ・モデル理論を適用すること。

データ・モデル理論は、3つの主要なコンポーネントを持つ:。

データ・フロー・ダイアグラム (DFD)

thumb

データ・フロー・ダイアグラムは、プログラムのコントロールの流れを示すフローチャートとは違い、情報システムを通してのデータの「流れ」を示す、図式表現である。データ・フロー・ダイアグラムはまた、データ処理 (構造化設計) の可視化 (visualization) のため使われうる。データ・フロー・ダイアグラムは、Martin と Estrin の コンピュータの「データ・フロー・グラフ」に基づいた構造化設計のオリジナル開発者である、Larry Constantine (Larry Constantine) によって考案された。

それは、システムと外側のエンティティ間の相互作用を最初に示す、文脈レベル・データ・フロー・ダイアグラム (context-level Data flow diagram) を描く共通の実践である。DFDは、どのようにシステムが、分割された部分間のデータの流れに着目してより小さな部分に分割するかを示すため設計される。この文脈レベル・データ・フロー・ダイアグラムは、そこでモデル化されているシステムをより詳細に示すため「激増」される。

情報モデル

) 情報モデルの例。]]

情報モデルは、データ・モデルの一つのタイプではないが、一つの代替モデルより多いかまたは少ない。ソフトウエア工学の分野でのデータ・モデルと情報モデルの両方は、特性、関連、及びそれらで実行され得る操作を含め、エンティティ・タイプの抽象であり、公式表現である。モデル内のエンティティ・タイプは、ネットワーク内の機器のような、実世界のオブジェクトの種類かもしれないし、またそれらは、勘定システム内で使われるエンティティのような、抽象化されたそれら自身かもしれない。典型的に、それらは、エンティティ・タイプ、特性、関連、及び操作の閉じたセットによって記述される、制約されたドメインをモデル化するのに使われる。

Lee (1999)によれば。一般的用語情報モデルはさらに、施設、ビルディング、プロセス・プラントなどのような、個々のもののモデルのため使われる。このような場合、概念は、ファシリティ情報モデル (Facility Information Model) 、ビルディング情報モデル (Building Information Model) 、プラント情報モデルなどと特定される。そのような情報モデルは、施設についてのデータと文書を伴う施設のモデルの統合である。

情報モデルは、どのようにその記述がソフトウエアにおいて実際の実装にマップされたかの記述を制約することなく、問題ドメイン記述の形式主義を提供する。情報モデリングのマッピングには多くもものが存在する。そのようなマッピングは、それらが(UMLを使った)オブジェクトモデル (object model) 、実体関連モデル、または XMLのスキーマ (XML schema) であるかどうかにかかわらず、データ・モデルと呼ばれる。

) 標準、Document Object Model]]

オブジェクト・モデル

コンピュータ科学におけるオブジェクト・モデル (object model) は、プログラムがその世界のある特定な部分を試しそして操作できるオブジェクトあるいはクラスの集合である。言い換えるなら、ある種のサービスまたはシステムへのオブジェクト指向インタフェースである。そのようなインタフェースは、表現されたサービスまたはシステムのオブジェクト・モデルであると言える。たとえば、Document Object Modelは、ページを調べて動的変化をプログラムするスクリプトを使う、ウェブブラウザにおけるページ表現の集合である。Microsoft Excelを他のプログラムからコントロールするための、Microsoft Excelオブジェクト・モデルが存在するし、またASCOM (AStronomy Common Object Model)Telescope Driver は、天体望遠鏡をコントロールするための1つのオブジェクト・モデルである。

コンピューティングにおける用語オブジェクト・モデルは、プログラミング言語技術、表記法、または 方法論を使うある特定なコンピュータにおけるオブジェクトの一般的特性とは別の2番目の意味をもつ。例は: Javaオブジェクト・モデルComponent Object Model、あるいは、 オブジェクトモデル化技法 (OMT) 。このようなオブジェクト・モデルは通常、 クラスメッセージ継承多態性情報隠蔽のような概念を使って定義される。プログラミング言語の形式意味論 のサブセットとして形式化されたオブジェクト・モデルに関する膨大な文献が存在する。

オブジェクト役割モデル

thumb

オブジェクト役割モデリング (ORM) は、概念的モデリング (conceptual modeling) のための1つの手法であり、情報やルールの分析のための1つのツールとして利用できる。

オブジェクト役割モデリングは、概念レベルでのシステム分析のための1つの事実指向の手法である。データベース・アプリケーションの品質は、その設計に重大に依存する。正しさ、明確さ、適合性、及び生産性を確かにするのを助けるため、情報システムは、人々が容易に理解できる概念と言語を使って概念レベルで最初に規定されることがベストである。

概念的設計は、データ、プロセス、及び振る舞い的観点を含むかもしれないし、その設計を実装のため使われた実際のDBMSは、(リレーショナル、階層型、ネットワーク型、オブジェクト指向等の)多くの論理的データ・モデルの1つに基づいたかもしれない。

統一モデリング言語モデル

統一モデリング言語 (UML) は、ソフトウエア工学分野での、1つの標準汎用モデリング言語である。それは、ソフトウエア集約システムの成果物 (ソフトウエア開発) (artifacts) を、可視化し、規定し、構築し、そして文書化するための1つの図式言語 (graphical language) である。統一モデリング言語は、以下を含む、システムの青写真を描く標準方法を提供する。

UML は、機能モデル、データ・モデル、及びデータベースモデル (database model) の1つのミックスを提供する。

文献案内

  • David C. Hay (1996). Data Model Patterns: Conventions of Thought. New York:Dorset House Publishers, Inc.
  • Matthew West and Julian Fowler (1999). Developing High Quality Data Models. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
  • Len Silverston (2001). The Data Model Resource Book Volume 1/2. John Wiley & Sons.
  • RFC 3444 - On the Difference between Information Models and Data Models
  • Len Silverston & Paul Agnew (2008). The Data Model Resource Book: Universal Patterns for data Modeling Volume 3. John Wiley & Sons.
  • Steve Hoberman, Donna Burbank, & Chris Bradley (2009). Data Modeling for the Business. Technics Publications, LLC
  • Andy Graham (2010), The Enterprise Data Model: a framework for enterprise data architecture

Category:データモデリング

Category:データベース

データモデル』に 関連する人気アイテム

リレーショナルデータベース入門―データモデル・SQL・管理システム

良い本だが話が冗長すぎる.

(参考になった人 6/9 人)

説明がいっぱいあってほんとは良い本なんですが,話が冗長過ぎてまとまってない.もうちょっと項目やパラグラフを分けていいただいて,せっかくTeX使ってんだからitemizeとかenumerateとかdescriptionとか使って定義と説明文をきっちり分ければわかりやすくなりそうです.話の筋が見えにくくて,だらだら読む必要が出てきます.だらだらと教科書を読み続けて勉強できるという人には本当に良い本です.ちなみに例題の解答例がないのも初学者にはつらいでしょう.他の方のレビューにもありますが,まず他の本で一通り概要を知った上で読めば本質的な部分を深められて良いと思います.

とにかくまとまってないので今すぐRDBを使いたいという人や概要を知りたいという人が読む本ではありませんね.学校のテキストとして使うのであれば用意するのが面倒なほどの板書やスライドが必要になるでしょう.内容の良さについては他の方がとてもよいレビューをたくさん書いていらっしゃいますので割愛します.

適切な入門書

(参考になった人 15/17 人)

初版は1991年、本書はその改訂版。RDBの基礎を学ぶには依然有用な一冊と言えます。 単純にDBにアクセスできる、操作できるという事だけを目的とするのでなく、 きちんとRDBの基礎理論まで理解させることを目的としており、 入門書とは言え、その辺りのお手軽本とは一線を画した内容となっています。その分、何の前提知識もない初学者には理解し辛い面があるのも事実だと思います。 少なくとも一度はDBに触れてから、もしくは触れながら本書を読むと良いでしょう。 早いうちに基礎理論体系をものにしておくことは、先行き大きな力になります。 本書はその「自分への先行投資」に十分応えてくれる一冊です。

半年あるいは1年かけて、じっくり学ぶのに適した教科書.長く愛用できると思います.<この本の良いところ> ・良心的な価格設定。あえてソフトカバー。英断だと思います。 ・十分な厚みがあり、丁寧な説明 ・「リレーショナルデータベース」に関する話題。設計理論、索引などなどをもれなく網羅 ・行間から識見、人柄がにじみ出る、個性と含蓄がある記述 ・Google等ではとても得られない.一貫性のある知識体系王道の教科書です。 明瞭な説明、さすがと敬服します。

実践的データモデリング入門

データモデリングについてわかりやすい解説をしている本本の構成は、基礎編(理論編)と実践編となっており、基礎編では モデリングの必要性や種類、そしてこの本で扱うIDEF1X形式をのべ データモデル以外、プロセスモデルなどの補完モデルについて述べています。 実践編では、架空のネット書店について、エンティティの切り出し、属性項目 、ボトムアップ分析を経て最後には物理実装まで扱っています。この本がすばらしいのは、基礎編でちゃんと理論的裏付けを行った後 実践編で、架空の書店についてモデリングを行っていること。

そして、実践編では、トップダウンモデリング、ボトムアップモデリングの 両方を解説し、最後に実際のデータベースのテーブルへと落とし込むところ までを解説しています。 それぞれの章には章のまとめがあり、何を理解していなければならないのかが 明確でありわかりやすくまとまっています。モデリングの解説書の中には、偏った分析を主に行っているものもある中 で、豊富な引用書籍を裏付けにした、網羅的でかつ、実践的でわかりやすい この本は、手元の本も6版と版を重ねており、とても良い本ではないかと 思います。 お勧めです。

リレーショナルデータベースに始めて触れた時、フィールドをきちんと配置し参照を考えたテーブルを複数用意すると、多少複雑な検索条件でも、SQL文一発で、検索結果が得られたのに非常に感動をしたことを思い出しました。今なおデータモデルの設計が甘い為に抽出したデータをプログラムで再加工していたり、なかなか美しいコーディングに行き着いてはいないので、本書を手に取るきっかけを得ました。本書にはERwinとER/Studioというモデリングツールの試用版が付録でついており本書内での演習に使えます。私自身は、もし使用版が非常に気に入ってしまうと、正規版がほしくなってしまうので、(ちょっと個人では買えそうにありません。

私はフォトショップでいっぱいいっぱいです)試用版を試すことなくもっぱら読むことで概念をつかもうと心がけました。それでも、論理モデルを作成することの有用性は充分に実感することが出来ましたので、企業でERwinとER/Studioを導入する予定のある方、もしくは個人でも余裕のある方にとっては非常に有効に活用できるのではないかと思います。

2chから辿って買った本だったかな?

(参考になった人 0/14 人)

内容は期待以下。まとめて読んであー楽しかった!とはならなかった。 机の上に置いて、たまに参照してみます。結果 評価が変わったら、☆の数を変えますね。今は2個。2014/3/5時点で13人が参考にならなかったレビューとしています。参考になった人は0人。 本日星1個にしました。この本を評価している人もいますが、本当にDB設計を学びたいのであれば、本なんか読んでる場合ではなく、データベーススペシャリストの勉強をすべきです。

NOSQLの基礎知識

※ 本書に習い、「NoSQL」ではなく「NOSQL」という表現を使用する。レビューワーは、所謂IT業界に籍を置くが、 データベースと聞けば、SQLやRDBMSしか頭に浮かばない(それで十分仕事は回る) レガシーな人間であり、NOSQLのソフトウェアを利用することや、 それを売ったりすることは無いものの、ただ一方では、 NOSQLって何なの?を知っていないと勉強不足のそしりを免れない立場にある。 そんなレベルの人間に、NOSQLの世界の概要を教えてくれる素晴らしい一冊である。本書はNOSQLを技術面から捉えた内容であり、ビッグデータというキーワードで ビジネスでの利活用や法制度等を説いたとセットで読めば、 もう鬼に金棒状態で、知ったかぶりのベンダーの営業や勉強不足の上司を撃退出来る。

レビューワーなりの要約を以下記載する。1章は、NOSQLという概念やそれを実現するソフトウェアが出てくるまでに至る 背景や歴史に始まり、NOSQLの特性、特徴を語る。 NOSQLは、大量のかつ多種なデータを早く安く処理するために、 目的を絞ったデータベースであり、 既存のRDBMSとは別カテゴリーのソフトウェアであると明示している。2章は、NOSQLのソフトウェアを、 データモデルという観点から、 キーバリュー型、カラム指向型、ドキュメント指向型、グラフ型の4つに分類し、 それぞれの特徴を説明する。 分類の仕方は色々あろうが、技術的な仕組み・実装ではなく、 データモデルという観点からの分類は、 素人・外野の立場の人間にとっては理解がしやすい。 カラム指向型という概念をこの本でやっと理解できた。細かいが、カラム指向型とカラムナデータベースは名前は似ているが違うという ちょっとした指摘に著者の見識の深さを垣間見た。3章は、NOSQLソフトウェアのアーキテクチャ、データの整合性を担保する仕組み、 データ分割の方法等を解説する(ここら辺からより技術的な内容が濃くなってくる) NOSQLデータベースでは、RDBMSではお馴染みのデータベースの4つの特性、 ACIDとは別の機能が求められ、 可用性と整合性のどちらを取るかで各プロダクトごとの特性が出てくる、というのが、 後々の章との関係でポイントとなる。4章は、Hadoopを取り上げる。 HadoopはNOSQLではなく、分散ファイルシステム(HDFS)と 並列分散処理システム(MapReduce)を包含するフレームワーク(概念)であり、 似ているところはあるものの、目的とする所が違うと解説する。5章は、主要なNOSQLデータベース製品を取り上げる。 やや駆け足的な記述になっている部分もあるが、 なんせ少なくとも何十という製品が世に出ている(本書P46)ので、 あまり懇切丁寧に説明していたら本書のメッセージがぶれただろう。6章は、3章と5章を受けて、NOSQL製品の選択基準を定義する。 こっち方面に詳しい人は、この章の記載は物足りないというか、 参考にならないと思うが、 素人・外野の立場の人間からしてみれば、 「かくかくしかじかなる選択基準が存在すること」を知ることが重要なのである。性能検証の結果も載っているが、 そのスピード絶対値は参考にならず(HWSWによって如何様でも変わりうる)、ただ、 製品ごとに得意・不得意な処理があることが一目瞭然であり、 製品のアーキテクチャーと利用目的を踏まえた製品選択が 大事であることが数字でもって示されている。7章は、NOSQLを使うビジネスと銘打っているが、 この章は平凡である。目新しい内容はない。各章の合間に、BBC、NYTimes、Twitter、Facebook、StumbleUpon、等々での NOSQL活用事例が紹介されており、NOSQLの活用イメージが湧きやすい。 日本企業はゼロなので、人によっては馴染みが薄いかも知れないが。 あと、Diggは本書に載っているシステムアーキテクチャー切り替えと それに伴うデザイン変更の結果、ユーザーから見放されたが (その顛末は本書では詳しく語られていないが)ご愛敬ということで。あと、こっち方面に詳しい人からすると、 テクニカルな正確さや厳密性やら網羅性やらが足らないとか いろいろツッコミが入りそうな予感が何となくするが、 そして、この本の著者ならオタッキーな方向に走ることをも十分できたと思うが、 それを抑えて、分かりやすさ、理解のし易さを第一に置いた構成は素晴らしい。読者像を勝手に描くと、 HadoopとNOSQLの違いが分からない人は、必読書。 HadoopとNOSQLが一緒くたになっている人も必読書。 キーバリュー型とカラム指向型という、キーワードは聞いたことがあるものの、 違いを説明できない人にとっても必読書。 一方、CassandoraとかHBaseをバリバリ使いこなせている人は、 そもそも本書を読む必要はない。日本にどれだけいるのか知らないが。色々な知識を持っていることを前提にしているので、 脚注で用語の補足説明は加えてくれてはいるものの、 本書を読みこなすこと自体、結構高度なことになるのかも。

買って損しない内容

(参考になった人 9/10 人)

国産NOSQL-DBのHibari開発企業執筆で間違いのない一冊です。 「基礎知識」というタイトルにふさわしく、GoogleのBigtable、AmazonのDynamoを踏まえたNOSQLとして定義されるべき事項をしっかり盛り込んでいます。 さにありながら、このような本にありがちのソフトウェア開発者、プログラマー向けの至る所にコマンド、コード、構文・・・の内容となってなく、きっちり初心者向けに分かりやすく書かれています。 第1章でビッグデータとNOSQLの背景(生い立ち)から入り、第2章のデータモデル(DB構造の違いで分かれる型)でのNOSQL-DB分類、第3章ではアーキテクチャ概説(当方はここが一番有意義だった)、そして「Hadoopはデータベースに非ず」として第4章にはHadoop、MapReducerを押さえています。

第5章の製品解説は置いておいて、第6章では今この時点でたぶん先端を行くNOSQL-DBの選択基準を示していることは非常に価値ありです。用途での選定ポイントは一般論過ぎですが、性能評価はプロも一読すべき内容です。 総じて、IT系企業でビッグデータ、NOSQL-DBを提案、構築するシステムエンジニアは必読。もしくはユーザ系でもこの程度の基礎知識を持てば、(雨後の竹の子)流行売り込みベンダの素性能力を見極めることができると考えます。

遂に基礎知識になった

(参考になった人 7/8 人)

ビッグデータはクラウドの次のバズワードと なっているようで、最近は大きなSIerも 盛んに喧伝をしているようなのですが、 その技術的基盤であるNOSQLについては ピンと来ない方も多かったのではないでしょうか。そこに真っ向勝負を挑んでいるのが紹介の本で、 NOSQLのデータモデル、アーキテクチャの基本概念、 NOSQL-DBMSの類型と代表製品の紹介、性能評価、 ユーザ事例などが平易にまとめられています。しかも、平易なだけでなく、 ところどころ切れ味も鋭いです。 「HadoopはNOSQL-DBMSじゃない」とか、 「現時点で最初に検討すべきNOSQL-DBMSは CassandraとHBaseだ」など、実際に数々の NOSQL-DBMSを比較検討し、システム開発に 適用している著者たちにしか書けない言葉は、 それだけで2520円以上の価値があるでしょう。こういう分かり易い基礎知識の本が出てくれると、 真面目にビッグデータの提案ができる雰囲気が いよいよ形作られていくのかなと思いますね。

業務別データベース設計のためのデータモデリング入門

イカす、入門書。

(参考になった人 10/12 人)

これすごく良いです。例えばあたらしい業種の仕事が入った場合なんかはもうすごく役に立ちます。僕の場合は実際、生産管理系の仕事なんかしたことがなかったのですが、これでとてもよくわかりました。 一般的に業務の視点から書かれた本なんかは、その業務については確かになんとなくわかった気になるのだけれどもそれだけじゃあ果たして、『じゃあそれシステムとして考えたときにはどうなるの?』ってのがすっぽり抜け落ちていたりします。 或いは逆に、システムの視点からの本だともうシステムべったりで業務の現場おかまいなしのはなしばっかりだったりして、実際に仕事になったときに『ああ、本にかいてあるみたいにうまくいくわけないじゃん、例外だらけ。

』みたいになりがち。 これ、その間を上手くとりもってくれている本だと思います。ですからまあ、でもやっぱりどっちつかずってとこもありますが、それはそれこの本を読むことで業務とシステムの間はどうなっているのかがぼんやりわかった上で、さらにそれぞれの専門書を読んだり実践で経験値高めていったりしなくてはならないですが、まあこの本のタイトルにもあるように、これ『入門』ですから。これでいいのだ。

データモデリングの考え方と業種ごとのデータモデルの例からなる本です。得に、前半のデータモデリングの考え方は、非常に、わかりやすいものです。専門家以外にもわかるように、丁寧に説明してあります。 このデータモデリングの考え方は、情報システムだけでなく、いろいろな場面で応用できると思いました。わかりにくい資料を作らないため、自分の持つ情報を整理するため、等です。情報を扱わない仕事をしている人は、いないと思います。前半だけでも、日々の仕事に十分なヒントを与えてくれる気がしました。 後半は、少し、しんどいですが、前半だけでも、元は取れます。 比喩の使い方、説明の方法が、エンジニアっぽくって、鼻につきましたが、ま、愛嬌です。

流行より汎用スキル

(参考になった人 11/15 人)

第一部で著者は、システム屋と業務屋の溝、意思疎通のインフラ整備の遅れを嘆いている。本書の初版が2001年。それから4年以上経った現在、状況は何も変わらない。我流UMLなどが出回ってむしろ現場は混乱する一方だ。小手先の技術でごまかしても本質は何一つ変わらない。 システムと業務知識が双方向で解説された本はいまだ数少ない。その意味で本書は4年経った現在も色あせていない。流行ばかり追うよりも本書のような汎用的なスキルを身につける方がはるかに大切だと思う。 データモデリングと業務知識を分離せずにコインの裏表のように一つのものとして解説している。後半がやや駆け足気味だったのが残念。

生産管理・原価管理システムのためのデータモデリング

読めば読むほどにうなずける

(参考になった人 12/14 人)

私は10年から15年も前に作られたIBMのAS400で稼動する生産管理を保守しております。この本を読んで自分の目の前に在るシステムと比べると、うなずける部分がこの本にはいっぱいありました。本が提唱するDB設計になっている部分は、なんら問題なく今も動いています。(あまりにもDB設計が似ているのでビックリです)未来在庫の予測などは勉強になりました。トリガー機能やジャーナル機能の存在をこの本で知りました(無知で恥ずかしいです)受注と出荷の関係や発注と仕入れの関係も良く理解できました。DBの正規化のプロセスが存在するなんて知りませんでした。今までの経験でなんとなくDBを追加していましたが、正規化を知っていればもっとマシなDBが追加できたのにと悔やみます。このような有益な本を出版して頂いてありがとうございました。

非常に参考になる

(参考になった人 3/7 人)

初心者でも分かりやすく記述された、非常に参考になるデータモデルの入門書である。継承属性および作出属性等を含むER図が固有の表記方法である。 「業務別データベース設計のためのデータモデリング入門」のpp59ー60には継承属性に関する説明が記載されており、同書pp240ー241に記載されているコラム「エンティティとテーブル」には継承属性の実装に関する説明もあり、この著書もあわせて読むことを推奨する。これを読むと、継承属性を含むエンティティはテーブル群を読み出しプログラム側で表示するか、条件付のテーブルジョイン等を行って表示すれば、それを示すことができるらしいことが分かる。 もう少し細かい索引があれば、便利であると思う。

教科書として精読すべし

(参考になった人 20/21 人)

システム設計屋からみて、初めて実践に役立つ本に 出会った思いです。現場を知ってる方が書かれた生産 管理手法の説明です。「本物」の迫力があります。 部品表の展開やバケット管理などDB構造を前提に しないと説明出来ないのですが、今までの本はそこが おろそかにされていたため学術書の域を越えませんで した。この本はシステム屋にとっての実用書です。 初級~中級のシステム屋さんは是非これで勉強して 欲しいと思います。

データモデル』by Google Search

This page is provided by Matome Project.
Contact information.