最短データベース設計ガイド

1つのプロジェクトのフレームワーク内で、既存のデータベースをインポートすることが私の冒険でした。 このベースはアクセスで作成され、プロジェクトの本質は、同様の機能を提供するWebアプリケーションを作成することでしたが、現在の現実(Webインターフェイス、権限の分離など)を考慮しました。 議論したキーで検討すると、開発は次のように構築されました。



1.要件を満たす独自のシステムを作成します

2.ソースデータベースからデータをインポートします



このメモはポイント2についてです。



私は最初に完全に異常な基盤に出会いました。 つまり リレーショナルデータベース構築のほぼすべての原則に違反しています。 それにもかかわらず、このベースは長い間使用されてきました。 詳細は説明しませんが、最初のショックの原因は「January」、「February」などの名前のテーブルだけです。 勤務スケジュール用。 私を信じて、その後、すべてがはるかに悪かった。 これを作成した人を判断するのは私ではないことを理解しています-システムは1年以上使用されており、ある程度顧客のニーズを満たしていました。 もうそのような「ベース」に出会いたくありません。 このメモがこれに役立つことを願っています。





最短のデータベース設計ガイド。





例として、商品の会計のベースを設計します。 ツリーのようなカタログと製造元情報。



1.オブジェクト



最初に行うことは、サブジェクト領域のオブジェクトのタイプを強調表示することです。 私たちの場合、これらは「商品」、「カタログセクション」、「メーカー」です。 各テーブルには独自のテーブルがあります。 テーブルの各レコード(行)には、1つのオブジェクトに関するデータが含まれています。 レコードの順序は定義されていません。 データがアルファベット順に追加されると、レコードのリクエストでこれに違反します。



データの重複は避けなければなりません。 たとえば、「product」テーブルの各レコードにメーカーに関する完全な情報を保存することは受け入れられません。 なぜなら 一部のメーカーのデータを変更する場合は、「商品」の表でそのデータへのすべての参照を探す必要があります。 テーブルのitem, node company.



呼び出しましょうitem, node company.







2.主キー



特定のオブジェクトに「アピール」するには、固有の番号を付ける必要があります。 一般的に、これは任意の一意のフィールドまたはフィールドのグループ(たとえば、従業員の場合、パスポート番号または姓、名、ミドルネーム)になりますが、多くの理由から、一意の値を持つ個別のフィールドを作成する方がはるかに便利です。 このフィールドは主キーです。 通常、このフィールドは「id」(識別子)と呼ばれます。



3.通信、外部キー



すべてのオブジェクトは何らかの形で互いに接続されています-メーカーは商品を生産し、商品はカタログに配置されます。 関係には3つの形式があります。



一対多



1つのメーカーがさまざまな製品を作成できます。 これは単純に実装されます-「多く」のオブジェクトのテーブルでは、オブジェクトのIDである「1」でフィールドが作成されます。 商品とメーカーの場合、company_idフィールドをitemテーブルに追加する必要があります。これには、この製品のメーカーのIDが含まれます。 このようなフィールドは外部キーと呼ばれます



多対多



カタログの複数のセクションに任意の製品を同時に表示できます。 このような関係は、製品IDフィールドとセクションIDフィールドを持つ別のテーブルに保存されます。 したがって、各テーブルエントリは、カタログセクション内の商品の存在を意味します。



一対一



私たちの商品は本とCDだとしましょう。 それらの一般的な情報と商品の種類はアイテムテーブルに格納され、書籍とディスクに固有のデータをそれぞれテーブルbookとdiskに格納します。 つまり bookテーブルの各エントリに対して、itemに正確に1つのエントリがあります。 実際、この1つのオブジェクトは2つのテーブルに格納されます。



このように実装されます-bookテーブルの主キーには、itemテーブルのIDが含まれます。 つまり 主キーは外部キーでもあります。





実際、これも1対多です。 カタログの1つのセクションには、他の多くのセクションが含まれています。 実装は同じです-ノードテーブルエントリには、親セクションのID(parent_id)が含まれます



4.整合性の確保



矛盾を避けるために、すべての通信とキーを適切に記述する必要があります。 データベース管理システムでは、製品またはサブセクションを含むカタログセクションが参照している製造元を削除することはできません。 他のタイプの反応も可能です。 主なことは、データベースが常に正しい状態にあることです。 存在しないエントリを参照する外部キーはありません。



SQLでも同じこと

1.テーブルを作成する



--

create table node (

id numeric not null, --

parent_id numeric not null, -- .

name varchar(200)

);



-- -

create table company (

id numeric not null, --

name varchar(1000),

);



--

create table item (

id numeric not null, --

company_id numeric not null, -- . -

type varchar(10) NOT NULL, -- 'book' 'disc'

name varchar(1000), --

qty numeric, -- -

price numeric --

);









2-3-4。 欠落しているリンクを作成し、どのフィールドが主キーおよび外部キーであるかを示します。



-- -

create table book (

id numeric not null, -- , item

author varchar(1000)

);



-- -

create table disk (

id numeric not null, -- , item

play_time numeric

);



create table node_item (

node_id numeric not null,

item_id numeric not null

);



--

alter table node add constraint "PK_NODE" primary key (id);

alter table item add constraint "PK_ITEM" primary key (id);

alter table company add constraint "PK_COMPANY" primary key (id);

alter table book add constraint "PK_BOOK" primary key (id);

alter table disk add constraint "PK_DISK" primary key (id);

-- , --, .

alter table node_item add constraint "PK_NODE_ITEM" primary key (node_id, item_id);



--

alter table node add constraint "FK_NODE_PARENT" foreign key (parent_id) references node(id);

alter table item add constraint "FK_ITEM_COMPANY" foreign key (company_id) references company(id);



alter table node_item add constraint "FK_NODEITEM_NODE" foreign key (node_id) references node(id);

alter table node_item add constraint "FK_NODEITEM_ITEM" foreign key (item_id) references item(id);



alter table book add constraint "FK_BOOK_ITEM" foreign key (id) references item(id);

alter table disk add constraint "FK_DISK_ITEM" foreign key (id) references item(id);










All Articles