データベースとは？DB設計、種類、例など初心者なら読んでおきたい基本ガイド

データベースとは、データを体系的に整理・保存し、効率的にアクセス・管理するための構造化された情報の集合体を指します。データベース（英：database・DB) は、様々なデータを一元管理し、必要に応じて情報を迅速かつ正確に取得するための基盤として機能します。

データベースは以下の特徴を持っています：

1. データの整理と構造化: データはテーブルやフィールドなどの構造に整理されます。これにより、関連するデータを効率的に保存・取得することができます。
2. データの一貫性と整合性: データベースシステムはデータの一貫性を保つためのルールや制約を設定できます。これにより、データの正確性と信頼性が向上します。
3. アクセスの効率化: データベースは検索やフィルタリングのための機能を提供し、必要なデータを迅速に見つけ出すことができます。
4. 同時アクセスと共有: 複数のユーザーが同時にデータベースにアクセスし、データを共有することができます。これにより、チームや組織内での情報共有が容易になります。
5. セキュリティとバックアップ: データベースはアクセス権の管理やデータのバックアップ機能を提供し、データの安全性を確保します。

データベースは、日常生活からビジネスの様々な場面において、情報の整理・管理・利用を支援する重要なツールです。例えば、オンラインショッピングサイトの製品カタログ、病院の患者記録、企業の財務データ、学校の成績管理システムなど、多岐にわたる分野で利用されています。

データベース管理システム (DBMS) は、データベースの作成、管理、および操作を行うためのソフトウェアであり、データベースの効率的な運用を支援します。DBMSには、Oracle、MySQL、PostgreSQL、Microsoft SQL Serverなどの様々な種類があります。各DBMSは、それぞれ異なる機能や特徴を持ち、用途やニーズに応じて選択されます。

Lucidchartを使用することで、データベースの設計を視覚的に行い、効率的なデータベース構築が可能になります。データベース設計の基本を理解し、実際にデータベースを作成してみることで、データ管理のスキルを向上させましょう。

適切に構築されたデータベース設計には、以下の特長があります。

• 冗長データを排除し、ディスク容量を節約する。
• データの正確性と整合性を保つ。
• 便利な方法でのデータへのアクセスを可能にする。

効率的で有用なDB設計のためには、以下のステップを含め、ベストプラクティスの実行が肝要です。

1. 要件の分析やデータベースの目的の定義
2. 表形式でのデータの整理
3. 主キーの指定と関連の分析
4. 正規化による表の標準化

それでは、DB設計のやり方の詳細を見ていきましょう。このガイドでは、(階層型、ネットワークやオブジェクトデータモデルではなく) SQL で記述されたエドガー・コッドの関係データベースモデルを主に取り扱っています。

次の手順では、データベースの視覚的なレイアウトを決定します。そのためには、関係データベースの構造を正確に理解しておく必要があります。

データベース内では、関連するデータは表形式にグループ化されます。表はスプレッドシートのように行（レコード）と列（フィールド）で構成されています。

データのリストを表に変換するには、まず製品、売上、顧客、注文などのエンティティごとに表を作成します。以下にその具体例を示します。

表の各行はレコードと呼ばれます。レコードには、特定の顧客などに関するデータが含まれます。列（フィールドや属性とも呼ばれます）には、表に記載された全ての顧客の住所など、各レコードに関連する情報の1つのタイプが含まれます。

履歴間でのデータの一貫性を保つために、各列に適切なデータ型を割り当てます。一般的なデータ型には以下のものがあります。

• CHAR: 固定長文字列
• VARCHAR: 可変長文字列
• TEXT: 大量の文字列
• INT: 正または負の整数
• FLOAT, DOUBLE: 浮動小数点数の格納が可能
• BLOB: バイナリデータ

また、データベース管理システムの中には、行ごとに一意の番号を自動生成するオートナンバーデータ型を含むものもあります。

データベースを視覚的に概観するためには、実体関連図（ER図）を作成します。ER図では、表の代わりに図内のボックスを使用します。各ボックスのタイトルは、表が記述するデータの内容を示し、属性は次のように列挙されます。

