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

Логическое проектирование — это процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий [5, c.78].

Первым этапом логического проектирования.

• 1. Преобразование локальной концептуальной модели данных в локальную логическую модель. (Удаление связей М: Н, сложных связей, рекурсивных связей, связей с атрибутами, удаление множественных атрибутов.)
• 2. Определение набора отношений исходя из структуры локальной логической модели данных.
• 3. Проверка модели с помощью правил нормализации.
• 4. Проверка модели в отношении транзакций пользователей.
• 5. Создание диаграммы сущность-связь.
• 6. Определение требований поддержки целостности данных. (Обязательные данные, ограничения для доменов атрибутов, целостность сущностей (PK не может быть NULL), требования данного предприятия (бизнес-правила)).
• 7. Обсуждение разработанных локальных логических моделей данных с конечными пользователями.

Второй этап проектирования:

• 1. Слияние локальных моделей в единую глобальную модель данных (анализ имен сущностей и связей, PK).
• 2. Проверка глобальной логической модели данных (нормализация и транзакции).
• 3. Проверка возможностей расширения модели в будущем.
• 4. Создание окончательного варианта диаграммы сущность-связь
• 5. Обсуждение глобальной модели данных с пользователем.

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий — «сотрудник», «отдел», «проект», «зарплата». Примеры взаимосвязей между понятиями — «сотрудник числится ровно в одном отделе», «сотрудник может выполнять несколько проектов».

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

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

Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение [7, c.94].

Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных [1, c.78]. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт [2, c.45], общее назначение процесса нормализации заключается в следующем:

• — исключение некоторых типов избыточности;
• — устранение некоторых аномалий обновления;
• — разработка проекта базы данных, который является достаточно «качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
• — упрощение процедуры применения необходимых ограничений целостности.

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

При том, что идеи нормализации весьма полезны для проектирования баз данных, они отнюдь не являются универсальным или исчерпывающим средством повышения качества проекта БД. Это связано с тем, что существует слишком большое разнообразие возможных ошибок и недостатков в структуре БД, которые нормализацией не устраняются. Несмотря на эти рассуждения, теория нормализации является очень ценным достижением реляционной теории и практики, поскольку она даёт научно строгие и обоснованные критерии качества проекта БД и формальные методы для усовершенствования этого качества, которые предлагаются в других моделях данных. Более того, можно утверждать, что во всей сфере информационных технологий практически отсутствуют методы оценки и улучшения проектных решений, сопоставимые с теорией нормализации реляционных баз данных по уровню формальной строгости [3, c.34].

Существует последовательность нормализации данных.

Первая нормальная форма (1NF).

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов [7, c.89].

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

Данные для выбранной темы курсовой работы можно представлены в таблице 1.7.

Таблица 1.7 — «Данные в первой нормальной форме».

Вторая нормальная форма (2NF).

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

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

Таблица 1.8 — «Залы».

Таблица 1.9 — «Секторы зала».

Таблица 1.10 — «Спектакли».

Таблица 1.11 — «Билеты».

Таблица 1.12 — «Сотрудники».

Обратим внимание, что данные таблицы 1.9 можно привести к 3НФ, поэтому нормализируем данные путем устранения транзитивности Таблица 1.13 — «Секторы зала».

Таблица 1.14 — «Места».

Сущности находятся в третей нормальной форме, об этом говорит отсутствие транзитивных зависимостей.

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