Построение концептуальной модели для информационно-управляющих систем

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

Рассмотрим процесс построения концептуальной модели коммерческого банка. Предположим, в процессе управления банком главный менеджер должен оперативно получать ответы на следующие вопросы: Сколько у нас текущих счетов? Сколько сберегательных счетов? Сколько кли­ентов? У каких клиентов есть и текущие, и сберегательные счета? Каков про­цент сберегательных счетов, баланс которых не превышает 1000 долларов? Какой тип клиентов имеет самый высокий средний баланс счетов? Сколько клиентов помимо обладания текущими и сберегательными счетами брали у нас ссуды?

У банка есть текущие счета, сберегательные счета и клиенты. Мы установим подходящие отношения между ними, как пока­зано нарис. 19.

Рис. 19. Модель данных банка: основные объекты и отношения

Сейчас мы рассматриваем следующие вопросы:

Сколько у нас текущих счетов?

Сколько сберегательных счетов?

Сколько клиентов?

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

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

У кого из клиентов есть и текущие счета, и сберегательные?

На этот вопрос можно ответить только рассмотрев отношения. У клиента есть текущий счет, если он (или она) связан посредством отношения ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ с некоторым элементом объектного множества ТЕКУЩИЙ-СЧЕТ. Аналогично, у клиента есть сберегательный счет, если он связан посредством отношения ИМЕЕТ-СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ с некото­рым элементом объектного множества СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ. Наконец, у клиента есть и текущий счет, и сберегательный, если он связан посредст­вом обоих этих отношений с некоторыми элементами объектных множеств ТЕКУЩИЙ-СЧЕТ и СБЕРЕГАТЕЛЬНЫЙ-СЧЕТ. Для того чтобы ответить на предыдущийвопрос, нам нужно просто подсчитать число клиентов, имею­щих обе связи.

Мощности. На рис. 19 были намеренно опущены мощности отноше­ний. Давайте займемся ими теперь. Допустим, мы определили мощности, как показано на рис. 20. Они означают, что у клиента не может быть более одного текущего или сберегательного счета. Каждый счет принадлежит ровно одному клиенту.

Рис 20. Мощности отношений банка

Однако такие мощности могут не отражать действительное положение вещей. Рассмотрим мощность со стороны объекта ТЕКУЩИЙ-СЧЕТ. Владеет ли каждый клиент только одним текущим счетом? АВТ, как и большинство банков, позволяет своим клиентам открывать несколько текущих счетов, однако мощности на рис. 20 этого не позволяют.

Теперь посмотрим на остальные мощности. Реально ли предположить, что счет может относиться к нескольким клиентам? Это тоже вполне веро­ятно, поскольку общие счета — мужа и жены или родителей и детей — весьма широко распространены. Для того чтобы отразить наше более точное восприятие действительности, мы исправили рис. 20 (рис. 21).

Рис. 21. Пересмотренные мощности отношений банка

Модель на рис. 20 неверна, поскольку не отражает наше представление о реальном банке. Для другого представления реальности модель, приведенная на рис. 20 может оказаться верной. Например, банк может позволить клиентам открывать только один текущий счет и запретить совместные счета. В этом случае рис. 20 будет верно отражать реальность такого банка. Модель верна или неверна только в том смысле, правильно ли она отражает реальность, в которой мы заинтересованы.

Обратившись к модели на рис. 21, мы можем теперь ответить на до­полнительные вопросы:

У скольких клиентов по несколько текущих счетов?

Сколько у нас общих счетов?

Сколько обладателей нескольких текущих счетов имеют также сберегательные счета?

Давайте посмотрим, как ответить на первый из этих вопросов. Клиент обладает несколькими текущими счетами, если он связан посредством отно­шения ИМЕЕТ-ТЕКУ ЩИЙ-С ЧЕТ как минимум с двумя элементами объект­ного множества ТЕКУЩИЙ-СЧЕТ. Мы ответим на первый вопрос, рассмот­рев каждый элемент множества КЛИЕНТ и проверив, имеет ли он такие связи, и подсчитав число таких элементов. Мы рекомендуем вам попытаться рассмотреть процесс поиска ответов на все сформулированные вопросы с по­мощью передвижений по диаграмме на рис. 21.

Конкретизация клиентов банка. Всегда ли клиентами банка являются люди? Клиентами банка могут быть организации: коммерческие предпри­ятия, некоммерческие организации, церкви, правительственные учрежде­ния. Хочет ли менеджер различать типы клиентов? Да, поскольку у разных типов клиентов могут быть разные атрибуты. Кроме того, их счета могут обладать разными характеристиками. На рис. 22 представлены две кон­кретизации объекта КЛИЕНТ, ФИЗИЧЕСКОЕ ЛИЦО, разумеется, включает клиентов-людей. ЮРИДИЧЕСКОЕ ЛИЦО объединяет клиентов-организации.

Рис. 22. Конкретизации объекта КЛИЕНТ

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

Рис. 23. Атрибуты типов клиентов

Давайте, модифицируем рис. 21, отразив конкретизации объекта КЛИЕНТ. Наша модификация представлена на рис. 24, который является комбинацией рисунков 21 и 23. (На этом рисунке мы опустили ромбы при обозначении отношений. Впредь мы обычно будем их опускать.) Мы также добавили атрибут БАЛАНС к каждому объектному множеству счетов.

Рис. 24. Счета клиентов разных типов

Теперь мы готовы ответить на несколько новых вопросов:

Каков процент сберегательных счетов, баланс которых не превышает 1000 дол­ларов? Какой тип клиентов имеет самый высокий средний баланс счетов?

Ответ на второй вопрос зависит от того, что мы подразумеваем под «типом клиента». Структура нашей базы данных позволяет нам различать физические лица и юридические лица. Мы также можем определить отли­чия внутри объекта ЮРИДИЧЕСКОЕ ЛИЦО с помощью атрибута ТИП ОРГАНИЗАЦИИ. Например, типом организации может быть Коммерческое Предприятие, Некоммерческая Организация, Церковь или Правительствен­ное Учреждение. Для того чтобы ответить на второй вопрос, мы начнем с объекта ФИЗИЧЕСКОЕ ЛИЦО и перейдем от него, минуя объект КЛИЕНТ, к объекту ТЕКУЩИЙ-СЧЕТ через ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ. Мы проделаем это для каждого физического лица, записывая баланс. Закончив с физическими лицами, мы подсчитаем средний баланс физических лиц. Затем мы проделаем все то же самое с юридическими лицами. Для того чтобы ответить на наш вопрос, нужно только сравнить два результата.