Создание хранимых процедур

Здравствуйте!
Возник следующий вопрос. Возможно ли написание собственных хранимых процедур в какой либо среде для создания Баз Данных. Т.е. создание Баз Данных из которых данные получаются посредством хранимых процедур.
Поясню для чего это нужно.
В данный момент я пользуюсь OLAP системой 'Контур Стандарт' от компании Intersoft Lab, в ней предусмотрен анализ трех типов данных:
1) Данных, полученных с помощью хранимых процедур (не SQL) головной Базы Данных
2) Данных полученных из связных таблиц
3) Данных полученных из локальных таблиц
Последние два пункта соответствуют анализу последней версии выборки данных, которые со временем устаревают, вследствии чево хотелось бы пользоваться хранимыми процедурами - чтобы иметь всегда самые свежие данные. Но вот тут то и появляется проблема - данные полученные с помощью хранимых процедур можно использовать только с данными также полученными из хранимых процедур. Т.е. нет возможности привязать свой классификатор к данным из головной Базы.
Вот поэтому и хотелось бы написать свою хранимую процедуру (в Access или Visual FoxPro или еще где нибудь) которая просто получала бы данные из того же Access или Visual FoxPro.

Заранее благодарен за любую помощь.

0

В принципе это возможно. Не знаю как с твоей системой, но работая в Delphi через ADO с Access хранящиеся в базе Queries распознаются системой как хранимые процедуры, при этом они как могут возращать данные, так могут и не возвращать, просто выполняя к.-л. поерацию с базой. В то же время сохраняется возможность работы с Input и Output параметрами... Короче, сказка...

0

Спасибо за ответ. Теперь я чуствую что на верном пути нахожусь ; ))
У меня тоже запросы распознаются как хранимые процедуры, но к сожалению не все. Распознаются ли те, которые содержат параметры.
Однако, при связи с Ассess через ODBC возникает ошибка и данные из этой процедуры не поступают.
Ошибка типа 'Слишком мало параметров', хотя при запуске я задаю значения параметра.

0

Хотел еще раз поблагодарить за помощь, теперь у меня все работает без проблем.
Если интересно, проблема была в следующем:
Запросы в Access действительно воспринимались как хранимые процедуры, когда в них явно указывалось наличие параметра. Проблема была в соответствии типов данных различных приложений.
Т.е. решение проблемы состояло в написании запроса в Access с указанием фиктивного параметра такого типа который существовал бы и в приложении использующем получившуюся хранимую процедуру. В моем случае это был тип SHORT, который трактовался 'Контур Стандартом' как Integer(16).
Одна из полученных хранимых процедур выглядела следующим образом:
/* sp_КлассификаторЛицСчета */
PARAMETERS Сумма Short;
SELECT *
FROM [tblКлассификаторЛицСчета];

Еще раз спасибо за участие !

0

Рад помочь брату по разуму... :-)

0

>1) Данных, полученных с помощью хранимых процедур (не SQL) головной >Базы Данных
>2) Данных полученных из связных таблиц
>3) Данных полученных из локальных таблиц
>Последние два пункта соответствуют анализу последней версии выборки >данных, которые со временем устаревают, вследствии чево хотелось бы >пользоваться хранимыми процедурами - чтобы иметь всегда самые свежие >данные. Это не так. ВСЕ способы получения данных выдают актуальную информацию из БД. Полученные из БД данные не сохраняются. По каждому пользовательскому запросу в Контур Стандарт генерируется SQL-запрос к источнику данных и отображаются те данные, которые были в БД на момент выполнения запроса. Чем хороша хранимая процедура, так это возможностью описания в ней сложных вычислительных алгоритмов, тонкого тюнинга и использования ее параметров для генерации диалога.

0

Спасибо за ответ, но вероятно я не слишком хорошо описал возникающие проблемы и поэтому вы меня не верно поняли.
Изначально проблема стояла в обработке данных полученных из различных источников. Эта поблема возникает из-за того что как правило в головной базе хранятся слишком детализированные данные, избыточные для анализа, которые требуют агрегирования. Классификаторы этих данных скорее всего хранятся в каких либо других источниках. Это происходит потому что у каждого аналитика обычно своя методика анализа и он должен иметь быстрый доступ к методике, для того чтобы быть в состоянии ее изменить.
'Контур Стандарт' изначально не предназначен для работы с несколькими источниками данных одновременно, поэтому здесь возможно лишь два решения проблемы:
1) Допустим классификатор хранится в базе данных Access. Тогда можно просто загрузить данные из головной базы в Access и продолжить анализ с помощью связных таблиц в 'Контур Стандарт'. Это анализ статических данных, т.е. нет прямой связи с головной базой.
2) Либо написать какие либо хранимые процедуры в Access, где описаны сценарии сбора данных из различных источников. Здесь уже будет анализ динамических данных.
Этот подход, насколько я понимаю довольно общий. Более продвинутые OLAP системы имеют в комплекте некую базу данных (буфер). Которая также собирает данные из различных источников и хранит агрегированные даные. Здесь в качестве такого буфера выступает Aceess.

0

Теперь я понял задачу. Речь идет о том, что Вам нужна Витрина данных - отдельная от Хранилища БД, в которой данные более агрегированы и особым образом категоризированы.
На этот счет есть несколько идей:
1. Применить классическое решение - создать витрину данных в OLAP-сервере, т.е. многомерную БД, которая агрегирует в себя данные из центрального хранилища(при этом измерения могут быть подтянуты из дополнительных баз данных) и предназначена для узкой предметной области. Это решение имеет много плюсов и три минуса - цена, необходимость в администрировании и offline.
2. Разработать хранимую процедуру(или view) которая объединяет несколько источников данных и агрегирует данные внутри себя, и на которую будет настроен OLAP-клиент, в данном случае Контур Стандарт.Это то, что Вы и сделали.
3. Разработать view вместо хранимой процедуры. Контур Стандарт будет рассматривать view как таблицу. С view можно объединять таблицы. Кстати, КС сам пошлет запрос с Gropup By, т.е агрегирует данные силами сервера БД, если это не Access, а например MS SQL.
4. Воспользоваться специфическими возможностями конкретного Хранилища данных (если я правильно понял - это Контур Корпорация) по автоматической генерации хранимых процедур. Т.е можно создать в нем справочники - Ваши классификаторы и добавить в объекты, которые Вас интересую, например в счета поля, ссылающиеся на эти справочники. Тогда сгенерируется хранимая процедура, которая будет возвращать данные в необходимых разрезах.

Одно рассуждение. Если OLAP-система умеет хранить данные, то это наверное OLAP-сервер. Если нет - OLAP-клиент (есть правда промежуточный вариант - OLAP-клиент с локальными кубами, но они как правило замкнуты на себя, их данные ни с чем не объединяются). Я к тому, что является ли танкер продвинутой яхтой, это еще вопрос

0

Еще раз спасибо за ответ.
Вы верно подметили - вопрос конечно же в цене и в острой необходимости внедрения тех или иных технологий автоматизации. Пока что меня устаивает и танкер. ; ))
Скажите пожалуйста, а на каком языке был реализован сам 'Контур Стандарт' ?

0

Вот Вы меня и вычислили. OLAP-машина на ANSI C++(между прочим очень быстро работает по сравнению с буржуйскими OLAP-клиентам). Интерфейс на Borland C++ Builder.
Еще хочу сказать, что Вы можете обращаться на support@iso.ru по техническим вопросам.

0