Опубликован: 20.12.2010 | Уровень: специалист | Доступ: платный
Лекция 13:

Метод моделирования "Свод данных"

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

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

Сущности-сателлиты обычно содержат следующие атрибуты:

  • первичный ключ — первичный ключ концентратора или связи, который мигрировал в сателлит;
  • временная метка загрузки (Load Data/Time Stamp) – это дата и время записи описательной информации в БД;
  • источник данных (Record Source) – записывается для трассировки данных;
  • сущности-сателлиту может быть назначен суррогатный первичный ключ.
Сущность-сателлит для адреса покупателя

Рис. 18.5. Сущность-сателлит для адреса покупателя

На рис. 18.5 приведена сущность-сателлит, содержащая информацию об изменении адреса клиента во времени. Атрибут "Время загрузки" является частью составного первичного ключа. Поскольку данные упорядочены по времени, основное назначение сущности-сателлитаобеспечить описание ключа концентратора. Табл. 12.3 иллюстрирует содержание соответствующих сущностям таблиц БД.

Таблица 18.3. Таблицы базы данных, представляющие концентратор и сущность-сателлит
Концентратор для покупателей
Номер Номер покупателя в источнике данных Время загрузки из источника Наименование источника данных
1 1234 23.01.2009 Продажи
2 1235 24.01.2009 Контракты
Сателлит для адреса покупателей
Номер покупателя Время загрузки Наименование источника Адрес
1 23.01.2009 Паспорт ул. Первая, д.1, кв. 1
1 15.03.2009 Паспорт Институтский пр., д. 6, кв. 3
2 24.01.2009 Паспорт ул. Вторая, д. 3, кв. 2
2 14.02.2009 Паспорт ул. Коммунальная, д. 2, кв. 4.

Сущность "Момент времени" (Point-In-Time) является производной от сателлита. Она строится для обеспечения поиска информации для заданных моментов времени. Пример сущности "Момент времени" приведен на рис. 18.6 ниже. Табл. 18.4 иллюстрирует содержание соответствующих сущностям таблиц БД (структура таблиц упрощена в целях наглядности).

Пример сущности "Момент времени"

Рис. 18.6. Пример сущности "Момент времени"
Таблица 18.4. Таблицы базы данных, представляющие сущность "Момент времени", "Изменение данных о покупателе" – концентратора для покупателей и его сателлитов
Изменение данных о покупателе
Номер покупателя Время загрузки изменений Время загрузки адреса Время загрузки имени
1 23.01.2009 23.01.2009 23.01.2009
1 15.03.2009 15.03.2009 15.03.2009
1 31.04.2009 31.04.2009 15.03.2009
Концентратор для покупателей
Номер Номер покупателя в источнике данных Время загрузки из источника Наименование источника данных
1 1234 23.01.2009 Продажи
Сателлит для адреса покупателей
Номер покупателя Время загрузки Наименование источника Адрес
1 23.01.2009 Паспорт Ул. Первая, д.1, кв. 1
1 15.03.2009 Паспорт Институтский пр., д. 6, кв. 3
Сателлит для имени покупателя
Номер покупателя Время загрузки Наименование источника Фамилия
1 23.01.2009 Паспорт Прохоров

Сущность "Момент времени" является производной от сателлита. Она строится для обеспечения поиска информации для заданных моментов времени.

Сущность-мост (Bridge) содержит временные метки последней загрузки. Эта сущность подобна сущности "Момент времени", но охватывает всю предметную область или схему данных.

Бизнес-пользователи часто хотят видеть данные, сгруппированные различным образом. В простейшем случае одно подразделение (к примеру, отдел маркетинга) имеет свою иерархию покупателей, а другое подразделение (к примеру, отдел продаж) имеет другую иерархию тех же покупателей. Можно включить обе иерархии в измерение "Покупатель". Однако несколько иерархий, встроенных прямо в измерение, сделают его малопригодным для использования.

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

Для поддержки дополнительных иерархий в ХД создается отдельная таблица, с помощью которой пользователь может сгруппировать данные по любой из имеющихся иерархий. Это и есть сущность-мост, или таблица-мост (bridge table). На рис. 18.7 показан пример такой промежуточной таблицы "Географическое положение покупателя" (CustomerRegionHierarchy) для группировки по географическому положению.

Пример сущности-моста

увеличить изображение
Рис. 18.7. Пример сущности-моста

В запросе значение поля "Имя иерархии" ( HierarchyName ) задает необходимую группировку данных. Например, предикат в предложении WHERE HierarchyName = 'Отдел маркетинга' задает группировку данных для отдела маркетинга.

Каждая иерархия в промежуточной таблице должна быть полной, т.е. начинаться с того уровня базового измерения, к которому присоединена промежуточная таблица, и заканчиваться самым верхним уровнем. Например, таблица "Географическое положение покупателя" (CustomerRegionHierarchy) соединена с уровнем "Область" (State).

Для упрощения анализа и создания отчетов промежуточная таблица должна содержать описание и стандартной иерархии. Стандартная иерархия становится используемой по умолчанию во всех предварительно настроенных отчетах, но пользователю предоставляется возможность переключиться на другую иерархию. Отдельная таблица "Иерархия" (Hierarchy) с одной строкой на каждую иерархию упрощает поддержку системы, но визуально усложняет дизайн. При необходимости можно провести денормализацию и объединить таблицы "Иерархия" (Hierarchy) и "Географическое положение покупателя" (CustomerRegionHierarchy).

Сущность-связь для группировки пользователей (User Grouping Link) содержит информацию, которая предоставляет пользователю определенную точку зрения на данные, но не влияет на содержание данных в ХД. Таблица 18.5 показывает, как используется сущность-связь для группировки пользователей.

Таблица 18.5. Использование сущности-связи для группировки пользователей (ключевые атрибуты выделены жирным шрифтом)
Таблица измерения "Группы покупателей"
ID Метка группировки Дата загрузки Описание источника
1 Крупные покупатели 10.04.2009 Excel
2 Мелкие покупатели 12.04.2009 Excel
Сущности-связи для группировки пользователей
Номер группы Номер покупателя Дата загрузки Описание источника
1 100 14.04.2009 Excel
2 101 14.02.2009 Excel
ID Номер покупателя Дата загрузки Описание источника
100 100ADB12 14.04.2009 Finance
101 ADF-1 14.04.2009 Finance

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

Мы рассмотрели основные и дополнительные элементы модели "Свод данных" и можем перейти к описанию общего алгоритма построения модели ХД описанным выше методом.

Владислав Нагорный
Владислав Нагорный

Подскажите, пожалуйста, планируете ли вы возобновление программ высшего образования? Если да, есть ли какие-то примерные сроки?

Спасибо!

Лариса Парфенова
Лариса Парфенова

1) Можно ли экстерном получить второе высшее образование "Программная инженерия" ?

2) Трудоустраиваете ли Вы выпускников?

3) Можно ли с Вашим дипломом поступить в аспирантуру?

 

Владимир Вишневский
Владимир Вишневский
Россия, Москва
Ольга Балуева
Ольга Балуева
Россия