Почему системы баз данных не поддерживают отношения 1: M и 1: 1 напрямую?

#database-design #relational-database #data-modeling

#проектирование базы данных #реляционная база данных #моделирование данных

Вопрос:

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

1: C (0 ИЛИ 1) и 1: MC (>= 1)

поддерживаются во всех базах данных отношений. Он не поддерживает оба

1: M и 1: 1

отношения напрямую. я не могу понять, почему это не поддерживается. Любая помощь была бы высоко оценена

Комментарии:

1. Пожалуйста, укажите ваш источник. Существует много различных подходов к проектированию. Реляционная база данных или ERM-проект представляет n-арную связь / relationship / association посредством отношения / таблицы с n атрибутами / столбцами. FKS (внешние ключи) и запросы объектов в отношениях ошибочно называются «отношениями» методами / инструментами / презентациями, которые не понимают реляционную модель или ERM. (Вы можете найти похожие путаницы в «физических» отношениях.)

Ответ №1:

Я полагаю, вы спрашиваете об обязательном участии в ссылочной целостности. В принципе, СУБД может поддерживать ограничения ссылочной целостности, которые являются обязательными «с обеих сторон» ограничения, и некоторые действительно допускают это.

Используя синтаксис Tutorial D.:

 CONSTRAINT non_empty_order (ORD{ordnum} = ORDITEM{ordnum});
  

Это ограничение целостности требует, чтобы каждый заказ имел по крайней мере одну строку в таблице ORDITEM и одну строку в таблице ORD. Таким образом, наличие любого заданного ordnum является обязательным для обеих таблиц.

В СУБД SQL эквивалентным ограничением целостности было бы:

 CREATE ASSERTION non_empty_order CHECK
(NOT EXISTS (SELECT ordnum FROM ORD EXCEPT SELECT ordnum FROM ORDITEM) AND
 NOT EXISTS (SELECT ordnum FROM ORDITEM EXCEPT SELECT ordnum FROM ORD));
  

К сожалению, большинство СУБД SQL не поддерживают утверждения. Даже если бы они это сделали, SQL имеет другое ограничение, которое мешает использовать такие ограничения. Большинство СУБД SQL обычно не позволяют обновлять несколько таблиц одновременно (функция, называемая множественным назначением), поэтому, когда несколько таблиц ограничены таким образом, их обычно нельзя обновить, не отключив ограничение на время обновления.

Из-за этих ограничений большинство разработчиков баз данных SQL будут придерживаться синтаксиса ограничения ВНЕШНЕГО ключа SQL для ссылочных ограничений. В SQL ограничение ВНЕШНЕГО КЛЮЧА не требует обязательного участия на стороне ссылки:

 ALTER TABLE ORDITEM ADD CONSTRAINT fk_order FOREIGN KEY (ordnum) REFERENCES ORD (ordnum);
  

Это ограничение требует, чтобы каждый ordnum в ORDITEM имел соответствующий порядок, но это не предотвратит создание пустого порядка (что означает ordnum в ORD, но не соответствующий ordnum в ORDITEM).

Поддержка ограничений целостности СУБД SQL не сильно улучшилась за последние 20 лет или около того. Его ограничения стали второй натурой многих разработчиков баз данных, у которых вошло в привычку не учитывать бизнес-правила, которые не вписываются в модель SQL. Более сложные правила, как правило, реализуются в приложениях, движках правил или процедурах базы данных, поэтому у поставщиков СУБД не было особых причин улучшать поддержку ссылочной целостности на уровне ядра.

Комментарии:

1. Некоторые системы SQL позволяют отложить проверку ограничений до времени фиксации. Это позволяет обойти некоторые ограничения.