輝々凛々

ガンバるってことは、素晴らしい事だ。

連載「データベース技術」:3つのデータモデル

前回「連載「データベース技術」:データモデルとは?」では、データモデルについて説明しました。今回は、データモデルにも種類があるってことを説明したいと思います。

3つのデータモデル

前回の例では、家計簿をデータベースにしようということで、下記の表を考えました。

日付金額目的
2013-2-11¥2,940理工書
2013-2-15¥346 食費
2013-2-16¥280 珈琲

この程度の表を作る程度であれば、簡単に現実世界の情報をピックアップし、データモデルを作り、実際にデータを作ることは簡単にできそうです。

ですが、実際には3つのデータモデルを順に作成します。

現実世界の情報 概念データモデル 論理データモデル 物理データモデル

まず現実世界の情報を、概念データモデルにし、さらに論理データモデルにし、物理データモデルにします。

直接、現実世界の情報をデータベースに入力するようなことはしません。

理由は、おおよそ、下記のようなものです。

  1. 要求の変化に柔軟に対応するため
  2. データベース管理システム(DBMS)の変化に対応するため
  3. データモデルの不具合が、全体に波及しないように

それぞれの役割は、下記の通りです。

概念データモデル
現実世界の情報を、そのままの形で記録したものです。ユーザーからの見た目をそのまま記述します。だからこそ、データベース管理システム(DBMS)に依存しないように作成します。扱う情報に適切な名前をつけます。その情報が取り得る値の範囲を蹴ってします。数値であれば上下限値、小数であれば桁数。文字であれば文字数や使用可能文字などです。また、その情報が他の情報とどういう関係があるかを記録します。先の家計簿で言うと、日付、金額、目的が概念データモデルです。
論理データモデル
概念データモデルをデータベース管理システム(DBMS)に入力するために作成します。ようわ、概念データモデルをDBMSに入力すると、それがそのまま論理データモデルです。ただ、入力するためにはある程度変形は必要かと思います。先の家計簿で言えば、Excelの表形式にします、というのが論理データモデルです。
物理データモデル
物理的な記録媒体への格納方法を示したものです。ファイルにするのか、何にするのか、です。先の家計簿で言えば、Excelファイルのファイル形式が、物理データモデルです。

ということで、次回は、もっと詳しく説明しましょう。

連載「データベース技術」:データモデルとは?

前回「連載「データベース技術」:データベースとは?」は、データベースというものが、現実の情報を分析し、収集し、利用するための技術である事を説明しました。今回は、そのうちの分析に関わる重要な概念「データモデル」を説明します。

データモデルとは?

まず最初に下表のような家計簿を考えます。

日付金額目的
2013-2-11¥2,940理工書
2013-2-15¥346 食費
2013-2-16¥280 珈琲

この表には、現実世界の3つの情報が書き込まれています。それは「日付」、「金額」、「目的」です。そして具体的な値として、私の財布に入っていたレシートを書き写しています。

この表を作る際、私は、何気なく管理したい情報をピックアップし、何気なく情報に名前を付けています。そして、名前のついた情報に対し、何気なく表にして、何気なく具体的なデータを収集しています。

このように管理したい情報をピックアップし、名前を付ける行為を「データモデリング」、あるいは「モデル化」と言います。

そして、この名前のついた情報が「データモデル」です。(あくまで、「大雑把に言えば」です。)

先ほどの家計簿で言えば、「表には“日付”と“金額”と“目的”があります」という情報がデータモデルです。具体的な値である「2013年2月16日に珈琲を280円で買った」という情報は単にデータと呼びます。これは最早、立派なデータベースです♪

データモデルとデータベース管理システム

さて、現実の業務で扱うデータとなると、今回の家計簿よりも複雑に絡み合っている情報を扱う事になります。それには、普通、データを管理するためのソフトウェア群であるデータベース管理システムを使用します。

もちろん、そこに「データモデル」が登場します。

