к единственному приложению.

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

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

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

5. РУКОВОДСТВО МОДЕЛИРОВАНИЕМ И ПРОЕКТИРОВАНИЕМ ДАННЫХ

5.1 Управление качеством моделей и проектных решений

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

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

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

5.1.1 Разработка стандартов моделирования и проектирования данных

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

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

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

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

Перечень и описание стандартных методов создания и сопровождения результатов модели рования и проектирования.

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

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

Требования и рекомендации к качеству метаданных (см. главу 13).

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

Руководства по подготовке и проведению проверки и оценки моделей и проектных решений.

Руководства по управлению версиями моделей данных.

Описание практик, не рекомендуемых к применению.

5.1.2 Проверка и оценка качества моделей данных и проектных решений

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

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

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

5.1.3 Управление версиями и интеграцией моделей данных

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

Каждое изменение должно сопровождаться следующими пояснениями.

Почему проект или ситуация потребовали внесения изменения.

Что и Как именно было изменено, включая точное описание добавленных, удаленных или измененных столбцов и связанных с ними изменений и т. д.

Когда было утверждено решение о внесении изменения и когда оно было внесено в модель (когда изменение было реализовано, в системе фиксировать не обязательно).

Кто внес изменение.

Где внесено изменение (в каких моделях).

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

К объективной оценке качества моделей данных можно подходить с различными наборами мерок и критериев, но в любом случае необходима эталонная база сравнения. В качестве примера при ведем лишь одну из возможных методик проверки соответствия модели данных общепринятым стандартам качества, а именно — шаблон ведомости оценки модели данных Data Model Scorecard® (Hoberman, 2015). Шаблон предусматривает оценку качества модели данных по десяти категориям критериев с подсчетом итоговой суммы баллов и процентов набранных баллов по каждой категории (табл. 11).

Таблица 11. Шаблон ведомости оценки модели данных Data Model Scorecard®

В столбце «Оценка модели» проверяющий модель эксперт выставляет свою оценку ее соот ветствия критерию, указанному в столбце «Категория» в пределах от нуля до максимального числа баллов, определяющего удельный вес этого критерия в суммарной оценке. Например, если экс перт выставляет оценку в 10 баллов из 15 возможных по категории «Насколько хорошо в модели отражены требования к данным?», эти 10 баллов добавляются к суммарной оценке, а в столбце степени соответствия (%) появляется значение 66%. В столбце «Комментарии» проверяющий

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

Далее приводится краткое описание каждой категории.

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

2.Является ли модель достаточно полной? Здесь полнота рассматривается в двух аспектах: пол нота соблюдения требований и полнота метаданных. Первый аспект подразумевает, что в мо дели все запрошенные требования учтены достаточно подробно. Этот же аспект подразумевает отсутствие в модели избыточных данных. Конечно, нет ничего проще, чем добавлять не запра шиваемые структуры данных — на тот случай, если они понадобятся в ближайшем будущем. Проверка призвана такие структуры выявлять и снижать за них оценку, поскольку они услож няют проект и задерживают срок его сдачи из-за того, что проектировщик тратит время на мо делирование данных, которые не требуются. Следует считаться с издержками от реализации по тенциальных будущих требований в случае, если эти требования так и не возникнут. Полнота метаданных означает наличие исчерпывающей описательной информации по всем элементам модели; например, если мы проверяем физическую модель данных, мы вправе ожидать наличия описаний форматов и информации о допустимости неопределенных значений по всем полям.

3.Насколько хорошо модель согласуется со схемой представления данных? Здесь мы прове ряем соответствие уровня детализации (концептуальный, логический или физический) и схе мы (например, реляционная, многомерная, NoSQL) рассматриваемой модели определениям, используемым для моделей соответствующего типа.

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

5.Насколько эффективно модель использует преимущества обобщенных структур? Здесь мы удостоверяемся в достаточном уровне и правильности абстрагирования понятий. На пример, заменяя атрибуты типа Местонахождение заказчика обобщенными атрибутами типа Местонахождение, проектировщик получает возможность впоследствии использовать те же сущности в качестве шаблонов-заготовок для описания местонахождения других физических объектов: например, складов, центров выдачи заказов и т. п.