Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Шпоры КИТ1.doc
Скачиваний:
0
Добавлен:
01.03.2025
Размер:
307.2 Кб
Скачать

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

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

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

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

28.Нормализация таблиц, ее цель. Первая нормальн форма. Вторая нормальн форма. Третья нормальн форма

Недостатки нормализации таблиц: а)избыточность данных, б)исп-е Null значений, в)возможность потери инф-ции. Нормализация- процесс преобразования реляционн базы данных в соответствии с требованиями нормальн форм.

Первая нормальн форма: таблица нах-ся в 1НФ, если все ее поля содержат только простые, неделимые значения.

Вторая нормальн форма: а)функциональн зависимость ( в отношении R атрибут Y функционально зависит от атрибута X тогда и только тогда, когда каждому значению X в любой момент времени соответствует ровно одно значение Y:R.X->R.Y), б)полная функциональная зависимость (функциональн зав-ть R.X->R.Y наз-ся полной, если атрибут R.Y не зависит функционально ни от какого подмножества R.X), в)неключевой атрибут (неключевым атрибутом наз-ся любой атрибут отношения, не входящий в состав первичного ключа), г)вторая нормальная форма (таблица соответствует 2НФ, если она удовлетворяет требованиям 1НФ и все ее неключевые поля функционально зависят от первичного ключа). Таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей.

29.Концептуальн проектирование, его цель и процедуры

Цель этапа концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур: а)определение сущностей и их документирование, б)Определение связей между сущностями и их документирование, в) Создание ER-модели предметной области, г)Определение атрибутов и их документирование, д)Определение значений атрибутов и их документирование, е)Определение первичных ключей для сущностей и их документирование, ж)Обсуждение концептуальной модели данных с конечными пользователями.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]