Построение БД

← →
Palladin © (2005-02-24 21:32) [0]

Хотелось бы потрепаться на эту тему, выслушать критику и вообще замечания.

Как известно чем выше нормаль базы тем строже соблюдается целостность. Но. Как замечено на личной практике, то же самое повышение нормали базы очень сильно снижает производительность при получении сводных данных, а еще точнее все сводится к использованию group by и в совокупности с merge (не знаю как наиболее точно это сказать по русски :), объединение? - однако union, совокупность? - не то... свод, может быть наиболее подходящее) нескольких таблиц. Все это дело мне надоело с год назад. В результате я решил строить параллельно с основной базой, имеющий наиболее высокую нормаль, базу-синоним, которая имеет наиболее низкую нормаль (степень нормали конечно же выбирается по ситуации). К сожалению построение базы-синонима тоже весчь очень тонкая. Если превысить, а точнее принизить :), нормаль, получится толпа таблиц (или как я их называю матриц), с огромным количеством полей и, соответсвенно, записей. В этом случае очень много времени уходит на scan table. Недоперенизить нормаль, сводит на нет смысл существования базы-синонима.
В общем то из этого и возникает вопрос. Существуют ли универсальные методы построения баз-синонимов... и вообще существуют ли базы-сононимы в теории БД или это чисто мои выкрутасы...

← →
Sergey_Masloff (2005-02-24 21:42) [1]

Что-то ты замутил не то ;-)
Есть как ты, естественно, знаешь системы OLTP и OLAP. Давай придерживаться этих терминов. Есть OLTP база в которой много простых операций и высокая (обычно) степень нормализации. Мы в коллективе используем чаще термин денормализация то есть база не с высокой нормализацией а с низкой денормализацией. Работает все быстро, но получать всевозможные сводные отчеты может быть не слишком просто. Типовое решение -> пакетная выгрузка данных в хранилище, то есть вторую базу - денормализованную где данные хрянятся так чтобы максимально удобно было отображать их на разные учетные проекции (разрезы) и анализировать. Общего у этих баз весьма немного, считать их синонимами... хм... не очень корректно.
Универсальных методов построения OLAP-ов конечно нет, тем более все очень сильно меняется от того что конкретно от хранилища нужно. Ну и параллельно одному проектировать OLTP и OLAP подсистемы одному человеку нереально. Совершенно разные принципы и руку набивать надо совсем по-разному. Такая моя ИМХА.

← →
Palladin © (2005-02-24 21:57) [2]

Давай придерживатся этих терминов :) Хотя они мало чего говорят простому человеку. Который с ними не знаком, хотя использует принципы заложенные в них давным давно. Читай - самоучка.

Точно, я вспомнил, что я читал, что эти т.н. базы-синонимы - есть денормализированные OLAP ... только писать это дольше :) проще база-синоним. Синоним потому что данные теже, но в другой структуре. Название корректно.

OLAP в исполнении СУБД это круто, это замечательно, но дорого. MS Online Analize (или как его там) - нафик никому не надо, когда все узнают сколько же это будет стоить... Oracle Cube (или как его там)... еще хуже по соотношению цена/качество.

Грубо говоря, база-синоним и является этими кубами. Довольно простое и дешевое решение. Параллельное заполнение/модификация этих двух баз. Глобальные отчеты строятся по OLAP, целостность бережется по OLTP. Соответственно облегчается брокер данных на толпу предохранителей.
Ну что еще можно сказать в защиту.... :)

← →
Palladin © (2005-02-24 21:58) [3]

> Ну и параллельно одному проектировать OLTP и OLAP подсистемы
> одному человеку нереально.

Ну блин приходится....

← →
Sergey_Masloff (2005-02-24 22:14) [4]

Ну погоди. Мы немножко о разном похоже. В OLAP обычно НЕ ТЕ данные. А уже сагрегированные, и они там лежат не в виде удобном для определенных отчетов а в виде в котором их удобно брать для различных анализов ВНЕШНИМИ как правило средствами. Для мелких систем (ну миллион строк агрегированных данных) очень неплохо зарекомендовал себя OLAP-пакет в составе Excel. А еще некоторые говорят что 800 у.е. за мс офис дорого - да в екселе олар такой что некоторым системам по 30 тыс. у.е. не снилось. Но это я уже как обычно в оффтоп.
К сожалению по этой теме я продуктивно трепаться не могу - все же мне больше по OLTP приходится по работе сталкиваться, хотя сейчас частично придется...

← →
Palladin © (2005-02-24 23:14) [5]

Нет, с Excel ты не прав. В Excel существует жуткое ограничение на 65535 строк чего бы то нибыло. Генерируя свои кубы, он вычисляет каждый итог, каждый подитог и тд и тп, рекурсивно. Соответственно, при существовании количества стро 1удx2удx3уд..xNуд (уд - уникальный данный :) ), превышающего 65535 строк в сводной таблице вместе с подитогами (которых может быть немеряно) Эксель становится абсолютным ничем. Excel - очень мощное средство при малом. Я ни в коем мере не собираюсь его обкакивать, более того, он мне очень помгает именно в мизерных данных. Но догадайся откуда берутся тим мизерные данные... точно... из группировок на основе базы-синонима...

В OLAP именно те данные, сгруппированные итоговые суммы по кубам в разных измерениях. В том то и дело. Стоят дорого.

Говорим мы похоже об одном и том же. Хотя...

> Palladin ©
"сисю и писю одной рукой не схваитишь"
Поэтому рук надо две,то есть разделить на OLTP и OLAP базы.
Высокая нормализация решает проблему быстрого модифицирования (insert/update/delete). Какие бы извращенные задачи ни были, при высокой нормализации они в большинстве случаев работают быстрее.
При высокой нормализации и извращенные "кубические" запросы тоже, как ни странно, работают быстрее, по одной простой причине - нормализованные данные занимают меньше блоков, а узкое место любой системы обработки данных - ввод/вывод. Но быстрее они работают до определенного предела - когда затраты памяти/cpu на обработку этих огромных массивов начинают играть роль.
Вывод такой - "кубические" (OLAP) запросы по небльшим объемам выгоднее делать прямо с OLTP-базы. А если объем (как правило, период) большой? Раз в какой-то период скидывать данные в денормализованную базу. Фактически работу, требующую памяти/cpu, провести один раз.
Как определить период скидывания, он же период, запросы за который лучше делать по OLAP-базе? Ваша база - считайте, анализируйте :)

при больших объемах нет альтернативы OLAP, пользователь не будет полчаса ждать отчета, да и для сервера другие дела есть, лучше на ночь запустить процедуру построения куба, данные будут чутка устаревшие, но обычно для аналитических отчетов не нужна опертивность

Как мы поступаем. У нас разные учетные задачи решаются разными средствами, иногда даже в разных СУБД. Дальше данные сливаются в одну таблицу фактов, которая не является, конечно ненормальзованной, однако состоит ID измерений и сумм на каждый период (декада, месяц, квартал, полугодие). Потом есть внешний app server, который проводит консолидацию данных этой таблицы, используя формулы, и т.д. После чего данные попадают в наперед сформированные шаблоны отчетов или в OLAP-грид. Консолидация запускается шедулером ночью. Если же нужно получать данные с детализацией по дням, тогда мы используем первичные данные.

Построение БД Найти похожие ветки