19. проверка отношений на свойства соединения без потерь и сохранения функциональных зависимостей;
20. предотвращение потери данных путем миграции первичных ключей отношения и назначения внешних ключей;
21. проверка на отсутствие незамкнутых связей;
22. проверка на отсутствие одиночных отношений;
23. формулировка части исходных данных для решения задачи управления ссылочной целостностью;
24. документирование логической модели реляционной базы данных;
25. принятие решения о реализуемости построенной логической модели реляционной базы данных;
26. принятие решения о разработке физической модели реляционной базы данных.
Результатом проектирования логической модели базы данных является нормализованная схема отношений базы данных. Отмечу, что в ходе выполнения этапа создания логической модели базы данных могут быть созданы новые объекты базы данных, не предусмотренные в информационной модели предметной области, например, связывающая сущность при нормализации отношения со степенью связи "многие-ко-многим". Рисунок 2. - Логическая структура базы данных «Фирма-посредник»
На Рисунке 2. изображена логическая структура базы данных «Фирма-посредник», выполненная в ER-Wine. На ней отображены сущности, их атрибуты и связи между сущностями.
5. Выявление перечня ограничений целостности
Целостность базы данных - соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint).
Задача аналитика и проектировщика базы данных — более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.
Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает, по крайней мере, правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.
Обеспечение целостности БД - важнейшая задача при создании БД, поскольку обеспечение адекватности базы данных отображаемой предметной области является одним из основных требований, предъявляемых к БД.
Существует 3 вида ограничений целостности:
1. Целостность по сущностям;
2. Целостность по ссылкам;
3. Целостность, определяемая пользователем.
Объекту, или сущности реального мира, в БД соответствуют кортежи отношения. Любой кортеж должен быть отличим от любого другого кортежа по составным значениям заранее определенного множества атрибутов, т.е. любое отношение должно обладать первичным ключом.
Первичный ключ представляет собой один из примеров уникальных индексов и применяется для уникальной идентификации записей таблицы. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа. Первичный ключ обычно сокращенно обозначают как PK (primary key).
В реляционных базах данных практически всегда разные таблицы логически связаны друг с другом. Первичные ключи как раз используются для однозначной организации такой связи.
По способу задания первичных ключей различают логические (естественные) и суррогатные (искусственные).
Для логического задания первичного ключа нужно выбрать в базе данных то, что естественным образом определяет запись. Примером такого ключа является номер паспорта в базе данных о паспортных данных жителей.
Если подходящих примеров для естественного задания первичного ключа не находится, пользуются суррогатным ключом. Суррогатный ключ представляет собой дополнительное поле в базе данных, предназначенное для обеспечения записей первичным ключом.
В БД «Фирма-посредник» я использовала искусственные первичные ключи, так как такой способ их назначения более простой, понятный и не создающий путаницы.
Для сущности «Товар» первичным ключом стало поле «Код товара», «Поставщики» - «Код поставщика», «Клиенты» - «Код клиента», «Продажа» - «Код продажи», «Поставка» - «Код поставки», «Менеджер поставки» - «Код менеджера поставки», «Менеджеры продажи» - «Код менеджера продажи».
Требование целостности по сущности означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенного значения Null.
Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение - это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неизвестных или неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.
Второй вариант состоит в использовании null-значений вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения null-значений, например, непонятно вообще, входят ли null-значения в домены или нет. Практически все реализации современных реляционных СУБД позволяют использовать null-значения, несмотря на их недостаточную теоретическую обоснованность.
Различные объекты предметной области, информация о которых хранится в БД, всегда взаимосвязаны друг с другом. Такие связи отражаются при помощи внешних ключей, связывающих несколько отношений.
Внешним ключом называется поле таблицы, предназначенное для хранения значения первичного ключа другой таблицы с целью организации связи между этими таблицами.
Подмножество атрибутов отношения называется внешним ключом, если:
1. Существует отношение с потенциальным ключом;
2. Каждое значение в отношении всегда совпадает со значением для некоторого кортежа либо является null-значением.
Замечание 1. Внешний ключ, также как и потенциальный, может быть простым и составным.
Замечание 2. Внешний ключ должен быть определен на тех же доменах, что и соответствующий первичный ключ родительского отношения.
Замечание 3. Внешний ключ, как правило, не обладает свойством уникальности. Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".
Замечание 4. Если внешний ключ все-таки обладает свойством уникальности, то связь между отношениями имеет тип "один-к-одному". Чаще всего такие отношения объединяются в одно отношение, хотя это и не обязательно.
Замечание 5. Хотя каждое значение внешнего ключа обязано совпадать со значениями потенциального ключа в некотором кортеже родительского отношения, то обратное, вообще говоря, неверно. Например, могут существовать поставщики, не поставляющие никаких товаров.
Замечание 6. Для внешнего ключа не требуется, чтобы он был компонентом некоторого потенциального ключа
Замечание 7. Null-значения для атрибутов внешнего ключа допустимы только в том случае, когда атрибуты внешнего ключа не входят в состав никакого потенциального ключа.
Т.к. внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.
Это определяет правило целостности внешних ключей - внешние ключи не должны быть несогласованными, т.е. для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.
В Access многие ограничения целостности могут задаваться самим пользователем при создании таблицы.
Тип поля. Он определяет допустимые символы, которые могут быть использованы при его заполнении (в частности, не допускается ввод текста в числовые поля).
Для некоторых типов полей, например, поля типа «дата», осуществляется и более сложная проверка. Если допущена ошибка в типе данных или неправильно введена дата, то пользователь должен обязательно исправить ошибку, так как СУБД не дает других возможностей продолжить работу.
Ряд свойств полей также позволяет обеспечивать контроль целостности: