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