Книга: Ценность ваших данных
Назад: Глава 10. Руководство данными
Дальше: Глава 12. Обеспечение доступности и обслуживание данных: основы
Глава 11. Планирование и проектирование данных
В главе 9 «Управление данными: принципы и структуры» говорилось о том, что деятельность по непосредственному управлению жизненным циклом данных сосредоточена на трех направлениях, соответствующих основным фазам жизненного цикла (см. рис. 9.4):
1. планировании и проектировании данных;
2. обеспечении доступности и обслуживании данных;
3. практическом использовании данных и расширении возможностей их применения для достижения целей организации.
Сравнивая цепи поставок продукции с цепочками поставок данных, мы уже отмечали, что управление и тем и другим начинается с процессов планирования и проектирования (см. главу 7). В текущей главе мы обсудим это важное направление и такие вопросы, как:
● роль концепции архитектуры предприятия в планировании и проектировании различных сторон деятельности организации;
● основополагающее место архитектуры данных в управлении данными;
● цели моделирования данных и связанные с ним артефакты.
11.1. Архитектура данных
Чтобы подчеркнуть важность архитектурной практики в управлении данными, обратим внимание на следующие два момента.
1. В рамочной модели управления корпоративной информацией (рис. 7.7) частные политики, процессы, процедуры и стандарты, поддерживающие политику работы с информацией, опираются на информационную архитектуру, формируемую в соответствии с дата-центричным подходом (рис. 6.2).
2. В своей книге, посвященной стратегии работы с данными (на которую мы уже ссылались в главе 6), Айкен и Харбор в качестве одного из трех важнейших элементов эффективной работы с данными (наряду с информационной грамотностью и цепочками поставок данных) выделяют стандартизацию информационных активов. Как мы увидим, в основе такой стандартизации лежит построение рациональной архитектуры данных.
11.1.1. Определение области знаний «Архитектура данных»
Архитектурой принято называть как искусство и науку о проектировании и строительстве, так и результаты этой деятельности – т. е. сами строения. В общем смысле архитектурой называют упорядоченную компоновку составляющих элементов, предполагающую оптимизацию функциональности, производительности, технологичности, стоимости и эстетичности создаваемой конструкции или системы.
Термин «архитектура» также применяется для описания отдельных аспектов проектирования информационных систем. Стандарт ISO/IEC/IEEE 42010:2011 Systems and software engineering. Architecture description («Системная и программная инженерия. Описание архитектуры») определяет архитектуру как «основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития».
На практике под термином «архитектура» в зависимости от контекста может подразумеваться описание текущего состояния систем, компонентов совокупностей систем, проектирование систем (как дисциплина и практика), планируемый проект системы или совокупности систем (будущее состояние или предполагаемая архитектура), артефакты, характеризующие систему (архитектурная документация), или команда, выполняющая работу по проектированию (архитекторы или архитектурная команда).
Архитектура данных образует фундамент управления данными. Поскольку большинство организаций располагают объемами данных, которые не могут быть осмыслены отдельными сотрудниками, возникает потребность в их представлении на разных уровнях абстракции таким образом, чтобы они были понятны, и руководство могло принимать относительно этих данных решения.
Архитектуру данных можно рассматривать с нескольких точек зрения, которые позволяют определить ее важнейшие составляющие.
● Выходные результаты архитектуры данных, такие как модели, определения и описания потоков данных на различных уровнях, т. е. все то, что принято называть артефактами архитектуры данных.
● Работы по формированию, развертыванию и внедрению целевых решений в области архитектуры данных.
● Организационное поведение в рамках работ в области архитектуры данных; формы сотрудничества, образы мышления и навыки, распределенные по различным ролям.
Архитектура данных организации описывается с помощью целостного комплекса проектных документов различной степени абстракции, включая стандарты, определяющие порядок сбора, хранения, упорядочения, использования и удаления данных. Она также делится на описания всех хранилищ данных и описания всех маршрутов их перемещения по информационным системам организации.
К артефактам архитектуры данных относятся спецификации, используемые для описания текущего состояния, определения требований к данным, порядка интеграции данных и контроля информационных активов в соответствии с действующей стратегией работы с данными. Наиболее детализированный архитектурный проектный документ в области данных – оформленная надлежащим образом корпоративная модель данных (включающая наименования элементов данных, подробные определения данных и метаданных, концептуальные и логические сущности и связи между ними, а также бизнес-правила). Наряду с другими документами в состав проектной документации входят и физические модели данных как продукты области моделирования и проектирования.
Архитектура данных наиболее полезна в тех случаях, когда она в полном объеме обеспечивает потребности на корпоративном уровне. Единая корпоративная архитектура данных позволяет последовательно и согласованно осуществлять стандартизацию и интеграцию данных в масштабах организации.
11.1.2. Цели и бизнес-драйверы
Основная цель архитектуры данных – служить мостом между бизнес-стратегией и ее технологической реализацией.
Будучи частью архитектуры предприятия (см. следующий раздел), архитектура данных должна:
● стратегически подготавливать организации к быстрому развитию продуктов, услуг и данных с целью полного использования бизнес-возможностей, которые открываются с появлением новых технологий;
● переводить бизнес-потребности на язык требований к данным и системам, чтобы бизнес-процессы не испытывали дефицита в необходимой информации;
● обеспечивать управление сложным процессом предоставления данных и информации в масштабах предприятия;
● способствовать повышению согласованности между бизнес– и ИТ-процессами;
● служить средством гибкого проведения изменений и преобразований.
Именно эти бизнес-драйверы определяют меру ценности архитектуры данных.
11.1.3. Архитектура предприятия
Архитектура информационных систем обычно рассматривается в рамках более широкой дисциплины – архитектуры предприятия (Enterprise Architecture, EA),, которая охватывает архитектуры нескольких предметных областей (доменов), включая данные, бизнес-приложения и технологии.
Отлаженные практики управления архитектурой помогают организации четко понимать текущее состояние своих информационных систем, проводить изменения, направленные на переход в желаемое состояние, обеспечивать соблюдение нормативно-правовых требований, повышать эффективность и производительность работы. Эффективное управление данными и использование их и систем хранения – одна из общих целей разделов концепции архитектуры предприятия.
Архитектура данных строится в контексте других предметных областей архитектуры, включая бизнес, приложения и технологическую инфраструктуру. Таблица 11.1 содержит их сравнительное описание. Архитекторы, занимающиеся различными доменами, должны совместно определять направления и требования к разработке, согласовывая их между собой, поскольку каждый домен влияет и накладывает ограничения на другие.
11.1.4. Модель Захмана
Базовыми моделями, используемыми для разработки широкого спектра родственных архитектур, являются архитектурные рамочные структуры. Они представляют собой своего рода общую «архитектуру архитектуры» и служат способом осмысления и понимания архитектурных построений.
Людям, не связанным с архитектурой и не разбирающимся во всех различиях между архитектурными уровнями и аспектами, легко в них запутаться, поэтому бывает сложно понять, чем занимаются архитекторы. Одна из причин, по которой архитектурные рамочные структуры крайне полезны, состоит в том, что они помогают неспециалистам получить представление о связях и соотношениях между отдельными компонентами.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
Самая известная рамочная структура архитектуры предприятия была разработана Джоном Захманом в 1980-х годах. Захман обратил внимание на то, что к созданию зданий, самолетов, предприятий, цепочек создания стоимости, проектов или систем имеют отношение различные группы людей, у каждой из которых есть собственная точка зрения на архитектуру создаваемого объекта. Эту концепцию он применил к требованиям для различных типов и уровней архитектуры предприятия.
Модель Захмана представляет собой матрицу 6×6, охватывающую полный набор моделей, требуемых для описания предприятия, и связей между ними. Архитектурная рамочная структура Захмана не описывает, как именно создавать входящие в нее модели. Она показывает, что эти модели должны быть созданы (табл. 11.2).
Столбцы матрицы отражают обсуждаемые вопросы (что, как, где, кто, когда и зачем), а строки – преобразования в процессе материализации (выявление – identification, определение – definition, представление, спецификация – specification, конфигурация – configuration, реализация – instantiation). В ячейках на пересечении строк и столбцов отражены уникальные типы артефактов архитектуры данных.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
Обсуждаемые аспекты представляют собой вопросы, которые могут быть заданы относительно какой-либо сущности. Применительно к архитектуре предприятия столбцы матрицы можно интерпретировать следующим образом:
● что (столбец объектов): сущности (объекты), используемые для построения архитектуры;
● как (столбец процессов): проводимые работы;
● где (столбец местоположений): местоположения бизнес-структур и технологических структур;
● кто (столбец обязанностей): роли и организационные системы;
● когда (столбец привязки по времени): сроки, интервалы, события, циклы, расписания;
● зачем (столбец мотивации): цели, стратегии и средства.
Процесс материализации состоит из шагов, необходимых для перевода абстрактной идеи в конкретный образец (реализация). Эти шаги отражены в строках матрицы, обозначенных с помощью названий соответствующих ролей: планировщик, владелец, проектировщик, разработчик, внедренный пользователь. Каждой из перечисленных ролей соответствует отличная от других перспектива процесса в целом, а также собственный круг решаемых проблем. Эта специфика и показана в строках. Например, каждая перспектива выражает различное отношение к столбцу «Что» (предметы или данные).
● Перспектива руководства (бизнес-контекст). Перечни составляющих бизнеса, определяющие содержание моделей идентификации.
● Перспектива бизнес-менеджмента (бизнес-концепции). Уточнение бизнес-менеджерами (как владельцами) связей между бизнес-концепциями и отражение их в моделях определения.
● Перспектива архитектора (бизнес-логика). Логические системные модели, детализирующие системные требования, и проектные решения без учета ограничений, отраженные архитекторами (как проектировщиками) в моделях представления.
● Перспектива инженера (физический уровень). Физические модели, оптимизирующие проектные решения с целью их реализации для конкретных применений с учетом ограничений по используемым технологиям, человеческим ресурсам, стоимости и срокам. Определяются инженерами (как разработчиками) в моделях спецификации.
● Перспектива технического специалиста (сборка). Чисто технический, без учета контекста, взгляд на то, каким образом отдельные компоненты должны быть собраны и функционировать. Отражается техническими специалистами (как внедренцами) в конфигурационных моделях.
● Перспектива пользователя (реализация). Реальные функционирующие объекты, с которыми работают сотрудники (как пользователи). Эта перспектива моделей не предусматривает.
Как уже отмечалось, каждой ячейке, определяемой в результате пересечения строки и столбца, в модели Захмана соответствует уникальный тип разрабатываемого артефакта. Каждый такой артефакт описывает, каким образом соответствующая перспектива отвечает на вопросы, обсуждаемые в процессе создания архитектуры.
11.1.5. Основные артефакты архитектуры данных
По мере поступления данных в организацию через каналы связи или интерфейсы обеспечивается их защита и интеграция; они сохраняются, регистрируются, каталогизируются, распространяются, включаются в отчеты, анализируются и предоставляются заинтересованным лицам. Попутно данные могут подвергаться верификации, улучшению, связыванию, сертификации, агрегированию, анонимизации и использованию в целях аналитики вплоть до момента их архивации или удаления. Следовательно, описания корпоративной архитектуры данных должны включать как корпоративные модели данных (с указанием структуры и спецификаций данных), так и описания потоков данных.
Корпоративная модель данных и описание потоков данных должны быть хорошо согласованы. При этом и модель, и потоки данных отражаются в трех состояниях – текущем, целевом (архитектурная перспектива) и переходном (проектная перспектива).
Корпоративная модель данных
Корпоративная модель данных (Enterprise Data Model, EDM) представляет собой целостную, не зависящую от технических средств реализации концептуальную или логическую модель данных, отражающую единый согласованный взгляд на данные в масштабах всей организации. Этот термин обычно используется для обозначения высокоуровневой упрощенной модели данных, но уровень абстракции может быть различным в зависимости от целей ее представления. EDM содержит данные о ключевых сущностях предприятия (на уровне бизнес-концепций) и связях между ними, критически важные руководящие бизнес-правила и некоторые ключевые атрибуты. EDM закладывает основу для всех проектов в области данных или связанных с данными. Модели данных уровня отдельных проектов должны создаваться на основе EDM (см. главу 6 – разделы 6.3 и 6.4 и главу 7 – раздел 7.3). Данная модель подлежит обязательной проверке всеми заинтересованными сторонами для обеспечения согласованного мнения о том, что в ней зафиксировано правильное представление об организации.
Организация, осознавшая потребность в EDM, должна определить, сколько времени и усилий она готова посвятить ее построению и ведению. EDM могут создаваться с различными уровнями детализации, а потому нужно изначально определиться с имеющимися ресурсами и, исходя из этого, спланировать объем работ по подготовке первоначального содержания модели. Со временем по мере необходимости можно расширять объемы и прорабатывать дополнительные детали собираемых данных, требующихся для оптимальной работы организации, что, как правило, и делается. Самые успешные EDM выстраиваются поэтапно, итерационно и послойно.
Рисунок 11.1 показывает, как связаны модели различных типов и как концептуальные модели могут быть привязаны к физическим моделям данных приложений. На рисунке отражены следующие уровни представления:
● концептуальная общая модель данных, предоставляющая обзор всех предметных областей организации;
● представления сущностей и связей по каждой предметной области;
● детализированные, с частично описанными атрибутами логические представления тех же предметных областей;
● логические (Logical Data Model, LDM) и физические (Physical Data Model, PDM) модели на уровне отдельных приложений или проектов.
Все уровни в совокупности составляют корпоративную модель данных. Структура связей позволяет проследить сущность с верхнего уровня до нижнего и между моделями на одном уровне.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
Описание потоков данных
В главе 8 мы подчеркивали важность понятий «поток данных» («цепочка данных») и «происхождение данных». Описание потоков данных содержит требования и основное рабочее описание (master blueprint) организации хранения и обработки данных по всем базам данных, приложениям, платформам и сетям. Потоки данных отражают их перемещение с целью использования в бизнес-процессах, на отдельных рабочих местах, сотрудниками с определенными бизнес-ролями, а также отдельными техническими компонентами.
Потоки данных являются одним из способов документального оформления происхождения данных. Они фиксируют маршруты прохождения данных через бизнес-процессы и системы. Описанный от начала до конца поток данных показывает, где данные возникают, где хранятся и используются, а также все преобразования данных в процессе их движения как внутри, так и между различными процессами и системами. Анализ происхождения помогает объяснить состояние данных в каждой точке потока.
Потоки данных отображают и документируют взаимосвязи данных:
● с приложениями, используемыми в рамках бизнес-процесса;
● хранилищами или базами данных в среде функционирования;
● сегментами сети (полезно для описания мер безопасности);
● бизнес-ролями, показывая, какие роли отвечают за создание, чтение, обновление, удаление данных;
● местами, в которых происходят изменения данных.
Потоки данных могут документироваться с разной степенью детализации – до уровня предметной области, сущности или даже атрибута. Системы могут быть представлены сегментами сети, платформами, наборами часто используемых приложений или отдельными серверами. Для схематического представления потоков данных могут использоваться матрицы (рис. 11.2) или диаграммы потоков данных (рис. 11.3).
11.1.6. Две точки зрения на архитектуру данных
В главе 8 в качестве наиболее поздних этапов эволюции развития управления данными были выделены этапы 2 и 3 (табл. 8.1). Второй этап ориентирован прежде всего на качество данных, а третий – на инновации на основе данных. В связи с этим создание архитектуры данных (и архитектуры предприятия) сопряжено с необходимостью учета сложного комплекса вопросов, обусловленных двумя основными точками зрения на архитектурные решения.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
1. Ориентированная на качество. Основное внимание направлено на совершенствование деятельности в рамках бизнес-цикла и цикла разработки в области ИТ. Без должного управления архитектурой качество решений ухудшается. Системы со временем будут чрезмерно усложняться и терять гибкость, что создаст дополнительные риски для организации. Неконтролируемое распространение и копирование данных, запутанные взаимосвязи делают организации менее эффективными и снижают доверие к данным.
2. Ориентированная на инновации. Основное внимание направлено на трансформацию бизнеса и ИТ в свете новых перспектив. Продвигать инновации за счет внедрения прорывных технологий и методов использования данных – еще одна задача современного корпоративного архитектора.
К двум этим позициям нужно подходить дифференцированно.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
Подход, ориентированный на качество, укладывается в традиционное представление о работе по проектированию архитектуры, предусматривающее ее поэтапное совершенствование. Архитектурные задачи распределяются по проектам, в которых принимают участие архитекторы. В любом случае специалист, как правило, не теряет из виду цельность архитектуры и руководствуется долгосрочными установками, связанными с руководством данными, стандартизацией и структурированной разработкой. Такой подход в большей степени способствует выработке дата-центричной архитектуры, о которой мы говорили в главах 6 и 7.
При подходе, ориентированном на инновации, может рассматриваться краткосрочная перспектива, а также предполагается использование еще не апробированных схем ведения бизнеса и передовых технологий. Такая направленность часто требует, чтобы архитекторы вступали в контакт с теми людьми внутри организации, которые обычно не входят в круг общения профессионалов в сфере ИТ (например, с представителями подразделений, отвечающих за разработку новых продуктов или бизнес-моделей).
11.1.7. Контекстная диаграмма области знаний и уровни зрелости функции «Архитектура данных»
Контекстная диаграмма области знаний «Архитектура данных» представлена на рисунке 11.4.
Работая в команде по поддержке корпоративной архитектуры (если в организации внедрена функция поддержки архитектуры предприятия) или в команде по поддержке архитектуры данных, архитекторы данных отвечают за разработку дорожной карты, управление требованиями к корпоративным данным в рамках проектов и интеграцию с общей архитектурой предприятия. Успех зависит от определения и соблюдения архитектурных стандартов, а также от создания и поддержания полезных и пригодных для использования архитектурных артефактов. Соблюдение дисциплины в архитектурной практике может повысить ее эффективность и качество за счет создания повторно используемых и расширяемых решений (см. главу 6 – разделы 6.3 и 6.4 и главу 7 – раздел 7.3).
Важный аспект проводимых работ – предоставление экспертам в отдельных предметных областях организации возможности сотрудничать в решении архитектурных задач. При наличии соответствующего времени и ресурсов это приведет к тому, что оптимальные архитектурные решения будут определяться в рамках обычных проектных циклов, а не путем приложения экстраординарных усилий при первоначальном проектировании.
Цель состоит в том, чтобы иметь запас созданных архитектурных решений, готовых к объединению и выполнению будущих бизнес-задач.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
Один из способов устранения препятствий для совместной работы – создание в организации единой стандартной архитектурной рамочной структуры, позволяющей использовать общий словарь, а также шаблоны, облегчающие кросс-функциональную интеграцию данных.
На рисунке 11.5 представлены обобщенные характеристики уровней зрелости функции «Архитектура данных».
* Smith P., Edge J., Parry S., Wilkinson D. Crossing the Data Delta: Turn the data you have into the information you need. Entity Group Limited, 2016.
11.1.8. Влияние на ценность данных
В каждой организации реализована некоторая архитектура данных, но для многих – это плохо представляемый комплекс проектных решений, про которые известно только то, что они состоят из некоторого количества физических хранилищ данных, систем, процессов, сервисов и интерфейсов. Данные поступают в организацию, циркулируют в ней и выходят через эти компоненты.
В таких организациях обычно мало что из архитектурного ландшафта задокументировано, поэтому никто не может с достаточной уверенностью утверждать, каким образом данные поддерживают бизнес. Это также означает, что изменения в информационном ландшафте могут оказаться слишком рискованными.
Во введении мы говорили о том, что четвертая промышленная революция характеризуется дизруптивным (ломающим привычные представления) воздействием на компании. Последние, чтобы остаться на плаву, вынуждены в ускоренном темпе трансформировать себя. У организаций, которые не способны внедрять инновации, быстро реагировать на меняющиеся рыночные условия, будет самое трудное и неопределенное будущее.
Архитектура данных в целом направлена на развитие способностей организации эффективно работать с данными и, следовательно, на повышение готовности к изменениям ее деятельности.
Архитекторы данных создают и поддерживают знания организации о данных и системах, через которые эти данные распространяются. Такие знания позволяют управлять данными как активом и повышать получаемую от них выгоду за счет выявления возможностей по их применению, а также снижения издержек и рисков. Поэтому одним из артефактов архитектуры данных (наряду с корпоративной моделью данных, описанием потоков данных и другими) могут быть описания цепочек ценности данных, которые мы обсуждали в главе 7.
Архитектуру стремятся сделать такой, чтобы она приносила организации ценность. Ценность же достигается за счет оптимизации требуемых ресурсов, операционной и проектной эффективности, а также расширения возможностей организации по использованию данных (см. главу 5). Для этого необходимы качественное проектирование и планирование, а также способность обеспечить эффективную реализацию проектов и планов. Кроме того, повышение ценности данных обеспечивается за счет расширения сотрудничества между различными функциональными направлениями организации – налаживания отношений, выявления областей для сокращения дублирования и затрат. Это позволит привлечь к участию больше сотрудников и повысить заинтересованность в улучшении процессов управления данными. Таким образом, архитектура данных станет важным элементом поддержки непрерывного совершенствования.
11.2. Моделирование и проектирование данных
Моделирование данных – критически важный компонент управления данными. Оно требует от организации выяснения и документирования того, как данные соотносятся друг с другом в рамках общей картины. В то же время моделирование само по себе заключается в разработке решений в отношении компоновки данных и их связи. Модели данных отражают и одновременно улучшают понимание организацией информационных активов, которыми она располагает и оперирует,.
11.2.1. Определение области знаний «Моделирование и проектирование данных»
Моделирование данных – это процесс последовательного выявления, анализа и формулирования основных требований к данным с последующим их представлением и распространением в точно определенной форме.
Модель – это представление чего-либо, что уже существует, или примерный образец того, что предстоит создать. Модель может содержать одну или несколько диаграмм. В каждой диаграмме используются стандартные символы, обеспечивающие понимание ее смыслового содержания. Примерами широко распространенных моделей являются карты, схемы организационных структур, чертежи зданий.
Модели данных – важная форма метаданных. Они содержат полезные для потребителей данных сведения. Значительная часть этих сведений, выявленных в процессе моделирования, необходима другим функциям управления данными. Например, определения, требующиеся для руководства данными, или информация, относящаяся к происхождению данных и используемая при ведении хранилищ данных, а также в бизнес-аналитике.
Модель данных либо описывает данные организации так, как они понимаются на текущий момент, либо отражает то состояние данных, в котором организация хотела бы их видеть. Она содержит набор символов с текстовыми метками, предназначенными для визуального представления требований к данным, в том виде, в котором их сообщили специалисту по моделированию. При этом количество элементов описываемой области данных может варьироваться от небольшого (если рассматривается отдельный проект) до весьма внушительного (если рассматривается организация).
Модель данных – форма документирования требований к данным и определений данных. Получаемые в результате процесса моделирования документально оформленные модели – главное средство коммуникации, обеспечивающее передачу требований к данным от сферы бизнеса в блок ИТ, а также (в рамках блока ИТ) от аналитиков, специалистов по моделированию и архитекторов, взаимодействующих с ними, проектировщикам и разработчикам баз данных.
11.2.2. Цели и бизнес-драйверы
Главная цель моделирования данных – подтвердить и документально зафиксировать понимание различных аспектов организации данных, которое обеспечит создание приложений, наиболее точно соответствующих текущим и будущим потребностям бизнеса, а также заложить фундамент для успешной реализации широкомасштабных инициатив, таких как программы управления основными данными и руководства данными.
Модели данных имеют критическое значение для эффективного управления данными, поскольку они:
● определяют единую общую терминологию во всем, что касается данных;
● собирают и документируют точные знания (метаданные) о данных и информационных системах организации;
● служат основным средством коммуникации в процессе реализации проектов;
● являются отправной точкой при настройке, интеграции или замене приложений.
11.2.3. Разновидности моделей данных
Существует множество различных типов моделей данных. Наиболее распространенные из них: реляционная, многомерная, объектно-ориентированная, на основе фактов, хронологическая и NoSQL. Разработчики информационных систем используют модели в зависимости от потребностей, а также особенностей моделируемых данных и систем организации, для которой разрабатывается модель. Различные типы моделей данных визуально представляют данные с помощью различных соглашений.
Модели также различаются в зависимости от уровня абстракции объектов, которые они отображают: концептуальная с высоким уровнем абстракции; логическая со средним уровнем абстракции и физическая, которая отображает конкретную систему или экземпляр данных. При разработке информационных систем концептуальное и логическое моделирование данных относят к категории работ по планированию и анализу требований, а физическое моделирование данных – к проектным работам.
11.2.4. Строительные блоки моделей данных
Вне зависимости от типа моделей, в большинстве из них выделяются одни и те же компоненты – «строительные блоки»: сущности, связи, атрибуты и области значений атрибута. Приведенные здесь определения и примеры помогут составить представление о том, как работают модели данных,.
Сущность
В общем смысле – вне контекста моделирования данных – под сущностью понимается предмет, существующий отдельно от других предметов. В рамках моделирования данных сущность – предмет, о котором организация собирает информацию. Иногда сущности уподобляют «существительным» организации. Действительно, сущность можно рассматривать как ответ на один из фундаментальных вопросов (кто, что, где, когда, почему и как) или сочетание таких ответов. В таблице 11.3 приведены определения и примеры общеупотребительных категорий сущностей.
Связь
Связь – это отношение между сущностями. Связи фиксируют информацию о взаимодействиях между концептуальными сущностями, детализированные характеристики взаимодействия между логическими сущностями и взаимные ограничения при взаимодействии физических сущностей. Связи на диаграммах моделей данных принято отображать линиями.
Важная характеристика связи – ее мощность. Мощность связи между двумя сущностями определяет, сколько экземпляров одной сущности и сколько экземпляров другой могут быть связаны друг с другом. Например, в организации может работать один или несколько сотрудников.
Мощность отображается специальными символами («вилками») на обоих концах линии связи. Допустимые значения мощности – ноль, один или много («много» означает «больше чем один»). Возможны произвольные сочетания трех этих значений на противоположных концах связи.
На рисунке 11.6 показаны различные соотношения значений мощности связи на примере реляционной модели данных. В организации работает один или несколько сотрудников. Сотрудник может содержать ноль, одного или нескольких иждивенцев. Но сотрудник занимает одну и только одну должность в течение определенного периода времени. Мощность связи – это способ фиксации правил и предположений, связанных с данными. Если данные показывают, что сотрудник выполняет более одной работы в течение установленного периода времени, то в них имеется ошибка или в организации допускаются отклонения от правила.
* Sebastian-Coleman L. Navigating the Labyrinth: An Executive Guide to Data Management, First Edition. Technics Publications, 2018.
Атрибут
Атрибут – это характеристика сущности, позволяющая ее идентифицировать, описать или измерить. На физическом уровне атрибуту сущности может соответствовать столбец, поле, тег или узел в таблице, представлении, документе, графе или файле.
На рисунке 11.7 представлены сущности с описывающими их атрибутами (на примере реляционной модели данных). Сущность «Организация» имеет атрибуты «ИНН организации», «Наименование» и «Номер телефона». Сущность «Сотрудник» имеет атрибуты «Номер сотрудника», «Имя», «Фамилия» и «Дата рождения». Сущности «Иждивенец» и «Должность» имеют атрибуты, отражающие их основные характеристики.
* Sebastian-Coleman L. Navigating the Labyrinth: An Executive Guide to Data Management, First Edition. Technics Publications, 2018.
На представленной диаграмме атрибуты «ИНН организации», «Номер сотрудника» и «Номер должности» являются первичными ключами соответствующих сущностей. Ключом называют атрибут или набор атрибутов, уникальным образом определяющий экземпляр сущности. Поскольку в общем случае вариантов ключей (так называемых потенциальных ключей) может быть несколько, то один из них выбирается в качестве фактического уникального идентификатора экземпляра – первичного ключа. В сущности «Сотрудник» и «Иждивенец» для организации связей с другими сущностями (расположенными на диаграмме над ними) добавлены так называемые внешние ключи. Атрибут (или набор атрибутов) сущности, который является внешним ключом, предназначен для хранения значения первичного ключа другой сущности. У каждого экземпляра сущностей «Сотрудник» и «Иждивенец» значение внешнего ключа должно совпадать со значением первичного ключа одного из экземпляров соответствующих связанных сущностей.
Домен
Отметим, что в моделировании данных доменом обычно называется исчерпывающим образом описанный набор, диапазон или множество значений, которые могут быть присвоены атрибуту. В свою очередь, определение домена – одно из средств стандартизации характеристик атрибутов. Например, домен «Дата», включающий все допустимые значения календарных дат, может задаваться для любого атрибута датировки в логической модели и для любых столбцов/полей дат в физической модели данных, таких как:
● дата_приема_на_работу;
● дата_поступления_заказа;
● дата_рекламации;
● дата_начала_занятий.
Домены важны для понимания качества данных. Все значения, входящие в домен, являются допустимыми значениями. Те, которые выходят за его границы, – недопустимы. Домен для атрибута «дата_приема_на_работу» может быть определен просто как действительные даты. Согласно этому правилу, он, например, не включает 30 февраля любого года.
* DAMA. DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition. Technics Publications, 2017. (Русский перевод: DAMA-DMBOK: Свод знаний по управлению данными. Второе издание / Dama International. – М.: Олимп-Бизнес, 2020.)
11.2.5. Контекстная диаграмма области знаний и уровни зрелости функции «Моделирование и проектирование данных»
Контекстная диаграмма области знаний «Моделирование и проектирование данных» представлена на рисунке 11.8.
Аналитики данных, разработчики моделей и баз данных выступают в роли посредников между потребителями информации (теми, кто определяет нужды бизнеса в данных) и производителями данных (теми, кто фиксирует данные в пригодной для использования форме). Профессионалы в области данных должны обеспечивать искомый баланс при учете требований к данным от потребителей информации и требований к приложениям от производителей данных.
Но и профессионалы, работающие в области данных, также должны обеспечивать баланс – причем с учетом краткосрочных и долгосрочных интересов бизнеса. Потребителям информации нужны актуальные данные для выполнения своих обязанностей по текущему управлению бизнесом и реализации возможностей. Команды проектов по созданию систем должны укладываться в заданные временные и бюджетные рамки. Они должны учитывать интересы всех заинтересованных сторон, обеспечивая размещение данных организации в безопасных и надежных хранилищах, защищенных системами резервного копирования и обеспечивающих совместный доступ к данным и их повторному использованию, а также корректность, актуальность, релевантность и максимальное удобство использования данных с точки зрения пользователей. Именно поэтому модели и проектные решения по организации базы данных должны быть разумно сбалансированы таким образом, чтобы учитывать как краткосрочные, так и долгосрочные нужды организации.
На рисунке 11.9 представлены обобщенные характеристики уровней зрелости функции «Моделирование и проектирование данных».
11.2.6. Влияние на ценность данных
Вполне осязаемые результаты правильного моделирования данных: снижение затрат на поддержку, расширение возможности повторного использования моделей при проведении в жизнь будущих инициатив, минимизация затрат на создание новых приложений.
Подтверждение и документирование понимания различных аспектов организации данных и перспектив в рамках моделирования данных способствует более эффективной деятельности по следующим направлениям.
* Smith P., Edge J., Parry S., Wilkinson D. Crossing the Data Delta: Turn the data you have into the information you need. Entity Group Limited, 2016.
● Формализация. Модель данных документирует краткое и четкое определение структур данных и связей между ними. Она позволяет оценивать, как влияют на данные реализованные бизнес-правила (как для текущих, так и для будущих целевых состояний). Формальное определение вводит строго соблюдаемую структуру данных, что снижает вероятность нарушений при обеспечении доступа к данным и их ведении. Иллюстрируя структуры данных и связи между их элементами, модель данных упрощает их практическое использование.
● Определение области применения. Модель данных помогает объяснить границы контекста данных, внедрения приобретенного программного обеспечения и области охвата проектов, инициатив и существующих систем.
● Сохранение/документирование знаний. Модель данных может сохранять корпоративную память о какой-либо системе или проекте, фиксируя знания в четко определенной форме. Она служит документацией для будущих проектов в качестве версии «как есть».
Модели данных помогают лучше понимать различные аспекты организации или бизнеса, механизмы работы приложений или последствия изменений существующей структуры данных. Таким образом, модель данных становится многократно используемой картой, помогающей профессионалам в области бизнеса, руководителям проектов, аналитикам, специалистам по моделированию и разработчикам лучше понимать структуру данных в контексте среды окружения. Так же как картографы изучают и документируют географический ландшафт, помогая другим осуществлять навигацию, специалисты по моделированию данных помогают другим понять информационный ландшафт.
ПРАКТИЧЕСКИЙ ПРИМЕР
С этого блока нашего сквозного примера мы начинаем обсуждение реализации программы управления данными компании «Телеком Дубль».В рамках мероприятий по планированию и проектированию данных в компании началась работа по созданию корпоративной модели данных и описанию потоков данных. Также в подразделениях началось обсуждение основных цепочек ценности данных.Специалисты «Телеком Дубль» приступили к переходу на дата-центричную архитектуру, о которой мы говорили в главе 6 (см. рис. 6.2). Далее, в главе 13 мы рассмотрим основные домены (предметные области) телекоммуникационной компании (см. раздел 13.8). По каждому из этих доменов, и в первую очередь по клиентскому, разрабатываются модели данных, ориентированные на использование всеми системами.При внедрении новых приложений компания не расширяет ИТ-ландшафт для дополнения сведений о клиенте новыми данными во всех смежных системах (CDI, CRM, ERP), а централизованно обновляет модель данных клиентского домена, что позволяет бесшовно для систем-потребителей получать новую информацию о клиентах.
Литература к главе 11
• Aiken P., Harbour T. Data Strategy and the Enterprise Data Executive: Ensuring that Business and IT are in Synch in the Post-Big Data Era. Technics Publication, 2017.
• Bernard S. An Introduction to Holistic Enterprise Architecture: Fourth Edition. AuthorHouse, 2020.
• Fox R. Controlling the Chaos: A Functional Framework for Enterprise Architecture and Governance; First Edition. Technics Publications, 2018.
• Hoberman S. Data Modeling Made Simple: A Practical Guide for Business and IT Professionals. Second Edition. Technics Publications, 2009.
• Smith P., Edge J., Parry S., Wilkinson D. Crossing the Data Delta: Turn the data you have into the information you need. Entity Group Limited, 2016.
• Strengholt P. Data Management at Scale: Best Practices for Enterprise Architecture; 1st Edition. O’Reilly Media, Inc., 2010.
• Van Gils B. Data Management: a Gentle Introduction: Balancing Theory and Practice. Van Haren Publishing, 2020.
Назад: Глава 10. Руководство данными
Дальше: Глава 12. Обеспечение доступности и обслуживание данных: основы
