Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Прошу совета по проектированию хранилища данных  [new]
Cardagant
Member

Откуда:
Сообщений: 190
Добрый день!

Есть проблема с проектированием хранилища данных, очень прошу направить на путь истинный!

Итак, в OLTP-базе есть 2 таблицы: одна таблица складских транзакций (InventTrans) вторая - таблица с агрегированными данными из первой (InventSum).

InventSum для упрощения содержит набор FK колонок, набор колонок с агрегированными данными по разным условиям (могу быть и сложные) из InventTrans и галочку Closed, которая показывает, что по данной комбинации FK запасов больше нет.

Пользователь хочет анализировать InventSum. Но при этом со временем там может появиться тьма записей с комбинациями FK, где наличие отсутствует.

Я так понимаю здесь подходит только вариант транзакционного факта, при этом перед каждой загрузкой данных требуется очищать эту таблицу от имеющихся записей, дабы не накапливать мусор с галкой Closed

Какой бы способ реализации применили Вы?

Заранее благодарю!
28 окт 14, 16:06    [16768363]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
кириллk
Member

Откуда:
Сообщений: 1044
Cardagant,

а работать только с "одна таблица складских транзакций" и агрегировать самому нельзя?
28 окт 14, 16:11    [16768405]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
Cardagant
Member

Откуда:
Сообщений: 190
кириллk,

Спасибо за ответ.

Там целая плеяда полей, которые собираются OLTP-системой на основе полей первой таблицы. Предложение реализовать на СКЛ всё, что делает OLTP-система?
28 окт 14, 16:24    [16768484]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 3547
Cardagant
кириллk,

Спасибо за ответ.

Там целая плеяда полей, которые собираются OLTP-системой на основе полей первой таблицы. Предложение реализовать на СКЛ всё, что делает OLTP-система?


Вам надо свести данные к схеме звезда или снежинка, то всё хорошо пойдёт в OLAP
28 окт 14, 16:32    [16768544]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
Cardagant
Member

Откуда:
Сообщений: 190
a_voronin,

Это я понимаю. То есть в данном случае всю логику, которую применяет OLTP для сбора агрегированной таблицы следует переложить таблицу фактов 1 (исходную InventTrans)?
28 окт 14, 16:35    [16768567]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1000
Cardagant, ага, Axapta Отпиши georgend @ mail.ru

С Уважением,
Георгий
28 окт 14, 16:57    [16768735]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
Cardagant
Member

Откуда:
Сообщений: 190
George Nordic,

ага, Аксапта) сейчас напишу, спасибо!
28 окт 14, 17:01    [16768766]     Ответить | Цитировать Сообщить модератору
 Re: Прошу совета по проектированию хранилища данных  [new]
Станислав Клевцов
Member

Откуда: Krasnodar-Russia
Сообщений: 559
Cardagant
Добрый день!

Есть проблема с проектированием хранилища данных, очень прошу направить на путь истинный!

Итак, в OLTP-базе есть 2 таблицы: одна таблица складских транзакций (InventTrans) вторая - таблица с агрегированными данными из первой (InventSum).

InventSum для упрощения содержит набор FK колонок, набор колонок с агрегированными данными по разным условиям (могу быть и сложные) из InventTrans и галочку Closed, которая показывает, что по данной комбинации FK запасов больше нет.

Пользователь хочет анализировать InventSum. Но при этом со временем там может появиться тьма записей с комбинациями FK, где наличие отсутствует.

Я так понимаю здесь подходит только вариант транзакционного факта, при этом перед каждой загрузкой данных требуется очищать эту таблицу от имеющихся записей, дабы не накапливать мусор с галкой Closed

Какой бы способ реализации применили Вы?

Заранее благодарю!


1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"

1.2. Хранилище планируете развернуть на отдельной машине ?

