Схема базы данных
Отношения «один ко многим» реализуются с помощью внешних ключей — ссылок на первичный ключ (атрибут, однозначно идентифицирующий строку таблицы). Отношения «один к одному» в базе данных отсутствуют — они равносильны объединению двух отношений в одно. На этом этапе вводятся дополнительные связующие таблицы. Необходимость введения такой таблицы зависит от степени отношения между сущностями… Читать ещё >
Схема базы данных (реферат, курсовая, диплом, контрольная)
Приведённая в предыдущем разделе ER-диаграмма преобразуется в схему базы данных. На этом этапе выделенным при моделировании предметной области сущностям ставится в соответствие структура, состоящая из таблиц реляционной базы данных. В отличие от ER диаграммы здесь явно обозначены ключи, о которым осуществляется связь между таблицами. Приведённая схема не является окончательной, так как некоторые отношения (таблицы) могут изменены — объединены или разделены — на этапе нормализации отношений с целью обеспечения логической целостности хранения данных, которая позволит избежать появления большинства аномалий и ошибок при работе с базой данных.
Схема базы данных является формальным описанием её структуры, определяющим таблицы, их поля и связи между ними.
Рис. 2 Схема базы данных.
На этом этапе вводятся дополнительные связующие таблицы. Необходимость введения такой таблицы зависит от степени отношения между сущностями, а именно в случае отношения «многие ко многим».
Отношения «один ко многим» реализуются с помощью внешних ключей — ссылок на первичный ключ (атрибут, однозначно идентифицирующий строку таблицы). Отношения «один к одному» в базе данных отсутствуют — они равносильны объединению двух отношений в одно.
Примером реализации такой связи может служить таблица «заказанные детали». Эта таблица с помощью внешних ключей ссылается на две другие — Деталь и Заказ, используя их уникальные идентификаторы — модель детали и номер заказа. Дополнительные связующие таблицы помимо ключей могут содержать дополнительную информацию. В случае таблицы «заказанные детали» такой дополнительной информацией будет количество деталей.
Так как таблицы для разных уровней элементов оборудования разделены, необходимо также ввести связующие таблицы, с помощью которых можно определить, к какому компоненту относится чертёж или фотография. В дальнейшем для упрощения доступа к чертежам определённого типа целесообразно будет создать представление (хранимый запрос), опирающееся на это сочетание.
Один чертёж или атрибут может принадлежать только одной сущности (узел, деталь, оборудование), но в нашем случае связь этих отношений реализуется с помощью связующих таблиц, а не внешнего ключа, так как сущности компонентов и оборудования идентифицируются по отдельности, следовательно множества числовых идентификаторов могут пересекаться.
Для обеспечения нормальной логики работы СУБД те связи, которые на ER-диаграмме (рис.1) были обозначены как обязательные в обе стороны, заменены на обязательные по отношению только к одной из связанных таблиц. Это нужно для того чтобы убрать логическое противоречие. В качестве примера можно рассмотреть связь между сущностями «Оборудование» и «Тип оборудования». Если связь обязательна по отношению к обеим таблицам, невозможно было бы создать оборудование без типа и тип без оборудования. Поэтому необходимо сделать возможным раздельное добавление элементов. В случае типа и оборудования сначала добавляется тип, а затем при создании нового оборудования используется ссылка на этот ранее созданный тип.