Этапы проектирования базы данных

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

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

При разработке эскиза необходимо ответить на следующие вопросы:

Какими данными мы располагаем?

Какие данные будут содержать таблицы?

Какой тип и какие свойства должны иметь данные в каждом поле таблицы?

Как эти таблицы будут связаны друг с другом?

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

Проектирование предусматривает этапы создания проекта базы данных от концепции до реального воплощения.

Этапы проектирования базы данных:

1. Исследование предметной области и формулировка основных допущений (накладываемых условий). На этом этапе составляется список всех форм и отчетов, которые могут быть затребованы пользователями вашей БД.

2. Анализ данных. Составить перечень всех элементов данных, входящих в формы и отчеты и сгруппировать их в таблицы БД.

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

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

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

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

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

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

Пример проектирования БД

Задача: Создать БД реализации товаров со складов, при условии, что на одном складе может храниться только один вид товара.

1. Составим примерный перечень отчетов, которые могут быть затребованы пользователями БД.

Отчет №1. Данные о товарах (Наименование, Марка, Цена, Номер телефона склада, где хранится товар, Количество имеющегося на складе товара, Описание товара, Название фирмы, которая занимается реализацией товара).

Отчет №2. Данные о фирмах (Название фирмы, Адрес фирмы, Телефон фирмы, Наименование товара, реализуемого фирмой).

Отчет №3. Система скидок (Фирма, Товар, Скидка).

Отчет №4. Продажи (Дата, Фирма, Товар, Марка товара, Количество проданного товара).

Отчет №5. Данные о складах (Номер склада, Адрес склада, Телефон склада, Фамилия заведующего, Товар, хранимый на складе).

Отчет №6. Данные о контактных лицах фирм (Фамилия, Имя, Дата рождения, Домашний адрес, Домашний телефон, Должность, Название фирмы, сотрудником которой он является).

Отчет №7. Список директоровфирм (Фамилия, Телефон фирмы, Адрес фирмы, Домашний телефон, Домашний адрес)*.

2. Составим подробный перечень всех элементов данных, требуемых для отчетов и сгруппируем их в таблицы БД:

	Отчет №1	Отчет №2	Отчет №3	Отчет №4	Отчет №5	Отчет №6	Отчет №7
Наименование товара	+	+	+	+	+
Марка товара	+			+
Цена	+
Количество	+
Описание товара	+
Название фирмы	+	+	+	+		+
Адрес фирмы		+					+
Телефон фирмы		+					+
Скидка			+
Номер склада					+
Адрес склада					+
Телефон склада	+				+
Фамилия заведующего					+
Дата продажи				+
Количество продажи				+
Фамилия контактного лица						+	+
Имя						+
Дата рождения						+
Адрес домашний						+	+
Телефон домашний						+	+
Должность						+	+

 

Сгруппируем данные в таблицы:

Таблица 1 Таблица 2 Таблица 3

Товары Фирмы Склады

	Товар Марка Цена Телефон склада Количество Описание Фирма		Фирма Адрес фирмы Телефон фирмы Товар		Склад Адрес склада Телефон склада Заведующий

 

 

Таблица 4 Таблица 5

Фирма Товар Марка товара Кол-во товара Дата продажи Скидка

Фамилия Имя Дата рождения Адрес домашний Телефон домашний Фирма Должность

Контактные лица Продажи

 

 

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

Код фирмы Название фирмы Адрес фирмы Телефон фирмы Код товара

Код товара Наименование товара Марка Цена № склада Количество Описание Код фирмы

Товары Фирмы Контактные лица

Код сотрудника Фамилия Имя Дата рождения Адрес домашний Телефон домашний Код фирмы Должность

 

 

№ cклада Адрес склада Телефон склада Заведующий

Склады

 

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

Существует 3 типа связей:

"один к одному" – каждой записи одной таблицы соответствует только одна запись в другой;

"один ко многим" - каждой записи одной таблицы может соответствовать несколько записей в другой таблице или "многие к одному" – в таблице может быть несколько записей, соответствующих только одной записи в другой таблице;

"многие ко многим" – множеству записей одной таблицы соответствует множество записей другой таблицы.

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

В нашем примере между полученными объектами установились следующие отношения:

"Склады" и "Товары"–– отношение "один ко многим"[4];

"Фирмы" и "Контактные лица" –– отношение "один ко многим";

"Фирмы" и "Товары" - отношение "многие ко многим".

Аccess не позволяет определить прямую связь "многие ко многим" между двумя таблицами. В этом случае необходимо создать дополнительную таблицу пересечения, с помощью которой одна связь "многие ко многим" будет сведена к двум связям типа "один ко многим". В нашем примере такой дополнительной таблицей может являться таблица "Продажи", ключ которой состоит из двух полей (составной ключ), являющимися полями первичного ключа в таблицах "Фирмы" и "Товары".

Код фирмы Код товара Кол-во товара Дата продажи Скидка

Продажи

 

 

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

Графически связи и таблицы после преобразования могут быть представлены в следующем виде:

Рисунок 2. Схема БД Продажи.