Преобразование диаграммы ER в реляционную модель

Question

Я знаю, как преобразовать сущность, отношение и т. Д. В реляционную модель, но мне интересно, что мы должны делать, когда дана целая диаграмма? Как мы его преобразуем? Создаем ли мы отдельную таблицу для каждой связи и для каждого набора объектов? Например, если заданы следующие ER диаграмму:

Мое решение это как следующее:

//this part includes the purchaser relationship and policies entity set 

CREATE TABLE Policies (
    policyid INTEGER, 
    cost REAL, 
    ssn CHAR(11) NOT NULL, 
    PRIMARY KEY (policyid). 
    FOREIGN KEY (ssn) REFERENCES Employees, 
    ON DELETE CASCADE) 


//this part includes the dependents weak entity set and beneficiary relationship 

CREATE TABLE Dependents (
    pname CHAR(20), 
    age INTEGER, 
    policyid INTEGER, 
    PRIMARY KEY (pname, policyid). 
    FOREIGN KEY (policyid) REFERENCES Policies, 
    ON DELETE CASCADE) 


//This part includes Employees entity set 

CREATE TABLE Employees(
    ssn Char(11), 
    name char (20), 
    lot INTEGER, 
    PRIMARY KEY (ssn)) 

Мои вопросы:

1)Is my conversion true? 
2)What are the steps for converting a complete diagram into relational model. 
Here are the steps that i follow, is it true? 
    -I first look whether there are any weak entities or key constraints. If there 
    are one of them, then i create a single table for this entity set and the related   
    relationship. (Dependents with beneficiary, and policies with purchaser in my case) 
    -I create a separate table for the entity sets, which do not have any participation 
    or key constraints. (Employees in my case) 
    -If there are relationships with no constraints, I create separate table for them. 
    -So, in conclusion, every relationship and entity set in the diagram are included 
    in a table. 

Если бы мой шаги не соответствуют действительности или есть что-то, чего я не вижу, можете ли вы написать шаги для преобразования? Кроме того, что мы будем делать, если есть только ограничение участия для отношений, но нет ограничения ключа? Мы снова создаем единую таблицу для связанного набора объектов и отношений?

Я ценю любую помощь, я новичок в базах данных и пытаюсь изучить это преобразование.

Спасибо

Answer 1

Привет @bigO Я думаю, что с уверенностью можно сказать, что ваше преобразование верно и те шаги, которые вы следовали правильно. Однако с точки зрения внедрения может быть место для улучшения. То, что вы реализовали, скорее логической модели, чем физической модели.

Общепринятой практикой является добавление идентификатора суррогатного экземпляра в физическую таблицу, это общее требование для большинства механизмов персистентности и, как указано в @Pieter Geerkens, повышает эффективность базы данных. Значение идентификатора экземпляра, например EmployeeId (INT), будет автоматически генерироваться базой данных при вставке. Это также поможет в проблеме, которую @Pieter Geerkens указал на SSN. Добавьте Идентификатор в качестве первого столбца всех ваших таблиц, я следую за соглашением tablename Id. Сделайте ваши текущие первичные ключи вторичными ключами (естественный ключ).

Добавление Идентификаторы затем делает необходимым для реализации таблицы пересечений DependentPolicy

DependentPolicyId, (PK) 
PolicyId, 
DependentId 

тогда Вам может понадобиться рассмотреть вопрос о том, что является естественным ключ зависимой таблицы.

Я замечаю, что у вас есть возраст как атрибут, вы должны подумать о том, является ли этот возраст на момент создания политики или фактическим возрастом зависимого, в каком случае вы должны использовать дату рождения.

Другие украшения, которые вы можете рассмотреть, это создание и изменение дат.

Я также одобряю использование единственного числа для таблицы, т.е. Employee not Employees.

Добро пожаловать в мир моделирования и дизайна данных.