こんにちは～、ふじです。
今回は本日勉強したSQLのテーブル設計について書いていこうと思います。
データベースを用いたシステムは、SQLやDBMSの機能に関する知識だけでは開発できません。
お客様からの要件を理解し、データベース設計に適切に落とし込む方法論を活用しなければいけません。
お客様から要件聴取をした後、
①概念設計
②論理設計
③物理設計
といった工程でテーブルを設計していきます。
ではその内容を見ていきましょう～
概念設計では抽象的な概念としてどのようなエンティティ(情報の塊)を管理しなければならないかを明らかにします。
通常エンティティは複数の属性(テーブルの列のようなもの)を持っています。
エンティティを導き出す方法は、
①要件の中から名詞を抜き出し、さらに要件に関わってくるであろう
人、物、事実、行為などの用語を書きだす。
②不要な用語を捨てる、例えば、他の用語の具体例となるもの(「利用者」に対する「ふじ」)や、
計算、集計をすれば算出可能な値等。
③同じ用語に関連がありそうなものはまとめる。
④エンティティ名と属性名に分ける。③でまとめたグループの中で「～の～」
が成り立つ場合、前者がエンティティ名で、後者がその属性名になる。
例えば、家計管理の概念で考えた場合の「入出金明細の金額」は入出金明細がエンティティ名で金額が属性名にあたる。
要件を聞いてエンティティと属性を導き出すのは大変そうですね…
この工程での目的はエンティティをリレーショナルデータモデル(関係性のある複数の二次元表)で取り扱いやすい形のテーブルに変形することです。
変形に必要なことはキー設計と正規化です。
他のエンティティとリレーションシップを持てるようになる外部キーを持たせるために、
それぞれのエンティティには主キーを持たせる必要があります。
主キーを持たないエンティティには人工キー(人工的な主キー)を追加します。
また、エンティティ同士が多対多の属性の関係を持っている場合、
RDB(リレーショナルデータベース)はこの関係を上手く扱うことができないので
中間エンティティを設定し「1対多」に変換する必要があります。
ここからRDBの形をどんどん整えていきます。
概念から実物に成形していきますので、ここからは
エンティティ→テーブル、属性→列として考えていきます。
論理設計における最も中心的な作業はこの正規化という作業です。
整合性の崩れやすい非正規形から第3正規形まで変形させて崩れにくくします。
第1正規形は、セルの結合や一つのセルに複数行書いてるなど、
一つのセルに値が複数入ってるものを整えて、
テーブルのすべての行のすべての列に1つずつ値が入っている状態にすることです。
第2正規形は主キーに対して列が従属しているテーブルです。
この関係性のことを関数従属性といいます。
複合主キーの一部の列に対してのみ関数従属する列がある場合は、
その部分を切り出して別テーブルを作りきれいな関数従属を作る必要があります。
第2正規形に加え、主キー以外の列同士で従属する列が存在していない状態
を第3正規形といいます。
この間接的に関数従属することを推移関数従属といいます。
推移関数従属は第2正規形の時と同じように、切り出して別テーブルを作り正規化します。
これでやっときれいな形になります。
理解するので時間がかかったので実際やろうと思ったら、かなり大変そうですね…
論理設計後、全テーブルについて詳細な設計を確定させます。
文字通り物理的な設計ですね。
この段階では利用するDBMS(データベース管理システム)製品に関する深い知識
がかかせないので、上記の概念設計、論理設計は場数に踏んで慣れていくのに対し、
この段階では日々の勉強の成果もかなり関わってきますね。
以上、今回はSQLのテーブル設計について見てきました。
今回みたいな概念とか論理とかそういった類のものはブログ等で書き出して復習すると、
結構頭に入ってきますね、前回のJavaのオブジェクト指向もそれで理解が深まりました。
ではまた次回のブログで会いましょう～