Логическая и физическая модели данных

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

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

В реляционных моделях данных объекты и взаимосвязи между ними представляются с помощью таблиц. Каждая таблица представляет один объект и состоит из строк и столбцов. Таблица в реляционной модели называется отношением.

Атрибут (поле) – любой столбец в таблице.

Домен – множество значений, которые может принимать атрибут.

Кортежи (записи) – строки таблицы.

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

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

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

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

В Access возможно создание двух типов связей:

- отношение один-к-одному (1:1);

- отношение один-ко-многим (1:M).

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

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

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

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

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

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

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

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

Исключить дублирование информации в таблицах.

Обеспечить возможность изменений в структуре таблиц.

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

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

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

Первая нормальная форма

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

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

Вторая нормальная форма

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

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

Третья нормальная форма

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

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

Четвёртая нормальна форма

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

Пятая нормальная форма и комбинированные элементы

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

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

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

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

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

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

Рисунок 3.2.1 Логическая модель данных

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

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

Файлом базы данных в теории баз данных называется таблица реляционной модели.

Физические модели для базы данных Интернет - кафе представлены на рисунках 3.2.2-3.2.7.

Рисунок 3.2.2 Конструктор таблицы Администраторы

Рисунок 3.2.3 Конструктор таблицы Залы

Рисунок 3.2.4 Конструктор таблицы Компьютеры

Рисунок 3.2.5 Конструктор таблицы Посетители

Рисунок 3.2.6 Конструктор таблицы Посещения

Рисунок 3.2.7 Конструктор таблицы Услуги