Важно описывать и котролировать модели данных, в том числе она учавствует в процессе проектирования
реализации клиентского пути. Сама компания зарабатывает на удовлетворении потребностей пользователей, решая их
предоставлением различных услуг и товаров. Наличие самих услуг или товаров так таковых не приносит компании
прибыли. По этому есть знаменитая фраза из книги по маркенгу, о том, что когда покупатель покупает сверло, он
покупает не сверло а дырку в стене. А самы дырка может пользоватерелю не нужна – он хочет смотреть на
картину. Возможно, будет выгодней
продать покупателю крючок на клейкой основе, путь в десять раз дороже, чем перфоратор, бур, клюк с высокой суманой
себестоимостью и необходимость убираться после установки крюка. Клиентский путь это путь клиента от потребности до
её удовлетворения. Так путь может быть взять кртину, пойти в маазин, купить необходимое, повесить картину. Но, это
свойсвенно людям, привыкшем всё делать самими. Другим людям будет присущ другой путь: найти телефон мастера,
приласить мастера, обяснить результат, получить услугу. Из-за привычек они не пересекаются, поэтому, новаторская
услуга может просто не найти своего покупателя из-за не сформированной клиентского пути. Когда клиентский путь
определён, необходимо определить, как может компания помочь его реализовать, для этого он разбиватеся на
бизнес процессы, то есть последовательности действий компании, для осуществление однотипного клиентского пути
клиентов. То есть процесс это повторяемая последовательность действий компании, которая детализирует часть
клиентских путей бизнес реализацией его (что необходимо компании сделать). Повторяемость обусловлено
выполенения его для разных клиентов – это важное свойство процесса, чтобы его можно было чётко обписать и обозначить
границы. В процессе может быть задействовано множество систем, которые его обеспечивают. Каждая такая система выполняет
отдельную операцию, зачастую унифицированную и учавствующую во множетсве бизнес процессах. Как обеспечиваеются
безнес процес с технической точки зрения сисетмами описывается в технологических картах. Описать же саму эту операцию
можно как изменение данных, а структуру самих даных описывает корпоративная модель данных. Корпоративная модель данных
описывает модель данных всей органиции, а модель данных конкретных систем описываются отдельно для каждой этой
системы. При этом не просходит дублирование, так описывается не сами данных, а их модель. Часто, копоративная модель
данных описывает данные на уровне абстрации свойственной пределённым категориям. Для стыковки таких копоративной
модели данных с моделью данных конкретной системы исползуют таблицу соответствия (data mapping).
По уровню логической абстракции её делят на: концептуальный, логический и физический
уровени. Информационная архитектура описывается моделями данных и связями между ними. Примером модели данных
для СУБД может быть структура таблицы данных. Модели данных бывают разных типов, например: реляционная,
объектно-ориентированная, хронологическая (Time based), NoSQL и другие. Управляется информационная архитектура (Data Governance)
с помощью артефактов, основным из которых является корпоративная модель данных (corporate data model, enterprise data model,
EDM). Корпоративная модельн данных представляет из себя унифицированную абстрактуную модель данных всей организации,
описывающие способ и доступ представления данных. Понятно, чтобы можно было ей пользоваться, нужны уровни абтаракции для
разных пользователей. Уровнями абстракции могут быть, к примеру, продукты, приложения и элементы (таблицы базы
данных). Пользовователями корпоративной модели данных могут быть бизнес специалисты и IT специалисты, например:
* Концептуальная – используются корпоративными архитекторами компании;
* Логическая – используются архитекторами данных, бизнес аналитиков данных и архитекторами СУБД конкртеных сервисов;
* Физическая – используется системными администраторами конкретных СУБД, очередей, программ, которые они обслудивают.
Рассмотрим, что они из себя представляют:
* Концептуальная – описывает категории данных с их взаимосвязями между ними, например, платёжные данные, данные о клиентах;
* Логическая – описывает бизнес сущности, взаимосвязи и их бизнес структуру (атрибуты), например, для интегрнет-магазина: Покупатель содержит Имя, Фамилию, Отчество, связан с Корзиной один ко многим, а Корзина связана Позицией содержащей цену, а Позиция связна с Товаром один ко многим с ценой, описывается общими полями, например, PRICE. При этом описываются данные не только
хранящиеся в безе данных, не только в принципе сохраняемые, но и обрабатываемые, например, поступающие в очередь событий. При
этом на физическом уровне они могут быть не определены (просто передаются в неструктурированном виде), а для логической
модели мы фиксируем передачу данных, учавствующих в бизнес процессах.
* Физическая – описывает конкретные технологии и их структуру, то есть конкретизирует логическую до конкретной реализации, например, MySQL10.4 PRICE_TABLE (int32 ID, char16 CODE, float PRICE, int32 ID_partition) при этом может иметь отличную структуру от логической модели данных, например, если используются несколько универсальных систем.
Рассмотрим более подробно уровни детализации модели данных. Уровни отличаются
уровнем детализации, но при этом не является обычным обобщением одной в другую – они описывают данные
для разного применения. Так одни уровни данных не являются простой детализацией других, то для связи их
применяется мэппинг одних сущностий данных на другие. Так, концептуальный уровень обычно применяется для
описания корпоративной модели данных вей компании. В модели можно увидеть взаимосвязи между данными, независящих
от систем и процессов. Логический же уронь, обчно, используется для проектирования управления данными, доступами
к ним и изменений их внутри систем. В первую очередь это касается критических данных, что позволяет их разметить
по критичности и конролировать их доступность. Например, системы обладающие критическими данными можно обязать
распологать в специальных сетевых зонах с повышенными требованиями к безопасности, как это требует поступать с
данными платёжных карт регуляторы банковской сферы в соответствии со стандартом PCI-DSS. Другим примером является
маппинг сущностей логической модели данных на поля API (физчиескую модель данных в рамках API), для контроля
распространения этих данных.
Лоическая модель данных (ЛМД) проверяется на этапе архитектруного контроля при проведении приёмосдаточных
испытаний на стенде интеграционно-фукнционального тестирования и приёмосдаточном стенде. В лигичекой моделях
указываются в перую очередь критические данные: персональные данные, банковская тайна, данные платёжных
карт и другие данные, тебующие контроля и обеспечения опеделённого управления. Логическая модель данных не привязана
Модель данных может быть выполенена в виде ER (Entity Relation), IE (Information Enginering), UML (Unified
Modeling Language), IDEF1X (Integration DEFinition for Information Modeling) нотации, мы же расмотрим
ER нотацию используя редактор SAP PowerDesigner. Сама программа имеет две недели пробного перриода.
В Archi модель данных описывается с помощью компонента Data Object. Для связей используются обычная линия, в контекстном
меню которой можно будет после её проведения установить отношение: композиция или агрегация.
SAP PowerDesigner поддерживает создание ER диаграм различных уровней копоратиной модели данных: Business Process Model,
Conceptual Data Model, Logical Data Model, Physical Data Model и другие. Для описания логической модели используется его диаграмма
Logical Data Model (LDM). Здесь нам предоставляются три области: дерево папок с диаграммами для навигации, рабочая область
для работы над идаграммой и область с примитивами. Примитивы представлены сущностями, различными связями межуд сущностями,
курсором для выделения сущности на рабочей области. Далее рассмотри сущности и связи подробнее.
Сущости изображаются в виде табличек с шапкой (для названия) и списка атрибутов. Сами сущности должны соответствовать
первой нормальной форме реляционной структуры, то есть за каждой сущностью закрепляется только один объект данных. Добавив
сущности и связи между ними мы получили концептуальную архитектуру. Для логической нам нужно указать атрибуты и ключи с
требуемой детальность, без технологических особенностей, таких как ID таблицы, поля для партиционирония и шардировани и
других поле, требующихся для реализации, но не несущих бизнесс логики. Для этого по сущности кликаем два раза и в появившемся
окне во вкладке Attributes добаляем атрибуты (поля базы данных): название, код атрибутов, коментарий, домен и тип ключа. Домен
это логический тип, обозначающее какое значение может принимать атрибут, такой как дата, время, дата и время, процент,
текст, целое количество, вецественное количество, ID, булевое значение, банарное значение, текст. В
коментарии указывается логический смысл атрибута с учётом специфики
аднной сущности. В случае, если атрибут может быть измерен в разных единицах измерения, то в его свойствах указвается единица
измерения для автоматического преевода из одной системы измерения в другую. Создание же двух свойст, отражающих
одно свойство в разных единицах измерения противоречит уникальности атрибута, тоже касается и для других типов
атрибутов. Одним из атрибутов должне быть первичный ключь, который однозначно и уникально идетифицирует эту
сущность. В база данных, обычно, для удобства используют ID, который увеличивается с появлением нового экземпляра
сущности. Но это не обязательно и реализация может быть разной, так для банковской платёжной карты первичным ключём
является её "номер", который математически не является номером, а содержит идентификатор платёжной системы, идентификатор
выпустившей карту организации, идентификатор клиента и контрольную сумму. Чтобы указать, что поле является ключём устанавливается
её тип: P (Primary, первичный ключ). Также можно указать M (Mondatory) – обязательность заполнения.
Связи в области выбора примитивов SAP PowerDesigner представлены тремя типами: один ко дному, многие к одному, один ко
многим. Свзь типа "многие ко многим" разрешается через объединяющую сущность. Обязательность наличия привязки одной
сущности к другой устанавливается в свойстве параметров свзяи: Cardinality. Если Cardinality установлена как "0:1", то
связь не обязательна, а если – "1:1", то связь обязательна. Так, неоязательность будет отображаться на
связи маленьким кружочком, а обязательность – штрихом.