|
alvkЁжик`Если нет реального контракта, то виртуальный (в таблице) должен быть.
+100
Опоздал я маленько, тоже хотел предложить виртуального, ибо пустые записи - это большое зло. Кстати виртуальный может вообще один быть, скажем "anonimus".
-100
Studieren, не верь никому.
Утверждение о вредности Null восходит к Дейту.
Он единственный, кто пытается под это подложить хоть какую-то логику.
Однако, следует иметь в виду, что в своих рассуждениях Дейт располагается в рамках
реляционной модели данных, в которой отсутствует прямая операция вида Outer Join.
Outer Join у реляционистов – операция производная, выводимая не вполне тривиальным образом, поэтому outer join – это последнее, о чем думает реляционист.
Отступление:
Спроси любого, изучавшего математику – что такое ноль и зачем он нужен.
Единственный вменяемый ответ, который ты получишь, будет таким – ноль эта такая хреновина, которая нужна для того, чтобы математика сходилась. Ну, чтобы операция вычитания, например, оказалась определена на всем множестве целых чисел.
А в ответ на вопрос, сколько нужно числовых нулей математике, (ведь в ней много разных числовых множеств с несовпадающими свойствами), ты получишь такой ответ – пока одним обходимся.
Возврат:
Посмотри на ситуацию с этой стороны. SQL обходится одним единственным нулем для обозначения пропущенных по любой причине значений. Пропуск значения универсально обозначает не только неполноту данных, но и незавершенность процесса, например.
Радетелям за реляционную чистоту и продвигателям реляционных идей в массы приходится а) заводить столько несовпадающих нулей, сколько типов данных они используют в своих системах и б) кроме нулевых значений вводить еще нулевые сущности (см. два предыдущих поста), там, где речь идет о пропущенных или отсутствующих связях в ситуации 0-n:0-m – и приговаривать, что это очень хорошо.
Ближе к телу:
Для принятия решения о том, как поступить, ты должен 1) дать себе отчет, какую роль играет тот илиной реквизит в заявке – роль собственного реквизита заявки или роль атрибута, связывающего заявку с другими сущностями, и 2) посмотреть на ситуацию с точки зрения того, что дожно измениться в схеме либо при изменении бизнес-правил.
(например, ты хотел бы применять свои наработки в похожих, но не полностью совпадающих ситуациях).
1) Принципиальный момент здесь вот в чем. Атрибуты, выполняющие только роль связующих между сущностями, с точки зрения реляционной чистоты модели, должны быть выделены в собственные сущности, т.к. связи между сущностями в реляционной модели представляются самостоятельными сущностями ( таблицами, в терминологии sql).
Сейчас описанная тобой ситуация выглядит так. роль клиента в заявке – двойная.
[клиент] в Заявке не просто связывает Клиента и Заявку в отношении 1:0-n, но представляет собой неотемлемый собственный атрибут Заявки пропуск которого недопустим, т.к. без него идетификация Заявки недостаточна, чтобы быть размещенной в таблицу в виде строки.
Попутный вопрос о нулях для размышления.
Пусть мы ошибочно решили, что связь между Клиентом и заякой 1:N, а не 1:0-N и сейчас находимся на этапе заведения нового клиента. Должны ли мы при добавлении
нового клиента завести на него одновременно и фиктивную заявку, которую он еще не подавал. Ответ – должны. Нулей (фиктивных заявок), чтобы наша математика 1:N сходилась, здесь будет столько, сколько клиентов заведено в базе (хихикать разрешается).
Роль же атрибута [контракт] – только связующая. [контракт] не является собственным атрибутом заявки, выражает связь между Контрактами и Заявками и поэтому с самого начала должен быть размещен в соственную таблицу, представляющую связь между Контрактами и Заявками.
А) Однако, т.к. согласно анализу предмета, связь со стороны Контракта 1, а со стороны Заявки 0-n, принимается решение денормализовать базу и разместить атрибут [контракт] прямо в сущности Заявка, допустив, естественным образом, наличие null-значений для этого атрибута.
Б) Альтернативой могло бы быть создание сущности Связь_Заявка_Контракт, с миграцией первичного ключа Заявки в эту сущность в качестве первичного ключа вновь образованной сущности. Таким образом, отношение между Заявкой и Связь_Заявка_Контракт оказалось бы 1:0-1, что позволило бы поддержать отношение 1:0-n между Заявкой и Контрактом с помошью Связь_Заявка_Контракт.
2) Допустим, вы хотите понять, что нужно изменить в получившихся двух вариантах реализации для ситуации, когда связь между Заявкой и Контрактом превращается из 1:0-N в N:0-M. В варианте А) необходимо произвести следующие действия
- создать таблицу Связь_Заявка_Контракт, заявив в ней оба поля [заявка] и [контракт] как not null и декларировав соотетствующие ФК.
- импортировать в нее из Заявка данные по накопленным связям.
- удалить атрибут [контракт] из Заявки.
В варианте Б) таблица связи уже есть, нужно
- дополнить первичный ключь Связь_Заявка_Контракт до возможности поддержки N:0-M, например, мигрировав в него атрибут [контракт]. Других действий не требуется.
Обращаю ваше внимание, что развитие системы в обоих сценариях идет без создания искусственных нулей не только на типах данных, но, и, тем более, без заведения искусственных нулевых экземпляров сущностей.
Outer Join прекрасно дышит в обоих случаях.
|
