スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

データベースをつつく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/x3/SPARC アーキテクチャでは、概念モデルと外部モデルが論理データモデルピヨね。
論理データモデルはどんな図でも良いわけじゃなくて機能要件があるピヨ。今からそれを列挙するピヨ。鳥ゃー


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


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


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

テーマ : 情報処理技術
ジャンル : コンピュータ

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

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

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

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


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


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

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

テーマ : 情報処理技術
ジャンル : コンピュータ

プロフィール

インドリ

Author:インドリ
みなさん、はじめまして、
コンニチハ。

ボクは、無限の夢(infinity dream)を持つネタ好きな虹色の鳥インドリ(in dre)です。
色々な情報処理技術を啄ばむから楽しみにしてね。

http://twitter.com/indori
は別人による嫌がらせ行為です。
私とは関係ないので注意して下さい。
次はなりすましブログなどをするかもしれませんが、ここ以外でブログをするつもりがないので、ここ以外にインドリのブログがあったとしても無視してください。


何度言っても分からない人がいるので、ここにコメント欄へ書き込むときの注意事項を書きます。


一、社会人としてのマナーをわきまえましょう。
一、妄想に基づく書き込みを止めてください。
一、暴言の類は書かないで下さい。
一、某誹謗中傷サイトの書き込みは彼らの妄想に基づく書き込みですから無視して、ここへ書き込まないで下さい。
一、コメント書く前に他のコメントよく読んでから行って下さい。
一、言いがかかり等の行為を禁止します。
一、その他常識的に考えて迷惑なコメントはしないで下さい。


以上のルールを守れない人のコメントは削除します。



利用上の注意
ここに紹介してある文章およびプログラムコードは正確であるように心がけておりますが、内容を保証するものではありません。当サイトの内容によって生じた損害については、一切の責任を負いませんので御了承ください。


執筆したCodeZineの記事


【VB.NETで仮想CPUを作ろう】

  1. VB.NETで仮想CPUを作ろう
  2. レジスタの実装
  3. 仮想CPUのGUI化
  4. テストドライバの改良
  5. CPUの基礎動作の実装
  6. MOV命令の実装
  7. ADD命令実装
  8. SUB命令実装
  9. INC命令&DEC命令の実装と命令長
  10. MLU命令の実装とModR/Mについて
  11. DIV命令の実装とイベント設計について
  12. 機械語駆動式 関数電卓を作ろう!
  13. 機械語駆動式 関数電卓を作ろう! 解答編(前半)
  14. 機械語駆動式 関数電卓を作ろう! 解答編(後半)


【仮想ネットワーク実装でTCP/IPを学ぼう】
  1. TCP/IPの基礎と勘所
  2. ネットワークアクセス層の勘所
  3. インターネット層の勘所
  4. トランスポート層の勘所
  5. アプリケーション層の勘所
  6. セキュリティの基礎と仮想ネットワークの仕様
  7. GDI+と独自プロトコルの定義



【並列化】
インテル Parallel Studioを使って並列化プログラミングを試してみた
並列プログラミングの効率的なデバッグを実現する「Parallel Inspector」


【TBBシリーズ】
  1. インテル スレッディング・ビルディング・ブロックの概要
  2. インテルTBBから学ぶループの並列化
  3. スレッドセーフとインテルTBBのコンテナ
  4. インテルTBBのスレッドクラス


【OpenMPシリーズ】
  1. OpenMPの基礎構文
  2. OpenMPの実行時ライブラリと並列ループ
  3. OpenMPのメモリモデルとfork- joinモデル

最近の記事
最近のコメント
月別アーカイブ
カテゴリ
Ada (9)
COBOL (5)
C (9)
C++ (11)
C# (370)
D (25)
Java (8)
Perl (1)
Ruby (14)
PHP (2)
Boo (2)
Cobra (2)
LISP (6)
F# (33)
HTML (0)
XHTML (0)
CSS (0)
XML (0)
XSLT (0)
Scala (4)
WPF (0)
WF (2)
WCF (0)
LINQ (4)
MONO (5)
Linux (0)
MySQL (0)
ブログ内検索
リンク
最近のトラックバック
RSSフィード
ブロとも申請フォーム

この人とブロともになる

QRコード
FC2カウンター
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。