Введение в проектирование реляционных баз данных
Цели проектирования
Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это
группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы).
Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных
подразделений. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.)
Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной
области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые – предметными БД
(соотносящимся с предметами организации, а не с ее информационными приложениями). (Первые можно сравнить с базами материально-технического
снабжения или отдыха, а вторые – с овощными и обувными базами.)
Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений,
поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки
неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным).
Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых
большинство изменений можно осуществить без вынужденного переписывания старых приложений.
Основывая же проектирование БД на текущих и предвидимых приложениях, можно существенно ускорить создание высокоэффективной информационной системы, т.е.
системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых
разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень
дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание
достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем
случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью
повышения эффективности обработки данных.
При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников
организации) [2,
3,
4,
6,
8,
9,
10].
Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по
"сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет – пассажир,
преподаватель – дисциплина, студент – сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой
ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик – по
"здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным
проектированием базы.
Далее будут рассматриваться вопросы, связанные с проектированием отдельных реляционных предметных БД.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат
на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и
том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации
отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с
рассмотрения причин, которые заставили Кодда создать основы теории нормализации.
Универсальное отношение
Предположим, что проектирование базы данных "Питание" (рис. 3.2)
начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.
Этот вариант таблицы "Питание" не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей
Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 – множественные. Для придания таким данным формы отношения
необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое
преобразование приводит к возникновению большого объема избыточных данных.
|
Блюдо
|
Вид
|
Рецепт
|
Порций
|
Дата Р
|
Продукт
|
Калорийность
|
Вес (г)
|
Поставщик
|
Город
|
Страна
|
Вес (кг)
|
Цена ($)
|
Дата П
|
|
Лобио
|
Закуска
|
Лом.
|
158
|
1/9/94
|
Фасоль
|
3070
|
200
|
"Хуанхэ"
|
Пекин
|
Китай
|
250
|
0.37
|
24/8/94
|
|
|
|
|
|
|
Лук
|
450
|
40
|
"Наталка"
|
Киев
|
Украина
|
100
|
0.52
|
27/8/94
|
|
|
|
|
|
|
Масло
|
7420
|
30
|
"Лайма"
|
Рига
|
Латвия
|
70
|
1.55
|
30/8/94
|
|
|
|
|
|
|
Зелень
|
180
|
10
|
"Даугава"
|
Рига
|
Латвия
|
15
|
0.99
|
30/8/94
|
|
Харчо
|
Суп
|
...
|
144
|
1/9/94
|
Мясо
|
1660
|
80
|
"Наталка"
|
Киев
|
Украина
|
100
|
2.18
|
27/8/94
|
|
|
|
|
|
|
Лук
|
450
|
30
|
"Наталка"
|
Киев
|
Украина
|
100
|
0.52
|
27/8/94
|
|
|
|
|
|
|
Томаты
|
240
|
40
|
"Полесье"
|
Киев
|
Украина
|
120
|
0.45
|
27/8/94
|
|
|
|
|
|
|
Рис
|
3340
|
50
|
"Хуанхэ"
|
Пекин
|
Китай
|
75
|
0.44
|
24/8/94
|
|
|
|
|
|
|
Масло
|
7420
|
15
|
"Полесье"
|
Киев
|
Украина
|
50
|
1.62
|
27/8/94
|
|
|
|
|
|
|
Зелень
|
180
|
15
|
"Наталка"
|
Киев
|
Украина
|
10
|
0.88
|
27/8/94
|
|
Шашлык
|
Горячее
|
...
|
207
|
1/9/94
|
Мясо
|
1660
|
180
|
"Юрмала"
|
Рига
|
Латвия
|
200
|
2.05
|
30/8/94
|
|
|
|
|
|
|
Лук
|
450
|
40
|
"Полесье"
|
Киев
|
Украина
|
50
|
0.61
|
27/8/94
|
|
|
|
|
|
|
Томаты
|
240
|
100
|
"Полесье"
|
Киев
|
Украина
|
120
|
0.45
|
27/8/94
|