データを管理するのですから、どういった項目があって、入力されるのかを把握する必要があります。先ほどの例で言うところの列名“日付”、“金額”、“目的”ですね。

ということで、データモデルは最終的には、最終的にはデータベース管理システムに入力し、そこで管理されるものになります。

ただ、それを直接やってしまうことも少々危険で・・・、という話はまた次回。

今日は、以上で。

次回→連載「データベース技術」:3つのデータモデル

連載「データベース技術」:データベースとは?

データベーススペシャリスト試験の受験を宣言し、勉強開始したのは、もう1月ほど前になります。(「データベーススペシャリストに俺はなる!」です)さて、それから、いろいろ本も読んでみて、自分ならもっとわかりやすく書けるのになぁ、と思ったので、書いてみます。

勉強中の自分の頭の中の整理のためのアウトプットでもあるので、間違えてるところなどあるかもしれません。また面倒くさくなって、途中放棄する可能性もありますが、なるべく後から、この記事を読んだ人も合格へ一歩でも近づけるよう書いておきます。

データベースとは

まず、データベーススペシャリストになるのだから、「データベース」を定義します。データベースは、英語で書けば「Database」あるいは「data-base」で、「情報基地」とでも日本語に訳せます(が、普通は、そんな言い方しません)。

つまり、データベースとは情報資源を管理する技術です。

データベースには、現実世界の情報を蓄えておきますが、当然、情報は貯めてるだけでは意味がありません。また不要なデータを貯めることも意味がありません。データベースという技術は、現実世界の情報を必要なだけ分析し、収集し、そして利用するための技術です。

データベース技術の要素技術の分類

雑多に分類すると、次のようになります。

  • 設計:情報の分析し、データにするための技術
  • 運用:データを収集し、利用するための技術
  • 他:トラブル対策や他技術との連携などなど、細かな技術がたくさん

上記のうち、データベーススペシャリスト試験に登場するのは、全部です。ただ、データベース関連のソフトウェアについての固有の問題は出てきません。あくまでも基礎的な内容です。

たとえば、情報の分析ってどうやるのか、それを現実世界の情報の変化に合わせて、どうメンテナンスしていくのか、そういったものは、本来は多くの経験に成り立つものです。データベーススペシャリスト試験を勉強する事は、これまで数多くの技術者が体験してきた知恵を疑似体験し、何十年もの知識をわずか数ヶ月のうちで手に入れられることになります。

能書きはいい

というわけで、まず、第一回、データベース技術は終了です。

また次回→「連載「データベース技術」:データモデルとは?」。

データベーススペシャリストに俺はなる!

勉強開始!

SQL命令の分類

データベースといえば、SQL。でもよく知らない。だって、仕事には使わないもの。

だもんで、勉強中。ま、自分もアウトプットしつつ覚えていこうっていう魂胆。

命令の分類

命令とは、ようわ「SELECT」とか「CREATE VIEW」とかのアレ。述語のようなもの。

そんな命令には、大きく3種類の命令がある。

  • データ操作言語 (DML=Data Manipulation Language)
  • データ定義言語 (DDL=Data Definition Language)
  • データ制御言語 (DCL=Data Control Language)

各種の詳細を見ていく。

データ操作言語 (DML=Data Manipulation Language)

データ操作言語は、データ(「表」って呼ぶ)に対して、参照、修正(変更)、追加、削除の操作を行うものである。

SELECT
データを参照する。
UPDATE
データを修正変更する。
INSERT
データを追加する。
DELETE
データを削除する。

各命令の詳細については、また後述。

データ定義言語 (DDL=Data Definition Language)

データ定義言語は、データ(「表」ね)を作る操作を行う物です。

CREATE TABLE
データ・テーブルを作成する。
CREATE VIEW
データ・ビューを作成する。

テーブルとビューの違いについては、後述します。

あと各命令の詳細についても後述します。

データ制御言語 (DCL=Data Control Language)

