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