序章

データベース管理システム(DBMS)は、ユーザーがデータベースを操作できるようにするコンピュータープログラムです。 DBMSを使用すると、ユーザーはデータベースへのアクセスの制御、データの書き込み、クエリの実行、およびデータベース管理に関連するその他のタスクの実行を行うことができます。

ただし、これらのタスクのいずれかを実行するには、DBMSに、データの編成方法を定義するある種の基礎となるモデルが必要です。 リレーショナルモデルは、1960年代後半に最初に考案されて以来、データベースソフトウェアで広く使用されているデータを整理するためのアプローチのひとつであり、この記事の執筆時点では、トップの4つです。最も人気のある5つのDBMSはリレーショナルです。

この概念的な記事では、リレーショナルモデルの歴史、リレーショナルデータベースがデータを編成する方法、およびそれらが現在どのように使用されているかについて概説します。

リレーショナルモデルの歴史

データベースは、論理的にモデル化された情報のクラスター、またはデータです。 データのコレクションは、保存方法や保存場所に関係なく、データベースです。 給与情報を含むファイルキャビネットでさえ、病院の患者フォームのスタックや、複数の場所にまたがる企業の顧客情報のコレクションと同様に、データベースです。 コンピュータを使用してデータを保存および管理することが一般的に行われる前は、情報を保存する必要のある政府および企業組織が利用できるのは、このような物理データベースだけでした。

20世紀の半ば頃、コンピュータサイエンスの発展により、処理能力が向上し、ローカルおよび外部のストレージ容量が増加しました。 これらの進歩により、コンピューター科学者は、これらのマシンがこれまでになく大量のデータを保存および管理する可能性があることを認識し始めました。

しかし、コンピューターが意味のある論理的な方法でデータを整理する方法についての理論はありませんでした。 ソートされていないデータをマシンに保存することは1つのことですが、一貫性のある実用的な方法でそのデータを追加、取得、ソート、またはその他の方法で管理できるシステムを設計することははるかに複雑です。 データを保存および整理するための論理的なフレームワークの必要性から、データ管理にコンピューターを利用する方法について多くの提案がありました。

初期のデータベースモデルの1つは、階層モデルでした。このモデルでは、データは、現代のファイルシステムと同様に、ツリーのような構造で編成されています。 次の例は、動物の分類に使用される階層型データベースの一部のレイアウトがどのように見えるかを示しています。

Example Hierarchical Database: Animal categorization

階層モデルは初期のデータベース管理システムに広く実装されていましたが、柔軟性がないことも証明されました。 このモデルでは、個々のレコードに複数の「子」を含めることができますが、各レコードには階層内に1つの「親」しか含めることができません。 このため、これらの初期の階層型データベースは、「1対1」および「1対多」の関係のみを表すように制限されていました。 この「多対多」の関係の欠如は、複数の親に関連付けたいデータポイントを操作しているときに問題を引き起こす可能性があります。

1960年代後半、エドガーF. IBMで働くコンピューター科学者のCoddは、データベース管理のリレーショナルモデルを考案しました。 Coddのリレーショナルモデルでは、個々のレコードを複数のテーブルに関連付けることができるため、「1対多」の関係に加えて、データポイント間の「多対多」の関係が可能になります。 これにより、データベース構造の設計に関して他の既存のモデルよりも柔軟性が高まり、リレーショナルデータベース管理システム(RDBMS)がはるかに幅広いビジネスニーズを満たすことができるようになりました。

Coddは、 Alpha として知られる、リレーショナルデータを管理するための言語を提案しました。これは、後のデータベース言語の開発に影響を与えました。 IBMのCoddの同僚の2人、DonaldChamberlinとRaymondBoyceは、Alphaに触発されたそのような言語を1つ作成しました。 彼らは自分たちの言語をSEQUELと呼びました。既存の商標で、言語の名前を SQL (正式には Structured Query Language と呼ばれます)に短縮しました。

ハードウェアの制約により、初期のリレーショナルデータベースは依然として非常に低速であり、テクノロジが普及するまでにはしばらく時間がかかりました。 しかし、1980年代半ばまでに、Coddのリレーショナルモデルは、IBMとその競合他社の両方の多くの商用データベース管理製品に実装されていました。 これらのベンダーは、独自のSQLダイアレクトを開発および実装することにより、IBMの主導に従いました。 1987年までに、米国規格協会と国際標準化機構の両方がSQLの標準を承認して公開し、RDBMSを管理するための受け入れられた言語としてのステータスを固めました。

