Информационная система ОСАГО

В данной модели также учитываются ограничения, накладываемы на атрибуты, а именно:

1. Дата взноса денежных средств по договору должна быть больше или равна дате страхования.
2. Дата выдачи страхового полиса должна быть больше даты досрочно закрытия страхового полиса.
3. Дата выдачи должна быть больше срока окончания страхового полиса.
4. Дата подачи документов для выплаты возмещения должна быть больше даты выдачи страхового возмещения.
5. Атрибуты Сумма страхования ТС, Сумма остатка по страхованию, Сумма страхового возмещения за единицу должны быть положительными.

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

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

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

Такой тип связи представлен  между сущностями (Родительская - Дочерняя):

• Транспортное средство – Договор
• Сотрудник – Договор
• Страховой полис – Договор
• Клиент – Транспортное средство
• Страховой полис – Данные о ДТП

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

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

Неидентифицирующая необязательная связь представлена между сущностями:

• Консультации – Клиент (клиент может и не являться потенциальным клиентом, т.е. с ним не проводилось консультаций)

Категорийная связь. Используется для описания сложных обобщенных объектов предметной области. Под обобщенным объектом понимается объект, экземпляры которого можно разделить на несколько категорий с частично различающимися наборами свойств. Одна из сущностей является главной и определяет набор свойств, общих для всех категорий. Каждая из остальных сущностей определяет набор свойств, специфичных для определенной категории. Первичный ключ сущностей категорий совпадает с первичным ключом главной сущности. Каждый экземпляр сущности категории связан с одним определенным экземпляром главной сущности и не может существовать самостоятельно. Экземпляр главной сущности может быть связан с каким-нибудь одним экземпляром из сущностей категорий либо быть не связанным с экземплярами категорий. Если все экземпляры главной сущности связаны с экземплярами сущностей категорий, то категорийная связь называется  полной, в противном случае – неполной.

 

3.2 Физическая  модель данных

На основании разработанной  логической модели можно построить физическую модель ИС.  Графическое представление физической модели приведено на рисунке.

Рисунок 3.7 Физическая модель данных

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

Таблица 3.1

	Родительская	Дочерняя
Удаление	RESTRICT	NONE
Добавление	NONE	RESTRICT
Изменение	CASCADE	CASCADE

3.3 Физическая реализация на языке SQL

Далее приведем физическую реализацию БД на языке SQL.

 

CREATE DATABASE OSAGO USER ‘SYSDBA’ PASSWORD ‘masterkey’;

 

CREATE TABLE Данные_о_ДТП (

       №_акта_по_страховому_случаю  NUMBER NOT NULL,

       №_полиса             NUMBER NOT NULL,

       Список_документов_клиента_для_ BLOB NOT NULL,

       Дата_подачи_документов_на_выпл  DATE NOT NULL,

       Сумма_страхового_возмещения  FLOAT NULL,

     Дата_выдачи_страхового_возмещ DATE NULL,

CHECK (Дата_подачи_документов_на_выпл >

Дата_выдачи_страхового_возмещ),

PRIMARY KEY (№_акта_по_страховому_случаю),

FOREIGN KEY (№_полиса)

REFERENCED Страховой_полис

ON DELETE RESTRICT ON UPDATE CASCADE

);

 

CREATE TABLE Договор (

       №_договора           NUMBER NOT NULL,

       №_полиса             NUMBER NOT NULL,

       №_клиента            NUMBER NOT NULL,

       №_автомобиля         NUMBER NOT NULL,

       Код_сотрудника       NUMBER NOT NULL,

       Сумма_страхования_ТС FLOAT NOT NULL,

       Дата_взноса_денежных_средств DATE NULL,

       Дата_страхования     DATE NULL,

CHECK (Дата_взноса_денежных_средств >= Дата_страхования),

PRIMARY KEY (№_договора),

FOREIGN KEY (№_полиса)

REFERENCED Страховой_полис

ON DELETE RESTRICT ON UPDATE CASCADE,

FOREIGN KEY (№_клиента)

REFERENCED Транспортное_средство

ON DELETE RESTRICT ON UPDATE CASCADE,

FOREIGN KEY (Код_сотрудника)

REFERENCED Сотрудник

ON DELETE RESTRICT ON UPDATE CASCADE,

);

 

