6.2. Выбор структуры бд на основе прагматического подхода
Несмотря на существование различных методик анализа предметных областей и построения эскизов БД, необходимо отметить следующее:
-
процесс определения окончательной структуры БД является циклическим, то есть на разных этапах проектирования, начиная от эскиза структуры БД и заканчивая промышленной эксплуатацией готовых программных систем, приходится возвращаться к структуре БД и вносить в нее изменения;
-
в процессе моделирования предметной области участвуют такие субъективные факторы, как прагматический подход разработчика, его интуиция, личностное восприятие проблемы, стереотипы мышления. Поэтому различные разработчики предлагают различные проекты структуры одной и той же БД, хотя в основных моментах, например, в определении большей части сущностей и связей между ними, эти проекты похожи.
Следовательно, с одной стороны, процесс проектирования структуры БД является процессом творческим, но с другой стороны, основные его моменты могут быть формализованы. Одной из таких формализаций является требование, согласно которому реляционная база данных должна быть подвергнута процедуре нормализации.
Процесс нормализации имеет своей целью устранение избыточности данных и заключается в приведении таблиц БД к 3НФ.
Для рассмотрения процесса нормализации структуры БД используем пример проектирования части структуры таблиц для «Информационной системы сбора и обработки экономической информации Управления связи». Задача состоит в автоматизации процесса сбора и обработки отчетных данных, получаемых из дочерних подразделений (филиалов) и характеризующих их финансово-хозяйственную деятельность.
Примерная структура получаемой в головной организации информации приведена ниже:
|
Дата |
Филиал |
Адрес электронной почты филиала |
|
1.07.97 г. |
Аннинский |
anna@dfg.ru |
|
Отчет |
Показатель |
|
1. «Тарифные доходы» |
Тарифные доходы Междугородной телефонной связи от населения |
|
|
Тарифные доходы Междугородной телефонной связи от бюджетных организаций |
|
|
Тарифные доходы Сельской телефонной связи от населения |
|
|
Тарифные доходы Сельской телефонной связи от бюджетных организаций |
|
|
Всего тарифные доходы |
|
2. «Анализ затрат» |
Расходы на отопление Городской телефонной связи |
|
|
Расходы на отопление Сельской телефонной связи |
|
|
Расходы на освещение Городской телефонной связи |
|
|
Расходы на освещение Сельской телефонной связи |
|
|
Итого затрат |
Существует несколько нормальных форм, из которых в практической разработке БД важны первые три - 1НФ, 2НФ, 3НФ.
Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД было неделимым и не содержало повторяющихся групп столбцов. Неделимость поля означает, что значение поля не должно делиться на более мелкие значения. Повторяющимися являются поля, содержащие одинаковые по смыслу значения.
РАБОЧАЯ ТАБЛИЦА
Дата_отчета
Филиал
Адрес
Отчет
Показатель
Отрасль
Аббревиатура_отрасли
Категория_клиентуры
Аббревиатура_категории_клиентуры
Ед_измерения_показателя
Значение_показателя
Правило_контроля_значений_показателей_в_отчете
Вторая нормальная форма (2НФ) требует, чтобы все поля таблицы зависели от первичного ключа, то есть чтобы первичный ключ однозначно определял запись и не был избыточен. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц.
Для приведения ко 2НФ выделим поля, которые входят в первичный ключ. Поле «Филиал» не может однозначно идентифицировать запись, поскольку его значение будет одинаковым для всех записей, относящихся к данному филиалу. Поэтому введем в первичный ключ поле «Отчет». Тем не менее этих двух полей не достаточно для уникального определения записей в таблице, так как отчеты состоят из нескольких показателей, а по совокупности полей «Филиал» и «Отчет» нельзя определить, к какой дате, показателю, отрасли и категории клиентуры относится конкретное значение показателя.
Д
ля
полной идентификации значений показателей
введем в первичный ключ поля «Показатель»,
«Дата отчета», «Отрасль» и «Категория
клиентуры». Проведя смысловой анализ
зависимостей между полями таблицы,
нетрудно увидеть, что созданный первичный
ключ однозначно определяет все записи
таблицы и не является избыточным. Второе
требование 2НФ предполагает, что значения
всех полей записи должны однозначно
зависеть от совокупного значения
первичного ключа и не должна иметь место
ситуация, когда некоторые поля зависят
только от части первичного ключа.
Анализируя структуру таблицы можно увидеть, что поле «Единица измерения показателя» зависит только от значения поля «Показатель» и не зависит от значения остальных полей первичного ключа. Поэтому выделяем данное поле в отдельную таблицу «Показатели» и определяем связь: поскольку один и тот же показатель может присутствовать в различных отчетах за разные даты и полученные от разных филиалов, таблицы «Показатель» и «Рабочая таблица» связаны отношением «один ко многим».
Третья нормальная форма (3НФ) требует, чтобы в таблице не имелось транзитивных зависимостей между неключевыми полями, то есть чтобы значения полей таблицы, не входящих в первичный ключ не зависели друг от друга.
В данном случае очевидно, что в полученных таблицах отсутствуют транзитивные зависимости между неключевыми полями. В результате получаем нормализованную (каноническую) модель базы данных
При реальной разработке БД первичные ключи обычно задаются числовыми полями
Рис. 6.2. Каноническая модель структуры БД с первичными лючами в виде числовых полей.
ПОКАЗАТЕЛЬ ФИЛИАЛ
ПОКАЗАТЕЛЬ_ОТЧЕТ ФИЛИАЛ_ОТЧЕТ
ОТЧЕТ
РАБОЧАЯ ТАБЛИЦА
КАТЕГОРИЯ КЛИЕНТУРЫ ОТРАСЛЬ
КАТЕГОРИЯ КЛИЕНТУРЫ_ ПОКАЗАТЕЛЬ ОТРАСЛЬ_ПОКАЗАТЕЛЬ
Деканонизация структуры БД на основе прагматического подхода
Недостатком нормализованной БД является необходимость считывать из таблиц связанные данные при выполнении запросов к нескольким таблицам БД. На практике ненормализованные данные (хранящиеся в одной таблице), отыскиваются быстрее по сравнению со случаем поиска данных в одной или более связанных таблиц. Подобное ускорение тем заметнее, чем большее число записей в связанных таблицах. На скорость поиска в дочерней таблице могут оказывать негативное влияние слишком большое число вложенных полей в индексе; индекс, структура которого не совсем корректно определена.
Поэтому при работе с большими объемами данных приходится искать компромисс между требованиями нормализации и необходимостью достигнуть максимального быстродействия системы.
ПОКАЗАТЕЛЬ ФИЛИАЛ
ПОКАЗАТЕЛЬ_ОТЧЕТ ФИЛИАЛ_ОТЧЕТ
ОТЧЕТ
РАБОЧАЯ ТАБЛИЦА