コラム・特集

3.6 データベース・スキーマの設計

IEハンドブック
第12部 コンピュータと情報処理システム

第3章 データベース管理

3.6 データベース・スキーマの設計

概 観
データベース・システムは,それが提供する。論理構造化の違いによって分類できるということを見てきた 論 理構造化の関係型,階層型,ネットワーク型の相違を例示するシステムを述べてきた。システムのデータ操作手段の性質は,サポートされている論理構造化の相違によって大きく影響される。操作コマンドは,システムが許容するデータを構造化する。構成概念(たとえば, レコー ド・タイプ,セ ット )に特有の表現で規定されている関係型,階層型,ネットワーク型のどのシステムが用いられるかにかかわらず,与えられたアプリケーション領域のために設計されるスキーマが,データベースのユーザーの見方を確立(そして制約)し,データ 操作の基礎として役立つ。したがって,データベースのスキーマの設計は非常に重要な活動であり,ゆゆしき活動でもある。

あるアプリケーションに対するデータベースのスキーマは,そのアプリケーションに適切な情報の構造をモデル化しシミュレートするように設計されなければならない。それは,現実の世界の形式的な記述である。異なる データ・モデルは,異なる記述用具を提供する。 現実の世界をシミュレートするときに用いるデータ・モデルの選択は,現実の世界をいかに思い描くかに大きくかかわって いる。その世界をネットワークであると考える人にとっては,ネ ットワーク型データ・モデルがもっとも強力なシミュレーション用具を与える。ネットワーク型システム によって,現実の世界に存在する関係の意味論を,(セットやN:Mセット名によって)明示的に記述し 与える。

他方, もし,世界を木の集まりであると見るならば, 階層型モデルがもっとも便利な シミュレーション用具であろう。しかしながらネットワーク型モデルと違い,一般的に階層型モデルは,木の間の連結をとるための基礎として,その設計に冗長性を導入するよう設計者に強要する (限られたネットワーク化の能力に相当するものをもたらす)IMSの論理関係を利用することによって, この問題は,除去されたわけではないけれども,ある程度軽減されている。最後に,世界をばらばらな表の集まりの観点からみるならば,関係型モデルが,その世界をシミュレートするのに便利な用具を提供するであろう。ばらばらな表(すなわちファイル)の間の関係は冗長性によってとらえられる。これらの関係の意味論は明示的には表現されてはいない。これは,何十もの関係(すべて暗黙のうちに表現されている)をもつスキーマにおいては,扱いにくいこともある。

どの見方をとるにせよ,アプリケーションの世界についての知識をデータベースのスキーマに変換するという設計の仕事がある関係型およびネットワーク型の見方に対する設計アプローチを示す前に,われわれは,スキーマの設計者が知るべきである2つ の問題を考察する。これは,データ関係保存(data relationship preservation)と 構造的不調和(structual anomalies)である用いられているデータ・モデルにおいて利用可能などんなメカニズムによっ ても ,ス キーマの設計者は現実世界 のデータ関係を保存しなければならない。4種類の関係のうち2つ,すなわち,多対1と多対多はすべて述べた 1対多の関係は,多対1の補集合である 2つの概念の間に1対1の関係が存在するのは,一方の概念の各場合が他方の概念の1つの場合を一意に識別し ,また逆も成り立つときである。 これらの関係は,3つのデータ・モデルで異なって表現されているが,それらすべてが,スキーマに保存されていなければならない。もし 諸関係が明示的に表現されていないならば,データベースのユーザーがスキーマの意味論を理解できるように,暗黙の関係の性質を文書化するのが賢明である。

関係保存がスキーマの代表性(representativeness) に関わっているのに対し,構造的不調和は,なんらかのスキーマ設計から生じうる首尾一貫性と冗長性の問題に関わっている。4つのデータ・アイテム・タイプ
SNAME,ADDRESS,PARTNO,QTYをもつレコード・タイプをもっているとする。この設計は次の4つの不調和問題をもつ。

1.冗長性の不調和 (Redundancy Anomalies) 部品メーカーの名前と住所が,供給される部品のそ れぞれに繰り返される。
2.更新の不調和 (Update Anomalies)冗 長性の 結果として,部品メーカー名や住所の更新が,多 くの場 所で繰り返されなければならない。データアイテム の繰り返された値すべてを更新するの1こ失敗すれぎ , 更新の不調和という形の矛盾となる
3.挿入の不調和 (Insertion Anomalies)も し , データベース・システムが, レコード ・ォカレンス に,空値を禁止しているならば,部品メーカーが現 在1つ も供給していないときにはその名前と住所を 記憶することはできない。
4.削除の不調和 (Deletion Anomalies)ある部品メーカーが供給するアイテムすべてを削除するならば,この部品メーカーの名前と住所を必然的に失うことになる。これは,挿入の不調和の反対である。

前述の具合の悪い状況は,明らかに, 1対1でない関係のデータ・アイテムを1つのレコード・タイプにグループ化したことから起こっている。不調和は,ネットワーク 型モデルでは完全に削除されうる。なぜなら,データ・ア イテム・リンケージがセット・タィプを通しており,どのデータ・アイテムも繰り返される必要はないからである。関係型モデルでは,リンケージロ的のために,データ・アイテムが繰り返される。したがって,不調和はどの個々 のレコード・タイプ内でも取り除かれうるけれども,レコード・タイプ間では在存する。ス キーマが図表12.3.8にされたデータベースの場合には,部品メーカーの名前を変えることは,SUPPLIER関係だけでなく,PART関係においてそれが繰り返されているところすべてのSNAMEを変えることを意味する。

