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

3.6 Отраслевые модели данных

Отраслевые модели данных представляют собой готовые модели, разработанные для универсаль ного применения в масштабах целых отраслей экономики, таких как здравоохранение, телеком муникации, страхование, банковское дело или промышленное производство. Такие модели часто весьма широки по области применения и одновременно очень детализированы. В некоторых от раслевых моделях данных содержатся тысячи объектов и атрибутов. Распространяются такие мо дели либо на коммерческой основе — разработчиками, либо через отраслевые ассоциации, такие как ARTS (торговля), SID (связь) или ACORD (страхование).

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

4. ЛУЧШИЕ ПРАКТИКИ

4.1 Лучшие практики в области соглашений об именовании

Международный стандарт ISO 11179 «Регистры метаданных» содержит разделы, посвященные стандартным рекомендациям в части представления данных, включая имена и письменные опре деления различных элементов данных1

1 См.: ГОСТ Р ИСО/МЭК 11179-5-2012 «Информационная технология (ИТ). Регистры метаданных (РМД). Часть 5. Принципы наименования и идентификация». — Примеч. пер.

Стандарты в области моделирования данных и проектирования баз данных определяют руко водящие принципы, соблюдение которых необходимо для удовлетворения потребностей бизнеса в данных, обеспечения согласованности с корпоративной архитектурой и архитектурой данных (см. главу 4) и поддержки высокого уровня качества данных (см. главу 14). Архитекторы и анали тики данных, а также администраторы баз данных должны совместными усилиями разрабаты вать эти стандарты. Причем стандарты данных должны дополнять соответствующие ИТ-стан дарты, а не вступать с ними в противоречие.

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

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

Стандарты наименований должны быть по возможности едиными для всех рабочих сред (environments). Следует минимизировать рассогласование имен элементов в различных средах — тестовой (test), обеспечения качества (Quality Assurance, QA) или эксплуатационной (production). Для этого достаточно избегать присвоения элементам имен, указывающих на конкретную среду. В то же время для простоты разграничения сущностей и атрибутов, названий таблиц и столбцов используйте слова, определяющие классы (class words), которые стоят последними в именах атри бутов, таких как Количество (Quantity), Имя (Name), Код (Code). Они же помогают понимать, какого типа данные — количественные или качественные — описывает атрибут/столбец.

4.2 Лучшие практики проектирования баз данных

В процессе проектирования и построения базы данных ее администратору следует постоянно иметь в виду следующие принципы (запомните акроним PRISM).

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

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