リレーショナルモデルは複数の業界で広く使用されているため、データ管理の標準モデルとして認識されるようになりました。 近年、さまざまな NoSQLデータベースが登場しても、リレーショナルデータベースはデータを保存および整理するための主要なツールであり続けています。

リレーショナルデータベースがデータを整理する方法

リレーショナルモデルの履歴についての一般的な理解ができたので、モデルがデータをどのように編成するかを詳しく見ていきましょう。

リレーショナルモデルの最も基本的な要素はrelationsであり、ユーザーと最新のRDBMSはこれをテーブルとして認識します。 リレーションは、タプルのセット、またはテーブル内の行であり、各タプルは属性のセットまたは列を共有します。

Diagram example of how relations, tuples, and attributes relate to one another

列は、リレーショナルデータベースの最小の組織構造であり、テーブルのレコードを定義するさまざまなファセットを表します。 したがって、それらのより正式な名前、属性。 各タプルは、テーブルが保持するあらゆるタイプの人、オブジェクト、イベント、または関連付けの一意のインスタンスと考えることができます。 これらのインスタンスは、会社の従業員、オンラインビジネスからの売上、またはラボのテスト結果などです。 たとえば、学校の教師の従業員レコードを保持するテーブルでは、タプルはnamesubjectsstart_dateなどの属性を持つ場合があります。

列を作成するときは、その列で許可されるエントリの種類を指定するデータ型を指定します。 RDBMSは多くの場合、独自のデータ型を実装しますが、他のシステムの同様のデータ型と直接交換できない場合があります。 一般的なデータ型には、日付、文字列、整数、ブール値などがあります。

リレーショナルモデルでは、各テーブルには、主キーと呼ばれる、各行を一意に識別するために使用できる列が少なくとも1つ含まれています。 これは重要です。これは、ユーザーが自分のデータがマシンのどこに物理的に保存されているかを知る必要がないことを意味します。 代わりに、DBMSは各レコードを追跡し、アドホックベースでそれらを返すことができます。 つまり、これは、レコードに定義された論理的な順序がなく、ユーザーが任意の順序で、または任意のフィルターを介してデータを返すことができることを意味します。

相互に関連付けたいテーブルが2つある場合、そのための1つの方法は、外部キーを使用することです。 外部キーは、基本的に、あるテーブル(「親」テーブル)の主キーを別のテーブル(「子」)の列に挿入したコピーです。 次の例は、2つのテーブル間の関係を示しています。1つは会社の従業員に関する情報を記録するために使用され、もう1つは会社の売上を追跡するために使用されます。 この例では、EMPLOYEESテーブルの主キーがSALESテーブルの外部キーとして使用されています。

Diagram example of how the EMPLOYEE table's primary key acts as the SALES table's foreign key

子テーブルにレコードを追加しようとして、外部キー列に入力された値が親テーブルの主キーに存在しない場合、挿入ステートメントは無効になります。 これは、両方のテーブルの行が常に正しく関連付けられるため、関係レベルの整合性を維持するのに役立ちます。

リレーショナルモデルの構造要素は、データを整理された方法で保存するのに役立ちますが、データの保存は、データを取得できる場合にのみ役立ちます。 RDBMSから情報を取得するには、 query 、または一連の情報に対する構造化されたリクエストを発行できます。 前述のように、ほとんどのリレーショナルデータベースはSQLを使用してデータを管理およびクエリします。 SQLを使用すると、さまざまな句、述語、および式を使用してクエリ結果をフィルタリングおよび操作できるため、結果セットに表示されるデータを細かく制御できます。

リレーショナルデータベースの利点と制限

リレーショナルデータベースの基本的な組織構造を念頭に置いて、それらの長所と短所のいくつかを考えてみましょう。

