Даталогическое проектирование

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

1. Определение таблиц

2. Определение полей таблиц

3. Определение типов данных в соответствии с выбранной СУБД

4. Определение длины каждого поля таблиц

5. Определение обязательности каждого поля

6. Определение индексации каждого поля

Особое внимание при построении модели уделяют целостности и отсутствию избыточности данных. Избыточность - это многократное повторение одних и тех же данных). Если в БД имеется несколько описаний одного и того же объекта, то все экземпляры этих описаний, кроме одного будут избыточными. При анализе схемы данных было выявлено отсутствие избыточности данных.

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

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

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

Каждый столбец содержит информацию одного типа.

Ячейки – поля – таблицы не содержат агрегатов (структур или массивов) данных.

Таблицы не содержат одинаковых строк.

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

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

На основании даталогического проектирования в Access были созданы 8 таблиц, которые описаны в таблицах 1-11.

Таблица 1 – Описание полей таблицы Отдел

Таблица 2 – Описание полей таблицы Сложный Ремонт

Таблица 3 – Описание полей таблицы Заявка

Таблица 4 – Описание полей таблицы Состав Ремонта

Таблица 5 – Описание полей таблицы Простой Ремонт

Таблица 6 – Описание полей таблицы Контрагенты

Таблица 7 – Описание полей таблицы Работники

Таблица 8 – Описание полей таблицы Ремонт Узла

Схема данных

Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

- первая нормальная форма (1NF);

- вторая нормальная форма (2NF);

- третья нормальная форма (3NF);

- нормальная форма Бойса - Кодда (BCNF);

- четвертая нормальная форма (4NF);

- пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Была проведена нормализация базы данных до 3 НФ.

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

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

Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Как видно из таблиц 1-8, каждый атрибут сущностей является элементарным и неделимым.

Отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа. Сущности проектируемой БД находятся в 1НФ и не содержат неполных зависимостей от не первичных атрибутов.

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.