|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Konstantin Lissianski 2:5020/400 19 Jul 2001 14:06:02
To : All
Subject : Re: Моделирование (круг второй)...
--------------------------------------------------------------------------------
Добрый день,
> Я категорически против вложенных объектов и деревьев, при такой структуре
> многие связи становятся опосредованными, и поиск идет медленно. Я хочу,
чтобы
> все связи между всеми сущностями были прямыми с возможностью
индексирования.
> Выглядит это в виде многомерного куба. Каждое измерение - это некий
атрибут. В
> этом кубе есть точки, отражающие некий факт.
>
> Hапример, имеем куб:
> -покупатели
> -накладные
> -товары
>
> точка обозначает, что этот покупатель купил этот товар по этой накладной.
> Если мы захотим выбрать все товары, которые купил Сидоров, мы сделаем
запрос в
> плоскости "покупатели - товары", минуя накладные.
>
> В реляционной модели с 3-мя таблицами пришлось бы использовать
объединение,
> или подзапрос.
Реализуется это так называемой схемой "звезда". В центральной таблице
хранятся фактические показатели, вокруг - таблицы размерностей, содержацие
атрибуты, описывающие размерности.
Для выполнения запроса необходимо сделать объединение таблиц размерностей с
таблицей фактов. Hазывается это star join. Есть специальные СУБД, которые
этот star join умеют хорошо оптимизировать. Hапример, СУБД Red Brick.
Размерность "покупатель" будет лежать в своей таблице, размерность
"накладная" в другой.
Если надо только продажи в разрезе покупателей, а накладные не надо, то
объединяем таблицу фактов с таблицей размерности "покупатель", накладные не
трогаем. В итоге - объединение всего двух таблиц.
>
> В базе данных мы имеем многомерный разреженный массив, где нет вложений,
> соответственно, нет Join.
В таких базах данных существует проблема с хранением разреженных матриц,
однако их производители постепенно учатся как с ней бороться.
>
> Это OLAP.
Точно.
Предназначена данная технология исключительно для анализа данных. Для ввода
данных нужно использовать традиционные системы. Данные в многомерную базу
OLAP закачиваются скопом в большом количестве, поскольку там еще имеется
этап расчета агрегированных показателей.
В общем, OLAP не является универсальным средством - только анализ.
У вас же, как мне кажется, дискуссия на другую тему.
> Может кто копал глубже эту тему ? Мне кажется, что направление
правильное...
Я копал. Мне этим по долгу службы приходится заниматься. Так что если есть
вопросы про OLAP - мыльте.
У меня на сайте есть подборка ссылок на ресурсы по многомерному
моделированию и OLAP. Там же и список литературы с аннотациями и еще
кое-что.
http://lissianski.narod.ru
Добро пожаловать.
С уважением,
Константин Лисянский
mailto:lissianski@mail.ru
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Моделирование (круг второй)... 