Проектирование базы данных
Проектирование БД является очень важным этапом, от которого зависят последующие этапы разработки СУБД. Время, затраченное разработчиком на проектирование БД, обычно окупается высокой скоростью реализации проекта.
Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, иметь всю необходимую информацию для удовлетворения предполагаемых запросов пользователя и определить потребности в обработке данных.
На основе такого описания на этапе проектирования базы данных осуществляется определение состава и структуры данных предметной области, которые должны находиться в базе данных и обеспечивать выполнение необходимых запросов и задач пользователя. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных.
Информационно-логическая модельотображает данные предметной области в виде совокупности информационных объектов и связей между ними. Эта модель представляет данные, подлежащие хранению в базе данных.
При разработке модели данных могут использоваться два подхода. В первом подходе сначала определяются основные задачи, для решения которых строится база, и выявляются потребности задач в данных. При втором подходе сразу устанавливаются типовые объекты предметной области. Наиболее рационально сочетание обоих подходов. Это связано с тем, что на начальном этапе, как правило, нет исчерпывающих сведений обо всех задачах. Использование такой технологии тем более оправдано, что гибкие средства создания реляционной базы данных в Access позволяют на любом этапе разработки внести изменения в базу данных и модифицировать ее структуру без ущерба для введенных ранее данных.
Основные этапы проектирования БД показаны на рисунке.
Информационный объект — это информационное описание некоторой сущности — реального объекта, процесса, явления или события. Информационный объект образуется совокупностью логически взаимосвязанных реквизитов, представляющих качественные и количественные характеристики некоторой сущности предметной области. Примерами информационных объектов могут быть — ТОВАР, ПОСТАВЩИК, ЗАКАЗЧИК, ПОСТАВКА, ОТГРУЗКА, СОТРУДНИК, ОТДЕЛ, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА и т.п.
Информационные объекты выделяются на основе описания предметной области путем определения функциональных зависимостей между реквизитами. Совокупность реквизитов информационного объекта должна отвечать требованиям нормализации. Каждому информационному объекту нужно присвоить уникальное имя, например, СТУДЕНТ, ПРЕДМЕТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА.
Информационный объект имеет множество реализаций — экземпляров. Например, каждый экземпляр объекта СТУДЕНТ представляет конкретного студента. Экземпляр образуется совокупностью конкретных значений реквизитов и должен однозначно определяться (идентифицироваться) значением ключа информационного объекта, который состоит из одного или нескольких ключевых реквизитов. Таким образом, реквизиты подразделяются наключевые и описательные. Последние являются функционально зависимыми от ключа.
Функциональная зависимость реквизитов имеет место в том случае, если одному значению ключа соответствует только одно значение описательного (зависимого) реквизита.
Замечание. При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества), поскольку устанавливается только функциональная зависимость, определяющая связи описательных и ключевых реквизитов, и на основе которой выявляется реквизитный состав каждого информационного объекта.
При графическом изображении модели данных каждый информационный объект представляется прямоугольником с обозначением его имени и идентификатора - ключа.
Реквизиты каждого информационного объекта должны отвечать требованиям нормализации:
- информационный объект должен содержать уникальный идентификатор (ключ). Ключ является простым, если он состоит из одного реквизита или составным, если из нескольких;
- все описательные реквизиты должны быть взаимонезависимы, т.е. между ними не может быть функциональных зависимостей;
- все реквизиты, входящие в составной ключ, должны быть также взаимонезависимы;
- каждый описательный реквизит должен функционально полно зависеть от ключа, т.е. каждому значению ключа соответствует только одно значение описательного реквизита;
- при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;
- каждый описательный реквизит не может зависеть от ключа транзитивно, т.е. через другой промежуточный реквизит.
Замечание. В случае транзитивной зависимости между реквизитами можно выполнить расщепление совокупности реквизитов с образованием двух информационных объектов вместо одного.
Выполнение требований нормализации обеспечивает построение реляционной базы данных без дублирования данных и возможность поддержки целостности при внесении изменений.