Тогда необходимо будет решать задачи :
  • Извлечения данных из разнородных источников;
  • Преобразования и очистки данных;
  • Загрузки данных в ХД;

    Вы готовы к этому ?
  • 30 окт 14, 14:25    [16777439]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Станислав Клевцов
    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"


    Это кто ж тебя такой чуши научил...
    30 окт 14, 20:08    [16779383]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Apex
    Станислав Клевцов
    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"


    Это кто ж тебя такой чуши научил...


    читал где-то ... это для бюджетного ХД пойдет.

    Для ХД можно использовать :
    https://ru.wikipedia.org/wiki/Greenplum -
    https://ru.wikipedia.org/wiki/Teradata - только вот цены кусаются
    из того что известно мне...но есть же и другие...

    Для построения хранилищ популярны несколько методологий:

    http://habrahabr.ru/post/227111/
    ...
    Во-первых это Кимбэл, и построение хранилища в виде комбинации «звезд». Одна из самых популярных методологий, т.к. ей учат во всех наших институтах, где читают про хранилища.

    Во-вторых, это Инмон.… Точнее не просто Инмон, а скорее инерция. Его подход к проектированию хранилищ содержит ряд красивых тезисов, вроде нормализации, но не содержит однозначного алгоритма, как именно преобразовать бизнес-модель в модель данных (в таблицы СУБД). Но всегда есть короткая дорога — можно взять таблицы исходной системы, из которой заполняется хранилище, перенести их AS IS, немного доработать и будет хранилище. Почти по Инмону.

    В третьих, это Data Vault. Относительно новая методология, но в России уже более-менее известная, даже статья в википедии на русском есть. Неплохая штука, есть и идеология, и алгоритм построения моделей.

    В четвертых, это Anchor Modeling. Совсем новая методология, местами шокирующая, т.к. предполагает хранение данных с соблюдением 6-й нормальной формы.
    ...
    30 окт 14, 21:06    [16779523]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Станислав Клевцов
    Apex
    пропущено...

    Это кто ж тебя такой чуши научил...


    читал где-то ... это для бюджетного ХД пойдет.

    Давай попробуем еще раз, я на этот раз выделю

    Станислав Клевцов
    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"
    31 окт 14, 07:04    [16780528]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Станислав Клевцов
    http://habrahabr.ru/post/227111/
    ...
    Во-первых это Кимбэл, и построение хранилища в виде комбинации «звезд». Одна из самых популярных методологий, т.к. ей учат во всех наших институтах, где читают про хранилища.

    Во-вторых, это Инмон.… Точнее не просто Инмон, а скорее инерция. Его подход к проектированию хранилищ содержит ряд красивых тезисов, вроде нормализации, но не содержит однозначного алгоритма, как именно преобразовать бизнес-модель в модель данных (в таблицы СУБД). Но всегда есть короткая дорога — можно взять таблицы исходной системы, из которой заполняется хранилище, перенести их AS IS, немного доработать и будет хранилище. Почти по Инмону.

    В третьих, это Data Vault. Относительно новая методология, но в России уже более-менее известная, даже статья в википедии на русском есть. Неплохая штука, есть и идеология, и алгоритм построения моделей.

    В четвертых, это Anchor Modeling. Совсем новая методология, местами шокирующая, т.к. предполагает хранение данных с соблюдением 6-й нормальной формы.
    ...

    Это, кстати, тоже каша какая-то. Data Vault - это не методология, это техника моделирования, нет там методологии. Методология как раз у Инмона и Кимбалла. А у Дэна грубо говоря способ замоделировать что-то для чего-то. Хороший способ, кстати, мне нравится, но на методологию все же не тянет.
    31 окт 14, 07:15    [16780540]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Cardagant
    Member

    Откуда:
    Сообщений: 190
    Станислав Клевцов,

    автор
    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"


    ДА, спасибо, теорию знаю :)

    автор
    1.2. Хранилище планируете развернуть на отдельной машине ?

    Тогда необходимо будет решать задачи :
    Извлечения данных из разнородных источников;
    Преобразования и очистки данных;
    Загрузки данных в ХД;

    Вы готовы к этому ?


    Подразумевается наличие хранилища СКЛ, которое будет наполняться посредством ССИС пакета.
    31 окт 14, 11:38    [16781965]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Apex
    Станислав Клевцов
    пропущено...


    читал где-то ... это для бюджетного ХД пойдет.

    Давай попробуем еще раз, я на этот раз выделю

    Станислав Клевцов
    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"


    '' (c ~43(44) минуты) не читал - а услышал в этом видео (поправка)

    ...
    В четвертых, это Anchor Modeling. Совсем новая методология, местами шокирующая, т.к. предполагает хранение данных с соблюдением 6-й нормальной формы.


    Интересно рассмотреть этот способ на примере.

    Допустим мы проектируем ХД, с помощью техники моделирования Data Vault для 2 сущностей нам необходимо будет наличие двух хабов, двух хаб-сателлитов и связь этих сущностей (линк и линк-сателлит). А как будет в Anchor Modeling ?
    31 окт 14, 19:46    [16785909]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Станислав Клевцов
    Apex
    пропущено...

    Давай попробуем еще раз, я на этот раз выделю

    пропущено...


    '' (c ~43(44) минуты) не читал - а услышал в этом видео (поправка)


    ОК, вечером гляну.

    Станислав Клевцов
    ...
    В четвертых, это Anchor Modeling. Совсем новая методология, местами шокирующая, т.к. предполагает хранение данных с соблюдением 6-й нормальной формы.


    Интересно рассмотреть этот способ на примере.

    Допустим мы проектируем ХД, с помощью техники моделирования Data Vault для 2 сущностей нам необходимо будет наличие двух хабов, двух хаб-сателлитов и связь этих сущностей (линк и линк-сателлит). А как будет в Anchor Modeling ?

    На каждый атрибут хаба будет отдельная таблица.
    1 ноя 14, 02:29    [16786927]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Apex
    Станислав Клевцов
    пропущено...


    '' (c ~43(44) минуты) не читал - а услышал в этом видео (поправка)


    ОК, вечером гляну.

    Ну, короче, там сильно поверхностное изложение, пример, приведенный на 43-й минуте - это всего лишь пример, т.е. один из возможных вариантов реалиазции, причем довольно простой, по понятным причинам, т.к. лекция явно расчитана на людей, которые вообще первый раз слушают о хранилищах. Делать вывод на основании этой лекции, что реализация должна быть именно такая и никакая иначе - как минимум неправильно, ибо хранилища данных не ограничиваются витринами.
    1 ноя 14, 05:49    [16787032]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Apex
    Apex
    пропущено...

    ОК, вечером гляну.

    Ну, короче, там сильно поверхностное изложение, пример, приведенный на 43-й минуте - это всего лишь пример, т.е. один из возможных вариантов реалиазции, причем довольно простой, по понятным причинам, т.к. лекция явно расчитана на людей, которые вообще первый раз слушают о хранилищах. Делать вывод на основании этой лекции, что реализация должна быть именно такая и никакая иначе - как минимум неправильно, ибо хранилища данных не ограничиваются витринами.


    Спасибо, что посмотрели пример.

    Apex
    ...лекция явно рассчитана на людей...
    ... хранилища данных не ограничиваются витринами...

    Согласен с вами.
    1 ноя 14, 14:45    [16787793]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Apex

    Клевцов Станислав
    Допустим мы проектируем ХД, с помощью техники моделирования Data Vault для 2 сущностей нам необходимо будет наличие двух хабов, двух хаб-сателлитов и связь этих сущностей (линк и линк-сателлит). А как будет в Anchor Modeling ?

    На каждый атрибут хаба будет отдельная таблица

    ... и поверх всех таблиц с атрибутами хаба будет витрина, собирающая все в одну кучу ?

    А в остальном все так же или есть какие - нибудь отличия?
    1 ноя 14, 14:56    [16787819]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Apex
    Станислав Клевцов
    пропущено...

    ...
    На каждый атрибут хаба будет отдельная таблица.


    В принципе здесь по шагам все описывается:

    http://www.anchormodeling.com/?page_id=186
    Приступимссс... :-)
    1 ноя 14, 22:58    [16788899]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    vmarch
    Member

    Откуда:
    Сообщений: 122
    Станислав Клевцов

    1.1. Реляционная база данных может быть хранилищем данных, но только в денормализованном виде

    Ненормализованные пространственные бд строятся чаще всего из схемы - "Звезда" или "Снежинка"


    ну вот почему бедную звезду или там снежинку упорно называют денормализованной...

    Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.

    https://ru.wikipedia.org/wiki/Денормализация

    Идеал денормализованного представления есть одна таблица содержащая буквально все в себе и не требующая джойнов вовсе.
    3 ноя 14, 22:36    [16794240]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Полковник.
    Member

    Откуда:
    Сообщений: 1626
    vmarch,

    Потому что одним из последних шагов при проектировании модели ХД по звезде является денормализация. Вы об этом не знали?
    3 ноя 14, 23:04    [16794413]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    vmarch
    Member

    Откуда:
    Сообщений: 122
    Cardagant
    Добрый день!
    ... в OLTP-базе есть 2 таблицы: одна таблица складских транзакций (InventTrans) вторая - таблица с агрегированными данными из первой (InventSum).

    InventSum для упрощения содержит набор FK колонок, набор колонок с агрегированными данными по разным условиям (могу быть и сложные) из InventTrans и галочку Closed, которая показывает, что по данной комбинации FK запасов больше нет.

    Пользователь хочет анализировать InventSum. Но при этом со временем там может появиться тьма записей с комбинациями FK, где наличие отсутствует.



    pardon, у Вас хранилище проектируется или витрина данных по состоянию на данный момент? подход немного разнится. В хранилище скорее всего надо предусмотреть возможность воспроизвести ситуацию "А что у нас, мнэээ, месяц назад было?" А месяц назад эта вот запись в InventSum не была Closed.


    Судя по всему, пользователя интересует только "здесь и сейчас". Тогда смело
    Cardagant
    очищать эту таблицу от имеющихся записей, дабы не накапливать мусор
    3 ноя 14, 23:14    [16794467]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    vmarch
    Member

    Откуда:
    Сообщений: 122
    Полковник.
    vmarch,

    Потому что одним из последних шагов при проектировании модели ХД по звезде является денормализация. Вы об этом не знали?


    извините, частичная денормализация - что еще в свою очередь не означает денормализованности звезды как таковой ;).
    3 ноя 14, 23:21    [16794499]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Cardagant
    Member

    Откуда:
    Сообщений: 190
    vmarch,

    Как раз-таки хранилище проектирую.
    4 ноя 14, 15:34    [16796227]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    vmarch
    Member

    Откуда:
    Сообщений: 122
    Cardagant
    vmarch,

    Как раз-таки хранилище проектирую.


    ок, тогда предлагается забыть о флаге "Closed" и перейти на логику "время жизни записи" в аггрегате from to
    4 ноя 14, 17:10    [16796597]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Cardagant
    Member

    Откуда:
    Сообщений: 190
    vmarch,

    То есть Вы предлагаете делать такой себе SnapShot для каждой строки?
    4 ноя 14, 18:12    [16796869]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Станислав Клевцов
    Apex
    пропущено...

    ...
    На каждый атрибут хаба будет отдельная таблица.


    В принципе здесь по шагам все описывается:

    http://www.anchormodeling.com/?page_id=186
    Приступимссс... :-)


    Посмотрел видео... Итого имеем:
    1. Anchor table (якорь)
  • содержит только один столбец - для идентичности сущности
  • не изменяем
  • может не иметь атрибутов вообще или иметь сразу целое множество атрибутов

    2. Knot table (узел)
  • содержит два столбца: один для идентичности и один для значения.
  • используются для хранения конечного множества значений, как правило, для описания состояния - сущностей (через knotted attributes) или отношений (через knotted ties).
  • имеет свои суррогатные ключи и, следовательно, не изменяем.
  • должен иметь значения, которые являются взаимоисключающими и исчерпывающими.
  • не может хранить историю изменений значений.

    3. Attrubute table (атрибут)
  • содержит два столбца: один для идентичности сущности и один для значения атрибута
  • исторический атрибут содержит три столбца: для идентичности сущности, для значения атрибута и факт времени.
  • не изменяем
  • значение атрибута может измениться только со временем
  • атрибуты могут быть в 4 состояниях : static, historized, knotted static, and knotted historized.

    4.Tie table (отношение \ связь)
  • используются для связи 2 сущностей
  • они могут быть в 4 состояниях: static, historized, knotted static, and knotted historized.
  • каждый объект, который является членом в отношении имеет заданную роль в отношении.
  • может иметь от 1 до N узлов (knot) или не иметь их вообще

    Поправьте меня, если что - то не понял из видео.
  • 5 ноя 14, 17:46    [16802239]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3896
    Станислав Клевцов
    для идентичности сущности

    Я не понимаю, что это значит. Либо напиши по-английски, либо на русский нормально переведи.
    6 ноя 14, 03:38    [16803944]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Станислав Клевцов
    Member

    Откуда: Krasnodar-Russia
    Сообщений: 559
    Клевцов Станислав
    Apex
    для идентичности сущности

    т.е. имел ввиду Id сущности

    Apex
    Я не понимаю, что это значит. Либо напиши по-английски, либо на русский нормально переведи.


    Информацию нашел в 3 источниках:
    1) Видео с www.anchormodeling.com

    2)
    http://en.wikipedia.org/wiki/Anchor_Modeling
    In Anchor Modeling there is a one-to-one mapping between the symbols used in the conceptual model and tables in the relational database. Every anchor, attribute, tie, and knot have a corresponding table in the database with an unambiguously defined structure. A conceptual model can thereby be translated to a relational database schema using simple automated rules, and vice versa. This is different from many other modeling techniques in which there are complex and sometimes subjective translation steps between the conceptual, logical, and physical levels.

    Anchor tables contain a single column in which identities are stored. An identity is assumed to be the only property of an entity that is always present and immutable. As identities are rarely available from the domain being modeled, they are instead technically generated, e g from an incrementing number sequence.

    An example of an anchor for the identities of the nephews of Donald Duck is a set of 1-tuples:
    {⟨#42⟩, ⟨#43⟩, ⟨#44⟩}

    Knots can be thought of as the combination of an anchor and a single attribute. Knot tables contain two columns, one for an identity and one for a value. Due to storing identities and values together, knots cannot be historized. Their usefulness comes from being able to reduce storage requirements and improve performance, since tables referencing knots can store a short value rather than a long string.

    An example of a knot for genders is a set of 2-tuples:
    {⟨#1, 'Male'⟩, ⟨#2, 'Female'⟩}

    Static attribute tables contain two columns, one for the identity of the entity to which the value belongs and one for the actual property value. Historized attribute tables have an extra column for storing the starting point of a time interval. In a knotted attribute table, the value column is an identity that references a knot table.

    An example of a static attribute for their names is a set of 2-tuples:
    {⟨#42, 'Huey'⟩, ⟨#43, 'Dewey'⟩, ⟨#44, 'Louie'⟩}

    An example of a knotted static attribute for their genders is a set of 2-tuples:
    {⟨#42, #1⟩, ⟨#43, #1⟩, ⟨#44, #1⟩}

    An example of a historized attribute for the (changing) colors of their outfits is a set of 3-tuples:
    {⟨#44, 'Orange', 1938-04-15⟩, ⟨#44, 'Green', 1939-04-28⟩, ⟨#44, 'Blue', 1940-12-13⟩}

    Static tie tables relate two or more anchors to each other, and contain two or more columns for storing the identities. Historized tie tables have an extra column for storing the starting point of a time interval. Knotted tie tables have an additional column for each referenced knot.

    An example of a static tie for the sibling relationship is a set of 2-tuples:
    {⟨#42, #43⟩, ⟨#42, #44⟩, ⟨#43, #42⟩, ⟨#43, #44⟩, ⟨#44, #42⟩, ⟨#44, #43⟩}

    The resulting tables will all be in sixth normal form except for ties in which not all columns are part of the primary key.


    3)

    www.anchormodeling.com
    -- KNOTS --------------------------------------------------------------------------------------------------------------
    --
    -- Knots are used to store finite sets of values, normally used to describe states
    -- of entities (through knotted attributes) or relationships (through knotted ties).
    -- Knots have their own surrogate identities and are therefore immutable.
    -- Values can be added to the set over time though.
    -- Knots should have values that are mutually exclusive and exhaustive.
    --

    -- ANCHORS AND ATTRIBUTES ---------------------------------------------------------------------------------------------
    --
    -- Anchors are used to store the identities of entities.
    -- Anchors are immutable.
    -- Attributes are used to store values for properties of entities.
    -- Attributes are mutable, their values may change over one or more types of time.
    -- Attributes have four flavors: static, historized, knotted static, and knotted historized.
    -- Anchors may have zero or more adjoined attributes.

    -- TIES ---------------------------------------------------------------------------------------------------------------
    --
    -- Ties are used to represent relationships between entities.
    -- They come in four flavors: static, historized, knotted static, and knotted historized.
    -- Ties have cardinality, constraining how members may participate in the relationship.
    -- Every entity that is a member in a tie has a specified role in the relationship.
    -- Ties must have at least two anchor roles and zero or more knot roles.
    --



    Из этого всего попытался понять и получилось вот это
    Клевцов Станислав
    1. Anchor table (якорь)
    содержит только один столбец - для идентичностиId сущности
    не изменяем
    может не иметь атрибутов вообще или иметь сразу целое множество атрибутов

    2. Knot table (узел)
    содержит два столбца: один для идентичност id и и один для значения.
    используются для хранения конечного множества значений, как правило, для описания состояния - сущностей (через knotted attributes) или отношений (через knotted ties).
    имеет свои суррогатные ключи и, следовательно, не изменяем.
    должен иметь значения, которые являются взаимоисключающими и исчерпывающими.
    не может хранить историю изменений значений.

    3. Attrubute table (атрибут)
    содержит два столбца: один для идентичностиid сущности и один для значения атрибута
    исторический атрибут содержит три столбца: для идентичности сущности, для значения атрибута и факт времени.
    не изменяем
    значение атрибута может измениться только со временем
    атрибуты могут быть в 4 состояниях : static, historized, knotted static, and knotted historized.

    4.Tie table (отношение \ связь)
    используются для связи 2 сущностей
    они могут быть в 4 состояниях: static, historized, knotted static, and knotted historized.
    каждый объект, который является членом в отношении имеет заданную роль в отношении.
    может иметь от 1 до N узлов (knot) или не иметь их вообще

    это черновой вариант
    изучаю другие источники информации
    6 ноя 14, 14:28    [16806240]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    vmarch
    Member

    Откуда:
    Сообщений: 122
    Cardagant
    предлагаете делать такой себе SnapShot для каждой строки?


    Если речь идет о хранилище в котором храяится история аггрегатов (и самому по фактам аггрегаты считать в лом) то да. Только для меня это скорее "потоковое видео" чем снэпшот ;). Снэпшотом будет некий временной срез такого представления.

    Если же заказчика интересует "здесь и сейчас" - то транкейт целевой таблицы аггрегатов в руки.
    Из описания хотелок так вот запросто понять "чего надо та" у меня не получилось.
    6 ноя 14, 19:48    [16808167]     Ответить | Цитировать Сообщить модератору
    Между сообщениями интервал более 1 года.
     Re: Прошу совета по проектированию хранилища данных  [new]
    мигель1
    Member

    Откуда:
    Сообщений: 3352
    vmarch,
    Хочу переделать звезду на Якорь

    Есть таблица товар (Id фрукта) - Dim
    Есть таблица чеки (Id чека , сумма чека, Id фрукта) - FCT

    Таблицу фактов как превратить в якорь?
    10 дек 17, 17:14    [21021948]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    мигель1
    Member

    Откуда:
    Сообщений: 3352
    мигель1,

    Сателиты?
    10 дек 17, 17:58    [21021998]     Ответить | Цитировать Сообщить модератору
     Re: Прошу совета по проектированию хранилища данных  [new]
    Полковник.
    Member

    Откуда:
    Сообщений: 1626
    мигель1
    vmarch,
    Хочу переделать звезду на Якорь

    Есть таблица товар (Id фрукта) - Dim
    Есть таблица чеки (Id чека , сумма чека, Id фрукта) - FCT

    Таблицу фактов как превратить в якорь?


    Таблицу фактов? Да легко - это много якорей и галстуков, их связывающих.
    16 дек 17, 10:55    [21038893]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2      [все]
    Все форумы / OLAP и DWH Ответить