最後に、必要に応じて各表の主キーとして機能する属性を決定します。主キー（PK）は特定のエンティティの一意の識別子を指します。つまり、その値さえ分かれば、顧客を正確に特定できるということです。

主キーとして選択する属性は、一意かつ不変で、常に存在する（NULLまたは空とならない）ものとします。例えば、注文番号やユーザー名は主キーに適しており、電話番号や住所は適していません。必要に応じて、複数のフィールドを組み合わせて複合キーを使用することもできます。

実際にデータベースを作成する際には、論理データ構造と物理データ構造を、使用するデータベース管理システム（DBMS）が対応しているデータ定義言語（DDL）に変換する必要があります。その際、必要なパフォーマンスレベルとストレージ容量が得られるように、データベースのサイズを見積もることも重要です。

データベースにはさまざまな種類があります。最も一般的なモデルには以下のものがあります。

• 階層型データベースモデル
• 関係モデル
• ネットワークモデル
• オブジェクト指向データベースモデル
• 実体関連モデル
• ドキュメント型モデル
• エンティティ-アトリビュート-バリューモデル
• スタースキーマ
• オブジェクト関係モデル

データベースを記述するモデルの選択は、いくつかの要因に基づいて行います。最大の要因は、使用しているデータベース管理システム（DBMS）が特定のモデルに対応しているかどうかです。複数のモデルに対応するDBMSもありますが、大半のDBMSは特定のデータモデルを念頭に設計されています。その場合、その特定のモデルを使用する必要があります。

また、DB設計プロセスの各段階に応じて異なるモデルを使用することもあります。例えば、ユーザーがデータを知覚する方法でデータ間の関連を図式化するには、高次的な概念データモデルが最適です。他方で、レコードに基づく論理モデルでは、サーバーにデータを格納する方法をより正確に記述できます。

さらに、データモデルを選択する際には、速度、コスト削減、利便性など、データベースに求める優先順位と特定のモデルの強みを考慮することも重要です。

それでは、最も一般的なデータベースモデルのいくつかを詳しく比較してみましょう。

関係データベース

関係モデル

最も一般的なデータベースモデルである関係モデルでは、データを行と列で構成される表（リレーション）に並べ替えます。各列には、価格、郵便番号、生年月日など、エンティティの属性が示されます。このような属性の集まりをドメインと呼びます。特定の属性やその組み合わせを主キーとして選択し、主キーは他の表で外部キーとして参照されます。

各行（タプル）には、特定の従業員など、エンティティの特定のインスタンスに関するデータが含まれます。

このモデルは、一対一、一対多、多対多といったテーブル間の関連性も表現できます。以下に例を示します。

関係データベース内では、テーブルを正規化し、データベースの柔軟性、適応性、スケーラビリティを確保するために正規化ルールを適用します。テーブルを正規化すると、データが最小単位に分解され、各部分が不可分となります。

関係データベースは一般に構造化照会言語（SQL）で記述されます。このモデルはエドガー・F・コッドによって1970年に発表されました。

階層モデル

階層モデルでは、各レコードが1つの親（ルート）を持つ木構造のようにデータを整理します。兄弟レコードは特定の順序で並べられ、その順序はデータベースに格納される物理的な順序として使用されます。この関係データベースモデルは、世界の多くの関連性を表現するのに適しています。

このモデルは、1960年代から1970年代にかけて、IBMの情報管理システムで主に使用されていました。しかし、運用面で非効率的なため、現在ではほとんど使用されていません。

ネットワークモデル

ネットワークモデルは、親となる複数の履歴を伴うリンクされた履歴間の多対多の関連を示すことにより、階層型モデルの形をとります。数学の集合論に基づき、関連する履歴の集合で構成されるモデルです。集合はそれぞれ、1つのオーナーまたは親履歴と1つ以上のメンバーまたは子履歴から構成されます。ある履歴が複数の集合のメンバーや子となることもでき、複雑な関連を表現することが可能なモデルです。

データシステム言語協議会 (CODASYL) により正式に定義されて以降、1970年代に最も人気を博したモデルです。

オブジェクト指向データベースのモデル

このモデルでは、データベースを関連する機能やメソッドを持つオブジェクト、または再利用可能なソフトウェア要素の集合として定義します。オブジェクト指向データベースには以下の種類があります。

