III. Логическая модель базы данных
Цель этапа логического проектирования преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации базы данных. Для её достижения выполняются следующие процедуры.
Выбор модели данных.
В нашем случае выбирается реляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.
Определение набора таблиц исходя из ER-модели и их документирование. Для каждой сущности создается таблица. Осуществляется формирование структуры таблиц на основании определённых правил. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.
Для связей, выявленных на концептуальном этапе, применяются следующие правила:
Согласно правилу 4, так как связь “СОТРУДНИКИ – ИМЕЕТ - КАТЕГОРИЯ” имеет тип “один ко многим” и класс сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М.
Связь между указанными таблицами будет иметь вид:
Согласно правилу 6, так как связь “СОТРУДНИК-ВЫПОЛНЯЕТ-РАБОТА” имеет тип “многие ко многим”, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
Связь между указанными таблицами будет иметь вид:
Нормализация таблиц. На этом шаге проверяется корректность структуры таблиц, созданных на предыдущем шаге, посредством применения к ним процедуры нормализации. Эта процедура заключается в приведении каждой из таблиц, по крайней мере, к 3НФ. В результате нормализации получается очень гибкий проект базы данных, позволяющий легко вносить в неё нужные расширения.
Определение 1НФ
Таблица находится в 1НФ, если все её поля содержат только простые неделимые значения.
Определение 2НФ
Таблица находится во 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа.
Определение 3НФ
Таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей.
Реляционная модель предметной области АУДИТ после нормализации.
IV. Модель физической организации данных. Реализация баз данных в ms Access.
Цель этапа физического проектирования – описание конкретной реализации базы данных, размещаемой во внешней памяти компьютера. Это описание структуры хранения данных и эффективных методов доступа к данным базы. При логическом проектировании отвечают на вопрос – что надо сделать. А при физическом проектировании – как это сделать. Процедуры физического проектирования следующие.
Проектирование таблиц базы данных средствами выбранной СУБД.
Реализация бизнес-правил в среде выбранной СУБД.
Проектирование физической организации базы данных.
Физические модели для базы данных выглядят следующим образом:
Уже готовая схема данных БД “АУДИТ” имеет следующий вид:
