СУБД и деревья

[alexus]

Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
4. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
5. Значение показателя в денежном выражении [VAL_CURRENCY].

Примечания:
А) если одна ветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той же таблицы в отношении многие-ко-многим, то нужна ещё таблица для ссылок;
Б) более оптимальное (правильное) решение состоит в том, что структура показателей хранится отдельно от значений показателей.

При данной структуре таблицы надо иметь всего один параметризуемый запрос, чтобы вывести нужный показатель:

Код: [Выделить]

SELECT "INDICATOR", "UNIT", "VAL_NATURAL", "VAL_CURRENCY" FROM "MY_TABLE" WHERE "OWNER_INDICATOR" = :OIND;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.

Можно более подробно про отдельную структуру показателей? Какая у нее таблица? Я так понимаю, можно выполнить до формирования отчета преобразование вышеописанной таблицы в 2 другие. Но не понял, как можно будет связать таблицу структуры и таблицу показателей?

Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты). Структура этой таблицы очевидна из предыдущего сообщения:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];

Таблица значений тоже очевидна:
1. Показатель; (первичный ключ, ссылка на таблицу структуры показателей) [INDICATOR];
2. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
3. Цена за единицу [PRICE];
4. Значение показателя в денежном выражении [VAL_CURRENCY] (вычисляемое/необязательное поле).

Примечание:
А) связь между таблицами один-к-одному, но можно расширить первичный ключ таблицы значений, например, идентификатором отчёта, тогда в ней можно хранить разные (например, по времени) отчёты;
Б) структуру показателей тоже можно расширить, добавив в первичный ключ поле "тип отчёта", тогда в этой таблице можно хранить разные отчёты, с разными показателями;
В) чтобы показатели выводились в определённом порядке можно добавить поле "вес показателя" в таблице показателей;
Г) чтобы была возможность отключать показатели (не удаляя их, можно предусмотреть логическое поле "активный" в таблице показателей;
Д) можно добавить поддержку версий отчётов;
Е) можно хранить запросы для показателей...
и т.д. и т.п.

[DIzer]

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.

Об этом и речь...

2. Олап это прежде всего следствие отсутствия  релевантных моделей анализа - и цель его - помощь в формирования оных.

То есть, всё тот же недостаток проектирования, неверно сформированы модели предметной области.

3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.

А с чего им меняться?.. Аналитических плоскостей не так уж много...

4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...

Речь видимо про Firebird или Interbase... С чего бы у версионных СУБД база "пухла"?.. Старые версии не хранятся дольше, чем к ним есть интерес. Отсутствие журнала - это не проблема версионных СУБД, а конкретной реализации (всё тот же Firebird). Для откатов (многоуровневых, в том числе) можно использовать save points, но, конечно, в рамках текущей транзакции. Если выходить за пределы транзакции, то нужна поддержка журнала, разработчикам Firebird об этом говорят лет 20... может быть и больше (я про то, что за время моей работы с этой СУБД знаю).

1. См. выше
2. В реале обычно базу не проектируют с нуля . а насаживают на некоторую базовую модель... и это в краткосрочной перспективе дешевле, однозначно - требует меньших затрат на проектирование, обучение персонала.. и т.д. и т.п.
3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..
4. Да , на практике вариантов не было - с 4 пунктом согласен полностью

[alexus]

1. На деле оказалось - что они ничего не проектируют - просто в  тупую работают с неудачно сформированными (не ими !!!) данными.

Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.

Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.

Какой смысл рассуждать о ее структуре?

Хм?.. Может быть и нет смысла... но не поэтому ли возникли у Вас вопросы? Менять таблицу никто не призывает, но можно
1. поучиться на этом примере, как делать не надо;
2. более основательно подойти к созданию новых таблиц...
То есть, добавлять таблицы не на потребу, а исходя из сути... предметной области (хотя докапываться до сути... любителей мало...).

[ilovb]

Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты).

alexus, вы какую-то свою задачу решаете.
Нету в реальности никакой статичной структуры показателей.

[alexus]

3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..

Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...

[alexus]

Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты).

alexus, вы какую-то свою задачу решаете.
Нету в реальности никакой статичной структуры показателей.

Примерно также сказала лиса из басни Эзопа... не сумев достать виноград. Хотя я понимаю, что в 1С, возможно, так и есть.

[ilovb]

В 1С вот так:
http://www.ec-network.ru/index.php?option=com_content&task=category&sectionid=4&id=32&Itemid=94

Цитата:
"Если бы все было так просто, уже давно появилась бы литература, исчерпывающим образом раскрывающая все вопросы данной темы. Так что, придется немного потерпеть."

[ilovb]

Зря я заговорил о затратах.

Надо было просто дать абстрактную таблицу:
[родитель][подчиненный]

Вместо обсуждения задачи получилось обсуждение системы 1С 

[DIzer]

3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..

Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...

Как скажете - в конце концов,  всегда  есть вероятность, что мы говорим о различных вещах... с другой стороны - с этой сферой деятельности я завязал лет 7 назад -так  что вполне могу быть не в курсе последних веяний- да и та же 1с ка развивается... а еще  до в 6.6 это было непотребство рассчитанное лишь на учет в конторах однодневках бешеных 90-х

[ilovb]

Обсуждать что-то кроме самой задачи больше не буду. Надоело.

[alexus]

В 1С вот так:
http://www.ec-network.ru/index.php?option=com_content&task=category&sectionid=4&id=32&Itemid=94

Цитата:
"Если бы все было так просто, уже давно появилась бы литература, исчерпывающим образом раскрывающая все вопросы данной темы. Так что, придется немного потерпеть."

Это "немного" растянется... на всю жизнь. Литература тут даром не нужна, можно обойтись собственным "серым веществом".
Суть в том, что для Вас показатели - это буковки и цифирьки... А Вы попробуйте поставить себя на место руководителя... посмотреть на свою задачу его глазами...
- Брак 18%... Это хорошо или плохо? Сколько было брака в прошлом квартале?
- А в прошлом квартале мы это показатель не считали...
- Тьфу... А какие причины брака?
- А этих показателей у нас нет, только общий итог?
- Тьфу... А какой износ основного оборудования?
- Три года назад был 64%.
- А сейчас?
- А сейчас мы это показатель не считаем...
- Тьфу... А у конкурентов, какой брак?
- В нашей системе этой информации нет...
- Так что же есть в вашем ... отчёте! На кой ляд он мне сдался!.. Проще самому пройти по производству... разгильдяи...

(разбавьте этот диалог матом, получите кальку типичного разговора в кабинете директора с... адептами 1С-идеологии)

[ilovb]

Литература тут даром не нужна, можно обойтись собственным "серым веществом".

Неужели? На западе в течении 100 лет теорию управления затратами развивали...

[DIzer]

Зря я заговорил о затратах.

Надо было просто дать абстрактную таблицу:
[родитель][подчиненный]

Вместо обсуждения задачи получилось обсуждение системы 1С 

Давайте считать... для эффективных манипуляций
супер таблица ДОЛЖНА  иметь как минимум три целочисленных поля (по которым  клиентом строится  сечение гиперкуба)
id _P1 ,id_P2, id _obj - первые два- ссылки на справочники категорий (они образуют дерево), последняя на название обьекта остальные поля  - специфика отчета... например ,стоимость позиции в рублях
к этой таблице должен прилагаться выход на справочник категорий  id _P1 ,id_P2, Name_P и обьектов учета id_obj, name_obj
- вопрос ? где приводить  ее к стандартному виду - на стороне сервера, или на стороне клиента

[DIzer]

точнее не на стороне клиента - а при пересылки данных клиенту

[alexus]

3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..

Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...

Как скажете - в конце концов,  всегда  есть вероятность, что мы говорим о различных вещах... с другой стороны - с этой сферой деятельности я завязал лет 7 назад -так  что вполне могу быть не в курсе последних веяний- да и та же 1с ка развивается... а еще  до в 6.6 это было непотребство рассчитанное лишь на учет в конторах однодневках бешеных 90-х

Ну, для примера... Любое/ая подразделение/подсистема предприятия основана на 3-х ключевых элементах. Возьму для примера сбыт (можно и производство, но писать больше... а лень).
Треугольник сбыта:
вершины: товар/продукция, клиенты, деньги;
ребра: товар-деньги (прейскуранты), деньги-клиенты (оплаты), товар-клиенты (заявки, рекламации);
В центре треугольника точка, которая смыкается с тремя вершинами, - это основные документы проходящие через сбыт:
1. Заказ (клиент, товар, цена);
2. Счет (клиент, товар, цена);
3. Накладная и счёт фактура  (клиент, товар, цена);
4. Товарная накладная  (клиент, товар, цена);
5. Возврат товара (клиент, товар, цена);
6. Любые другие документы...

Можно расширять любые из элементов  (клиент, товар, деньги), вводить категории и группы, фиксировать те или иные контакты... сути сбыта это не изменит, и аналитические плоскости будут всегда определяться этими ключевыми элементами... То есть, всегда работу сбыта будут анализировать
1. по клиентам (какие клиенты или группы клиентов сколько товаров закупают, сумма товаров, по каким товарам);
2. по продукции (какая продукция наиболее ликвидна, какая продукция наиболее доходна/рентабельна);
3. по деньгам (какие формы оплаты предпочитают те или иные клиенты/группы клиентов [для промышленных предприятий не очень актуально... пока денег в стране хватает], какие отсрочки платежей наиболее эффективны для тех или иных групп клиентов, для тех или иных категорий товаров).

Ну, и что ещё принципиально иного можно добавить к этому?..