• マルチメディアデータベース: 画像などのメディアを格納できるデータベースで、関係データベースには格納できないデータを含みます。

• ハイパーテキストデータベース: 任意のオブジェクトを他の任意のオブジェクトにリンクできるデータベースです。異なる性質の多量のデータを整理するのに役立ちますが、数値解析にはあまり適していません。

• ハイブリッドデータベースモデル: 表を組み込んだオブジェクト指向データベースモデルで、ポスト関係データベースモデルとして最も知名度があります。ただし、組み込む対象は表に限定されません。

オブジェクト関係データベースモデル

オブジェクト関係データベースモデルは、関係データベースの簡潔さとオブジェクト指向データベースモデルの高度な機能性を組み合わせたハイブリッドデータベースモデルです。設計者が使い慣れた表構造にオブジェクトを組み込める点が特長です。

このモデルでは、以下のような言語とコールインターフェイスが利用されます:

• SQL3: 標準SQLの第3版で、オブジェクト関係モデルで使用される拡張機能をサポートしています。
• ベンダー固有の言語: 各ベンダーが独自に提供するデータベース操作言語やインターフェイスです。
• ODBC: Open Database Connectivityの略で、さまざまなデータベースへのアクセスを標準化したAPIです。
• JDBC: Java Database Connectivityの略で、JavaプログラムからデータベースにアクセスするためのAPIです。
• 関係モデルで用いられる言語とインターフェイスの延長線上にある独自のコールインターフェイス: 特定の関係データベース管理システムが提供する独自のAPIやインターフェイスです。

これらの言語とインターフェイスを利用することで、オブジェクト関係モデルは柔軟性と拡張性を提供します。

実体関連モデル（ER図）

実体関連モデルは、実世界の実体間の関連を示すデータベースモデルです。このモデルでは、ネットワークモデルと類似していますが、ネットワークモデルが物理的なデータベース構造に直接的に依存するのに対して、実体関連モデルはより概念的な設計を重視します。オブジェクト関係モデルと同様に、データベースの概念的な設計に広く用いられます。

ER図では、格納されたデータポイントに関連する人物、場所、または物事が「実体」として表現されます。それぞれの実体は、固有の属性を持つドメインを構成します。また、実体間の関連性も明示され、図示されることがあります。

人気のある実体関連図（ER図）の一種にはスタースキーマがあります。スタースキーマは、中央のファクト表（事実表）が多次元のデータベース表に接続される図式です。

その他のデータベースモデル

この他にもさまざまなデータベースモデルが存在します。

転置ファイルモデル

• 高速の全文検索を支援するために設計されたデータベースモデルで、データコンテンツがインデックス化されたキーとしてインデックステーブル内に格納されます。例として、Software AG のADABASデータベース管理システムで1970年代から使用されています。

フラットモデル

• 初期のデータベースモデルで、1つの表にデータを行と列で簡単に列挙するモデルです。小規模なデータセットには適していますが、データアクセスや操作が非効率な場合があります。

多次元モデル

• 関係モデルの拡張で、オンライン分析処理（OLAP）向けに設計されています。データベースは多次元のデータ構造を持ち、立方体のような形で表現されます。

半構造モデル

• データとスキーマの境界が不明瞭なモデルで、特定のウェブベースのデータソースや非構造化データを扱うのに適しています。

コンテキストモデル

• 他のデータベースモデルの要素を組み込むことができるモデルで、柔軟性が高く、複数のモデルの特性を組み合わせることができます。

連想モデル

• データを実体と関連に基づき分割し、それぞれに一意の識別子を割り当てます。このモデルでは、ソース、動詞、ターゲットという一意の識別子を持つリンクでデータを構造化します。

これらの他にも、以下のようなデータベースモデルが存在します：

• セマンティックモデル: 格納されたデータと実世界との関連を明確に示す情報を含むモデル。
• XMLデータベース: データを指定し、XML形式で格納することができるデータベース。
• 名前付きグラフ: ノードとエッジで構成されるデータを表現するグラフデータベース。
• トリプルストア: 主語、述語、目的語の3つ組（トリプル）でデータを格納するデータベース。

これらのモデルは、それぞれの特性や使用目的に応じて選択され、実世界のデータ管理や操作に活用されています。