関係型スキーマ設計へのアプローチ
関係型モデルでは,データベースの設計は「正規形」 (normal form)という概念に基づいている。正規形を導出するのに用いられる手続きが「正規化」(normalization)と呼ばれる。多くの種類の正規形がある 。いくつかの予備的な定義に続き,3つのタイプの正規形を議論する。

1つのデータ・アイテム(あるいは複数のデータ・アイテム)Aのいくつかのオカレンスが1つのデータ・アイテム(あるいは複数のデータ・アイ テム)Bに同じオカレンスを持っているかもしれないが,Aの各オカレンスがBの1つかつ唯一のオカレンスに対応するならば, BはAに関数従属(functionally dependent)しているという(A→Bと表わす)たとえば,A={SNAME,PARTNO}, B={QTY}であるならば,A→ Bは,与 えられたSNAME,PARTNO,QTYが 一意に決まるということを意味する A→ BかっB→ Cであるならば,A→ Cは真であり,CはAに推移従属 (transitively dependent)している。関数従属は多対1の関係を表わす。

レコード・タイプRに対するキーとは,複数のデータ・アイテムKがRに対して1意検出子(unique identifier) であるようなRの なかの1つのKあるいはそれの集まりである。ある与えられた1つのレコード・タイプに対していくつかのキーが存在しうる。1つのデータ・アイテムAがRに対する任意のキーの1つのメンバーであるならば, Aを「プライム・データoア イテム」(prime data iteω と呼ぶ Aが任意のキーのメンバーでなければ,Aは非 プライムである。K→Aである上に,AがKの真部分集 合にも関数従属であるならば,R内の1つのデータ・アイ テム (あるいは複数のデータ・アイテム)Aは,Rに対する1つのキーKに半従属 (partially dependent)してい る AがKに半従属していなくて,かつ,K→ Aであるならば,データ・アイテムAはKに全従属 (fully dependent)している。

3つの正規形は次のとおりである。

1.第 1正 規形(First Normal Form :lNE)あるレコード・タイプが第1正規形であるのは,そのデータ・アイテムのどれもが,それ自身レコード・タイ プではない場合である。

2. 第2正規形 (Second Normal Form :2NF)あるレコード・タイプRが第2正規形であるのは,Rが lNFであり,かつ,Rの非プライム・データ・アイテムのそれぞれが,すべてのキーに全従属している場合である。Rが 2NFでないなら ば,R内の非プライ ム・データ・アイテムXに対して, K→ XかつKl→Xは真である。ここでKは Rに対する1つのキーであり,K=K1UK2,K2≠ 0である。 データ ・アイテム K1と Xは,K2の異なる。オカレンスのそれぞれに対して繰り 返さなければならず ,冗長性を生み出すことに注意さ れたい。たとえば,レコード・タイプRが,K1, K2,X,Yという4つのデータ・アイテムからなるとする 。 データ ・アイテムK1,K2が1つのキーを形成し, K1→ Xが真ならば,k1k2xy2とk1k’2xy2はR内の2つの可能なレコード・オカレンスである。Rが Rl=Kl K2Yと R2=Kl Xという2つのレコード・タイプに変更されるならば、R1とR2は第2正規形であり、先の相違の冗長性は除去される。

3.第3正規形(Third Normal Form :3NF)あるレコード・タイプRが3NFであるのは,Rが2NFであり,かつ,Rの非プライム・データ・アイテムのどれもがRの任意のキーに推移従属しない場合である。もし,Kが1つのキーであり,Aが非プライム・データ・アイテムであり,K→ X→ Aが真であるならば,Xオカレンスに対応するAオカレンスが存在しないかぎり,Kオカレンスと端にXオカレンスを記憶することはできない。もし,Aを削除すると, K→ X対応もまた失われる。したがって,3NFでないレコード・タイプは,挿入の不調和と削除の不調和をもたらすであろう。そこで,3NFは,レコードの不調和を除去する。さらに,その関係が3NFである。データベースは,すべての多対1関係を保存する。

ネットワーク型スキーマ設計へのアプローチ
ある与えられたアプリケーション領域に対して,ネットワーク型スキーマの設計をどのように押し進めるかに関する公表された研究はほとんどない。しかしながら,1つの有用な手順を図表12.3.14に要約した。この設計戦略は,Holsappleを書き改ためたものである。この手順を用いるためには,アプリケーション領域に関する知識をもたなければならない。1対1,1対多および多対多の関係は,手順の7つのステップに忠実に従うことによって自動的に保存される。不調和は,レコード・タイプ内でもレコード・タイプ間でも発生しない。これは,冗長性が関係表現において用いられていないからである いくらかの冗長性は,記憶や処理効率のためには望ましいかもしれないということに注意すべきである。設計戦略から生まれるネットワーク型スキーマは,様々な程度の冗長性を許容するために修正されうる(たとえば,2つの レコード・タイプを1つにしてしまうことによって).スキーマのユーザーは,このような修正から生じるありうる不調和を知っているべきである。

 本コラムは絶版となっている「IEハンドブック(サルベンティ編・日本能率協会訳・1986)」をアーカイブとして掲載するものです。このハンドブックの各章は多くの事例と理論を通して生産性向上に対するアイデアを提供するべく専門家によって執筆されています。基盤をなしているIEの考え方・原則はインダストリアル・エンジニアリングにかかわるすべてのひとに有用でしょう。

関連記事一覧

2019ものづくり公開セミナーガイド

B2Bデジタルマーケティングセミナー

ものづくり人材育成ソリューション

マーケティング分野オンラインセミナー