データベースをつつく5－関係モデル以外のモデルについての補足説明

ボクは関係モデルしか使ったことがないので、他のモデルについて少し調べたピヨ♪やっぱり、好奇心が疼くよね♪幾つかの文献を見てみると、ネットワークモデル、階層モデル、エンティティ関係モデル、エンティティ属性関係モデル、バイナリ関係モデルなどがあったそうだピヨッ。
先ずはネットワークモデルについて囀るピヨ。ネットワークモデルはレコードとポインタで構成されるモデルピヨ。例えば、社員レコードの所属部署データは、部署レコードへのポインタ・・・という風に実現されているピヨ。C言語ぽい構造ピヨね。このモデルは、その特徴から察しが付くと思うけど、現実をモデル化しにくいという弱点があるピヨ。もちろん馴れた人ならばかなり高度な事を出来るだろうけど、モデルは対象となる現実を表すものだから、ちょっとモデルとしては問題あるピヨ。あと、レコードとポインタで実現されているって事は、必要とされているデータが2倍になるという事ピヨ。おまけにSQLのような言語を策定する際に、レコードとポインタを操作する構文が必要になるから問い合わせ言語も作り難いよね。これが廃れた原因だとボクは思うピヨ。
次は階層構造を囀るピヨ。階層構造は一言で言うとツリー構造のモデルピヨ。これはB-Treeなどのアルゴリズムがある事を考えればわかるように、プログラマの思考とマッチしていて結構有効だったんだ。それで結構流行ったらしい。だけど、 現実をツリー構造に無理やり押し込めるから、モデルとしては不十分だったんだ。それらなら、直接プログラミングした方が早いしね。モデルにする意味が無いピヨォ。残念だね。
あと、バイナリ関係モデルなどのマイナーなモデルが数多く発明されたんだけど、はっきりいって普及しなかったピヨ。その中で生き残った発明がオブジェクト指向データベースなんだけど、オブジェクト指向データベースはかなり巨大なトピックなのでこっちでは詳しく説明しないピヨォ。
これらのモデルの歴史を調べて思ったんだけど、昨今搭載可能なメモリ容量がかなり増えているから、メモリ内データベース管理ソフトを考えた場合階層型モデルも結構ありかもしれない♪見方を変えれば、XMLデータベースもDOMとして扱う際にツリー状態だからね♪あと、ネットワークモデルについてもセマンティックWebとか、ニューロンコンピューターとかに適しているモデルと思うピヨ。こんな風に、情報処理技術では滅びた技術が華麗なる復活を遂げる事があるから注意が必要ピヨ♪温故知新ピョッ♪

データベースをつつく4－関係モデル誕生の背景。どうして発明されたの？

何かの技術を学ぶ時は、その技術が必要な理由をつつくと深く理解できるピヨ♪だから今回は、関係モデルが作られた理由をつつくピヨ♪
関係モデルが誕生するまでは、階層モデルとネットワークモデルが使用されていたピヨね。この二つのモデルは当時は画期的な技術で、想定内のデータアクセスは非常に早いという大きな利点があったんだけど、幾つかの弱点があって生産性はあまり向上しなかったピヨォ。その理由は以下の通りだピヨッ。


【生産性が上がらない理由】

• ナビゲーションが複雑・・・定型の検索処理は非常に早いものの、データの操作に関係のない概念が多くてプログラマが非常に困ったピヨ。もっと具体的に言うと、1対多対応、存在従属性、利用者に見える構造とデータパスを対応付ける方法、の三つをネットワークと階層構造で表現するのは無理があったピヨね。
• 単一レコードしか扱えない・・・関係モデルのように一度に複数のデータを扱うことが出来ないのが非常に問題になったピヨ。
• 柔軟性が無い・・・ネットワークと階層構造は柔軟性がなく、予め決められた検索パスを使ってデータ処理を行うので、プログラマが予測出来ない検索が出来なかったピヨ。

この三つの問題点がプログラマを非常に苦しめ、開発生産性が上がらなかったので、より柔軟な構造をもつ関係モデルが発明されと言うわけさ♪だから関係モデルはデータの構造が柔軟なんだ。だけどその一方で、関係モデルは結合処理がパフォーマンスを落とすという弱点もあるピヨ。他にもメタデータの変更がやり辛いという弱点があって、アジャイル開発にはそぐわないので、昨今は色々なサポートツールが作られたり、XMLデータベースの概念やオブジェクト指向データベースの概念も誕生したピヨね。そろそろ新しいハイブリッドかつ新しいデータベースの概念が生まれる時期だとボクは思うだピヨッ♪だって、既にオブジェクトリレーショナルやXMLと関係モデルのハイブリッドもあるからね。そろそろ全てが混ざって新しい概念が生まれてもいい頃ピヨ。

データベースをつつく3－関係モデル。貴方と私の関係は？

