От UML к SQL (PostgreSQL)

Question

Я готовлюсь к предстоящему экзамену и только что закончил это (простое) упражнение.

Я просто хотел убедиться, что все правильно реализовал, особенно Композиция с кратностями 1 и 0 .. *

Мой ответ:

CREATE TABLE exam.A(
    idA integer,
    b text NOT NULL,
    c float DEFAULT -1.0 CONSTRAINT negative_c CHECK (c < 0.0),
    PRIMARY KEY(idA));

CREATE TABLE exam.B(
    idB integer,
    c integer,
    PRIMARY KEY(idB));

CREATE TABLE exam.RelationAandB(
    idA integer NOT NULL ON DELETE CASCADE,
    idB integer,
    b integer,
    c text,
    FOREIGN KEY (idA) REFERENCES exam.A(idA),
    FOREIGN KEY (idB) REFERENCES exam.B(idB),
    PRIMARY KEY (idA, idB));

Answer 1

Ваш код SQL довольно хороший, но я вижу следующие проблемы:

1. В диаграммах классов UML атрибуты являются обязательными по умолчанию.Они были бы необязательными, только если они квалифицированы выражением множественности [0..1].Следовательно, все атрибуты должны быть закодированы как столбцы NOT-NULL.Возможно, однако, ваш инструктор не знал об этом или использует нестандартное чтение для «моделей данных UML».
2. Строковый атрибут A :: b имеет «{не пустой}»модификатор свойства, который читается как ограничение, требующее непустые строки.Обратите внимание, что наличие непустого строкового значения не является обязательным (NOT NULL), поскольку пустая строка "" удовлетворяет ограничению NOT NULL.
3. Вам также необходимо правило CASCADE DELETE для idB в RelationAandBтаблицы, потому что независимо от того, удаляются ли A или B, связанные кортежи в RelationAandB также должны быть удалены.
4. Я думаю, что для удобства чтения предпочтительно добавить объявление PRIMARY KEY в столбецопределение, если ключ не является составным (имеет только один столбец).То же самое относится и к объявлениям FOREIGN KEY с одним столбцом.
5. Многие думают, что композиция подразумевает зависимость удаления, хотя это не гарантируется семантикой UML (см. Агрегация против композиции ),и это также не основано на здравом смысле (см. мои замечания ниже).В вашем коде SQL вы не реализовали такую ​​зависимость («всякий раз, когда A удаляется, все зависимые B также должны быть удалены»), что является правильным в соответствии с семантикой UML диаграммы классов, но, возможно,намерение вашего инструктора, тем более что он сделал обязательным, чтобы компонент B имел композит A (кратностью 1 на стороне композита).Такое обязательное обязательное составное ограничение подразумевает, что при удалении их составного элемента либо компоненты либо должны быть либо удалены, либо их необходимо переназначить другому (A) составному элементу.Если ваш инструктор предполагал, что должна быть зависимость удаления, вам лучше добавить соответствующее объявление внешнего ключа в exam.B от idB к RelationAandB с правилом CASCADE DELETE: idB integer FOREIGN KEY REFERENCES exam.RelationAandB CASCADE DELETE,

ОтносительноНа вопрос, подразумевает ли композиция зависимость жизненного цикла между композитом и его компонентами, мы должны различать три уровня абстракции: 1) чисто концептуальный (философский) уровень, который должен быть здравым смыслом разработчика моделей данных, 2)Семантика UML, которая часто точно не определена, и 3) уровень (например, SQL) кода.На концептуальном уровне должно быть ясно, что существуют композиции с такой зависимостью жизненного цикла и без нее, поэтому сам факт наличия композиции не подразумевает зависимость жизненного цикла.

К сожалению, UML не определил никаких способов объявления того, что композиция имеет экзистенциально зависимые компоненты.В моем ответе SO Агрегация против композиции я предложил использовать стереотип «неразделимый» для такой композиции.