2.5 Стадии и этапы разработки

1. Анализ задания на проектирование

2. Разработка концептуальной модели данных

3. Разработка логической модели

4. Разработка физической модели

5. Создание вычисляемых полей, генераторов, триггеров

6. Внесение данных в базу и тестирование работы

7. Документирование согласно существующим ГОСТам

2.6 Порядок контроля и приёмки

Для контроля работы базы данных должен быть разработан тестовый набор данных, состоящий из списка клиентов, сведений о приеме вещей и видах работ в химчистке.

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

3. Концептуальная модель данных

Концептуальная модель данных отображает обобщающее представление о данных, не зависимое от типа выбранной СУБД. Она описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними. Фактически это полное представление требований к данным со стороны организации, у которой работают пользователи.

Концептуальная модель данных состоит из сущностей со своими атрибутами и n-арных связей и используется как средство построения и представления информационных потребностей предприятия.

Проанализировав описание предметной области, выделим объекты, сведения о которых участвуют в описании. Как правило, они мало меняются с течением времени и не зависят от существования других объектов. Сущности изображаются на диаграмме «объект/отношение» в виде прямоугольников. К сущностям относятся объекты: «Клиенты», «Вид работ», «Услуги».

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

«Клиенты» – код клиента

«Услуги» – код услуги

«Вид работ» – код вида работы

Затем проставляем не ключевые свойства (атрибуты) для объектов.

Определенные сущности и атрибуты представлены в таблицах 1-3:

Таблица 1 Сущность Клиенты

KLIENT
kodklienta	PK	Код клиента
familiya		Фамилия
imya		Имя
otchestvo		Отчество
ppk		Признак постоянного клиента

Таблица 2 Сущность Виды работ

VIDRAB
kodvida	PK	Код вида
nazvanie		Название
tip		Тип
stoimost		Стоимость

Таблица 3 Сущность Услуги

HIMCHI
koduslugi	PK	Код услуги
srochnost		Срочность и сложность
datapr		Дата приема
datavozvr		Дата возврата

Объекты вступают между собой в некоторые смысловые отношения, отображаемые на диаграмме «объект/отношение» в виде овалов (связи). Овалы соединяются отрезками прямых с прямоугольниками, которые соответствуют объектам, участвующим в отношении:

1-М (один-ко-многим) – Услуги-Клиенты (Оказываются), Услуги-Вид работ (Относятся).

Степень участия связи «Оказываются» между сущностями Услуги и Клиенты неполная и имеет показатели кардинальности 1,1 и N,1 соответственно, так как клиентам услуги могут оказываться многократно, а одной записи об услуге соответствует только один клиент.

Степень участия связи «Относятся» между сущностями Услуги и Виды работ неполная и имеет показатели кардинальности 1,1 и N,1 соответственно, так как одни и те же виды работ могут оказываться многократно, а одной записи об услуге соответствует только один вид работ.

Концептуальная диаграмма представлена в приложении В, рисунок 1.