Лекция 8

модели данных. 3) Методика преобразования концептуальных структур данных в реляционные структуры.

4) Преобразование связи типа «суперкласс/подкласс».
5) Преобразование составных объектов.

данных в логическую модель, в результате которого будет определена схема

реляционной модели данных;
проверка модели с помощью концепций последовательной нормализации;
проверка модели в отношении транзакций пользователей;
проверка поддержки целостности данных.

в результате которого будет определена схема реляционной модели данных, может

иметь два подхода.

ее предварительному преобразованию. В этом случае ему придется столкнуться с

необходимостью преобразования разнообразных структур данных

модели к логической модели, стремится вначале данный переход максимально упростить,

проведя предварительные преобразования концептуальной модели, преобразования некоторых ее, не подходящие для реляционных СУБД структур данных.

сложные связи;
рекурсивные связи;
связи с атрибутами;
множественные атрибуты;
избыточные

связи.

Если в модели присутствуют перечисленные нежелательные структуры, то они должны быть исключены путем тождественной их замены на структуры данных, допустимые для логической модели.

многим» осуществляется путем введения некоторого промежуточного объекта с заменой одной

связи двумя связями типа «один ко многим» с вновь созданным объектом. При организации новых связей необходимо следить за тем, чтобы максимальная мощность связи «один» была направлена к исходному объекту, а максимальная мощность связи «много» — к вновь созданному объекту.

1: N между объектами КУРС и ЧТЕНИЕ.

ПрО в отношения реляционной базы данных состоит в следующем:
построить

набор предварительных отношений и указать первичные ключи для каждого отношения;

которые не были перечислены в диаграмме в качестве первичных ключей

объектов) и назначить каждый из этих атрибутов одному из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК. Если полученные отношения в итоге не находятся в НФБК, то в этих случаях диаграммы необходимо пересмотреть.

связи типа «суперкласс/подкласс» объект суперкласса необходимо определить как родительский, а

объект подкласса — как дочерний.
Если суперкласс с его подклассами имеет непересекающиеся связи, где каждый экземпляр суперкласса обязательно должен быть членом одного подкласса, то решением является представление каждого из подклассов в виде отдельного отношения, содержащего копию первичного ключа суперкласса.

ФИО, Адрес, Педагог_стаж);
ПРОФЕССОР (Табельный номер, Номер_диплома_профессора);
ДОЦЕНТ (Табельный номер, Номер_диплома_доцента);
СТАРШИЙ_ПРЕПОДАВАТЕЛЬ (Табельный

номер);
АССИСТЕНТ (Табельный номер).

(Индекс_Нир, Название, Руководитель);
ПО (Таб_номер, Код_вида, Индекс_Нир, Час_оплата, Кол_часов).