データ制御言語は、先に述べた2つの操作を行えるかどうかを、許す、許さないを決めます。つまり、権限(アクセス権)を定義します。

GRANT
権限を付与する。
REVOKE
権限を取消す、取り下げる。

各命令の詳細については後述します。

命令の分類を覚える意義

最終的には、命令の分類は覚えていなくて構わないと思います。ただ、SQLを覚え始めたときには、各分類ごとに覚えるのが楽なので、強く意識して、各命令を覚えていくのが良いと思います。

ひとまず、以上

データベース

データベースのことを全然知らないんで、どうにも試験対策できなくって、本を買ったのだけど、やっぱり妙にわからない。的を射ることができない。どこが足りないんだ、、、、と考えて、何となくわかった気がする。これだ。

データベースの基礎技術というか考え方。これだけしかありません。

というわけで、データベース関連の技術って、底辺にあるのはちょっとだけで、それを実現するためにSQLやら何やらがあるだけのような気がする。というわけで、まとめていきます。

分類とか形式

データベースを構築する際に、どんな型にはめて作るかっていうのがこれ。

  • 三層スキーマ:3階層にわけることで、それぞれの独立性を保ち、他層の変更が他層に影響を及ぼさないように作る型。
  • 概念データモデル:データベース化する対象を抽象化して表すもの
  • 論理データモデル:データベース化する対象を具体化して表すもの

で、気をつけることは、上記3種類の型は別に相反するものじゃないってことで、ひとつのデータベースを「三層スキーマに乗っ取って、概念データモデルを作って、論理データモデルを作る」というように同時に適応することができる。

また、たとえば「概念データモデルはどうやって作る?」に対する答えが「E-Rモデル」であったり、「論理データモデルで一般的に使われているのは何?」の答えが「階層モデル」だったり「関係モデル」だったりする。

設計手法

先の分類とか形式を決めたときに、「どうやってデータベースを作るか?」を体系化したのが次のようなデータベース設計手法になる。

  • トップダウンアプローチ:外部仕様の理想系から作って、実装へと落とし込んでいく。
  • ボトムアップアプローチ:ハードの制約など実装レベルから外部仕様を作っていく。
  • 混合アプローチ:その両方
  • E-R図:これはE-Rモデルを、図で作ろうってもの。

他にも関係モデル用の「キー」やら何やらがある。情報処理試験では、E-Rモデルと関係モデルが頻出する。

DBMS

データベースマネジメントシステムの略。先にあげた分類とか形式で作り上げたデータベースを管理するためのシステム。管理というか、データベースへの新規データ追加をどうやってやるの? とか、あの値を取り出すにはどうしたらいい? みたいなのを決めている。世間的にはSQLを使って取り出したり書き込んだりするみたい。

まとめ

というわけで、データベース関連の出題範囲なんてこんなもの。だけど、E-Rモデルや関係モデルに関する実装手法や実装に関する基礎知識、関係モデルの表を読み取ることやSQL, 関係代数などなど、覚えることは多くある。

たぶん、ネットワークも基本的には同じ。でもたぶん、こういうことを実際に仕事としている人にとって、こういう技術って「全部は知らなくても仕事になるけど、データベース以外のことも知らなきゃ仕事にならん」って感じだと思う。プログラミングできても、プログラミングで作りたい物がなければ意味ないのと同じ。

以上

SQL

毎年恒例の国家試験、情報処理技術者試験の「ソフトウェア開発」を受けます。
それで、勉強をしているのですけど。
今回で3回目の受験です。
最初は、とりあえず何も勉強せずにいったのが功を奏して、不合格。
(というか合否確認もしてないほど明らかに不合格)
前回は、どうしようもないほどのバス酔いと
どうしようもないほどの、データベース関係の不勉強が、
やはり功を奏して、不合格(明らかに、誤用)。

ま、そんなこんなで、
今日は一所懸命にデータベース関係、主にSQLの勉強をしようと
がんばっちょります。
続きを読む