Пример создания сложной IDEF1X модели

В качестве примера создания модели данных ИС рассмотрим процесс создания базы данных на основе модели потребительского кредитования.

В результате проведенного анализа, были сформированы следующие сущности:

- Заемщик

- Банк

- ПлатежиЗаемщика

- Документы

- ВыдачаКредита

- ПервоначальныйВзнос

- ЧерныйСписокЗаемщиков

- Договор

- ДоговорПоручительства

- НачисленныеПроценты

- СчетСсудный

Определим связи между этими сущностями и построим начальную ER диаграмму. В результате анализа взаимоотношений сущностей была построена следующая диаграмма

Рис. 23. Диаграмма «сущность-связь» модели Потребительское кредитование

Практически все элементы этой диаграммы не нуждаются в комментариях за исключением следующих. Сущности Банк и ЧерныйСписокЗаемщиков не связаны ни с какими другими сущностями модели. Рассмотрим какими соображениями пользовался автор при создании этой модели. Сущность Банк представляет собой информацию о Банке, выдающем кредит. Хотя и планируется использование системы в рамках одного банка, но все равно необходимы его реквизиты, которые удобно хранить в отдельной таблице. Эта таблица никак логически не связана ни с одной другой сущностью рассматриваемой модели. Если же планируется использование системы в разных банках (например филиалах), необходимо связать сущность Банк с сущностью Договор связью «один-ко-многим». Сущность ЧерныйСписокЗаемщиков предназначена для хранения информации о заемщиках, которым в будущем никогда не будет выдаваться кредит по разным причинам. Предполагается, что заемщик будет попадать в черный список путем копирования данных о нем из таблицы Заемщик. Таким образом, атрибуты сущности аналогичны атрибутам сущности Заемщик, но она не связана ни с одной другой сущностью т.к. информация о неблагонадежных заемщиках нигде (в других сущностях) не используется. Одним из вариантов организации хранения черного списка заемщиков является создание отдельного атрибута в сущности Заемщик, по значению которого было бы возможно определить входит ли он в черный список.

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

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

Рис. 24. Предварительная ключевая модель «Потребительское кредитование»

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

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

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

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

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

Рис. 25. Окончательный вариант ключевой модели системы «Потребительское кредитование»