26.Правила преобразования er-диаграмм в реляционные таблицы в случае связи 1:1.

Концептуальные модели позволяют более точно представить предметную область, чем реляционные и другие более ранние модели. Но в настоящее время существует немного систем управления базами данных, поддерживающих эти модели. На практике наиболее распространены системы, реализующие реляционную модель. Поэтому необходим метод перевода концептуальной модели в реляционную. Такой метод основывается на формировании набора предварительных таблиц из ER-диаграмм.

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности [3].

Правило 1

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

Правило 2

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

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

Правило 3

Если связь типа 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

27. Правила преобразования er-диаграммы в реляционные таблицы связи 1:м, м:n.

1)Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущ-ти должен б. первич. ключом соответ-щей таблицы. Перв. Ключ сущ-ти на стороне 1 добавляется как атрибут в таблицу для сущ-ти на стороне М. Пример: ER-диаграмма связи 1:М класс принадлежности сущ-ти ЗАКАЗ яв-ся обяз-ным.

2 )Если связь типа 1:М и класс прин-сти сущ-ти на стороне М является необязательным, то необходимо построить три таблицы: по одной для каждой сущности и 1 для связи. Перв. ключ сущ-ти д.б. первич. ключом соответ-щей таблицы. Таблица для связи д. иметь среди своих атрибутов ключи обеих сущ-тей. Пример: класс принадлежности сущ-ти ЗАКАЗ яв-ся необяз-ным.

3 ) Если связь типа М:N, то необ-мо построить 3 таблицы – по одной для каждой сущности и 1 для связи. Перв.ключ сущ-ти д.б. перв. ключом соотв-щей таблицы. Таблица для связи среди своих атрибутов д. иметь ключи обеих сущн-тей.

31.Физическое проектирование, его цель и процедуры.

Физическое проектирование — создание схемы БД для конкретной СУБД.

Цель этапа физ. Проектир-я – описание конкр. реализации БД, размещаемой во внешн. памяти комп-ра. Это опис-е стр-ры хранения дан. и эффективных методов доступа к дан. базы. При логич-ом проектир-ии отвечают на вопр. что надо сделать, а при физ. – выбир-ся сп-б как это сделать.

Процедуры:

1)проектир-е таблиц БД средствами выбр-ой СУБД

2)реализация бизнес-правил в среде выбранной СУБД

3)проектир-е физ. орг-ции БД

4)разраб-ка стратегии защиты БД

5)орг-ция мониторинга функционир-я БД и её настройка.