web-dev-qa-db-ja.com

カーディナリティと参加の明確化

私は現在、20ほどのテーブルでスキーマを再設計しています。最初のタスクは、既存のテーブル/制約/関係からERDを作成することです。ビジネスルールからERDを作成するのは得意ですが、設計が不十分なデータベースから同じ情報を抽出するのは困難なため、これは予想以上に難しいことがわかりました。

私の特定の質問は、DDLからの制約と関係をカーディナリティーとERDへの参加に変換することを中心に展開します。例：

2つのサンプルテーブルの次のDDL（関連する属性、つまりFKとPKのみを含めました）：

CREATE TABLE SCHEMA.SCHEDULE (
    SCHEDULE_ID NUMBER(22,0),
    CONSTRAINT SCHEDULE_PK PRIMARY KEY (SCHEDULE_ID)
) ;

CREATE TABLE SCHEMA.OBJECTS (
    OBJECT_ID NUMBER,
    SCHEDULE_ID NUMBER,
    CONSTRAINT OBJECT_PK PRIMARY KEY (OBJECT_ID),
    CONSTRAINT OBJECTS_SCHEDULE_FK FOREIGN KEY (SCHEDULE_ID) REFERENCES SCHEMA.SCHEDULE(SCHEDULE_ID)
) ;

上記のDDLから、私は次のことを理解しています。-SCHEMA.SCHEDULEは親であり、SCHEMA.OBJECTSは子です

その後、次のERDを作成できました。

Incomplete ERD taken from DDLs

私が理解できないことは、カーディナリティと参加です。 SCHEDULEの場合は（1、M）、OBJECTSの場合は（0、m）だと思います。これは正しいです？

多くの例を含むリソースや優れた明確な説明も高く評価されています。 ERDを最小/最大表記で作成しています。

ありがとうございました。

database-designforeign-keyprimary-keyconstrainterd
1
William

さらなる研究の後、そして将来の誰かのために、私はこのトピックを調べて学んだことを投稿したいと思いました。クレジットは、主にナラヤンS.ウマナートとリチャードW.スカメル（第2版）による「データモデリングとデータベースデザイン」に使用されます。

私は次の参加とカーディナリティを思いつきました： ERD with Participation and Cardinality Constraints in Min/Max Notation

上記の関係を参照して、 "has"関係のエンティティ "Objects"の参加とカーディナリティは、カーディナリティが多数（m）のオプション（0）であると判断しました。その理由は、「オブジェクト」テーブルの外部キー「schedule_ID」がオプションの属性であるためです。つまり、「オブジェクト」は関係に必須の参加を持たないということです。さらに、ビジネスロジックでは、「オブジェクト」テーブルの各タプルは「スケジュール」テーブルの1つのタプルにしか対応できないと規定されています。

関係「has」の「schedule」エンティティの参加とカーディナリティを定義する（0、m）の場合、関係の親エンティティが参加することはほとんどなく、ほとんどの場合（特定のビジネスロジックで必要とされない限り）、部分パーティション（「0」で示される）。カーディナリティについては、「スケジュール」テーブルの各タプルを多くのオブジェクトに関連付けることができます。

さらに、これらのタイプのケース（既存のデータベースのERDの作成）で役立つ可能性があることを検討しながら、以下のメモをまとめました。-デフォルトでは、親と子の関係は（0、m）（0,1）です。 -トリガーを使用せずに親側に強制参加を強制することはできません。 -子エンティティに参加するために、外部キーフィールドにNOT NULL制約を設定します。 -代替キー（候補キー）を指定するには、UNIQUE制約を配置できます。

私は他の人にコメントと批評を提供することを勧めます。これが誰かを助けることを願っています！

0
William