Диаграмма ER - правильны ли отношения и мощности? - PullRequest
Новая
       20

Диаграмма ER - правильны ли отношения и мощности?

0 голосов
/ 06 февраля 2019

Я строю диаграмму на LucidChart для пивоваренного завода, который продает и производит пиво в 1 месте.Я посмотрел несколько видео о том, как разработать модель ER.Хотите знать, если это правильно или я сделал какие-либо ошибки.Кроме того, что именно означает «отображение», когда речь идет о моделях ER?

Вот моя модель ER: enter image description here

Также легенда кардинальности, из которой я вышел из LucidChart: enter image description here

1 Ответ

0 голосов
/ 12 апреля 2019

что именно означает «отображение», когда речь идет о моделях ER?

В контексте модели данных термин «отображение» является именемдля процесса преобразования модели данных в DDL SQL, который затем можно использовать для создания схемы базы данных в системе управления базами данных, такой как MySQL, SQL Server, Oracle и т. д.

В меру моих возможностейзнания, вы не можете "сопоставить" с такими инструментами, как Visio и LucidChart, потому что эти инструменты не предназначены для моделирования данных.Они предназначены для механизации процесса рисования диаграмм.(Правильная модель данных содержит намного больше, чем рисунки)

В качестве примера я использовал вашу диаграмму ER для разработки модели роли объекта с помощью бесплатного инструмента NORMA. На следующих диаграммах показано:

  1. Ролевая модель объекта

  2. Логическая модель (Создание логической модели из модели роли объекта заняло несколько миллисекунд.)

  3. DDL-код SQL, который я "сопоставил" из модели роли объекта (потребовалось несколько секунд, чтобы отобразить модель роли объекта в DDL-код SQL.)

Я использую SQL Server Management Studio, чтобы можно было скопировать и вставить версию DDL T-SQL в окно «Новый запрос» и создать таблицы базы данных за несколько секунд.

Это объект-ролевая модель (разбито на страницы) Brewery object-role model

Это логическая модель (автоматически генерируется). Обратите внимание, что в отличие от вашей модели в логической модели есть только одна таблица «Адрес».Brewery logical model

Это SQL DDL для MySQL Server (создается автоматически) 

CREATE TABLE Brewery
(
    breweryNr INT NOT NULL,
    addressNr INT NOT NULL,
    breweryName CHAR(63) NOT NULL,
    CONSTRAINT Brewery_PK PRIMARY KEY(breweryNr)
);

CREATE TABLE Address
(
    addressNr INT NOT NULL,
    country CHAR(63) NOT NULL,
    street CHAR(63) NOT NULL,
    town CHAR(63) NOT NULL,
    zipCode CHAR(63) NOT NULL,
    CONSTRAINT Address_PK PRIMARY KEY(addressNr)
);

CREATE TABLE Beer
(
    beerType CHAR(63) NOT NULL,
    alcoholPercent INT NOT NULL,
    beerAmountLitres CHAR(63) NOT NULL,
    beerID CHAR(63) NOT NULL,
    beerPrice CHAR(63) NOT NULL,
    kegNr INT NOT NULL,
    CONSTRAINT Beer_PK PRIMARY KEY(beerType)
);

CREATE TABLE BreweryMakesBeer
(
    beerType CHAR(63) NOT NULL,
    breweryNr INT NOT NULL,
    CONSTRAINT BreweryMakesBeer_PK PRIMARY KEY(breweryNr, beerType)
);

CREATE TABLE Keg
(
    kegNr INT NOT NULL,
    kegState CHAR(63) NOT NULL,
    CONSTRAINT Keg_PK PRIMARY KEY(kegNr)
);

CREATE TABLE Employee
(
    employeeNr INT NOT NULL,
    addressNr INT NOT NULL,
    birthDate INT NOT NULL,
    breweryNr INT NOT NULL,
    firstName CHAR(63) NOT NULL,
    lastName CHAR(63) NOT NULL,
    salary DECIMAL(6,4) NOT NULL,
    SSN CHAR(63) NOT NULL,
    middleInt CHAR(63),
    CONSTRAINT Employee_PK PRIMARY KEY(employeeNr)
);

CREATE TABLE Distributor
(
    distributorNr INT NOT NULL,
    brewingIngredientNr INT NOT NULL,
    CONSTRAINT Distributor_PK PRIMARY KEY(distributorNr)
);

CREATE TABLE BrewingIngredient
(
    brewingIngredientNr INT NOT NULL,
    ingredientName CHAR(63) NOT NULL,
    CONSTRAINT BrewingIngredient_PK PRIMARY KEY(brewingIngredientNr)
);

CREATE TABLE IngredientSupplier
(
    ingredientSupplierNr INT NOT NULL,
    addressNr INT NOT NULL,
    CONSTRAINT IngredientSupplier_PK PRIMARY KEY(ingredientSupplierNr)
);

CREATE TABLE IngredientSupply
(
    brewingIngredientNr INT NOT NULL,
    ingredientSupplierNr INT NOT NULL,
    CONSTRAINT IngredientSupply_PK PRIMARY KEY(brewingIngredientNr, ingredientSupplierNr)
);

ALTER TABLE Brewery ADD CONSTRAINT Brewery_FK FOREIGN KEY (addressNr) REFERENCES Address (addressNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE Beer ADD CONSTRAINT Beer_FK FOREIGN KEY (kegNr) REFERENCES Keg (kegNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE BreweryMakesBeer ADD CONSTRAINT BreweryMakesBeer_FK1 FOREIGN KEY (breweryNr) REFERENCES Brewery (breweryNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE BreweryMakesBeer ADD CONSTRAINT BreweryMakesBeer_FK2 FOREIGN KEY (beerType) REFERENCES Beer (beerType) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE Employee ADD CONSTRAINT Employee_FK1 FOREIGN KEY (breweryNr) REFERENCES Brewery (breweryNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE Employee ADD CONSTRAINT Employee_FK2 FOREIGN KEY (addressNr) REFERENCES Address (addressNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE Distributor ADD CONSTRAINT Distributor_FK FOREIGN KEY (brewingIngredientNr) REFERENCES BrewingIngredient (brewingIngredientNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE IngredientSupplier ADD CONSTRAINT IngredientSupplier_FK FOREIGN KEY (addressNr) REFERENCES Address (addressNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE IngredientSupply ADD CONSTRAINT IngredientSupply_FK1 FOREIGN KEY (brewingIngredientNr) REFERENCES BrewingIngredient (brewingIngredientNr) ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE IngredientSupply ADD CONSTRAINT IngredientSupply_FK2 FOREIGN KEY (ingredientSupplierNr) REFERENCES IngredientSupplier (ingredientSupplierNr) ON DELETE RESTRICT ON UPDATE RESTRICT;
...