Проектирование базы данных

Для отображения атрибутов в столбцы также существует множество способов. Все они влияют не только на отображение столбцов, но и на отображение классов в таб­лицы. Возможно, у вас есть атрибуты, которых нет в базе данных, или столбцы, кото­рые никогда не отображаются или вообще не обрабатываются в программе, но вклю­чены в базу данных для каких-то определенных целей. Иногда атрибут или даже класс преобразуется в несколько столбцов в базе данных.

При отображении атрибутов в столбцы иногда учитываются параметры произво­дительности базы данных, но, как правило, определяющими в этом процессе оказы­ваются требования. В такой сценарий можно даже включить представления базы дан­ных, в которых атрибуты как часть класса отображались бы в таблице или в других столбцах. Это делается, в основном, с целью ускоренного доступа к часто запраши­ваемым столбцам или из соображений защиты информации. Во многих базах данных нельзя защитить отдельный столбец, можно защитить только всю таблицу целиком, поэтому представления играют важную роль в вопросах защиты данных. Очевидно, что не вся информация о служащем должна быть доступна. Например, незачем пока­зывать данные о заработной плате всем пользователям базы данных. Для этого можно создать представление для определенной группы пользователей, в котором данная информация будет доступна. Для пользователей, не принадлежащих к указанной группе, данные по заработной плате служащего будут недоступны.

При отображении атрибутов в столбцы частично происходит и отображение клас­сов в таблицы, но в любом случае их нужно рассматривать как один процесс. Нельзя преобразовать столбцы, не изменив таблиц, и невозможно переделать таблицы, не изменив при этом столбцы. Рассмотрим, например, класс, который содержит метод поиска адресных данных по почтовому индексу. Абсолютно неважно, какой алгоритм поиска используется в базе данных, лишь бы в ней была вся необходимая адресная информация. С другой стороны, в программе этот набор может оказаться в двух клас­сах — один класс для поиска по адресу, а другой для поиска по почтовому индексу (рис. П1.30).

Рис. П.1.30. Класс с поиском по почтовому индексу на диаграмме классов и его представление в модели базы данных.

В приложении часто вычисляется общая сумма продаж, однако ее нет в базе дан­ных, где продажи хранятся по конкретным товарам или регионам, а общая сумма раз­личных комбинаций вычисляется по разным выборкам данных. Атрибуты, которые содержат значения для вычислений, выбранных в базе данных, называются производ­ными атрибутами и не хранятся в базе данных.

При отображении атрибутов в столбцы важно отобразить не только названия столбцов, но также понимать, как типы данных в логической модели будут отображе­ны в типы данных именно в вашем варианте базы данных. Данные в моделях, разра­ботанных на этапе анализа, могут быть либо основного, либо логического типа, по­этому специальные знания по конкретному программному обеспечению (например, Oracle, IBM DB2, Microsoft SQL Server и т.п.) не требуются, достаточно только общих представлений о типах атрибутов. При описании атрибутов необходимо точно знать длину типов данных в отличие от анализа, где это не так важно.

Итак, при отображении атрибутов в конкретные столбцы базы данных необходи­мо расширить эти столбцы насколько позволяют допустимые значения. Например, для столбца Country (Страна) требуется создать диапазон допустимых значений в виде списка стран, которые можно ввести в этот столбец. Примерно то же требуется сделать при проектировании архитектуры, когда решается, где фактически должны быть реализованы бизнес-правила. В приложении их можно реализовать через мето­ды или группы методов, в базе данных — через диапазоны допустимых значений или вообще реализовать бизнес-правила на бизнес-уровне, чтобы при их изменении не изменять ни программу, ни базу данных.

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

Рис.П1.31 Диаграмма классов базы данных.

Далее нужно произвести нормализацию диаграммы классов, по которой будет создаваться модель базы данных. Т.е. надо проанализировать все ассоциации между классами и заменить связи "много-ко-многим" и "один-к-одному", разбив или объединив таблицы соответственно.

Между классами "Счет" и "Расходная накладная" существует связь "один-к-одному", поэтому эти классы можно объединить в один "Расход". Между классами "Приходная накладная" и "Товар" - связь "много-ко-многим", поэтому чтобы ее изменить введен такой класс как "Строка ПН", в которой будет информация о каждом товаре, включенном в одну приходную накладную. Связь между классом "Клиент" и классом "Товар" является избыточной. Таким образом, внеся все эти изменения, физическая модель базы данных будет выглядеть следующим образом (рис. П1.32).

Рис.П1.32 Физическая модель базы данных (промежуточный этап).

Как видно из диаграммы у нас осталась еще одна связь "много-ко-многим" между "Товар" и "Расход". Избавимся от нее аналогично как в случае с "Приходная накладная" и "Товар". Тогда окончательная физическая модель базы данных будет выглядеть так (рис.П1.33):

Рис.П1.33. Физическая модель базы данных.

На этом завершаются фрагменты шагов этапа Проектирование.

Этапы Подготовка (описание предметной области, глоссарий предметной области, документ Видение), Анализ (концептуальная модель предметной области, требования к информационной системе, диаграммы вариантов использования, краткое и полное описание вариантов использования,пользовательский интерфейс), Проектирование (диаграммы анализа, диаграммы последовательности, диаграммы классов уровня проектирования, структура базы данных) описываются в Исследовательской части расчетно-пояснительной записки.

 Далее начинаются фрагменты шагов этапа Создание, которые уже будут описаны в Конструкторской и Технологической частях расчетно-пояснительной записки.