データモデルには、階層モデル、ネットワークモデル、関係モデルの三つがある事はもう言ったよね？今回はその中でも、一番有名で広く使われている関係モデルをつつくピヨ♪
関係モデルというのは、E.F.Codd氏が提唱した数学の集合理論に基盤を置くモデルで、フラットな表（テーブル）をデータ構造に採用したデーモデルピヨ♪関係モデルは一番成功したモデルで、みんながよく使っている、SQL Server、Oracle、MySQL・・・などはこのモデルによって作られたDBMSなんだ。だから、関係モデルは非常に重要な概念ピヨッ♪こういった概念の学習、楽しくないと感じる人が多いだろうけど、無味乾燥な知識じゃないし、分かったら楽しいから絶対マスターした方がいいピヨ♪じゃあ、前置きはこれぐらいにして、もっとつついていくピヨ♪

【特徴】
関係モデルの特徴は、三つあるピヨ♪。先ず一つ目は、対象となる世界をテーブルで表現する事ピヨ。二つ目は、テーブルの関係（リレーション）を重視する事ピヨ。三つ目は対象世界にある情報を数学の集合理論で捉える事ピヨ。この三つの特徴が関係データモデルを強力なものにしているんだ。数学に抵抗感を感じる人が居るかもしれないけど大丈夫、意外と感覚的に分かるピヨ♪それに、ボクの経験上、数学としての集合理論に拘り過ぎると、現実の曖昧さが影響してかえってシステム設計が出来ないピヨ。だから気楽に行こう♪考えるんじゃなくて感じよう♪
特徴を軽くつついたから、今度は関係モデルの概念を一つずつつついていくピヨ♪

バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ

【属性】
情報が持つ性質の事を属性と呼ぶピヨ♪例えば会員を管理するシステムを作る場合、テーブル館員は、会員番号、名前、住所、性別、生年月日・・・などの項目がが必要だよね。この項目を属性と呼ぶんだ。ちなみに、名前＝山田太郎などのある属性の値を属性値と呼ぶピヨ♪

【定義域（domain）】
属性値がとりうる範囲の事を定義域(domain)と呼ぶピヨ♪。先ほどの例で言うと、名前と住所は「文字列」だよね。オブジェクト指向に慣れている人は、型のようなものだと思えばいいピヨ♪型との違いは、型はデータと手続きがセットだけど、定義域はデータと制約だという事ピヨ。

【関係】
複数の定義域の直積結果を定義域と呼ぶピヨ♪これは難しい概念だから例をあげるピヨ。例えば、先ほどの会員テーブルの他に、商品テーブルを参照する売り上げテーブルがあったとする。この場合、会員と商品の関係は売上という事ピヨ。

【候補キー】
複数ある関係の中で、1つの値を識別するための属性を候補キーと呼ぶピヨ♪候補キーは関係の中に複数あってもいいピヨ。

【主キー】
候補キーのうちどれか一つの主となるキーを主キーと呼ぶピヨ♪この概念は正規化の回で詳しくつつくピヨ♪

【外部キー】
テーブル間に参照関係があるとき、参照する側の項目を外部キーと呼ぶピヨ♪この概念も正規化の時に詳しくつつくピヨ♪


今回は軽く関係モデルの特徴と概念をつついたピヨ♪だから、今はあまり理解できなくてもいいピヨ♪ 次回からはもっと深く関係モデルをつついていくピヨね。関係モデルが分かったら設計能力が飛躍的に上昇するからお楽しみに♪

データベースをつつく2－データモデル2。物理データモデル。

今回は物理データモデルをつつくピヨ♪物理データモデルというのは、DBMSの特性や実装方式を加味して作成されるモデルの事ピヨ♪物理データモデルは論理データモデルとは違ってコンピュータ化されない部分は記述しない事に注意してね♪
代表的な物理データモデルは、階層モデル、ネットワークモデル、関係モデルの三つが存在するけど、ボクは関係モデル以外使っているのを見た事が無いピヨ。
物理データモデルはこれといっていうことが無いから、ボクの意見を書いておくピヨ。ボクが思うに、実務ではUMLやE-R図などで物理と論理の区別無く書く事が多いけど、論理用と物理用の図を書いたほうがいいと思うピヨ。ただ、こうしたら情報のロストが発生する可能性があるけどね。それでも、お客様の要望についての情報の漏れがあるよりもましだし、注意さえすれば何とかなる事だと思うピヨ。これが出来ないのは、図の表現力不足とお客様とのコミュニケーションの問題が原因だから、論理データモデルと物理データモデルはまだ改良のの余地があると思うピヨ。

データベースをつつく1－データモデル1。論理データモデル。

今回は論理データモデルをつつくピヨ♪データモデルを大別すると論理データモデルと物理データモデルの二つに分けられるピヨッ。それで、論理データモデルとは実装方式とは独立した情報を記述するモデルで、コンピュータ化できない部分も記述するモデルピヨォ。論理データモデルで、コンピュータ化されない部分を検討するのを忘れている人が多いから注意してね。前回言及したANSI/ｘ３/SPARC アーキテクチャでは、概念モデルと外部モデルが論理データモデルピヨね。
論理データモデルはどんな図でも良いわけじゃなくて機能要件があるピヨ。今からそれを列挙するピヨ。鳥ゃー


バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ


【論理データモデルの機能要件】

• 1、誰がモデル化しても同じ結果になる事・・・言いたいことは分かるけど、これを満たすのは不可能だと思うピヨ。
• 2、視覚的に理解しやすい事・・・当然だね。
• 3、複合オブジェクトや汎化／特化等のデータ意味関係を表現できる事。大まかに分けると下記のア～ウの三つがあるピヨ。
• （ア）複合オブジェクト・・・これは複数のデータ型などを含んだ複雑な関係を表現する事を意味しているピヨ。オブジェクト指向DBMSに必要な要件ピヨ。
• （イ）汎化／特化関係・・・これはオブジェクト指向をイメージすれば分かりやすいピヨ。例えば、動物の特化情報が人間とかそんな感じの事ピヨ。
• （ウ）PART0-OF関係・・・これは、情報を構成する情報を表現しなさいと言うことだピヨ。例えば、車は、タイヤ、エンジンなどの部品で構成されているよね。
• ４、論理データモデル機能自身に矛盾があってはならない（完全性）・・・まぁ当然だね。
• 5、整合性制約が表現できる事・・・この要件がないとデータベース設計では役に立たない図になるからね。

教科書的な事を書くとこれらの要件があるんだけど、実際にこれらの機能が1つの図で使用されているかと言えば疑問だね。先ほど少し書いたけど、汎化／特化につてはオブジェクト指向に関する要素だから、これらの情報はUMLに書く事が多いピヨね。実務ではどの情報がUMLか、どの情報がE-R図か・・・などと揉めて複雑になる事が多いピヨ。この際気をつけなければならないは情報漏れピヨ♪論理データモデルを書く段階ではコンピュータ化できない部分も記述しなければならないから、UML・EーR図などに拘り過ぎると情報が漏れるピヨね。これよくあることだからくれぐれも注意してね。
それらの事情を踏まえると、論理データモデルは複数の図で表現すると思えばいいピヨね。そうすれば情報漏れも防げると思う。データモデルというのはあくまで概念だと前回言ったのは、こういう事があるからなんだよ。設計に関わる人は注意しよう！これでプロジェクトの成否が決まるといっても過言じゃないピヨォッ！！！

データベースをつつく0－データモデル。空気のような概念。

データベースは範囲が広いから先ず何をつつくのか迷ったピヨ♪迷った結果、結局はセオリー通り実世界からつついていった方がいいと思ったピヨ♪そこで第0回目はデータモデルをつつく事にしたピヨ♪
データモデルというのは、現実世界のある領域のデータ体系を、ダイアグラムなどを使って表現したものピヨ♪ある領域と言うのは、よくあるのが企業、部門、店、個人・・・などの業務や私事で発生する情報ピヨね♪ちなみに、データモデルは意味データモデルと言われる事もあるピヨ。一応頭の片隅においておこう。
データモデルを作る意義は、情報が視覚化出来る事ピヨね。ちょっと抽象的で分かりにくいから、自分が働いている会社の業務を考えてごらん。きっと訳が分からなくなると思う。だけど図にちゃんと書けば、業務を全体的に見る事が出来て理解できるピヨ♪これがデータモデルの利点だと思えばいいピヨ。

データモデルは皆が理解できなければならない。でも残念ながら、データモデルはちゃんとした作図ルールがなければならないので、ご察しの通りいっぱい作られたんだ・・・ DSPテキスト体系、ANSI/ｘ３・SPARC、IRM研究会、THモデル、IDEF1X・・・etc。あーあ、これじゃ混乱するピヨ・・・。でもご安心めされよ。今ではどうやらANSI/ｘ３・SPARCが一番有力なようだピヨ♪だからこれ以降はANSI/x3/SPARCをつついていくピヨ♪他のはボクも知らないしねｗ

ANSI/x3/SPARCの特徴は3層のスキーマから構成されている事ピヨ♪3層のスキーマは次のように定義されているんだ。

• 外部スキーマ・・・利用者やアプリケーションインタフェースに直接見えるデータを定義するスキーマ。このスキーマを独立して作ると、内部構造が変わってもアプリケーションインターフェースに影響を与えないで済むピヨ♪これを論理データ独立性と呼ぶピヨ♪
• 概念スキーマ・・・データベース化する対象全体を定義するスキーマ。このスキーマはDBMSの特性を考慮するするピヨ。間違えやすいところだから注意してね。
• 内部スキーマ・・・データの物理的な側面を定義するスキーマ。使用するテーブル、インデックス、ファイルの構造などの物理的な事を決める層なんだ。このスキーマを独立させると、物理面の変更が他に影響を与えないように出来るんだ。これを物理データ独立性と呼ぶピヨ♪
  

この考え方は実務でも役に立つから覚えておいて損は無いピヨ♪ただ、中の人に聞いたら厳密にデータモデルを定義している現場に遭遇した事が無いそうだよ。だからデータモデルについては、ひとまず思考法だと考えておいたらいいみたいだね。今回はこれでおしまい。

バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