Уважаемые специалисты,
помогите, пожалуйста, неученому в SQL'е советами.
 
Задача из области систем по энергоучету (см. структуру в приложенном файле):
в структурной схеме есть элементы обведенные ? знаком - то в чем я, простите, не разбираюсь, но делать надо. 
 
упрощенная структура данных показана в таблице "сводная таблица данных":
В данной таблице показана минимально выборка (почасовка) на период времени с 12:00:00 до 13:00:00. говоря Вашим языком, такая таблица совсем не нормализированная. 

После нормализации (не знаю насколько корректной) получилось 4 таблицы:
R_Energy, R_LEVEL, R_ZONE, R_LOG 
таблица R_LOG имеет "отношения" к таблицам R_Energy и R_ZONE через ключи ID_Energy и ID_ZONE.
 
Далее пытаюсь соорудить перечень SQL запросов к такой "супер БД", по которым была бы возможность суммировать значения величин энергии в зависимости от выборки (почасовка, посуточно) и выводить результаты в отфильтрованном виде (по зонам (SPA, ресторан) и типу энергии (Электрика, Вода, Газ, Тепло)). 
Пытаюсь соорудить SQL запросы в виде функции с некоторыми формальными параметрами:
Если данную процедуру вызвать, например, в следующем виде
exec DoRep 1000,-1, '2012-01-10', '2012-01-11', '00:00:00','11:00:00', 0
то результат будет в виде сумм почасовки по электрике по всем зонам за фиксированный период времени. 
На рисунке показан только некоторый фрагмент - по дате 2012-01-10 (таблица "результат запроса")
 
Реализации такой функции видимо очень не оптимальна - в своем теле она вызывает еще несколько функций. 
 
Например, 
реализация SQL запроса вывода отчета для посуточной выборки с фильтром по зонам:
 
Запрос 1 

реализация SQL запроса вывода отчета для посутоной выборки беp фильтра по зонам:
 
Запрос 2
...
 
Оба запроса реализованы каждый в отдельной функции, которые вызываются в основной процедуре DoRep.  
Данный способ очевидно очень неоптимальный - наверное существуют варианты совмещения двух запросов в одну более сложно обвязанную логикой процедуру, но только у меня совсем не получается это сделать: в первом запросе иимет место ....SELECT  R_ZONE.ZONE_DESCR ..... Во втором запросе зона не рассматривается нигде, так как иначе будет неверно суммироваться значения энергии Value. Таких неоптимальных ситуаций получилось предостаточно - знаний не хватает. 
 
В общем вопросы к Вам весьма примитивны - не судите строго:
1. Насколько удачно спланирована база?
2. Как оптималнее всего построить запросы к базе, так, что бы в конечном счете получилась одна параметризированная функция. Или может такой способ вообще не правильный ? 
 
Всем большое спасибо!

Это сообщение отредактировал(а) Akina - 13.1.2012, 16:57

Присоединённый файл ( Кол-во скачиваний: 14 )
 struct.GIF 34,74 Kb

скажите, а зачем вообще была проведена нормализация?


1) Прежде всего не стоит стремиться к гибкости и универсальности.
Стоит помнить что для каждого запроса строится только один план и самый универсальный запрос, наверняка, будет далеко оптимальным. Совершенно нет ничего зазорного в том, чтобы для каждого способа группировки и для каждого способа фильтрации был реализован специфический запрос, даже в случае, если структура результата одинакова. 
2) Индексируйте те поля, по которым производите фильтрацию. Держите в уме, что запрос может использовать составные индексы, содержащие для них избыточное перечисление столбцов лишь в том случае, если используемые в запросе предикаты производят отбор по первым перечисленным в индексе полям.
Например:
Первому запросу определенно понравится составной индекс по R_LOG(ID_ZONE,ID_Energy,_Date)
Однако же второй запрос не сможет использовать этот индекс.
Если мы индекс перестроим по полям R_LOG(_Date,ID_ZONE,ID_Energy), то второй запрос уже сможет использвать этот индекс, но только лишь для фильтра по дате.
Если же построить индекс по R_LOG(_Date,ID_Energy,ID_ZONE), то оба запроса смогут его использовать и первый, для отбора по всем трем полям и второй для отбора лишь по первым двум.

Не знаю...но так ведь книжка пишет. Если имеет место избыточность, то нормализация нужна, что бы сущности типа "Электрика", "SPA", и т.д. были объявлены  только один раз. Да и в R_LOG сохранять число 1000 (два байта) рациональнее чем слово из девати чаров (девяти байт) "Электрика". В общем я ж не спец, но во всех методиках просто заставляют приводить таблицы к 1NF, 2NF, 3NF и т.д.





Вы хотели сказать не оптимальным ?

1) Исходная таблица представлена в 1НФ, если я не ошибаюсь
2) Чтобы прямтаки заставляли - не припомню.   
3) В этих же методиках, обычно пишут, что нормализация в значительной мере усложняет построение аналитических запросов, недоумеваю, почему читающие не доходят до этого места при чтении методик   


Так то можно было слово "Электрика" сократить до "Э", был бы один байт.  

И таки зачем?

Обычно нормализация используется для облегчения обеспечения согласованности и целостности данных. В вашем случае, я так понимаю, вы получаете исходные данные откуда то извне - нет? Вероятнее всего на той стороне обеспечен некий комплекс мер, чтобы значение "Электроника" не могло быть представлено как "ЭЛЕКТРОНИКА" или "Электр." -  тот самый случай, для не допущения которого нормализация могла бы быть полезной. А так, получается, вы нормализуете исходные данные, лишь чтобы потом их обратно денормализовать?

И все таки, сильного из любопытства ради.
возможно ли в одном запросе объеденить всякую там логику, например
первый вариант запроса



Если строки, отмеченные /*!*/ закоментировать ( /*R_ZONE.ZONE_DESCR*/, /*R_ZONE*/, /*R_ZONE.ZONE_DESCR*/), то получится второй вариант запроса, который можно сохранить в отдельный файл и использовать, но хотелось бы у Вас спросить,  а можно ли два запроса объеденить в один, через какую то логику - может какие то дополнительные операторы SQL. 
Пока все что у меня вышло - это реализовать два запроса в отдельные процедуры (в одной - целый запрос, в другой с закоментированными /*!*/ или поудалять их вообще) 
и вызывать эти два запроса из третей процедуры через IF, ELSE. 


Спасибо.

Чем вас не устраивает предложенное вами же решение?