Рисунок 3 - Список дел по клиентам

2.5 Описание выходной информации

1) В документе Акт осмотра ТС (структура документа представлена на рисунке 4) предоставлены данные о транспортном средстве клиента: тип ТС, марка, модель, год выпуска, государственный номер, цвет, номер кузова, свидетельство о регистрации, ФИО владельца, адрес владельца, повреждения аварийного характера. Документ существует в двух формах: экранной и бумажной - в обоих представляет собой :

Рисунок 4 - Акт осмотра ТС

2) Каталог деталей: форма представления бумажная и экранная. Каталог в бумажной форме представляет собой перечень цен на детали, размер страницы А4. На ней располагают : наименование детали и информацию о ее стоимости, детали комплектуются по маркам и моделям ТС (структура документа представлена на рисунке

Каталог деталей:

Наименование транспортного средства х(60)

Рисунок 5 - Каталог деталей

3) В документе Акт приема - передачи документов (структура документа представлена на рисунке 6) предоставлены данные о необходимых документах, которые клиент должен иметь, обращаясь в фирму, о их количестве, дате сдачи. Документ существует в двух формах: экранной и бумажной .Структура обоих документов одинакова.

АКТ ПРИЕМА- ПЕРЕДАЧИ ДОКУМЕНТОВ

Рисунок 6 - Акт приема- передачи документов

4) В документе Заявление от клиента (структура документа представлена на рисунке 7) предоставлены данные о клиенте: фамилия, имя, отчество, адрес, номер дела, характеристики ТС. Документ существует в двух формах: экранной и бумажной - в обоих представляет собой :

6) В документе Чек на выплату (структура документа представлена на рисунке 8) представлена информация о чеке, по которому выплачивается страховое пособие клиенту: наименование поврежденной детали, процент ее оплаты, полная стоимость, выплата с учетом процентов, общая сумма выплаты, ФИО и роспись клиента, ФИО и роспись кассира. Документ существует в двух формах: экранной и бумажной .Структура обоих документов одинакова.

Рисунок 7 - Заявление от клиента

ЧЕК на выплату

ИТОГО к выплате: 9(8)

Кассир : ФИО х (60)

Клиент: ФИО клиента х (60)

Рисунок 8 - Чек на выплату

7) В документе Список сотрудников (структура документа представлена на рисунке 9) представлена информация о сотруднике: фамилия, имя, отчество, должность. Документ существует в экранной форме

СПИСОК СОТРУДНИКОВ

Рисунок 9 - Список сотрудников

2.6 Разработка базы данных

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

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

Сущность - это объект, информация о котором хранится в базе данных.

Выделим следующие сущности:

- Заявление

- Клиент

- Сотрудники

Связи между сущностями приведены на рисунке 9.

Рисунок 9- Связи между сущностями

Приведение модели к требуемой нормальной форме.

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

Следует иметь в виду, что чрезмерное увеличение количества таблиц приводит к потере общей идеи создания базы данных, и сама база данных становится трудной для восприятия. Оптимальное количество таблиц не более 50. Всего существует 5 нормальных форм, но на практике используют 3.

Приведение БД к первой нормальной форме.

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

- должны отсутствовать повторяющиеся записи;

- должны отсутствовать повторяющиеся атрибуты;

- каждый атрибут (поле) должен быть неделимым.

Для каждой сущности определяем атрибуты, которые будем хранить в БД. Приведем таблицу атрибутов и первичных ключей сущностей информации модели.

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

Сущность Клиент имеет следующие атрибуты:

- уникальный ключ клиента;

- фамилия клиента;

- имя клиента;

- отчество клиента;

- адрес;

- контактный телефон;

- процент оплаты;

- наименование ТС;

- год выпуска;

- цвет;

- номер кузова;

- свидетельство о регистрации;

- наименование детали;

- стоимость детали;

Сущность Заявление имеет следующие атрибуты:

- уникальный ключ заявления

- уникальный ключ клиента;

- уникальный ключ сотрудника.

Сущность Сотрудники имеет следующие атрибуты:

- уникальный ключ сотрудника;

- фамилия;

- имя;

- отчество;

- должность;

Приведение БД ко второй нормальной форме.

Отношение находится во второй нормальной форме, если оно находится в 1НФ, и каждый не ключевой атрибут функционально полностью зависит от первичного ключа. Теперь применим к полученным мной на предыдущем этапе сущностям условия второй нормальной формы:

1. выполняются условия первой нормальной формы;

2. первичный ключ однозначно определяет запись;

3. все поля записи зависят от первичного ключа;

4. первичный ключ имеет минимальную форму (отсутствует избыточность).

Приведем схему взаимосвязей между атрибутами сущностей во второй нормальной форме( схема приведена на рисунке 10):

Страницы: 1, 2, 3, 4, 5