kbownerДоброго всем времени суток.
Есть таблица фактов.


Если мне не изменяет предчуствие мы тут начинаем иметь дело с Дата март? То есть Вы коллега строите Дименшинс? Расскажите поподробнее о Ваших бизнес задачах...

kbowner
Дата март я не делаю. Просто надо денормализовать/реструктуризировать существующую реляционную схему, чтобы
a) первичная задача - отчеты в cognos'е , много данных;
b) возможно потом будет перенос на warehouse . В примере - упрощенная часть схемы. Таких кусков около десятка . И у многих дименшинов есть пересекающиеся (одинаковые) аттрибуты - вроде приведенного в примере LOCATION.

Коллега - что то уж я совсем запутался. Cognos - очень любит как раз Data Mart representation of your data. Судя по вашей "неустроинности" или "неловкости" в агрегатном составлении данных Вы создаёте STAR - Schema. Это и есть реляционное представление аналитической информации. Чтобы Вам помочь - мне следовало бы навигировать Вас в область Аналитической Обработки данных.

Давайте я задам Вам бизнес вопрос - насколько важным для ваших Когнос юзеров является группирование данных по времени? Если данные группируются по -недельно [по] -месячно [по] -квартально - не раздумывайте более ни минуты - сводИте всё к дата март.

Коллега, для начала попробуем из определения отличий OLAP i OLTP. Нормализация характерна для ускорения ввода - изменения удаления данных при минимальном хранилище. Для ускорения поиска в большом объёме мы данные подготавливаемым индексируем, денормализуем - готовим для быстрого ПОИСКА и удобного ПРОСМОТРА. Это самое главное отличие. Постарайтесь ЭТО очень хорошо понять прежде чем начнутся ваши коренные изменения. Наличие повторяющихся аттрибутов в OLAP - вполне допустимо. Законы нормализации конечно же помагают - но ни в коем случае не определяют OLAP систему. Если Вы посмотрите большинство современных БД Дезайнерских систем - они на самом первом этапе создания дают возможность настроить систему или на "Реляционную" OLTP или "мулти-дименшинал" OLAP модель. Итак ответьть на Ваш вопрос - начните с маленькой STAR - схемки где будут [может быть] дубликаты ваших главных сущностей - Назовите их DimPerson; DimOrganisation; DimLocation; DimTime. Профактируйте всё в звёздочку ну например как это сделано вот тут

Вот там Вы и почувствуете зачем нам всё это надо.

Коллега, Тема эта неоднозначна и весьма многоплановая. Она не может быть решена "в общем" Не существует также и "общепринятого" ведения дела. Вся структура OLAP систем в первую очередь зависит от данных необходимых бизнесу. Никакая логика кроме Вашей Бизнес логики не может и не должна рассматриваться. Мой Вам дружеский совет - отступите назад на 10 шагов - начните разговоры с Бизнесом. Задавайте им самые глупые вопросы но начните с очень правильного "КАК БЫ ВЫ (бизнес пиплы) ПОКАЗАЛИ МНЕ (технарю) ЧТО ВАША РАБОТА СДЕЛАНА ХОРОШО". Не смотрите ни на STAR ни на SNOWFLAKE. Смотрите и изучайте репорты которые должны быть представлены. Найдите как они сегодня выглядят и как их хотят видеть Бизнес Пиплы.

А Значит разводите каждую группу вашего Data Mart. Не важно что NAME будут "очень похожи" Обратите внимание что в OLAP не работают натуральные ключи. Все они ИРРАЦИОНАЛЬНЫ. То есть например у вас есть кастомер Vera Inber которая была когда то Mary Picford. Тот же самый физически определённый человек. И Вам (может быть) понадобится следить за ВСЕМИ ее покупками на протяжении всей траснформации с ее адресами и фамилиями. Такая возможность тоже существует, но нужна ли вам она.... Это совершенно другой уровень задач, коллега и решать его Вы сможете только с Вашим бизнесом. Не со мной. Я Вам могу только немного подсказать если Вы поставите мне конкретную задачу Бизнеса - ни в коем случае не техническую.

Кстати простите моё незнание терминологии Русского Языка. Тема Топика "Хранилище данных - таблицы измерения+консольные" - что имеется ввиду?

Если перевести "в лоб" - Data warehouse - Dimensional Tables + Consol... Я не совсем понял ведь Вы где то говорили не про Датамарт? Или в значении Дата Март я допустил оплошность?

Вид Ваших табличек измерений будет - супермножество всех значений. Проиндексированных по всем (возможным) атрибутам) то есть если DimPerson - там будут все имена ваших кастомеров для которых когда либо велись какие либо бизнес операции. Ключём будет ИРРАЦИОНАЛЬНЫЙ ID - например последовательность чисел. То же будет с DimLocation - все Locations должны быть введены не зависимо какие - OrganisationLocation или PersonLocation - все будут введены и проиндексированы. Ключём опять же будет ИРРАЦИОНАЛЬНЫЙ ИДЕНТИФИКАТОР. Когда будете загружать можете добавить аттрибут LocationCode - перевести его значение по отношению к "P" - Person или "О" Organisation. Если потом появятся Location для склада ("W" - Warehouse) запросто добавите и переиндексируете. Это по поводу вашего вопроса. Теперь по поводу сути OLAP. Постарайтесь посмотреть на свою будующую систему как можно отвлечённее. Она в конце концов преднозначена для ответов на Business Questions. А Вопросы ети задаёте не Вы- пользователь. Data Mart - уменьшенная форма хранилища (Data warehouse). Необходима для ответов на локальные задачи поиска. Представьте себе универмаг - Warehouse. Отдел универмага - data mart. Задачи всего склада решаются в Warehouse. Задачи отдельного департамента - v datamart