Проектирование базы данных в третьей нормальной форме — КиберПедия 

Таксономические единицы (категории) растений: Каждая система классификации состоит из определённых соподчиненных друг другу...

Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций...

Проектирование базы данных в третьей нормальной форме

2017-09-10 79
Проектирование базы данных в третьей нормальной форме 0.00 из 5.00 0 оценок
Заказать работу

Нормализованная база данных обладает следующими важными свойствами:

· данные в таблицах соответствуют своим доменам;

· неключевые поля зависят от полного составного ключа (так объединение в одной таблице полей № студента, Код дисциплины, Название дисциплины, Оценка ошибочно, так как первичным ключом таблицы является ключ из № студента и Кода дисциплины, но Название дисциплины полностью определяется Кодом дисциплины и №студента для этого не нужен, а Оценка определяется только составным ключом);

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

Рассмотрим процедуру нормализации на примере задания №1.

Дан список атрибутов: Код факультета, Наименование факультета, Код специальности, Наименование специальности, № группы, Код студента, ФИО студента, Наименование дисциплины, Оценка.

Распределим атрибуты по таблицам по следующему правилу: все неключевые поля таблицы функционально зависят от первичного ключа таблицы.

Результат (в виде отношений реляционной модели):

· ФАКУЛЬТЕТ (Код факультета, Наименование факультета), т.к. каждому коду факультета соответствует одно наименование;

· СПЕЦИАЛЬНОСТЬ (Код специальности, Наименование специальности, Код факультета), т.к. каждому коду специальности соответствует одно наименование специальности и каждая специальность строго на одном факультете;

· ГРУППА ( № группы, Код специальности), т.к. предполагается, что все студенты одной группы учатся на одной и той же специальности;

· СТУДЕНТ (Код студента, ФИО студента, № группы) при условии, что данный студент всегда учится в одной группе, и в БД не предполагается хранить историю перехода студента из группы в группу;

· УСПЕВАЕМОСТЬ (Код студента, Наименование дисциплины, Оценка) при условии, что в БД фиксируется строго одна оценка студента по каждой дисциплине.

Если в БД необходимо хранить все оценки по дисциплине, получаемые студентом в процессе обучения, то к исходному списку атрибутов необходимо добавить атрибут Дата.

Если наименование дисциплины не гарантирует уникальности (например, физика на одной специальности и физика на другой специальности преподаются по разным учебным планам), то необходимо создать справочник дисциплин, добавив атрибут Код дисциплины. В результате структура БД измениться следующим образом:

· добавится отношение ДИСЦИПЛИНА (Код дисциплины, Наименование дисциплины);

· изменится отношение УСПЕВАЕМОСТЬ (Код студента, Код дисциплины, Дата, Оценка).

Создание таблиц БД

При создании таблиц необходимо обеспечить поддержку целостности БД.

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

· тип данных и ограничения, накладываемые на данные, например, в виде диапазона и/или маски ввода (см. справку);

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

Выбор вида ограничений и способа их задания определяется особенностями предметной области базы данных и решаемых прикладных задач.

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

Целостность по сущностям обеспечивается заданием первичного ключа или заданием уникального индекса (повторение значений не допускается). Ключ или индекс может быть задан на одном или нескольких атрибутах.

СУБД предоставляет альтернативные сценарии выполнения одной и той же работы.

Возможный алгоритм создания таблицы базы данных:

1. Выбрать объект базы данных Таблицы.

2. Одним из возможных способов (см. справку) включить режим конструктора.

3. Последовательно описать поля таблицы:

    • указать имя поля;
    • при необходимости задать подпись;
    • выбрать тип поля;
    • задать свойства поля с учётом необходимости обеспечения целостности базы данных;
    • задать первичный ключ;
    • задать индексы.

4. Сохранить таблицу.

5. Перейти в режим таблицы и заполнить таблицу данными.

Создание схемы данных

Схема данных используется для определения правил поддержки ссылочной целостности и предназначена для отображения связей между правилами и таблицами в удобной для восприятия форме. Схема не является обязательной частью реляционной БД и служит для поддержки администрирования БД.

Поддержка правил ссылочной целостности предполагает, что при выполнении запросов на поиск и извлечение данных, хранящихся в разных таблицах, но связанных между собой с учётом семантики предметной области (например, данные относящиеся к одному студенту), всегда будет выдаваться правильный результат.

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

Наиболее часто используемыми правилами поддержки ссылочной целостности являются:

· ограничения на выполнение операций Insert, Delete, Update при наличии связанных записей (совпадает значение полей) в таблицах базы данных (вариант Restrict, обычно задаётся по умолчанию);

· разрешение на выполнение каскадных (одновременных) операций Insert, Delete, Update для связанных записей (вариант Cascade).

При выборе ограничений необходимо руководствоваться следующими рекомендациями:

· вариант Restrict в большинстве случаев обеспечивает наиболее высокий уровень защиты данных в базе данных (недостатки этого способа, связанные с жёстким сценарием редактирования данных, легко снимаются путём управления проверкой ограничений из клиентских приложений);

· вариант Cascade используется тогда, когда в разных таблицах хранятся данные, имеющие смысл только как единое целое, например в нескольких таблицах хранятся фрагменты одного и того же документа (редактирование таких данных должно выполняться одновременно).

Возможный сценарий создания схемы данных:

1) перейти на вкладку Работа с базами данных и приступить к созданию схемы данных путём связывания таблиц по первичным и внешним ключам (см. справку);

2) для каждой связи задать правила поддержки ссылочной целостности (см. справку);

3) Заполнить таблицы данными с учётом требований целостности.


Поделиться с друзьями:

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

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

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...

Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.014 с.