|
|
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Необходимо создать базу данных для страховой компании. Одна из подзадач - учет договоров. У меня никак не удается грамотно связать сущности (построить грамотную структуру базы). Есть такие сущности: Договора Дополнительные договора Застрахованные Договора заключаются на определенный срок и есть сумма оплаты по этому договору. У каждого договора есть дополнительные договора, которые изменяют договор (срок действия договора, добавляются или убираются застрахованные по этому договору). Дополнительные договора являются в принципе той же сущностью, что и договора, но необходимо знать какой договор они изменяют. Так же в доп. договорах изменяется состав застрахованных. Застрахованные могут быть застрахованы по договору или по доп. соглашению Мысли вслух: если не выделять доп. договора в отдельную таблицу, то в таблице договора надо вносить поле "Номер доп. договора", поле "Тип договора" и в принципе может получиться вариант, что договор ссылается сам на себя (так называемая циклическая ссылка). Кроме того дополнительные договора могут изменять сам договор, но также нужно хранить все изменения, которые вносят доп. соглашения в договор. К примеру, на 20е Апреля сколько человек было застраховано? Хелп, плиз, запутался :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 17:32 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
1) разберемся с теминологией давайте говорить не застрахованные, а - объекты страхования 2) ситему договоров действительно лучше держать в одной таблице причем в иерархической, каждый документ, если у него есть родительский документ - это доп соглашение(доп.договор) 3) объекты страхования могут не только добавляться, но и удаляться 4) необходима система триггеров, ХП, и CHECK CONSTRAINT-ов для поддержки целостности и актуальности данных. 5) Только этими сущностями - Договорами, Объектами страхования и пр. не обойтись. Понадобятся и прайсы ЛПУ и пр.ипр. Учет страховых премий, и многое другое. ИМХО страхование - самая сложная область относительно проектирования бд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 18:31 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ По пунктам: 2) Не могли бы вы пояснить на примере, что есть иерархическая таблица? Как быть тогда с циклическими ссылками (договор ссылается сам на себя как на доп соглашение). Не будет ли такая структура противоречить правилам нормализации? 4) это понятно, куда ж без целостности и актуальности данных :) 5) В данный момент меня интересует именно решение этой подзадачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 18:41 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
авторИМХО страхование - самая сложная область относительно проектирования бд. Абсолютно верно На основе своего и зарубежного опыта Структура БД для страхования - разрабатывается не один год При этом даже после 3-х лет все равно не удовлетворяет всем требованиям функциональности (не говоря о нормализации и целостности) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 18:51 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
У нас сейчас в модели ~500 таблиц. Причем сделано все не лучшим образом) Я бы делал по-другому. Если писать все, получится достаточно толстая книга. > договор ссылается сам на себя как на доп соглашение - если не сложно, приведите пожалуйста пример, когда это нужно?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 18:53 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Слабо знаю предметную область, но предполагаю, что тут можно иметь два варианта. 1. Каждый допдоговор рассматривается, как новый, и в него переносятся все участники предыдущего договора. С нужными иключениями/дополнениями. 2. У каждого участника договора есть отношение к номеру договора, его личному вступлению в договор и его выхода из договора. Т.е. должна быть история договоров и их условий, привязанная к конечному участнику. Способ 2, на мой взгляд, лучше. Блин. Написал очень путано. Попробую, несмотря на Пятницу разъяснить. Каждый участник имет интервал дат, в котором он иммеет право на исполнение договора. От конкретной, до NUUL, что значит, что договор еще действует. Каждыый договор (допдоговор) тоже имеет интервал действия. Нужно отслеживать попадание интервала действия договора клиента в интервал действия условий договора, и высчитывать эти условия. Кажется, я еще больше запутал. На самом деле, все просто. Но словами этого я сделать не могу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 19:10 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Прошу прощения, дата окончания договора может быть, конечно, и конкретной, а не только NULL. Может быть я только со своими мыслями спорю? =============== Полностью согласен с gardenman, что плясать надо от объекта страхования. А все остальное - надстройки. ========= У меня запущена сходная база. Расчет населения за электроэнергию. Тарифы действуют от сюда до сюда, льготы действуют от сюда до сюда, право на льготы действуют от сюда до сюда, соцнормы - от сюда до сюда, счетчик стоит от сюда до сюда. Абонент проживает от сюда до сюда. По сравнению c этим - страховая база - пыль для пограничника ========= Иерархическаих таблиц не бывает. Бывают иерархические базы даных. Данная задача вполне может быть решена в рамках реляционых баз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2004, 20:32 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
То Сат2 ... Вот расчет за электро энергию как раз и фигня полная , плавали знаем ... А вот рекурсивные (но не иерархические ;-) ) таблицы на самом деле весьма любопытная штука .. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 09:25 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 09:55 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
2 Dyadya Zed 1. А эта БД является больше аналитической или оперативной? 2. Какие требования: -- к скорости удаления/обновления/изменения записей -- к времени отклика при формировании отчетов -- к историчности данных (запоминаем ли предыдущие состояния информационных объектов - полей записи, записей и т.п.) -- количеству доступных отчетов и сложности их создания? 3. Какие планируются объемы данных? Почему спрашиваю: Если больше нужна историчность и аналитика, то можно провести денормализацию (в разумных пределах конечно), что затруднит (в плане программирования) работу по изменению записей в БД, но даст прирост в скорости при создании аналитических отчетов. Так же это повлияет на выбор в плане использования таблиц со связью "сам-на-себя", т.к. для аналитики это - не лучший вариант. ------------ Best regards, Jimmy ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 10:22 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
2Dyadya Zed: в таком контексте ничего сложного таблица договора: ид договора ccылка на родительский договор атрибуты договора (тип договора, дата заключения и тп) таблица детализация договора: ид строки ид договора атрибуты (например, максимальное кол-во застрахованных) таблица объекты страхования: ид объекта ид договора дополнительные атрибуты -------------------------------- потом определяемся с историчностью данных если хочется все сделать просто, то для хранения всех измений создаем протокольные таблицы в которые триггером или просто сами сваливаем всю информацию для таблицы договора: время изменения операция (insert, delete, update) пользователь новая строка полностью из табл договора соответственно всю историю изменений можно увидеть в этой протокольной таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 11:02 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Все что тут написано - всего лишь верхушка айсберга. Дополнительно можно озвучить следующие направления учета, которые нужно анализировать в разрезах страхователя, вида страхования, типов объектов страхования, типов рисков -Поступившая премия -Заработанная премия -Полученная премия (выписка счетов, рассрочки, контроль оплаты...) -Агентское вознаграждение -Перестрахование (облигаторное, факультативное, и куча всяких подтипов, целую книжку написать можно) (взаиморасчеты по перестрахованию) -регресы (и платежи по ним) -учет убытков и платежей по убыткам Что касается доп.соглашения, то этот документ может менять в договоре почти всё - начиная от тарифов кончая и ставки агентского вознаграждения, кончая обектом страхования и страхователем. Осложняется все еще тем, что законодательство (как и что учитывать ) по страхованию еще только формируется (в отдичии от банковской сферы, где есть незабываемая 61 инструкция) Кстати, многие подходы, которые наработаны в банковской сфере могут быть применены здесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 12:27 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Браво gardenman... Я уж думал, что никто толком и не понимает прелести доп. соглашений и что все просто "зациклились" на деревянной ссылке Я б конечно предложил не париться и просто систему купить, но стоящей системы пока ни одной не видел... Предлагать народу довести до ума хоть одну "слепленную" - наверное бесполезно. Посему могу только предложить всеж таки посмотреть что было сделано и задавать вопросы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2004, 13:24 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
2 Dyadya Zed У меня была похожая ситуация, только в другой предметной области - Производство. В моем случае могли меняться рецептурные карты продукции. Было сделано следующее: 1. Составлен список основных рецептов (в твоем случае это может быть список договоров) 2. Протоколировались все изменения и периоды их действия (естественно, изменения разбивались по типам; в твоем случае это могут быть таблицы для фиксирования изменений длительности договора, числа застрахованных и т.д.) 3. В отдельный файл (аналогичный списку основных рецептов) процедурой собиралось текущее состояние рецептурной карты. Для этого на определенную дату сканировались по всем протоколам изменений действовавшие на эту дату изменения и происходило физическое замещение исходных данных указанными в протоколах. Надеюсь моя идея тебе поможет.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2004, 07:11 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Спасибо за помощь.. Сделал сам, очень похоже на вариант от Simon. Действующий договор будет полностью "вычисляемым" на основе данных доп. соглашений. Если реализовать грамотно, то можно будет просматривать действующие отношения на любой срок вперед или назад. За идею с атрибутами спасибо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2004, 11:49 |
|
||
|
грамотная структура базы (сложно)
|
|||
|---|---|---|---|
|
#18+
Вычисление договора - вещь хорошая, но советую посмотреть это под нагрузкой. Боюсь что на 100 тыщ договорах. У каждого в среднем по 2-5 допов это будет тормозить безбожно. Хотя надо конечно смотреть реализацию :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2004, 15:27 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32495021&tid=1546513]: |
0ms |
get settings: |
4ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
153ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 425ms |
| 0 / 0 |
