Помогите собрать Схему для БД по страхованию

[ju4ek]

Здравствуйте!

Я на форуме совсем недавно
Хотел бы попросить мне помочь со схемой данных
Немного накидал схемку, она в приложенном рисунке, а также в файле аксеса.
Я делаю диплом на эту тему, в страховании разбираюсь хорошо, сдал на 5 балов его.
Мне нужно только автострахование - КАСКО и ОСАГО.
а в лучшем случае помимо основной БД, необходимо сделать авторизацию и разбиение по уровням доступа к информации.

может, кто уже разбирал эту тему.
Заранее благодарю за советы

[Oldy]

Для начала надо-бы определиться с сущностями.  Затем с их атрибутами. Потом можно взяться за связи. Ну и не след. забывать и бизнес-логику.

Для примера:
Сущность "Страхователи" - могут быть а)физические лица, б)юридические лица. Отсюда следует, что нужны разные атрибуты.
"Физические лица" - могут быть как граждане РФ так и прочих государств. У граждан РФ могут быть как паспорта, так и удостоверения личности (военнослужащие). Что может быть у граждан прочих государств, один Бог ведает.
Примерно так-же пройтись по юридическим. Там думаю остались привилегированные (скажем бюджетники), так и прочие.   
Ну и так далее.

[Dimka]

ju4ek, а какие у базы данных категории пользователей и какие уровни доступа этих категорий?

[ju4ek]

Спасибо за отклик о помощи)

мной решено делать БД исключительно по ОСАГО, не задевая остальные виды страхования
т.к. создавать калькуляцию по остальным видом страхования для многих страховых нереально, т.к. они у всех отличаются, и необходимые данные им нужны разные.
а ОСАГО - это общий вид страхования у всех страховых.
в общем, делаю БД по калькуляции и хранению ОСАГО.
вот мной была сделана схема. скажите свое мнение?
благодарю

[Dimka]

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

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

Если так сделать, то сущность "Водитель" окажется добавкой к физическому лицу (очевидно, юридические водителями быть не могут), что, опять же, позволит не дублировать ФИО, а хранить его в одном месте.

Это делается для того, чтобы внутри базы сохранялась целостность данных. Иначе возможно внести изменения в одну запись и забыть поменять дубликат информации в записях других таблиц - так разрушается целостность.


Теперь о логике.

Меня смущает отношение 1 водитель ко многим заявлениям. Если водитель - не собственник транспортного средства (например, юр.лицо), то по идее у одного транспортного средства может быть много водителей (например, у рейсового автобуса). По твоей схеме получается, что с каждым водителем связано отдельное заявление на то же самое транспортное средство с одним и тем же страхователем и владельцем. Это действительно так?

Меня смущает отношение 1 полис ко многим заявлениям. Это действительно так, или просто в Access нет отношения 1 к 1? Вот как раз для таких случаев лучше показывать не физическую модель БД, а её логическую модель.

Полис связан с заявлением или с транспортным средством?

По идее, с каждым полисом ещё может быть связан выгодоприобретатель в отношении... думаю, 1 полис ко многим выгодоприобретателям - бывают же ДТП, в которых один сталкивается со многимим. Кроме того, наверно, должны как-то сохраняться документы с описанием ДТП, оценками стоимости ремонтов/лечения, информация о других участниках ДТП и т.п. вещи, связанные с расчётом суммы выплаты и страховщиками других участников.

Таково моё мнение и мои сомнения.