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):

Рисунок 10- Связи между атрибутами

Поле ИТОГО является вычисляемым: ИТОГО=? Выплат с учетом процентов

Поле Выплата с процентом является вычисляемым:

Выплата с процентом = Процент оплаты * Стоимость детали

Стоимость детали берется из таблицы "Каталог деталей", процент оплаты берется из таблицы "Таблица учета выплат".

Таблица 1 - Вторая нормальная форма

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

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

1. выполняется условия 2НФ;

2. каждое не ключевое поле не должно зависеть от другого не ключевого поля.

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

Поле ИТОГО является вычисляемым: ИТОГО=? Выплат с учетом процентов

Поле Выплата с процентом является вычисляемым:

Выплата с процентом = Процент оплаты * Стоимость детали

Стоимость детали берется из таблицы Каталог деталей, процент оплаты берется из таблицы "Таблица учета выплат".

Рисунок 11 - Графическая модель БД

База данных сформирована и состоит из 10 таблиц. Структура каждой таблицы приведена ниже.

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