2.1. Прецеденты использования базы данных предметной области

Прецеденты служат для документирования функциональных требований к программным системам. Прецедент описывает некоторый целостный фрагмент использования базы данных/базы знаний, не вдаваясь при этом в особенности внутренней реализации. Само собой, что проектируемые в дальнейшем база данных и база знаний должны соответствовать указанным случаям использования.

Определение прецедента содержит постановку задачи прецедента, последовательность действий различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них.

Для базы данных прецеденты описывают случаи доступа к данным и формирование отчётов. Количество прецедентов не менее 7, упорядоченных по мере возрастания сложности запроса.

2.2. Построение концептуальной модели бд

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

Для начала построения концептуальной модели данных

Давайте в качестве примера рассмотрим интернет-магазин. У магазина есть товары, которые поставляются поставщиками и покупаются покупатели. Это можно представить тремя объектами и двумя связями:

Но как поставщик поставляет товары? Он делает поставку, которая подтверждается документом. Аналогично и покупатель делает покупку, которая также может подтверждаться документом. Таким образом, поставка и покупка могут рассматриваться, как самостоятельные объекты:

Теперь у нас пять объектов и четыре связи. Две связи "один ко многим" (один поставщик может осуществить несколько поставок, но каждая поставка осуществляется только одним поставщиком, аналогично и для связи Покупатель - Покупка) и две связи "многие ко многим" (каждая поставка может содержать несколько товаров, а один и тот же товар может содержаться в нескольких поставках, аналогично и для связи Покупка - Товар).

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

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

В качестве результатов этого этапа представляются результаты реализации следующих процессов:

• Общая диаграмма сущность-связь для концептуальной модели в виде рисунка по аналогии представленной выше.

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

Таблица: Описание сущностей

№ п/п	Имя сущности	Описание сущности	Псевдонимы	Особенности использования
1	2	3	4	5

Таблица: Описание связей

№ п/п	Сущность	Связь	Сущность	Кардинальность
1	2	3	4	5