Моделирование данных и XML

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

• Моделирование информации (понимание структуры и назначения информации, содержащейся в документах);
• Проектирование документа (трансляция информационной модели в набор правил или схем для создания фактических документов);
• Нотации схем (методы записи проекта документа, чтобы он был доступен как для обрабатывающего его программного обеспечения, так и для пользователя-человека).

Моделирование информации

Информационная модель - это описание используемой организацией информации, не зависящее от какой бы то ни было информационной технологии.

• Каким образом она структурирована?
• Что она означает?
• Кому она принадлежит, и кто отвечает за ее своевременность и качество?
• Откуда она берется и что происходит с ней в конце?

Моделирование информации имеет такое значение, потому что без модели нет информации, есть только данные. Информационная модель описывает назначение данных.

Любое информационное моделирование преследует две цели, которые не всегда бывает легко сочетать:

• Получение абсолютно точных определений
• Эффективная коммуникация с пользователями

Существуют два основных типа информационной модели: статическая и динамическая.

В статической модели описываются допустимые состояния системы. В статических моделях описываются типы объектов в системе, их свойства и связи. Описывая объекты, они определяют, разумеется, и их имена. Достичь соглашения по именованию всех объектов означает выиграть половину битвы, именно поэтому информационные модели XML иногда называют словарями.

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

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

Язык XML, разумеется, может использоваться для представления в системе данных обоих типов - документов и сообщений. Тем не менее, в любом проекте системы необходимо рассмотреть как статические, так и динамические модели, причем оба типа моделей одинаково важны. Лучше начинать работу со статической модели. Отчасти это связано с тем, что именно в ней определяется базовая терминология, а еще с тем, что модели статической информации являются наиболее долговечными аспектами любой информационной системы.

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

Документы и данные

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

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

Сеть Web объединила эти миры. Язык XML стал первым примером технологии, одинаково применимой в обоих случаях.

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

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

Статическая информационная модель

При построении статической информационной модели необходимо пройти следующие этапы:

Этап 1. Идентификация понятий, присвоение им имен и их определение

Этап 2. Организация понятий в иерархию классов

Этап 3. Определение связей, множественности и ограничений

Этап 4. Добавление свойств для конкретизации деталей значений, связанных с объектами

Этап 1. Именование понятий

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

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

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

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

В конце этого этапа мы получим список типов объектов с именами и определениями, по поводу которых достигнуто соглашение.

Этап 2: Таксономия

Таксономия - это термин, используемый в биологии для обозначения системы классификации; в информационном моделировании ее также называют иерархией типов (иногда ее называют еще онтологией). Перечислив и назвав типы объектов, их надо организовать в иерархическую схему классификации. Часто эти иерархические отношения возникают уже на этапе определения типов объектов.

Ключевой здесь является фраза, определяющая принадлежность (в английском языке - is или is kind of). Написав предложение вида "А есть разновидность В" или "Каждое А есть В", вы определили отношения подтипов в вашей таксономии.

Иногда эти действия называются тестом "is а" ("есть", "представляет собой"). Однако будьте внимательны, поскольку эта конструкция используется также и для описания отношений между конкретным экземпляром и его типом, безопаснее писать этот тест в форме "is a kind of" ("представляет собой разновидность").

Идентификация подтипов бывает полезна при проектировании документа, что более важно, она помогает лучше понять определения типов объектов.

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

Итак, этап 2 сводится к организации типов объектов в иерархию типов.

Этап 3: Поиск связей

После того как объекты названы, в статическом информационном моделировании надо определить связи, существующие между ними. Связи (на языке UML они называются ассоциациями) можно показать просто сформулировав их в виде обычных предложений или их можно показать графически в виде диаграммы. Для диаграмм, описывающих связи между объектами, существует большое количество нотаций, каждый может выбрать более предпочтительную для себя. Диаграммы следует делать предельно простыми и интуитивно понятными, сосредоточившись на ключевых сообщениях и оставив подробности текстовым документам, которые проще обслуживать.

Существует некая информация, которую надо знать о каждой связи:

1. Множественность связи показывает сколько объектов каждого типа может принимать в ней участие.
   • Связи типа "один-ко-многим": одна глава содержит много параграфов, один человек покупает много туристических поездок.
   • Связи типа "многие-ко-многим" также часто встречаются: один автор может написать несколько книг, но у книги также может быть несколько авторов.
   • Связи типа "один-к-одному".
2. При моделировании информации для окончательного представления XML особенно важным типом связей являются связи включения. Множественность этих связей всегда бывает "один-ко-многим" и "один-к-одному". Хотя четкого правила по поводу того, какие объекты образуют связи включения, не существует, можно иногда использовать правила обычного языка: глава содержит параграфы, курорт содержит отели, а отель содержит посетителей. В языке UML определено две формы связей включения. Первая - это агрегации, относительно свободное объединение объектов, позволяющее рассматривать их группу в течение некоторого времени как целое (например, туристическая группа, одни и те же люди могут в разное время входить в разные группы). Вторая форма - композиция. Это более строгая форма; отдельные части целого не могут существовать независимо от него (например, комнаты в отеле не могут существовать независимо от отеля).

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

Итак, в конце этапа 3 мы определили связи существующие между типами объектов в нашей модели.