今日、SQLとそれを実装するデータベースは、いくつかの点でCoddのリレーショナルモデルから逸脱しています。 たとえば、Coddのモデルでは、テーブルの各行は一意である必要がありますが、実用性の理由から、ほとんどの最新のリレーショナルデータベースでは重複行が許可されています。 リレーショナルモデルに関するCoddの各仕様に準拠していない場合、SQLデータベースを真のリレーショナルデータベースと見なさないものもあります。 ただし、実際には、SQLを使用し、リレーショナルモデルに少なくともある程度準拠しているDBMSは、リレーショナルデータベース管理システムと呼ばれる可能性があります。

リレーショナルデータベースの人気は急速に高まりましたが、データの価値が高まり、企業がより多くのデータを保存し始めると、リレーショナルモデルの欠点のいくつかが明らかになり始めました。 一つには、リレーショナルデータベースを水平方向にスケーリングするのは難しい場合があります。 水平スケーリングまたはスケールアウトは、負荷を分散し、より多くのトラフィックとより高速な処理を可能にするために、既存のスタックにマシンを追加する方法です。 これは、多くの場合、既存のサーバーのハードウェアをアップグレードする垂直スケーリングとは対照的です。通常、RAMまたはCPUを追加します。

リレーショナルデータベースを水平方向にスケーリングすることが難しい理由は、リレーショナルモデルが整合性を保証するように設計されているという事実と関係があります。つまり、同じデータベースをクエリするクライアントは常に同じデータを取得します。 リレーショナルデータベースを複数のマシンにまたがって水平方向にスケーリングする場合、クライアントは1つのノードにデータを書き込むことができますが、他のノードにはデータを書き込まないため、一貫性を確保することは困難になります。 最初の書き込みと、変更を反映するために他のノードが更新される時間との間に遅延が発生する可能性があり、その結果、ノード間に不整合が生じます。

RDBMSによって提示される別の制限は、リレーショナルモデルが構造化データ、または事前定義されたデータ型と一致するか、少なくとも事前に定義された方法で編成されたデータを管理するように設計されていることです。 しかし、1990年代初頭のパーソナルコンピューティングの普及とインターネットの台頭により、非構造化データ —電子メールメッセージ、写真、ビデオなど。 —より一般的になりました。

これは、リレーショナルデータベースが役に立たないと言っているわけではありません。 まったく逆に、リレーショナルモデルは、40年以上経った今でもデータ管理の主要なフレームワークです。 それらの普及と寿命は、リレーショナルデータベースが成熟したテクノロジーであることを意味し、それ自体がそれらの主要な利点の1つです。 リレーショナルモデルで動作するように設計された多くのアプリケーションがあり、リレーショナルデータベースに関しては専門家である多くのキャリアデータベース管理者もいます。 リレーショナルデータベースを使い始めようとしている人のために、印刷物やオンラインで利用できるさまざまなリソースもあります。

リレーショナルデータベースのもう1つの利点は、ほとんどすべてのRDBMSがトランザクションをサポートしていることです。 トランザクションは、単一の作業単位として順番に実行される1つ以上の個別のSQLステートメントで構成されます。 トランザクションはオールオアナッシングアプローチを提示します。つまり、トランザクション内のすべてのSQLステートメントが有効である必要があります。 そうしないと、トランザクション全体が失敗します。 これは、複数の行またはテーブルに変更を加えるときにデータの整合性を確保するのに非常に役立ちます。

最後に、リレーショナルデータベースは非常に柔軟性があります。 これらは、さまざまなアプリケーションを構築するために使用されており、非常に大量のデータでも効率的に機能し続けます。 SQLも非常に強力であるため、データをその場で追加および変更したり、既存のデータに影響を与えることなくデータベーススキーマとテーブルの構造を変更したりできます。

結論

データの整合性に関する柔軟性と設計のおかげで、リレーショナルデータベースは、データが最初に考案されてから50年以上経った今でも、データを管理および保存するための主要な方法です。 近年、さまざまなNoSQLデータベースが登場していますが、データの力を活用するアプリケーションを構築したい人にとっては、リレーショナルモデルとRDBMSの操作方法を理解することが重要です。

いくつかの人気のあるオープンソースRDBMSの詳細については、さまざまなオープンソースリレーショナルSQLデータベースの比較を確認することをお勧めします。 データベース全般について詳しく知りたい場合は、データベース関連コンテンツの完全なライブラリを確認することをお勧めします。