Разработка руководства пользователю базой данных

    Связь является типовым понятием, т. е. все  экземпляры связываемых сущностей  подчиняются правилам связывания типов. Сущности, объединяемые связью, называются участниками. Степень связи определяется количеством участников связи. Если каждый экземпляр сущности участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае — неполным (или необязательным).

    Возможны  следующие типы связей:

1. «Один к одному» (1:1) – каждому экземпляру сущности А соответствует 1 или 0 экземпляров сущности В;
2. «Один ко многим» (1:М) – одному экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В;
3. «Многие к одному» (М:1) – одному экземпляру сущности В соответствует 0,1 или несколько экземпляров сущности А;
4. «многие ко многим» (М:М) – 0,1 или нескольким экземплярам сущности А соответствует 0,1 или несколько экземпляров сущности В.

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

    Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно  идентифицирующий каждый из его кортежей.

    В АСУ «Страховая компания» я выделила следующие сущности:

    - сущность «Клиенты»

    - сущность «Договора»

    - сущность «Объекты страхования»

    - сущность «Страховые выплаты»

    - сущность «Сотрудники»

    Сущность  «Клиенты» содержит информацию обо всех клиентах страховой компании. Отдельный экземпляр этой сущности содержит информацию только  об одном клиенте.

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

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

    Сущность  «Страховые выплаты» содержит информацию о суммах страховых выплат. Между сущностью «Страховые выплаты» и сущностью «Договора» существует существует связь типа «1:М», которая означает, что страховая выплата производится в соответствие с заключенным договором между страховщиком и клиентом.

      Сущность «Сотрудники» содержит информацию обо всех сотрудниках страховой компании. Между сущностью «Сотрудники» и сущностью «Договора» существует связь типа «1:М», которая означает, что один и тот же сотрудник может заключить с разными клиентами договора.

    Ключи – уникальные идентификаторы экземпляров каждой сущности: для сущности «Клиенты» - это код клиента (ID), для сущности «Договора» - код договора (ID), для сущности «Объекты страхования» - код объекта (ID), для сущности «Страховые выплаты » - это код выплаты (ID), для сущности «Сотрудники» - это код сотрудника (ID).

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

    Инфологическая  модель АСУ «Страховая компания» имеет следующий вид:

Рисунок 1 - Инфологическая модель базы данных "Страховая компания" 

2. Даталогическая  модель

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

    Базами  данных называют электронные хранилища  информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.

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

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

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

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

    Одно  из требований — реляционная база данных должна быть нормализована. Процесс  нормализации имеет своей целью  устранение избыточности данных и заключается в приведении к третьей нормальной форме (или к нормальной форме Бойса-Кодда).

    Нормализацией называется формальная процедура, в  ходе которой атрибуты данных группируются в таблицы, а таблицы группируются в базу данных (БД). Нормализация выполняется поэтапно.

    1 НФ – таблица должна быть  плоской и не содержать повторяющихся  групп. У плоской таблицы есть  только две характеристики - длина  (количество записей или строк)  и ширина (количество полей или  столбцов). Такая таблица не должна содержать ячеек, включающих несколько значений.

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

    3  НФ - все не ключевые столбцы  таблицы зависят от первичного ключа таблицы, но независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

    4 НФ – в отношение не должны  присутствовать функциональные многозначные зависимости, то есть в одной таблице не должны содержаться независимые элементы данных, если между ними существует отношение «многие-ко-многим».

    5 НФ – каждая проекция, полученная из 4 НФ, содержит не менее одного возможного ключа и хотя бы один не ключевой атрибут из исходного отношения.

3. Физическое проектирование

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

    Данные  в таблицах Access сохраняются в определенном формате, который называется типом данных. Типы данных могут быть классифицированы по четырем категориям: числовые (numeric), символьные (character), даты (date) и BLOB.

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

    В АСУ «Страховая компания» я использовала следующие типы данных:

1. Текстовый (256 символов) – текст или числа не требующие проведения расчетов;
2. Числовой - Байт (от 0 до 255);
3. Числовой - Длинное целое (от -32768 до 32767);
4. Счетчик – уникальные последовательно возрастающие (на 1) или случайные числа, автоматически вводящиеся при добавлении каждой новой записи в таблицу;
5. Дата/Время – хранится в специальном фиксированном числовом формате. Дата является целой частью значения поля, а время его дробной частью;
6. Денежный – предназначен для хранения информации, выраженной в денежном эквиваленте;

7. Поле объекта – предназначен для хранения изображений.

    Структура таблиц базы данных «Страховая компания» следующая: 
 

 

Таблица 1 – структура таблиц базы данных "Страховая компания" 

 

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

    Для того чтобы создать таблицу необходимо перейти на вкладку «Таблицы» и выбрать «Создать». Выбираем «Мастер таблиц» и жмем ОК.

    

    Рисунок 2 – Создание новой таблицы

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

    

    Рисунок 3 – Создание таблицы в режиме мастера

    Также можно создать таблицу и в  режиме конструктора. В этом режиме мы сами выбираем название таблицы, полей, их тип и т.д.

    

    Рисунок 4 – Создание таблица в режиме конструктора 

1. Разработка  схемы связей таблиц, нормализация базы данных  и приведение ее к НФБК

    На  основании изучения предметной области, определения основных сущностей, атрибутов  и связей осуществляется непосредственное создание базы данных.

    Обработав данные предметной области, я получила реляционную схему, приведенную, к  НФБК:

    Клиенты: (ID, ФИО клиента, Пол, Дата рождения, Паспортные данные);

    Договора: (ID, № договора, Дата заключения, Срок, ID клиента, ID объекта, Страховая премия, Страховая выплата, ID сотрудника);

    Страховые выплаты: (ID, Дата, № договора, Сумма выплаты );

    Объекты страхования: (ID, Объект страхования);

    Сотрудники: (ID, Имя, Фотография, Фамилия, Адрес, Область, ДатаРождения).

    Моя база данных состоит из главной таблицы  «Договора» и связанных с ней таблиц: Клиенты, Объекты страхования, Страховые выплаты, Сотрудники.

    Рисунок 5 – Таблицы базы данных.

    Для того, чтобы определить связь между  таблицами необходимо выполнить  команду Сервис ->Схема данных. Также можно отобразить панель схемы данных нажав на кнопку «Схема данных» на панели инструментов. После открытия нажимаем правой кнопкой мыши и выбираем «Добавить таблицу». Выбираем необходимые таблицы, нажимая дважды на них. Они появляются в окне схемы данных. Для установления  связи между таблицами выбираем ключевое поле одной таблицы и, зажав его клавишей мыши, перетаскиваем на аналогичное поле в другой таблицы. Появится диалоговое окно связи.