非SQL データベースモデル

オブジェクトデータベースモデルの他にも、関係データベースモデルとは対照的な以下の非 SQL モデルがいくつか登場してきました。

グラフデータベースモデル

• ネットワークモデルよりもさらに柔軟で、ノードとエッジで構成されるデータを表現します。このモデルでは、複数のノード間に複数の関係を持たせることができ、非常に複雑な関連性を表現することができます。特に、ソーシャルネットワークや推薦システムなどの分野で有用です。

複数値モデル

• 属性が単一のデータポイントではなく、複数の値やデータリストを含めることができるモデルです。これにより、1つのエンティティが複数の値を持つことができ、関係モデルの単一の属性と比較して柔軟性が増します。例えば、1つの商品に対して複数のタグやカテゴリを持たせることができます。

ドキュメントモデル

• 文書や半構造化データの格納や管理を目的としたモデルです。JSONやXMLなどの形式でデータを格納し、階層的な構造を持つことができます。このモデルは、ウェブコンテンツ管理やコンテンツ配信ネットワーク (CDN)、さらにはユーザープロファイルやログデータなど、柔軟なデータ構造が必要な場面で広く使用されています。

これらのモデルは、それぞれの特性を活かして、異なるデータ管理の課題に対応するために設計されています。関係データベースモデル以外の非 SQL モデルは、特にデータの柔軟性や複雑な関係性の表現が求められる場面で役立ちます。

ウェブ上のデータベース

データベースの利用は、現代のさまざまな産業や活動に不可欠な要素となっています。ウェブサイトやオンラインサービス、オンラインショッピング、政治活動、産業の製造とサプライチェーン管理など、広範な分野でデータベースが活用されています。それぞれの業界では、データベースの設計や利用に関する独自の規範が設けられています。

データが表形式に変換され、これらの表間の関連を分析する準備ができました。濃度とは、2つの関連する表間でやり取りする要素の量を指します。濃度を特定することで、データを表へ効率的に分割できたかどうかを確認することができます。

実体はそれぞれ、他のあらゆる実体と関連をもつことができますが。これらの関連は通常、以下の3つの種類のいずれかに該当します。

一対一の関連

実体 B のインスタンスすべてに対して実体 A のインスタンスが1つしかない場合、これらの実体は一対一 (1:1) の関連にあるとされます。ER 図では、以下のように、各端にダッシュをもつ線でこうした関連を示すことができます。

特別な理由が他にない限り、1:1の関連は通常、2つの表のデータを1つの表に統合した方がよい旨を示すものです。

ただ、特殊な条件下で1:1の関連の表を作成したい場合もあるでしょう。「説明」など、省略可能なデータのフィールドがあり、履歴の大半でこのフィールドが空白の場合には、これら「説明」すべてをまとめて別個に表を作成し、空白のスペースを排除してデータベースのパフォーマンス改善につなげることができます。

データを正しく一致させるには、各表に同一の列 (通常、主キー) を少なくとも1列含める必要があります。

一対多の関連

この関連は、1つの表内の履歴が別表の複数の入力内容に関連付けられている場合に発生します。例えば、ある顧客が複数の注文を行った場合や、利用者が一度に図書館で複数の図書を借りた場合がこれに当たります。一対多 (1:M) の関連は、以下の例のような「カラスの足記法」で示されます。

データベース構築時に1:M の関連を実装するには、関連の「1」側の表の主キーを他方の表の属性として追加します。こうして別の表に記載された主キーは、外部キーと呼ばれます。関連の「1」側の表は、「M」側の子表に対して親表とみなされます。

多対多の関連

ある表の複数の入力内容がもう1つの表の複数の入力内容に関連付けられる場合、これらは多対多 (M:N) の関連にあるとされます。この例としては、学生と生徒の関係が挙げられます。学生は多数の授業を受講でき、授業には多数の学生が参加できるためです。

ER 図では、これらの関連は以下の線で示されます。

残念ながら、データベースに直接多対多の関連を実装することはできません。2つの一対多の関連に分割する必要があります。

