Курсовая Базы данных. Страховая компания. Инфологическое проектирование Анализ предметной области
 Скачать 273.51 Kb.
|
|
Инфологическое проектирование Анализ предметной области База данных создаётся для информационного обслуживания руководства организации, руководителей проектов и участников проектов. БД должна содержать данные об отделах организации, сотрудниках и проектах. В соответствии с предметной областью система строится с учётом следующих особенностей: В страховой компании каждый сотрудник работает в определённом отделе, в каждом отделе могут работать несколько сотрудников; Страховая компания заключает договоры на страхование имущества (недвижимости, автомобилей, и т.д.) от страховых случаев (пожар, угон, и т.д.) со страхователями; По каждому договору назначается срок договора, сумма договора и страховая премия. Страховая премия в сумме определенного процента от суммы договора выплачивается страхователем; При наступлении страхового случая по заявлению страхователя страховой компанией проводится экспертиза и определяется сумма страховой выплаты по договору. Страховая выплата выплачивается страхователю; Сотрудники получают заработную плату в размере оклада и определенного процента от суммы страховых премий от заключенных договоров. Процент определяется для каждого сотрудника и зависит от ряда факторов (стажа работы, заслуг перед компанией, и т.д.). Для создания ER-модели необходимо выделить сущности предметной области: Отделы. Атрибуты: название, аббревиатура, КАБИНЕТы, телефоны. Сотрудники. Атрибуты: ФИО, паспортные данные, дата рождения, пол, ИНН (индивидуальный номер налогоплательщика), номер пенсионного страхового свидетельства, адрес, телефон (мобильный), должность. Страхователи: Атрибуты: ФИО, паспортные данные, дата рождения, пол, ИНН (индивидуальный номер налогоплательщика), номер пенсионного страхового свидетельства, адрес, телефон (мобильный) Договоры. Атрибуты: номер, дата, страхователь, сотрудник, вид страхования, имущество, страховые случаи, сумма договора, процент страховой премии, Страховой случай: договор, сотрудник, страхователь, заключение, оценка, страховая выплата. Исходя из выявленных сущностей построим ER-диаграмму: Анализ информационных задач и круга пользователей системы Определим группы пользователей, их основные задачи и запросы к БД: 1.Руководители организации: – получение списка всех страховых агентов; – изменение должностных окладов и штатного расписания; – получение полной информации о деятельности страховых агентов; 3.Сотрудники отдела кадров: – приём/увольнение сотрудников; – внесение изменений в данные о сотрудниках. 4.Бухгалтеры: получение ведомости на выплату зарплаты. 5.Сотрудники – страховые агенты: – заключение новых договоров; – просмотр данных о заключенных договорах; – прием заявлений о страховых случаях; – проведение оценки страхового случая, страховая выплата. 6.Страхователи: – просмотр информации о договорах; – подача заявления на страховую выплату при наступлении страхового случая; – получение страховой выплаты. Составление реляционных отношений Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N – числовой, C – символьный тип фиксированной длины, V – символьный тип переменной длины, D – дата (этот тип имеет стандартную длину, зависящую от СУБД, поэтому она не указывается). Потенциальными ключами отношения ОТДЕЛЫ являются атрибуты Аббревиатура и Название отдела. Первый занимает меньше места, поэтому мы выбираем его в качестве первичного ключа. Таблица 1. Схема отношения ОТДЕЛЫ
Потенциальными ключами отношения ОТДЕЛЫ являются атрибуты Аббревиатура и Название отдела. Первый занимает меньше места, поэтому мы выбираем его в качестве первичного ключа. Таблица 2. Схема отношения СОТРУДНИКИ
Потенциальными ключами отношения СОТРУДНИКИ являются поля Паспортные данные, ИНН и Номер страхового пенсионного свидетельства. Все они занимают достаточно много места, а паспортные данные кроме того могут меняться. Введём суррогатный первичный ключ Номер сотрудника. Таблица 3. Схема отношения СТРАХОВАТЕЛИ
Потенциальными ключами отношения СТРАХОВАТЕЛИ являются поля Паспортные данные, ИНН и Номер страхового пенсионного свидетельства. Все они занимают достаточно много места, а паспортные данные кроме того могут меняться. Введём суррогатный первичный ключ Номер страхователя. Таблица 4. Схема отношения ДОГОВОРЫ
Потенциальным ключом отношения ДОГОВОРЫ является атрибут Номер договора, при условии, что нумерация договоров сквозная и не начинается в начала каждый год. Мы выбираем его в качестве первичного ключа. Страховой случай: договор, сотрудник, страхователь, заключение, оценка, страховая выплата. Таблица 5. Схема отношения СТРАХОВЫЕ СЛУЧАИ
Потенциальных ключей отношения СТРАХОВЫЕ СЛУЧАИ не выявлено, поэтому введём суррогатный первичный ключ Код страхового случая. Нормализация полученных отношений (до 4НФ) Механизм нормализации подразумевает определённую последовательность преобразования отношений к третьей нормальной форме. Мы не будем чётко придерживаться этой последовательности, т. к. она избыточна, и многозначные атрибуты сразу вынесем в отдельные отношения на первом же этапе. 1НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (одно значение атрибута – одна ячейка таблицы) и разбить сложные атрибуты на простые. Разделим атрибут Фамилия, имя, отчество на два атрибута Фамилия и Имя, отчество, Паспортные данные на Номер паспорта (уникальный), Дата выдачи и Кем выдан. Многозначные атрибуты Кабинеты и Телефоны из отношения ОТДЕЛЫ вынесем в отдельное отношение КАБИНЕТЫ, а домашние и мобильные телефоны и адреса сотрудников – в отношение АДРЕСА – ТЕЛЕФОНЫ. Так как в КАБИНЕТЕ может не быть телефона, первичный ключ отношения КАБИНЕТЫ не определен (ПК не может содержать null-значения), но на этих атрибутах можно определить составной уникальный ключ. В отношении АДРЕСА – ТЕЛЕФОНЫ также нет потенциальных ключей: оставим это отношение без первичного ключа, т. к. на это отношение никто не ссылается. Что касается рабочих телефонов сотрудников, то один из этих номеров – основной – определяется рабочим местом сотрудника (рассматриваются только стационарные телефоны). Будем хранить этот номер в атрибуте Рабочий телефон. Наличие других номеров зависит от того, есть ли в том же помещении (кабинете) другие сотрудники, имеющие стационарные телефоны. Добавим в отношение СОТРУДНИКИ атрибут Номер кабинета, чтобы дополнительные номера телефонов сотрудника можно было вычислить из других кортежей с таким же номером кабинета. Связь между отношениями СОТРУДНИКИ и КАБИНЕТЫ реализуем через составной внешний ключ (Номер кабинета, Рабочий телефон). Мы также удалим вычислимый атрибут СУММА СТРАХОВОЙ ПРЕМИИ из отношения ДОГОВОРЫ, т. к. он является произведением значений атрибутов СУММА ДОГОВОРА и ПРОЦЕНТ СТРАХОВОЙ ПРЕМИИ. 2НФ. Отношение находится во второй НФ, если оно находится в 1-ой НФ и каждый из его неключевых атрибутов зависит от всего ключа. В соответствии с этим определением, если отношение имеет в качестве ключа единственный атрибут, то оно автоматически находится во 2-ой НФ. В нашем случае составных ключей нет, поэтому наши отношения находятся во второй НФ. 3НФ. Отношение находится во третьей НФ, если оно находится в 2-ой НФ и не имеет неключевых атрибутов, которые находились бы в транзитивной зависимости от первичного ключа. В отношении СТРАХОВЫЕ СЛУЧАИ присутствуют три внешних ключа: ДОГОВОР, СТРАХОВАТЕЛЬ и СОТРУДНИК. Ссылка на ДОГОВОР однозначно определяет СТРАХОВАТЕЛЯ. Также, при условии, что СОТРУДНИК, заключивший ДОГОВОР, занимается и СТРАХОВЫМ СЛУЧАЕМ, то и СОТРУДНИКА однозначно определяет ссылка на ДОГОВОР. Внешние ключи СТРАХОВАТЕЛЬ и СОТРУДНИК можно убрать. Описание групп пользователей и прав доступа Опишем для каждой группы пользователей права доступа к каждой таблице. Права доступа должны быть распределены так, чтобы для каждого объекта БД был хотя бы один пользователь, который имеет право добавлять и удалять данные из объекта. Права приведены в таблице 16. Используются следующие сокращения: – s – чтение данных (select); – i – добавление данных (insert); – u – модификация данных (update); – d – удаление данных(delete). Реализация проекта базы данных Средством разработки БД выбран MS Access 2016. Отношение СОТРУДНИКИ  Отношение ТЕЛЕФОНЫ СОТРУДНИКОВ  Отношение АДРЕСА СОТРУДНИКОВ  Отношение ОТДЕЛЫ  Отношение КАБИНЕТЫ  Отношение СТРАХОВАТЕЛИ  Отношение ТЕЛЕФОНЫ СТРАХОВАТЕЛЕЙ  Отношение АДРЕСА СТРАХОВАТЕЛЕЙ  Отношение ДОГОВОРЫ  Отношение СТРАХОВЫЕ СЛУЧАИ  СХЕМА ДАННЫХ  Создание представлений (готовых запросов) Представление СТРАХОВАЯ ПРЕМИЯ Вычисляем размер страховой премии по каждому договору. Для использования данного представления для последующих представлений вычисляем поля Месяц и Год заключения договора. Для этого применяем встроенные функции Year и Month  ВЫРУЧКА ПОМЕСЯЧНО На основании представления СТРАХОВАЯ ПРЕМИЯ создаем представление для анализа выручки страховой компании помесячно. РАСХОДЫ КОМПАНИИ На основании отношения СТРАХОВЫЕ СЛУЧАИ создаем представление РАСХОДЫ КОМПАНИИ ПОМЕСЯЧНО для расчета страховых выплат помесячно. ПРИБЫЛЬ КОМПАНИИ На основании представлений ВЫРУЧКА ПОМЕСЯЧНО и РАСХОДЫ КОМПАНИИ Представление ПРЕМИИ СОТРУДНИКОВ Предположим, что фирма ежемесячно выплачивает премии сотрудникам в размере 5% от выручки от заключенных договоров. CУБД MS Access для удобства и эффективности работы с СУБД позволяет создавать Формы отображения данных Форма данных СОТРУДНИК – ДГОВОР  Разработка стратегии резервного копирования Интенсивность обновления разработанной базы данных низкая, поэтому для обеспечения сохранности вполне достаточно проводить полное резервное копирование БД раз в день (перед окончанием рабочего дня). Для разработанной БД нет необходимости держать сервер включенным круглосуточно, поэтому можно создать соответствующее задание операционной системы, которое будет автоматически запускаться перед выключением сервера. |