Оглавление
Если интересы читателя совпадают с интересами автора данной статьи, то он, как и автор, должен быть заинтригован выходом на рынок моделирования данных продукта компании Rational. Компания Rational распространила свой продукт Rose на область моделирования данных с использованием нотации UML (Унифицированный язык моделирования) в отличие от традиционно используемых нотаций, таких как IDEF1X и Information Engineering (IE). Стоит ли тратить время на изучение моделирования данных с использованием UML? Анализируя продукт компании Rational - Rational Rose Data Modeler, основанный на UML, автор изучил данный и связанные с ним вопросы.
Но что же делает UML более подходящим для моделирования данных по сравнению с традиционными нотациями IDEF1X или IE? Во-первых, большинство больших компаний имеет группу, работающую с базами данных, которая отделена от группы разработчиков. Подобная структура команды позволяет оптимально использовать время аналитиков данных (DA) и администраторов баз данных (DBA), но не повышает эффективности работы команды над проектом. Кроме того, соперничающие идеи по поводу качества данных и эффективности приложения реализуются в виде средств анализа, которые разрабатываются разными группами на основе различных case-средств, с применением различных нотаций. Автор наблюдал именно такой сценарий при работе с предыдущим клиентом. Группа сопровождения базы данных имела в своем составе аналитиков данных, обязанностью которых было моделирование данных и проектирование базы данных. Аналитики данных для документирования требований к данным в виде логических и физических моделей использовали, в основном, ERwin . Команды разработчиков приложений, с другой стороны, использовали Rational Rose для создания средств анализа и проектирования. Для разработчиков были понятны их диаграммы классов, но они выставляли на первый план диаграмму связи сущностей, после чего аналитики бледнели. Средство моделирования данных Rose предназначено для решения этой проблемы на основе построения всех моделей с помощью нотации UML. Что касается Rational, то при создании приложения и средств проектирования с использованием одной и той же нотации "взаимодействие будет более согласованным, исчезнут барьеры между группами разработчиков, что позволит повысить качество и снизить риск появления ошибок".
Второе важное преимущество продукта Rose вытекает из его возможностей по моделированию процессов. Вместо того чтобы сохранять хранимые процедуры, триггеры и код в базе данных, Rose позволяет моделировать код базы данных аналогично коду приложений. Представьте себе полный набор средств анализа приложений и проектирования, включающий все присоединенные процедуры с сохранением целостности на уровне ссылок и загружаемые присоединенные процедуры!
Начнем с заявления о том, что все аналитики данных должны изучить UML. Учитывая большое количество разрабатываемых объектно-ориентированных проектов, аналитики данных, которые, не способны работать с UML, быстро окажутся не у дел. Спецификацию UML 1.3 можно загрузить с сайта Rational. Важно помнить, что UML был разработан, имея в виду процессы и данные, а не только данные. Поэтому UML весьма гибок и расширяем, что позволяет справляться с моделированием сложных бизнес-процессов. Для моделирования данных необходимо только подмножество спецификации UML. К сожалению, совершенно неочевидно, что является излишним, и что нет. Это ясно из следующего примера. При моделировании данных используются два типа связей, оба отражают ясные бизнес-отношения:
| Идентифицирующая связь | Сущность-потомок зависит от порождающей сущности и не может существовать без нее |
| Неидентифицирующая связь | Сущность-потомок не зависит от порождающей сущности. |
В UML существует много нюансов взаимосвязей, которые имеют больше значения, чем просто идентификация. Они отражают зависимость и позволяют осуществлять управление. На приведенном рисунке 1 сущность CUSTOMER позволяет управлять или ссылаться на сущность ORDER. Стрелка указывает на управление.
Рис. 1. Фрагмент модели класса
На рис. 2 показана модель данных, построенная прямым проектированием.
Рис 2. Трансформированная модель данных
Оказывается, что таблица ORDER имеет ссылку (т. е. внешний ключ) на таблицу CUSTOMER. Стрелка навигации, показанная в модели класса, не имеет отношения к модели данных и только скрывает значимые объекты в модели.
Фрагмент модели, приведенный на рис. 3, относится к той же самой модели с сущностью ORDER, связанной отношением с сущностью CUSTOMER.
Рис 3. Фрагмент модели класса
Как можно видеть в модели данных, построенной прямым конструированием, направление управления на трансформированную модель данных (рис. 4) влияния не оказывает. (И автор даже не будет придираться к тому, почему изменилось количество элементов с 0..n в модели класса на 0..* в модели данных).
Рис. 4. Трансформированная модель данных
Автор мог бы смириться с этой проблемой, так как она не влияет на точность модели данных. Но что же относительно тех проблем, которые существенны при работе с данными, но недопустимы при работе с процессами. В приведенном ниже фрагменте модели (рис. 5) показаны две новые сущности, AIRPLANE и SEAT.
Рис. 5. Фрагмент модели класса с Composite Aggregation Relationship
В этом случае вместо ассоциации возникает составная агрегация. В терминах моделирования данных составная агрегация преобразуется в идентифицирующую связь. Так случилось, что автор неумышленно поместил символ зависимости не на том конце связи. Это означает, что AIRPLANE представляется зависящим от SEAT, в то время как SEAT зависит от AIRPLANE. Автор, однако, сумел правильно обозначить связь. Он смог даже добавить направление управления, но уже ясно, что это может дать! Не пытайтесь изобразить данную структуру в ERwin, так как это невозможно.
Автор преобразовал модель класса Rose в модель данных. Результаты приведены на рис. 6.
Рис. 6. Трансформированная модель данных с идентифицирующей связью
Несмотря на то, что элементы отношения свидетельствуют, что сущность AIRPLANE является порождающей, обратное отношение зависимости обуславливает миграцию первичного ключа сущности SEAT (T_SEAT_ID) "вниз" на отношение сущности AIRPLANE. Для обострения ситуации компания Rose решила изменить количество элементов отношения SEAT с 0..n (0, 1, или более) на 0..1 (0 или 1). Может случиться, что Rose распознает, тот факт, что количество элементов отношения, превышающее единицу, противоречит спецификации UML 1.3, или, возможно, это свидетельствует о том, что невозможно поддерживать отношение 0..n через внешний ключ. Остались вопросы относительно составного первичного ключа для AIRPLANE, где один из столбцов (T_SEAT_ID) нулевой. Последний раз автор убедился, что Oracle не может реализовать нулевой столбец внешнего ключа для первичного ключа.
Итак, отношение не зависит от времени, как и управление. В ассоциациативных отношениях зависимость является минимальной, но в идентифицирующей связи зависимость указывает на порождающую сущность, независимо от количества элементов отношений. Автор приписывает этот тип ошибки попыткам Rose сделать все и для всех. Автор, кроме того, считает, что Rose не совсем точно реализует спецификацию UML. Другими словами, Rose предоставляет структуры модели данных, которые не могут быть реализованы в виде реляционной базы данных.
Продукт Rose является прекрасным средством программного моделирования. К сожалению, когда дело доходит до моделирования данных, то оказывается, что он еще не совсем готов для этого. Богатая спецификация UML из преимущества фактически превращается в недостаток, когда дело доходит до моделирования данных. Хотя Rose обладает некоторыми преимуществами при моделировании кода базы данных и повышает эффективность корпоративной разработки, автор, тем не менее, рекомендует использовать для построения баз данных проверенные методики IDEF1X и IE. В данной статье автор лишь коснулся некоторых проблем. В следующей статье будет дан более глубокий анализ различий логического и физического моделирования в Rose и ERwin. Помните золотое правило: "Информация - это капитал".