Читайте также:
|
Понять сущность Связь (таблица Связь (Link)) значит понять природу взаимоотношений внутри бизнеса. Например, когда человек бизнеса заявляет: «вот номер счета-фактуры», большинство вовлеченных в этот бизнес знают, что это означает. Конечно интерпретации того, что счет-фактура действительно означает для разных групп, может отличаться – поэтому определение метаданных должно проводиться по всей компании. Однако, когда то же самое лицо заявляет: «этот счет-фактура выписан клиенту X», то этим уже установлены отношения между заказчиком и счетом-фактурой.
И клиент, и счет-фактура – это отдельные сущности. Иными словами, счет-фактура не всегда требует данных о клиенте (счета-фактуры могут быть внутренними), а клиент может иметь контакты только с маркетингом и, возможно, не иметь ни одного выставленного ему счета. Общее деловое чутье говорит нам, что необходимо связать счет, по крайней мере, с одним клиентом (под клиентом, может пониматься корпорация, индивидуальное лицо и т.п.).
Существует другая вложенная тема к этим выражениям: реальное время, предприятие с нулевой задержкой, близко к реальному времени, по требованию. Назовите, что будет у вас? Архитектуры моделей данных сегодня (за исключением Data Vault) зависят от наборов данных и времени прохождения данных через обрабатывающие системы, что делает невозможным осуществлять синхронизацию данных в режиме близком к реальному времени. Data Vault, частично из-за таблицы Связи, частично из-за того, как структурированы Хабы, позволяет практически в реальном времени питать данные «позднего связывания» («late-bind» data) или синхронизировать данные при их прибытии. Конечно, это является предметом метаданных, и я отвлекся – так давайте вернемся обратно на уровень выше, и сосредоточим внимание на взаимосвязях между элементами.
Определение, которое приводится в 1-ой статье Серии выглядит следующим образом: «Связь представляет собой отношения или транзакции между двумя или более бизнес-компонентами (двумя или более бизнес-ключами)». Сущность Связь может выглядеть следующим образом:
Рисунок 2-1. Связь Клиента и Счет-Фактуры
Здесь показано только два слоя детальный данных: клиент со счетами-фактурами. Чтобы добавить другие детальные данные, добавьте другие Хабы или другие Связи. Приведенное выше изображение показывает, что клиент с идентификатором 1 связан со счетом 100, а клиент с идентификатором 2 связан со счетом 101. Конечно, верхняя и нижняя таблица – Customer Hub и Invoice Hub соответственно.
А что относительно отношений «один к одному», «один ко многим» или «многие к одному»?
Мы пока не рассматриваем управление процессами загрузки, наполняющими структуры данных. Есть несколько важных причин, почему мы реализуем структуру Связей независимо от типа отношений:
a. 1. Будущая расширяемость (extensibility) – мы можем легко добавлять Хабы c дополнительными Связями в наши существующие модели хранилищ данных, не нарушая существующую историю. Это важно для успешного развития модели в будущем. Особенно сегодня, когда требования бизнеса быстро меняются – информационные системы и модели данных должны быть в состоянии идти в ногу. В будущем эта архитектура может играть роль на физическом уровне динамически расширяемых моделей данных.
b. 2. Изменение бизнес правил – сегодня правило может быть «один к одному», в будущем, бизнес может продиктовать, что на самом деле, один клиент может быть связан с более чем с одним счетом-фактурой, или, возможно, один счет-фактура может быть направлен нескольким клиентам. Когда бизнес меняется, эта структура оставляет модель понятной и позволяет сохранить историю, в то время как новые правила начинают применяться.
c. 3. Неуместные (Misplaced) Данные – Слишком часто в существующих архитектурных моделях есть данные, ассоциируемые с таблицами, имеющими составные ключи, но не подходящие этим таблицам. В этой архитектуре моделирования становится проще обнаружить ошибки моделирования и исправить их, иными словами поставить данные в то место, которому они принадлежат, непосредственно с соответствующим ключом.
d. 4. Контроль Степени детализации – повсеместное поддержание степени детализации информации очень важно. Удостоверьтесь, что информация или элементы данных размещаются в соответствии их назначению и смыслу, а также, что агрегация контролируется степенью детализации ключей. Добавление еще одного ключа к сущности Связь очень похоже на добавление еще одного измерения к таблице фактов. Это может изменить степень детализации Спутников, связанных со Связью. Для таблицы Связи, не имеющей Спутников, вносить изменения очень легко.
Зачем сразу создавать таблицы Связи?
Частично этот вопрос был рассмотрен в 1-ой статье серии. Важно признать, что объекты существуют в нашем физическом мире без приписывания к другим объектам. Автомобили существуют без водителей, бутылки содовой существуют без потребителей, брюки существуют без владельцев. Эти элементы снабжены ярлыками, пронумерованы, и некоторым способом идентифицированы. Когда человек становится потребителем, владельцем или пользователем, то он становится связанным с этими объектами. Это имеет жизненно-важное значение для повышения уровня понимания информации, имеющейся в нашем распоряжении. Без ассоциации информации у нас есть большая проблема распознавания паттернов и причин существования этих паттернов.
Ассоциации могут быть извлечены из первичных и внешних ключей, но почему разделяют их на таблицы связей?
По большей части бизнес заинтересован не только в ассоциациях, но и в паттернах (моделях) ассоциаций и в ориентирование в этих ассоциациях. Отделяя ассоциативные данные, мы можем начать применять логические механизмы (inference engines) к этим паттернам, и узнать новые факты, возможно, упущенные нами ранее. Основная причина заключается в гибкости. Ассоциации изменяются с течением времени. Как только я потребляю бутылку содовой, я избавляюсь от бутылки, отправляя ее на переработку (утилизацию) – теперь переработчик является владельцем бутылки, а не я. Если история этих отношений может быть отслежена, то в будущем отношения могут регулироваться через различные методы воздействия. Это широко известно, как использование интеллектуального анализа (data mining), для нахождения умозаключений и ассоциативных паттернов, сегментации и детерминированных паттернов, скрытых в данных, которые мы могли бы пропустить и не найти, если бы не извлекали.
Эти ассоциативные паттерны, однажды помещенные в таблицу Связи, легче обнаружить, в будущем легче произвести гибкие архитектурные изменения модели данных, и исследовательские отношения могут быть созданы, измерены и удалены по желанию (или автоматически).
Дата добавления: 2014-12-15; просмотров: 34 | Поможем написать вашу работу | Нарушение авторских прав |