Преобразование объектных множеств и атрибутов

Лекция. Преобразование концептуальной модели в реляционную

Содержание лекции: принципы преобразованиz концептуальной модели в реляционную модель данных.

Цель лекции: изучить методы преобразования элементов концептуальной модели в реляционные таблицы.

Огромное большинство СУБД основано на реляционной модели. Объектно-ориентированные СУБД, которые могли бы напрямую реализовать концептуальную схему, еще не лостигли «промышленной мощности», необходимой для больших приложений, и, следовательно, не могут использоваться. Необходим некоторый метод перевода концептуальных моделей в те модели, которые могут быть реализованы. Рассмотрим методы преобразования концептуальной модели в реляционную.

Концептуальная модель состоит из объектов, отношений, атрибутов, конкретизация, составных объектв и т.д. Рассмотрим методы преобразования каждой из этих конструкций в реляционные таблицы.

1. Для каждого объектного множества модели создается реляционная таблица. Чаще всего имена объектных множеств и таблиц совпадают. Но они могут быть и различными, потому что на имена объектных множеств могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. Имена же таблиц могут быть ограничены требованиями конкретной СУБД. Чаще всего эти имена являются идентификаторами в некотором базовом языке, они ограничены по длине и не должны содержать пробелов и некоторых специальных символов. Например, объектное множество может быть названо СОТРУДНИКИ (рисунок 11.1), а соответствующую ей таблицу желательно назвать, например, EMPLOYEE (без пробелов и латинскими буквами).

Рисунок 11.1 - Преобразование объектного множества СОТРУДНИКИ в таблицу EMPLOYEE

Атрибуты объектного множества становятся атрибутами реляционной таблицы. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование объектных множеств. Для каждого атрибута задается конкретный допустимый в СУБД тип данных (рисунок 11.2) и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).

Рисунок 11.2 -Свойства атрибутов отношения EMPLOYEE

2. Если в концептуальной модели существует ключевой атрибут, то он может использоваться в качестве ключа реляционной таблицы (PRIMARY KEY). В противном случае ключевой атрибут таблицы может быть создан проектировщиком базы данных. Все-таки лучше, если такой атрибут естественным образом возникает из модели. На практике, конечно, проектировщики должны советоваться с пользователями по поводу выбора ключа. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

3. Если в концептуальной модели есть конкретизации объектного множества, то есть подобъекты и обобщающие объекты, то возможны несколько вариантов представления. Возможно создать только одно отношение для всех подобъектов одного обобщающего объекта. В него включают все атрибуты всех подобъектов. Однако тогда для ряда экземпляров ряд атрибутов не будет иметь смысла. И даже если они будут иметь неопределенные значения, то потребуются дополнительные правила различения одних подобъектов от других. Достоинством такого представления является то, что создается всего одно отношение. При втором способе для каждого подобъекта и для обобщающего объекта создаются свои отдельные отношения. Недостатком такого способа представления является то, что создается много отношений, однако достоинств у такого способа больше, так как можно работать только со значимыми атрибутами подобъекта.

Обычно конкретизация объектного множества будет иметь все атрибуты объектного множества, которое оно конкретизирует. Тогда конкретизация и обобщающее множество содержат повторяющуюся информацию. Чтобы избежать такой избыточности данных, из реляционной таблицы конкретизации удаляются все повторяющиеся не ключевые атрибуты; ключи же совпадают с ключами обобщающих объектных множеств.

Дата добавления: 2014-01-04