Нарушение ссылочной целостности: что бы сказал Эдгар Кодд?

Question

Я пытаюсь понять правила реляционной модели, как они были определены Эдгаром Коддом в 1970 году.

В частности, меня интересует, является ли ссылочная целостность частью его реляционной модели или нет. Я попытаюсь продемонстрировать на следующем примере (просто, чтобы сделать этот вопрос довольно):

Пользователи

+------+------------
| Name | Address
|------+------------
| John | ....
| Mike | ....
| Kate | ....
+------+------------

1011 * Инвойсы *

+------+------------
|  ID  | Customer
|------+------------
|   1  | John
|   2  | John
|   3  | Mary
+------+------------

Теперь, очевидно, как вы можете видеть, у нас есть один счет, где покупатель (внешний ключ) имеет значение Мэри Будет ли это нарушать его реляционную модель? Эдгар Кодд посмотрит на это и скажет: ну и дела, какого черта? Или он сказал бы, что это прекрасно ...

Это теоретический вопрос.

Answer 1

Если в таблице «Клиенты» нет клиента с именем «Мария», то между таблицами нет ссылочной целостности. В частности, внешний ключ относится к несуществующему первичному ключу.

Это нарушает реляционную модель? Нет. Он определен в реляционной модели (т.е. отсутствие ссылочной целостности) и является признаком того, что существует проблема с базовыми данными.

Из "Реляционной модели данных для больших общих банков данных" Эдгара Кодда (из сообщений ACM, том 13, номер 6, июнь 1970 года):

Возможно, пользователь намеревался вставить элемент в P - элемент, вставка которого будет преобразовывать согласованное состояние в согласованное состояние. Дело в том, что система обычно не может решить этот вопрос без опрашивая его среду (возможно, пользователь, который создал несоответствие).

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

Answer 2

Чтобы язык считался реляционно полным (фраза, придуманная Коддом), он должен поддерживать набор реляционных операторов, известный как реляционная алгебра . Заметьте, что не существует единственной истинной реляционной алгебры: Кодд предложил первую, но другие с тех пор усовершенствовали и основали ее на кодде (например, Третий Манифест ), и я уверен, что он увидит это как правильное и правильное.

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

Answer 3

Реляционная модель не требует, чтобы функции ссылочной целостности применялись к каждой реляционной базе данных - это было бы абсурдно, если бы такие ограничения не были релевантными или нежелательными. Представьте себе список членов клуба, состоящий из имени, адреса и номера участника. Там не обязательно будет какое-либо применение для ограничений RI, но это все еще реляционная база данных, если данные хранятся в форме отношения.

Даже 13 правил Кодда не требуют, чтобы СУБД поддерживала возможность создавать ограничения RI. Просто внешние ключи настолько полезны, что ожидается, что большинство СУБД будут иметь их.

Answer 4

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

Два правила целостности применяются к каждому реляционная база данных:

1 Целостность объекта:
Нет отметки либо тип разрешен в любом атрибуте который является компонентом первичного ключ базового отношения

2 Ссылочная целостность:
Пусть D будет домен, из которого один или несколько отрисовка первичных ключей с одним атрибутом их ценности. Пусть K будет внешним ключом который берет свои значения из области D. Каждое немаркированное значение, которое встречается в К также должен существовать в базе данных как значение в первичном ключе некоторых базовое отношение.

" Отсутствующая информация (применима и неприменима) в реляционных базах данных ," E.F. Codd, ACM SIGMOD Record, vol. 15, нет 4, стр. 53-78, 1986.

Под «знаком любого типа» он ссылается на неизвестное значение, для которого мы сегодня используем NULL. В этой статье предлагаются два разных типа неизвестных значений: одно для «применимо, но отсутствует», а другое для «неприменимо».

Под «неотмеченным» он подразумевает не NULL.

---

Re comment from @dportas: Действительно, вам даже не нужно, чтобы ссылочное отношение было пустым, чтобы аргументировать. Он может содержать несколько строк, но поскольку нельзя сказать, что A-знак в K равен какому-либо значению, существующему в этом ссылочном отношении, нельзя сказать, что гипотетическое пропущенное значение удовлетворяет ограничению. Поэтому разрешение знака А должно стать актом веры, что после предоставления значения оно будет удовлетворять ограничению, поскольку в противном случае строка была бы недействительной с момента ее вставки, и нам пришлось бы поддерживать концепцию нарушение обратной силы, которое бессмысленно.

Answer 5

Сначала вы спросите, является ли RI частью RM:

является ли ссылочная целостность частью его реляционной модели или нет

Да. Из классики Кодда "Является ли ваша СУБД действительно реляционной?" Компьютерный мир, 14 октября 1985 года:

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

Правило 10: Ограничения целостности, характерные для конкретной базы реляционных данных, должны определяться в подъязыке реляционных данных и храниться в каталоге, а не в прикладных программах.

Но тогда вы перефразируете другой и неоднозначный вопрос:

у нас есть один счет, где клиентом (внешним ключом) является Мэри. Будет ли это нарушать его реляционную модель?

Если вы имеете в виду: разрешает ли RM объявленный FK нарушаться, т.е. не останавливаться СУБД?

Нет. Это будет СУБД, которая позволяет вам объявлять ограничение FK, но не применяет его. Такая СУБД в этом отношении нереляционная.

Если вы имеете в виду: разрешает ли RM бизнес-правило, которое гласит, что клиент по счетам должен также отображаться в имени клиента (т. Е. Все действительные состояния базы данных аналогичны таковым, то есть существует ограничение FK от клиента по счетам до имени клиента) быть не объявленным в СУБД (например, через объявление FK)?

Да. Но это плохой дизайн, потому что он допускает некоторые недопустимые состояния.

Answer 6

Я думаю, что это хорошо или нет, зависит от вашего дизайна.

Счет должен содержать данные такими, какими они были на момент создания или отправки счета. Таким образом, могут потребоваться данные, относящиеся к данным клиента, но не напрямую к внешнему ключу, особенно если вы используете естественный ключ.

Например, предположим, что Мэри Джонс заказала что-то и ей выставили счет 31 мая 2010 года. 12 сентября 2010 года она сменила имя на Мэри Джонс-Смит и переехала на адрес своего мужа. Счет, являющийся изображением во времени, должен содержать имя Мэри Джонс и оригинальный адрес, на который он был отправлен. Лучше всего сохранить ссылку на текущего клиента и его информацию (поэтому я должен иметь идентификатор клиента в таблице клиентов при изменении имен и таблицу счетов FK of Customerid). Но хранить Мэри Джонс, когда Мэри Джонс больше не существует в таблице клиентов, - это не только нормально, необходимо отслеживать, что на самом деле произошло.

То же самое с продуктами и ценами и счетами. Вы не хотели бы, чтобы счет отражал цену сейчас, но процесс во время счета, даже если это не имеет прямого отношения к тому, что там сейчас. В этом случае таблица Product может быть скорее справочной таблицей, чем истинным родительским дочерним отношением. Если вы храните все данные о продукте в таблице сведений о счете-фактуре, вам не нужен внешний ключ для продуктов, он нужен только для поиска активных продуктов во время размещения заказа. На самом деле, номер модели прошлой накладной может больше не быть в таблице продуктов, если поставщик изменил ее или полностью отбросил продукт. Но вы не хотели бы потерять данные о том, какие из этих продуктов были куплены в прошлом.

С другой стороны, если отношение требует, чтобы данные оставались согласованными с текущими значениями, формальный внешний ключ является лучшим методом.