5.6. Слабые наборы сущностей
Случается, что набору сущностей для уникальной идентификации конкретной сущности (объекта) требуется “помощь”. Горорят, что набор сущностей слабый (или подчиненный), если для уникальной идентификации объекта из этого набора требуется включить в него ключ другого, связанного с ним набора сущностей. Табельный номер сотрудника может в определенных условиях однозначно определить объект набора сущностей Сотрудники (а именно, если в этом наборе сущностей хранятся данные о сотрудниках только одного предприятия). Однако если мы в наборе сущностей Сотрудники захотим хранить данные о сотрудниках нескольких предприятий, то табельный номер перестает быть ключом. Но табельный номер вместе с именем предприятия, на котором работает сотрудник, уже образуют ключ.
Рисунок 9. Подчиненный набор сущностей Сотрудники.
5.7. Борьба с избыточнотью
При проектировании структур данных следует избегать ситуации, когда один факт выражается двумя разными способами. Будем называть это избыточностью. Избыточность может привести к несогласованности данных и к перерасходу пространства на диске.
Рисунок 10 Пример отсутсвия избыточности.
На рис.10 каждый поставщик присутствует лишь однажды – это приемлемое решение. На рис.11 поставщик упоминается дважды – как атрибут набора сущностей Товар и как связанная сущность из набора сущностей Поставщики. Это пример плохой структуры данных.
Рисунок 11. Пример избыточности (плохое решение).
На следующем рис.12 представлено еще одно неудачное решение: для каждого товара повторяется его поставщик и адрес поставщика. Кроме того, если товар еще не поставлялся, не удастся зафиксировать имя и адрес поставщика в такой базе данных.
Рисунок 12. Еще одно плохое решение.
Можно задаться вопросом: что лучше – создавать набор сущностей или создавать дополнительные атрибуты в исходном наборе сущностей? Ответ зависит от нескольких факторов. Во первых, набор сущностей должен представлять нечто большее, чем просто имя сущностей, т. е. иметь не только ключевые поля. Во вторых, набор сущностей должен играть роль стороны “многие” в связи типа “один ко многим” или “многие ко многим”. Достаточно выполнения одного из условий. Возвращаясь к рис. 8 можно сказать:
Поставщики стоит выделить в набор сущностей, т. к. каждая сущность имеет неключевой атрибут Адрес.
Товары стоит выделить в набор сущностей, потому что они находятся на стороне “многие” в отношении “один ко многим”. По этой причине их стоило бы выделить в отдельный набор сущностей, даже если бы не было неключевого атрибута НДС.
Предположим, что нас не интересуют подробности, связанные с поставщиком. Тогда на рис.13 представлено приемлемое решение – нет необходимости создавать отдельный набор сущностей Поставщик т. к. нам, по смыслу задачи, не надо хранить какую-либо характеристику поставщика, кроме его имени.
Рисунок 13 Пример приемлемого решения
В этих условиях решение, представленное на рис.14 может оказаться неприемлемым. Хотя однозначно этого утверждать нельзя – все решают требования и характер использования данных.
Рисунок 14 Пример неоднозначного решения
Говоря в общем, не стоит всегда создавать отдельные наборы сущностей. Зачастую можно обходиться без них. Не стоит злоупотреблять слабыми наборами сущностей. Зачастую можно использовать собственные (естественные) ключи – ИНН, государственный номер автомобиля, а можно и искусственный ключ (например, поле типа Счетчик в СУБД Microsoft Access).