Информационное моделирование 2
Информационное моделирование для меня означает процесс описания предметной области или построения модели предметной области в том виде или формате, который, с одной стороны, легко воспринимается человеком, и, с другой стороны, легко может быть преобразован в набор элементов информационного хранилища, программных компонентов и других составляющих прикладного программного обеспечения. Чаще всего термин информационное моделирование можно видеть в контексте описания процесса построения ER диаграмм или UML диаграмм. Существует мнение, что именно эти нотации наиболее удобны для описания модели целевой предметной области перед тем, как воплотить задуманное в виде информационной системы. Как минимум, на счет ER диаграмм у меня есть ряд возражений. Время идет, и многие методики и подходы требуют усовершенствования или замены.
ER диаграммы предназначены в основном для того, чтобы описать структуру реляционной базы данных, которая играет роль информационного хранилища для большей части программных продуктов. Это обстоятельство серьезно ограничивает возможности аналитика, поскольку он вынужден переносить ограничения, присущие реляционной базе данных на свою модель. Иными словами, абстрагироваться от особенностей организации хранения данных в полной мере не удается. Абстракция без лишних ограничений – это залог создания наиболее гибких и адекватных информационных моделей. Немного поясню, что я имею в виду. ER диаграмма – это набор “плоских” сущностей и связей между ними. Под термином “плоский” я понимаю представление моделируемого объекта в виде его названия и характерного для него набора свойств, что однозначно сопоставляется с таблицей реляционной базы данных и ее набором полей.
Нельзя к объектам относиться так примитивно, даже если разрабатываемый программный продукт должен решать достаточно простые задачи. Рассмотрим простейший пример – программный продукт, который должен обеспечивать информационную поддержку персоналу компании, торгующей недвижимостью, в частности, квартирами. Представление квартиры в виде одной сущности весьма проблематично, поскольку, помимо таких параметров, как возраст объекта, общая и жилая площадь, клиентов интересуют параметры каждой отдельной комнаты.
Получается, что комнату необходимо выделять в отдельную сущность. А если речь идет о загородной недвижимости или многоэтажных квартирах, то этаж также становится отдельной промежуточной сущностью в модели. С одной стороны вроде бы ничего “криминального”, но в итоге мы получаем, что наша модель состоит как из независимых объектов (дом, квартира), так и из объектов, которые сами по себе существовать не могут (этаж, комната). ER диаграмма не позволяет выходить за пределы измерений “плоского мира” реляционной базы данных. Помимо самих структур данных аналитик также обязан определить правила обеспечения целостности данных: например, при удалении записи о квартире из базы данных должна также исчезнуть информация обо всех ее комнатах – что логично с точки зрения здравого смысла на языке ER диаграмм требует дополнительного описания. Про “искусственные” сущности, которые используются для моделирования связей типа “многие ко многим” вообще отдельный разговор. Иными словами, моделировать предметную область средствами ER диаграмм – малоэффективное занятие.
ER диаграммы предназначены в основном для того, чтобы описать структуру реляционной базы данных, которая играет роль информационного хранилища для большей части программных продуктов. Это обстоятельство серьезно ограничивает возможности аналитика, поскольку он вынужден переносить ограничения, присущие реляционной базе данных на свою модель. Иными словами, абстрагироваться от особенностей организации хранения данных в полной мере не удается. Абстракция без лишних ограничений – это залог создания наиболее гибких и адекватных информационных моделей. Немного поясню, что я имею в виду. ER диаграмма – это набор “плоских” сущностей и связей между ними. Под термином “плоский” я понимаю представление моделируемого объекта в виде его названия и характерного для него набора свойств, что однозначно сопоставляется с таблицей реляционной базы данных и ее набором полей.
Нельзя к объектам относиться так примитивно, даже если разрабатываемый программный продукт должен решать достаточно простые задачи. Рассмотрим простейший пример – программный продукт, который должен обеспечивать информационную поддержку персоналу компании, торгующей недвижимостью, в частности, квартирами. Представление квартиры в виде одной сущности весьма проблематично, поскольку, помимо таких параметров, как возраст объекта, общая и жилая площадь, клиентов интересуют параметры каждой отдельной комнаты.
Получается, что комнату необходимо выделять в отдельную сущность. А если речь идет о загородной недвижимости или многоэтажных квартирах, то этаж также становится отдельной промежуточной сущностью в модели. С одной стороны вроде бы ничего “криминального”, но в итоге мы получаем, что наша модель состоит как из независимых объектов (дом, квартира), так и из объектов, которые сами по себе существовать не могут (этаж, комната). ER диаграмма не позволяет выходить за пределы измерений “плоского мира” реляционной базы данных. Помимо самих структур данных аналитик также обязан определить правила обеспечения целостности данных: например, при удалении записи о квартире из базы данных должна также исчезнуть информация обо всех ее комнатах – что логично с точки зрения здравого смысла на языке ER диаграмм требует дополнительного описания. Про “искусственные” сущности, которые используются для моделирования связей типа “многие ко многим” вообще отдельный разговор. Иными словами, моделировать предметную область средствами ER диаграмм – малоэффективное занятие.