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

2. ПРОВОДИМЫЕ РАБОТЫ

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

2.1 План проведения работ по моделированию данных

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

Результаты процесса моделирования данных делятся на следующие виды.

Диаграмма. Модель данных содержит одну или несколько диаграмм. Требования на диаграм ме должны быть отражены в точной форме. Указывается выбранный уровень детализации модели (концептуальная, логическая или физическая), схема (реляционная, многомерная, объектно-ориентированная, на основе фактов, хронологическая или NoSQL) и нотация (IE, UML, объектно-ролевая модель и т. п.).

Определения. Определения сущностей, свойств/атрибутов и отношений/связей в полном объеме, необходимом для обеспечения точной реализации модели данных.

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

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

2.2 Построение модели данных

Проектируя модели, разработчики часто опираются на богатый практический опыт анализа и моделирования данных — как собственный, так и накопленный коллегами. Они могут изучать существующие модели и базы данных, выверять свои действия по опубликованным стандартам, рассматривать и учитывать всевозможные требования к данным. Изучив все входные материа лы подобного рода, проектировщики приступают непосредственно к построению модели. Мо делирование — в очень большой мере процесс итерационный (см. рис. 53). Подготовив проект модели, разработчики обращаются к бизнес-профессионалам и аналитикам за разъяснением ре альных условий и бизнес-правил. Затем, доработав и уточнив модель, они формулируют новые вопросы и снова обращаются за ответами на них к практикам и аналитикам (Hoberman, 2014).

Рисунок 53. Моделирование как итерационный процесс

2.2.1 Прямое проектирование

Прямое проектирование (forward engineering) представляет собой процесс построения нового приложения, начиная с выяснения предъявляемых к нему требований. Cначала создается CMD, чтобы понять границы и состав предстоящих работ, выработать и согласовать ключевую терми нологию. Затем создается LMD, документирующая бизнес-решение, и наконец — PMD, докумен тирующая техническое решение.

Выбор схемы. Решите, в соответствии с какой схемой — реляционной, многомерной, на осно ве фактов, хронологической или NoSQL — будет строиться модель данных. Руководствуйтесь описанными выше особенностями и критериями выбора различных схем (см. раздел 1.3.4).

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

Создание исходной CMD. Первоначальная версия CMD должна отражать точку зрения не кой группы пользователей. Это позволит избежать излишних осложнений и задержки про цесса проектирования из-за необходимости согласовывать все позиции (других подразделе ний или организации в целом).

Определите совокупность самых высокоуровневых понятий, которыми оперирует органи зация (существительные). Самые распространенные концептуальные категории отража ют Дату/Время, Географию (местонахождения/адреса), Клиентов/Участников, Продукты/ Услуги и Транзакции.

Определите совокупность действий, связывающих эти понятия (глаголы). Отношения (связи) могут быть односторонними, двусторонними (обоюдными) или многосторонни ми, то есть связывающими более двух понятийных категорий. Примеры: одному Клиенту может соответствовать несколько Местонахождений (по домашнему адресу, месту работы и т. д.); а одному и тому же Местонахождению — много Клиентов. Транзакции соответ ствуют Время и Функция, а Клиенту при продаже — Продукт или Услуга.

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

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

2.2.1.2 ЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ ДАННЫХ

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

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

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

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

Во многих организациях установлены строгие формальные требования. Проектирование может происходить под руководством начальства, требующего соблюдения правил вплоть до порядка слов в формулировках, например: «Система должна поддерживать…» В таких случаях полезно управлять письменными инструкциями и спецификациями требований к данным с по мощью специализированных программных средств управления требованиями. Спецификации, собранные и обобщенные в результате анализа содержания всевозможной регламентирующей документации, должны тщательно синхронизироваться с требованиями к данным, зафиксиро ванными в моделях, что позволяет значительно упростить анализ влияния и получение ответов на вопросы вроде: «Где именно в моей модели учтено или реализовано требование X?» или «На каком основании в модель включена сущность Y и почему именно в этом месте?»

2.2.1.2.2 АНАЛИЗ ИМЕЮЩЕЙСЯ ДОКУМЕНТАЦИИ

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

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

2.2.1.2.3 ДОБАВЛЕНИЕ АССОЦИАТИВНЫХ СУЩНОСТЕЙ

Ассоциативные сущности (associative entity) используются для развернутого описания связей типа «многие-ко-многим» (или «многие-ко-многим-ко-многим» и т. п.) с целью их декомпозиции. В ассоциативную сущность переносятся идентифицирующие атрибуты объектов, участвующих в описываемой связи. При необходимости ассоциативная сущность дополняется новыми атрибу тами — например, датами, описывающими срок действия. Ассоциативные сущности могут иметь более двух родительских сущностей. В графовых базах данных ассоциативные сущности порой играют роль узлов. В многомерных моделях ассоциативные сущности, как правило, превращают ся в таблицы фактов.

2.2.1.2.4 ДОБАВЛЕНИЕ АТРИБУТОВ