関連を分割するには、2つの表の間に新しい実体を作成します。販売と製品の間に M:N 関連が存在する場合には、各販売における内容を示すであろう新しい実体に「販売済み製品」と名を付けるのも一案です。販売と製品の表はいずれも、「販売済み製品」との間で1:M の関連をもつことになります。こうした橋渡し役をする実体は、さまざまなモデルでリンク表、関連実体や結合表などと呼ばれます。

このリンク表の各履歴は、隣接する表の実体2つを一致させたものです (補足情報が含まれる場合もあります)。例えば、学生 (Students) と授業 (Classes) の間のリンク表は以下のようになります。

必須か否か?

関連を分析するには、関連の一方が存在する前提として、他方が存在する必要があるかどうかを検討する方法もあります。存在が必須でない側には、線上の通常ダッシュを付ける位置に丸を付けて示すことができます。例えば、以下の例では、ある国の国連代表 (UN representative) が存在するためにはその国 (Country) 自体の存在が不可欠ですが、逆は真ではありません。

2つの実体を相互依存 (他方が存在しない場合には存在し得ない) とすることもできます。

再帰関連

時に、表がその表自体を参照することもあります。例えば、従業員の表に同じ表内の他の人を指す属性「マネージャー」が含まれる場合があります。これは再帰関連と呼ばれます。

冗長関連

関連が複数示されている場合、関連が冗長であると称されます。通常は、重要な情報を失うことなく、関連の片側を削除することができます。例えば、実体「学生」が他の実体「教師」と直接関連しており、なおかつ「授業」を通じて間接的にも「教師」と関連している場合には、「学生」と「教師」の間の関連を削除することも考えられます。「学生」は「授業」を通じてのみ「教師」に割り当てることができるため、「学生」と「教師」の間の関連は削除した方がよいでしょう。

データベースの基本設計が完了したら、正規化ルールを適用して表が正しく構成されていることを確認します。

データベースの中には正規化に適さないものもあります。一般に、ユーザーが履歴の作成、読み出し、更新や削除に関与するオンライントランザクション処理 (OLTP) データベースでは、正規化が必要となります。

分析とレポーティング向きのオンライン分析処理 (OLAP) データベースの場合には、計算速度が重視されるため、ある程度の非正規化が適している可能性があります。データを変更せずに迅速に分析する必要のある意思決定支援アプリケーションもこれに含まれます。

正規化の各形式とレベルにはいずれも、下位の形式に関連付けられたルールが含まれます。

第1正規形

第1正規形 (1NF) は、表内の各セルに設定できる値が１つのみで、複数の値を含むことがありません。したがって、以下のような表はこれに該当しません。

データを別の列に分割してこのルールを回避したくなるかもしれませんが、それもまたルールに違反しています。反復、または密接な関係をもつ属性のグループを含む表は第1正規形の条件を満たさないためです。例えば、以下のような表は条件を満たしません。

代わりに、各セルに含まれる値が1つのみとなり、余分な列がなくなるようにデータを複数の表や履歴に分割します。この時点で、データは利用可能な最小単位へ分割され、不可分となります。上記の表の場合には、特定の製品を売上と一致させる表「売上詳細」を追加で作成することができます。そうすることで、「売上」と「売上詳細」が一対多の関係をもつようになります。

第2正規形

第2正規形（2NF）では、各属性は主キー全体に完全に依存する必要があります。つまり、各属性が他の属性を経由せずに直接的に主キーに依存する必要があります。

例えば、「学生 ID」に依存する「生年月日」に「年齢」が依存する状態は部分関数従属と呼ばれ、このような属性を含む表は第2正規形を満たしません。

さらに、複数のフィールドから構成され、主キーを含む表で、1つまたは複数のフィールドが主キーの一部にのみ依存する場合、その表は第2正規形には該当しません。

したがって、以下の表は第2正規形に該当しません。表は次のフィールドを含みます：「注文番号」（主キー）、「製品 ID」（主キー）、そして「製品名」。これには、「製品名」が「製品 ID」に依存しているが、「注文番号」には依存していないためです。

 第3正規形

データベースを適切に構成し、ルールに従ってデータを検証することは非常に重要です。Microsoft Accessを含む多くのデータベース管理システムには、こうしたルールを自動的に適用する機能が備わっています。

