ВУЗ: Финансовый университет при правительстве Российской Федерации
Категория: Методичка
Дисциплина: Базы данных
Добавлен: 21.10.2018
Просмотров: 3978
Скачиваний: 18
6
4. Этапы проектирования базы данных
Прежде чем приступить к созданию таких объектов базы данных, как
таблицы, формы и отчеты, нужно разработать их проект. Главное назначение
проекта — выработка четкого пути, по которому нужно следовать при его
реализации. База данных – достаточно сложный объект, и время, затраченное
на ее планирование, может значительно сократить сроки ее разработки. От-
сутствие продуманной структуры базы данных приводит к необходимости
постоянной переделки и перенастраиванию объектов базы данных, таких, как
формы и таблицы.
Проектирование базы данных целесообразно начать с краткого описания
отчетов, списков и других документов, которые необходимо получить с по-
мощью БД. Далее следует разработать эскиз объектов, требуемых для полу-
чения необходимых результатов и определить связи между этими объектами.
При разработке эскиза необходимо ответить на следующие вопросы:
Какими данными мы располагаем?
Какие данные будут содержать таблицы?
Какой тип и какие свойства должны иметь данные в каждом поле таблицы?
Как эти таблицы будут связаны друг с другом?
Законченный план должен содержать подробное описание всех таблиц
(имена полей, типы данных и их свойства), а также связей между ними.
Проектирование предусматривает этапы создания проекта базы данных от
концепции до реального воплощения. Этапы проектирования базы данных:
1. Исследование предметной области и формулировка основных допу-
щений (накладываемых условий). На этом этапе составляется список всех
форм и отчетов, которые могут быть затребованы пользователями вашей БД.
2. Анализ данных. Составить перечень всех элементов данных, входя-
щих в формы и отчеты и сгруппировать их в таблицы БД.
3. Установить, какие взаимосвязи существуют между элементами дан-
ных. Определить первичные и вторичные (внешние) ключи отношений. Ор-
7
ганизовать поля данных в таблицах, причем это необходимо сделать, следуя
4-м правилам нормализации:
Правило 1: Каждое поле таблицы должно представлять уникальный тип
информации. Это правило означает, что необходимо избавиться от повторя-
ющихся полей и разделить составные поля на отдельные элементы данных.
Правило 2: Каждая таблица должна иметь уникальный идентификатор или
первичный ключ, который может состоять из одного или нескольких полей.
Правило 3: В таблице не должно быть данных не относящихся к объек-
ту, определяемому первичным ключом.
Правило 4: Независимость полей. Это правило означает возможность
изменять значения любого поля (не входящего в первичный ключ) без воз-
действия на данные других полей.
Результатом 3 этапа должна явиться группа таблиц, удовлетворяющих
правилам нормализации. На этом же этапе необходимо установить связи
между таблицами.
Пример проектирования БД
Задача: Создать БД реализации товаров со складов, при условии, что на
одном складе может храниться только один вид товара.
1. Составим примерный перечень отчетов, которые могут быть затребо-
ваны пользователями БД.
Отчет №1. Данные о товарах (Наименование, Марка, Цена, Номер те-
лефона склада, где хранится товар, Количество имеющегося на складе това-
ра, Описание товара, Название фирмы, которая занимается реализацией то-
вара).
Отчет №2. Данные о фирмах (Название фирмы, Адрес фирмы, Телефон
фирмы, Наименование товара, реализуемого фирмой).
Отчет №3. Система скидок (Фирма, Товар, Скидка).
Отчет №4. Продажи (Дата, Фирма, Товар, Марка товара, Количество
проданного товара).
8
Отчет №5. Данные о складах (Номер склада, Адрес склада, Телефон
склада, Фамилия заведующего, Товар, хранимый на складе).
Отчет №6. Данные о контактных лицах фирм (Фамилия, Имя, Дата
рождения, Домашний адрес, Домашний телефон, Должность, Название фир-
мы, сотрудником которой он является).
Отчет №7. Список директоров фирм (Фамилия, Телефон фирмы, Ад-
рес фирмы, Домашний телефон, Домашний адрес)
2
.
2. Составим подробный перечень всех элементов данных, требуемых для
отчетов и сгруппируем их в таблицы БД:
Отчет
№1
Отчет
№2
Отчет
№3
Отчет
№4
Отчет
№5
Отчет
№6
Отчет
№7
Наименование товара
+ + + + +
Марка товара
+ +
Цена
+
Количество
+
Описание товара
+
Название фирмы
+ + + + +
Адрес фирмы
+ +
Телефон фирмы
+ +
Скидка
+
Номер склада
+
Адрес склада
+
Телефон склада
+ +
Фамилия заведующего
+
Дата продажи
+
Количество продажи
+
Фамилия контактного лица
+
+
Имя
+
Дата рождения
+
Адрес домашний
+
+
Телефон домашний
+
+
Должность
+
+
2
Перечень требуемых данных и отчетов может быть скорректирован (например, могут рассматриваться
данные о сотрудниках склада) и продолжен, в зависимости от степени полноты рассматриваемой предмет-
ной области. В учебных целях мы ограничимся этим перечнем.
9
Сгруппируем данные в таблицы:
3. Для каждой таблицы определим уникальный идентификатор (первич-
ный ключ) и перегруппируем таблицы так, чтобы в них остались только дан-
ные, относящиеся к объекту, определяемому первичным ключом.
Товар
Марка
Цена
Телефон склада
Количество
Описание
Фирма
Таблица 1
Товары
Фирма
Адрес фирмы
Телефон фирмы
Товар
Склад
Адрес склада
Телефон склада
Заведующий
Таблица 2
Фирмы
Таблица 3
Склады
Фамилия
Имя
Дата рождения
Адрес домашний
Телефон домашний
Фирма
Должность
Таблица 4
Контактные лица
Фирма
Товар
Марка товара
Кол-во товара
Дата продажи
Скидка
Таблица 5
Продажи
Код товара
Наименование товара
Марка
Цена
№ склада
Телефон склада
Количество
Описание
Код фирмы
Товары
Код фирмы
Название фирмы
Адрес фирмы
Телефон фирмы
Код товара
Фирмы
Код сотрудника
Фамилия
Имя
Дата рождения
Адрес домашний
Телефон домашний
Код фирмы
Должность
Контактные лица
Склады
№ склада
Адрес склада
Телефон склада
Заведующий
10
Сформировав таблицы и установив ключевое поле
3
для каждой таблицы,
между таблицами можно установить взаимосвязи, которые будут поддержи-
ваться при создании форм, отчетов и запросов и задать условия целостности
данных этих таблиц.
Существует 3 типа связей:
"один к одному" – каждой записи одной таблицы соответствует только
одна запись в другой;
"один ко многим" - каждой записи одной таблицы может соответство-
вать несколько записей в другой таблице или "многие к одному" – в табли-
це может быть несколько записей, соответствующих только одной записи в
другой таблице;
"многие ко многим" - множеству записей одной таблицы соответству-
ет множество записей другой таблицы.
При определении связи ключ в одной таблице содержит ссылки на кон-
кретные записи в другой таблице. Поле, не являющееся ключевым для дан-
ной таблицы, но значения которого являются значениями первичного ключа
другой таблицы, называют внешним ключом
4
. Содержимое поля внешнего
ключа (значения и свойства) должно совпадать с содержимым ключевого по-
ля. Эти поля также могут иметь одинаковые имена.
В нашем примере между полученными объектами установились следу-
ющие отношения:
"Склады" и "Товары"— отношение "один ко многим"
5
;
"Фирмы" и "Контактные лица" — отношение "один ко многим";
"Фирмы" и "Товары" - отношение "многие ко многим".
Аccess не позволяет определить прямую связь "многие ко многим" меж-
ду двумя таблицами. В этом случае необходимо создать дополнительную
таблицу, с помощью которой одна связь "многие ко многим" будет сведена к
3
Ключевые поля в таблицах выделены полужирным шрифтом.
4
Поле внешнего ключа выделено курсивом.
5
Условием нашего примера оговорено, что на одном складе может храниться один вид товара, но марок
этого вида может быть несколько.