CREATE TABLE Клиент (

       №_клиента            NUMBER NOT NULL,

       ФИО_клиента          VARCHAR(40) NOT NULL,

       Дата_рождения        DATE NOT NULL,

       Адрес_проживания     VARCHAR(50) NULL,

       Серия__номер_паспорта  INTEGER NOT NULL,

       №_потенциального_клиента  NUMBER NULL,

PRIMARY KEY (№_клиента)

);

 

CREATE TABLE Консультации (

       №_потенциального_клиента  NUMBER NOT NULL,

       Дата_консультации    DATE NULL,

       ФИО_потенциального_клиента  VARCHAR(20) NULL,

       Вопросы_потенциального_клиента  BLOB NULL,

       Ответы_на_вопросы    BLOB NULL,

PRIMARY KEY (№_потенциального_клиента)

);

 

CREATE TABLE Сотрудник (

       Код_сотрудника       NUMBER NOT NULL,

       ФИО                  VARCHAR(40) NOT NULL,

       Должность            VARCHAR2(25) NOT NULL,

       Дата_рождения        DATE NOT NULL,

       Серия__номер_паспорта INTEGER NOT NULL,

       Адрес_проживания     VARCHAR(50) NULL,

PRIMARY KEY (Код_сотрудника)

);

 

CREATE TABLE Страховой_полис (

       №_полиса             NUMBER NOT NULL,

       Дата_выдачи          DATE NOT NULL,

       Срок_окончания       DATE NOT NULL,

       Закрытие_страхового_полиса NUMBER NULL

                                   CHECK (Закрытие_страхового_полиса BETWEEN 0 AND 1),

       Дата_досрочного_закрытия  DATE NULL,

       Сумма_остатка_по_страхованию  FLOAT NULL,

CHECK (Дата_выдачи > Дата_досрочного_закрытия),

CHECK (Дата_выдачи > Срок_окончания),

PRIMARY KEY (№_полиса)

);

 

CREATE TABLE Транспортное_средство (

       №_автомобиля         NUMBER NOT NULL,

       №_клиента            NUMBER NOT NULL,

       Марка__модель_ТС     VARCHAR(30) NOT NULL,

       Идентификационный_номер_тс VARCHAR(15) NOT NULL,

       Паспорт_ТС           VARCHAR(10) NOT NULL,

       Гос._регистрационный_знак VARCHAR(10) NULL,

PRIMARY KEY (№_автомобиля),

FOREIGN KEY (№_клиента)

REFERENCED Клиент

ON DELETE RESTRICT ON UPDATE CASCADE

);

COMMIT;

3.4 Выводы

Во второй главе  было произведено проектирование логической и физической модели данных, дано текстовое описание основных сущностей, атрибутов, ограничений целостности.

Также приведем физическую реализацию БД на языке SQL

Заключение

Итогом выполнения курсового проекта стала разработка ИС для страховой компании, которая предоставляет услуги по обязательному страхованию автогражданской ответственности (ОСАГО). При выполнению курсового проекта были спроектированы:

- Функциональные модели IDEF0, IDEF3, DFD в нотации пакета BPWin;

- Модели данных: логическая и физическая модели в нотации пакета ERWin;

- Обоснован выбор архитектуры системы;

 

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

Приложение А 
(обязательное) 
Библиографический список

 

1. Кислицын А.Б. Базы и банки данных: Курс лекций для студентов специальности 071900. – Киров, 2001.
2. Кислицын А.Б. Проектирование информационных систем: Курс лекций для студентов специальности 071900. – Киров, 2004.

Приложение Б 
(обязательное) 
Список принятых сокращений

 

ИС – информационная система;

БД – база данных;

ТС - транспортное средство;

ОСАГО - обязательное страхование  автогражданской ответственности;

ДТП - дорожно-транспортное происшествие