1. 実体整合性ルール: 主キーをNULLにすることは許されません。主キーが複数の列で構成される場合、それぞれの列もNULLにすることはできません。このルールに違反すると、履歴を一意に識別することができなくなる可能性があります。

2. 参照整合性ルール: 外部キーは、参照先の表内の主キーと一致しなければなりません。主キーに対して変更や削除を行った場合、これらの変更内容をデータベース全体のすべての参照元に反映させる必要があります。

3. ビジネスロジック整合性ルール: データが特定のビジネスルールや論理パラメータに従うことを確保します。例えば、予約時間は通常営業時間内に収まる必要があります。

これらの整合性ルールを厳密に遵守することで、データベースの信頼性や効率性を高め、データの品質を保つことができます。データベース管理システムが提供する自動適用機能を活用することで、エラーや不整合を未然に防ぐことができます。

インデックスは、本質的には並べ替えられた1つまたは複数の列のコピーで、昇順または降順で値が並ぶものを指します。インデックスを追加することで、ユーザーはデータをより効率的に取得できるようになります。システムは、クエリを再度データを並べ替えることなく、インデックスで指定された順序でデータにアクセスすることができます。

しかし、インデックスを使用することでデータ取得の速度が向上する一方で、履歴に変更が加えられるたびにインデックスの再構築が必要となります。そのため、データの挿入、更新、削除の速度が低下する可能性があります。

ビューは、データベースに保存されたクエリを指します。複数の表からのデータの結合や特定の表の一部の表示を行う際に便利です。ビューを使用することで、データの複雑な結合や必要な部分の抽出を容易に行うことができます。

基本的なレイアウトが完成したら、指示テキスト、入力マスク、特定のスキーマ、ビューや列に適用する形式設定ルールなどの拡張プロパティを使ってデータベースを調整します。これらのルールはデータベース自体に格納されるため、そのデータにアクセスする複数のプログラム全体でデータの整合性を確保できるという利点があります。

オブジェクト指向言語で作成された複雑なシステムを視覚的に表現するためのもう一つの方法が統一モデリング言語 (UML) です。このガイドで取り上げた概念のいくつかは、UML においては別の名前で表現されます。例えば、実体は UML ではクラスと呼ばれます。

UML はかつてほどは使われなくなり、現在では、学術用途やソフトウェア設計者とクライアントの間のコミュニケーション手段として主に使われています。

データベース管理システムを選ぶ際には、いくつかのポピュラーな選択肢があります。それぞれのシステムには異なる特性や利点がありますので、具体的な要件や条件に基づいて適切なものを選ぶことが重要です。

1. Oracle DB: 大規模なエンタープライズ環境向けで、高い可用性やセキュリティ機能が特徴です。コストが高いことがありますが、大規模なデータ処理や複雑なアプリケーションに適しています。

2. MySQL: オープンソースで広く利用されており、軽量で高速なデータ処理が可能です。Webアプリケーションや中小規模のシステムに適しています。コストが低く、多くのオペレーティングシステムで動作します。

3. Microsoft SQL Server: Microsoft製のデータベースで、Windows環境での統合性が高く、簡単な管理が可能です。企業内のアプリケーションやBI（ビジネスインテリジェンス）向けに広く利用されています。

4. PostgreSQL: オープンソースで高度な機能と拡張性を持ち、データの信頼性や安全性が重視される環境に適しています。多くのオペレーティングシステムで動作し、コミュニティによるサポートが充実しています。

5. IBM DB2: IBM製のデータベースで、大規模なトランザクション処理や企業向けの高可用性を提供します。特にIBM製品との統合が強みであり、大規模なデータウェアハウスや分析用途に適しています。

選択の際には、以下のような要素を考慮すると良いでしょう：

• コスト: ライセンス費用やサポートコスト、ハードウェア要件などのコストを含めた総所有コスト（TCO）を考慮します。
• オペレーティングシステムのサポート: 自社のシステムが稼働するオペレーティングシステムとの互換性やサポートが重要です。
• 機能: 必要な機能や性能要件に応じて、各データベースの提供する機能を評価します。

選択肢の中から最適なデータベース管理システムを選ぶことで、データの効率的な管理と処理、システムの信頼性の確保が可能となります。