Добавление атрибутов к концептуальным сущностям в дальнейшем продолжается в логической модели и должно производиться вплоть до ее атомарного представления. Каждый атрибут дол жен соответствовать строго одному (и только одному) элементу данных (факту), не допускающему возможности дальнейшего дробления. Например, концептуальный атрибут «номер телефона» разбивается на все возможные логические атрибуты, описывающие тип номера телефона (до машний, рабочий, мобильный, факс и т. д.) и его структуру (код страны, код города/оператора, прямой номер, дополнительный номер и т. п.).

2.2.1.2.5 ОПРЕДЕЛЕНИЕ ДОМЕНОВ

Области значений атрибутов (домены), о которых говорилось в разделе 1.3.3.4, позволяют обес печивать согласованность форматов, настроек и ограничений на значения однотипных данных в рамках связанных между собою проектов. Например, Стоимость обучения в год и Ставка опла ты преподавателей привязываются к домену Валюта, который является стандартным.

2.2.1.2.6 ОПРЕДЕЛЕНИЕ КЛЮЧЕЙ

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

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

2.2.1.3 ФИЗИЧЕСКОЕ МОДЕЛИРОВАНИЕ ДАННЫХ

Логические модели данных требуют модификаций и адаптации с целью получения итогового проектного решения, обеспечивающего эффективную работу в среде конкретной СУБД. Напри мер, адаптация LMD для Microsoft Access потребует внесения одних изменений, а для Terada ta — совсем других. Далее в этом разделе термин таблица используется собирательно для обо значения таблиц, файлов и схем; термин столбец — для обозначения столбцов (колонок), полей и элементов; термин строка — для обозначения строк, записей и экземпляров в терминологии различных СУБД.

2.2.1.3.1 РАЗРЕШЕНИЕ ЛОГИЧЕСКИХ АБСТРАКЦИЙ

Логические абстрактные сущности (супертипы и подтипы) на стадии создания физического про екта базы данных преобразуются в отдельные объекты одним из двух способов.

Поглощение (absorption) подтипа. Атрибуты подтипа сущности включаются в таблицу су пертипа в виде столбцов, допускающих пустые поля (NULL).

Разделение (partition) супертипа. Атрибуты супертипа сущности распределяются по отдель ным таблицам, каждая из которых соответствует одному из подтипов.

2.2.1.3.2 ДОБАВЛЕНИЕ ДЕТАЛЬНОЙ ИНФОРМАЦИИ ОБ АТРИБУТАХ

В физической модели к атрибутам добавляются такие детали, как технические имена таблиц и столбцов (в реляционных базах данных), файлов и полей (в нереляционных БД) или схем и эле ментов (в базах данных XML).

Определите физические домены, тип и длину столбца или поля физической базы данных. До бавьте необходимые ограничения (например, по допустимости неопределенных значений) и зна чения по умолчанию для столбцов или полей, уделяя особое внимание обязательному указанию в явном виде требований по недопустимости неопределенных значений (NOT NULL).

2.2.1.3.3 ДОБАВЛЕНИЕ ОБЪЕКТОВ СПРАВОЧНЫХ ДАННЫХ

Небольшие наборы справочных данных, указанные на логическом уровне, в PMD могут быть реализованы тремя распространенными способами.

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

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

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

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

2.2.1.3.4 ОПРЕДЕЛЕНИЕ СУРРОГАТНЫХ КЛЮЧЕЙ

Часто в PMD бывает удобно использовать суррогатные ключи. Значения таких ключей должны быть скрыты от бизнес-пользователей, а кроме того, они не должны нести никакой смысловой нагрузки и не могут быть каким-либо образом связаны с данными, которым соответствуют. Этот этап не является обязательным, поскольку суррогатный ключ используется лишь в тех случаях, когда естественный ключ слишком велик, имеет сложносоставную структуру или содержит атри буты, которые со временем могут меняться.

Если суррогатный ключ назначается первичным ключом таблицы, убедитесь, что на основе исходного первичного ключа определен альтернативный ключ. Например, если в LMD первич ный ключ объекта Студент состоял из Фамилии студента, Имени студента и Даты рождения сту дента (то есть использовался составной первичный ключ), в PMD первичным ключом таблицы Студент может быть назначен суррогатный ключ ID студента. В таком случае должен быть опре делен и альтернативный ключ, основанный на исходном первичном ключе из Фамилии студента, Имени студента и Даты рождения студента.

2.2.1.3.5 ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ЗА СЧЕТ ДЕНОРМАЛИЗАЦИИ

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

2.2.1.3.6 ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ ЗА СЧЕТ ИНДЕКСИРОВАНИЯ

Индексирование данных — альтернативное средство оптимизации и ускорения обработки за просов к базам данных. Повысить производительность СУБД за счет индексирования данных удается во многих случаях. Но для этого администратору или разработчику базы данных нужно правильно выбрать тип индексирования таблиц. Основные коммерческие реляционные СУБД поддерживают разнообразные типы индексирования. Индексы могут быть уникальными или неуникальными, кластеризованными или некластеризованными, секционированными или не секционированными, одностолбцовыми или многостолбцовыми, на основе сбалансированных бинарных деревьев (b-tree), битовыми (bitmap) или хешированными (hashed). Без надлежащей