|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #05-06/96
|
|
Развитие технологии Data Warehouse (DWH - Хранилища данных) является следствием желания конечных пользователей иметь непосредственный и быстрый доступ к необходимым им данным, на основе анализа которых в дальнейшем можно принимать решения. Технология DWH необходима, так как мир не идеален (различные платформы, форматы данных, недостаточная производительность аппаратного обеспечения и т. п.), и, оставаясь в рамках OTLP-систем, невозможно решить все проблемы, связанные с анализом данных. Таким образом, особую важность приобретают программные средства доступа к данным для конечного пользователя (аналитика). С функциональной точки зрения, эти средства должны выполнять три основные функции.
Среди этих функций одной из ключевых является первая, так как, например, если не иметь функционально полного средства построения запросов, то не будет и данных для того, чтобы создать отчет, даже если имеется развитое средство для этого. Естественно желание конечных пользователей иметь полностью интегрированное средство, однако различные поставщики такого рода ПО развили три упомянутых функциональных элемента в разной степени полноты. Среди компаний-разработчиков таких средств следует упомянуть следующие: IQ Software, Cognos, Brio, Platinum, Software AG, Crystal Services. Перечислим программное обеспечение для доступа к данным, поставляемое этими компаниями. Компания Brio поставляет продукт Brio Query, IQ Software - IQ, Platinum - SQL*Assist, Cognos - Impromptu и PowerPlay, Software AG - Esperant, Crystal Services - Crystal Views. Одним из интересных продуктов в этом ряду является Esperant, который хотя и не имеет OLAP-средства, обладает рядом достоинств, делающих его эффективным средством доступа к данным для конечного пользователя. Более того, сочетание Esperant с DSS Agent компании MicroStrategy (партнер Software AG) дает возможность обеспечить три необходимых функциональных свойства программного обеспечения данного класса. Software AG в настоящее время разрабатывает прямой интерфейс между Esperant и DSS Agent, тем самым делая прозрачным использование OLAP. Помимо Software AG все функциональные свойства покрывают также продукты компаний: Platinum, Cognos, IQ. Следует сказать о перспективах развития обсуждаемых средств в связи с DWH. Один из функциональных объектов, создаваемых с использованием этих средств, - метамодель данных, которая является не только набором представлений данных для конечного пользователя, но и содержит информацию о способах конструирования запросов. Если рассматривать DWH как логическую конструкцию, то метамодель - это представление DWH. DWH, построенное физически, будет лишь некоторой реализацией метамодели данных. Таким образом, средства построения запросов в будущем будут поддерживать возможность автоматического создания DWH. Процесс такого создания можно представить себе в виде следующих шагов: 1) создается метамодель данных, которая логически реализует DWH; 2) на основе этой модели проверяется корректность функционирования DWH; 3) контролируется производительность системы, реализованной с помощью метамодели, если она удовлетворительна, то на этом процесс построения DWH завершается, в противном случае, с помощью специальных средств, на основании метамодели генерируется сценарий конструирования физического DWH.
Далее рассмотрим основные функциональные характеристики Esperant, уделяя особое внимание способу построения метамодели и системе запросов, которые являются одними из важных с функциональной точки зрения.
Использование технологии Data Warehouse (DWH) дает возможность конечным пользователям принимать решения на основе всестороннего анализа бизнес-данных. Технология DWH является основой систем аналитической обработки данных (OLAP). Процесс создания, поддержки и функционирования DWH можно разбить на следующие этапы:
Esperant, программный продукт компании Software AG, занимает важное функциональное место в информационной технологии DWH, обеспечивая конечного пользователя (аналитика) возможностью доступа к данным различных СУБД. Причем, что очень важно, это средство позволяет формулировать запросы с использованием языка и понятий реального мира, поскольку в противном случае, когда средство построения запросов и отчетов так сложно, что применять его может только специалист в области информационных технологий, оно не подойдет для использования в системах OLAP, ориентированных на аналитика. Esperant можно определить как средство построения запросов и создания отчетов, которое обеспечивает конечного пользователя возможностью принимать решения на основе данных, хранящихся в корпоративной информационной системе. Необходимо отметить, что Esperant позволяет пользователю, не знающему SQL, строить сложные, в аналитическом смысле, запросы. Esperant состоит из следующих программных компонентов: Query System (Система построения запросов, включающая в себя систему создания отчетов с использованием запросов, построенных пользователем.), Adminis-tration System (Система администрирования), Executive Desktop (Средство для запуска сохраненных запросов с рабочего стола), Batch Server (Сервер пакетной обработки запросов).
Рассмотрим теперь в общих чертах основные характеристики и функциональные возможности этого продукта.
Esperant функционирует в среде Windows и дает возможность доступа ко многим популярным СУБД, включая Oracle, Sybase, DB2, ADABAS C, ADABAS D, Informix, Microsoft SQL Server, Ingres, Watcom и др., а также к большинству ODBC- и QELIB-совместимым источникам данных, включая локальные файлы (dBase, FoxPro, Microsoft Access, Paradox и др.). Esperant поддерживает следующие прямые интерфейсы: Oracle SQL*Net, Sybase DBLIB, Microsoft ODBC, Software AG ENTIRE ACCESS и ENTIRE NET-WORK, TechGnosis SequeLink. В зависимости от квалификации, пользователь системы может строить запросы с помощью ассистента запросов (Query Assistant), формулировать запрос на языке Esperant, а также напрямую строить SQL-оператор, более того, доступ к данным возможен как через их метамодель или представление (DataView) (в основном конечный пользователь пользуется именно этим способом), так и непосредственно к физическим таблицам БД. Вышеперечисленное приведено здесь для того, чтобы отметить функциональную гибкость Esperant, так как ясно, что непосредственный доступ к БД необходим лишь для ограниченного числа высококвалифицированных пользователей, и, естественно, способы доступа к БД определяются администратором системы. Характеристики доступа контролируются настройкой соответствующих параметров для каждой группы пользователей. На рис. 2 показано диалоговое окно, содержащее настраиваемые администратором параметры доступа. Среди них, в частности, параметр Open Database, позволяющий разрешить или запретить непосредственный доступ к СУБД.
Ключевым объектом в Esperant является метамодель данных (DataView), которая дает конечному пользователю возможность восприятия хранимой информации в виде понятных ему бизнес-категорий и составляющих их элементов, построенных администратором системы на основе физических таблиц и столбцов БД. Концептуальное представление позволяет также скрыть от пользователя информацию о каких-либо существующих связях между таблицами в физической БД и показать только необходимую аналитику информацию в требуемом виде. Естественно, что сама метамодель содержит всю необходимую информацию о БД или, точнее, о соответствии между концептуальным и физическим представлением информации. Построение различных DataView в зависимости от требований конкретного пользователя и задач, стоящих перед аналитиками, является функцией администратора, который с помощью Administrative System строит необходимые представления данных, а также определяет группы пользователей и их параметры доступа. Центральной частью системы является средство для построения запросов Query System, которое обеспечивает аналитика, бизнес-пользователя графическим инструментом для быстрого и простого доступа к информации, хранящейся в корпоративной БД; при этом нет необходимости в освоении SQL и всей технологии, относящейся к СУБД. Входящий в Query System ассистент запросов (Query Assistant) позволяет неподготовленному пользователю строить правильные запросы, используя интуитивно понятный графический интерфейс. Более того, SQL Expert постоянно контролирует правильность (синтаксис) и корректность (семантику) создаваемого запроса. Естественно, что более опытный пользователь может сам формулировать запросы непосредственно на языке Esperant, не используя Query Assistant. Полная цепочка построения запроса, его трансляции и получение конечного результата выглядит следующим образом:
Query Assistant->Запрос на языке Esperant->SQL-запрос->Результат
На рисунке 3 изображено 4 окна: окно Query Assistant, окно в котором сгенерирован запрос на языке Esperant, SQL-запрос, полученный в результате трансляции SQL генератором, окно результата. На основе построенного запроса пользователь имеет возможность с помощью генератора отчетов (Reporter), являющегося частью Query System, создать отчет необходимого формата и типа, содержащий результат запроса, диаграммы, картинки и т. д., а также произвести дополнительные преобразования над результатом.
Опишем теперь более подробно основные функциональные возможности Esperant в соответствии с технологией использования программного продукта и с точки зрения важности компонентов в области систем построения запросов. Как уже упоминалось во введении, наиболее важными компонентами являются средства построения метамодели и функциональные характеристики, относящиеся к системе создания запросов. Поскольку прежде всего администратор системы должен построить метамодель данных, которую будут использовать конечные пользователи системы для доступа к БД, рассмотрим функциональные возможности Adminis-trative System. Схема тестовой БД и DataView приведена на рисунке 4.
DataView можно определить как средство отображения физической структуры БД в привычную конечному пользователю (аналитику) терминологию. Необходимость построения концептуальной схемы решается администратором с учетом задач, стоящих перед пользователями системы формирования запросов (Query System). В Administrative System есть возможность разрешить пользователям прямой доступ к БД, но это в большинстве случаев не даст эффективных результатов, так как а) конечные пользователи скорее всего, с трудом представляют себе структуру БД, существующие связи между таблицами; б) им необходим контроль за правильностью и корректностью формируемых ими запросов; в) аналитику для успешного анализа необходимо видеть объекты в привычной ему форме. Стандартный процесс построения DataView начинается с построения базового представления, которое затем уточняется на основе концептуальной диаграммы. Использование функции автоматического построения (AutoBuild) DataView значительно ускоряет процесс создания концептуального представления. Выбрав эту функцию, администратор через серию диалогов указывает интерфейс доступа, источник данных (СУБД), необходимую информацию для получения доступа (пароль, пользователь). Возможно указание второго подсоединения к источнику данных (другой СУБД) в случае использования гетерогенных соединений таблиц. Далее администратор присваивает имя генерируемого Data-View и указывает директорию, где будет хранится вся относящаяся к DataView информация. После этого система администрирования автоматически читает информацию из системного каталога СУБД и импортирует данные об именах столбцов, их типах, соединениях таблиц (первичные и внешние ключи).
На этом процесс построения базового представления заканчивается, и в принципе пользователь может с ним работать. Однако для того, чтобы полностью завершить построение DataView в соответствии с концептуальной диаграммой, следует указать дополнительную информацию. После первого шага пользователю придется, например, иметь дело с физическими именами столбцов, которые, возможно, не будут соответствовать его представлению. Следует отметить, что аналогами таблиц и столбцов физической БД выступают соответственно категории и элементы (Category and Items) концептуального представления. В процессе дальнейшего построения можно скомбинировать несколько таблиц в одной категории, присвоить им бизнес-названия, определить вычисляемые поля и скрыть от пользователя не используемые им столбцы и таблицы. Например, категория ORDERS (Заказы) получена в результате комбинации физической таблицы, содержащей общую информацию о заказах ORDERS и таблицы LINE_ITEMS, содержащей информацию о позициях заказов. Более того, пользователь и не подозревает, что вообще существует таблица LINE_ITEMS, так как администратор сделал ее невидимой для него. Как было указано выше, DataView оказывается настроенным на определенный источник данных (через определенный интерфейс), но имеется возможность без повторения всего процесса построения концептуального представления переопределить источник данных для выбранного DataView или создать его копию, имеющую доступ к другой СУБД. Метамодель строится администратором системы в зависимости от требования аналитиков, таким образом для одной физической модели реляционной БД могут быть построены различные DataView. Содержание представления изображено в виде набора 14 форм, 4 из которых являются необходимыми, а именно формы, содержащие информацию об именах таблиц (Tables), столбцов (Columns), первичных ключах (Primary Keys) и внешних ключах (Foreign Keys). На содержимом этих форм основано, упоминавшееся выше базовое представление, соответствующее физической структуре БД. При заполнении остальных форм получается расширенная метамодель, соответствующая концептуальному представлению пользователя. Перечислим их: Category Names (Названия категорий), Item Names (Названия элементов), Category Descriptions (Описание категорий), Item Descriptions (Описание элементов), Virtual Tables (Виртуальные таблицы), Virtual Columns (Виртуальные столбцы), Join Path Definitions (Определения путей соединения), Non-Equijoins (Определение не-эквисоединений), No Display Tables (Неотображаемые таблицы), No Display Columns (Неотображаемые столбцы). Рассмотрим функциональное назначение каждой из форм и способы внесения в них информации.
Формы Tables и Columns определяют, используемые в метамодели, соответственно имена таблиц БД и столбцов для каждой таблицы, а также тип данных каждого столбца.
В формах Primary Keys и Foreign Keys содержится информация о первичных и внешних ключах таблиц, содержащихся в создаваемой метамодели. Следует отметить, что в форме Primary Keys указывается также информация об альтернативных первичных ключах, если таковые существуют. В форме Foreign Keys указана информация о типе связи между таблицами.
Формы Category Names и Item Names содержат ориентированные на пользователя имена категорий и их элементов.
Category Descriptions и Item Descriptions содержат описательную информацию о соответствующих объектах.
Форма Virtual Tables позволяет расщепить таблицу на несколько производных и используется для представления пользователю ненормализованных таблиц так, как будто бы они нормализованы, за счет введения новых категорий или для определения подтипов, если записи содержат поле, определяющее подтип.
Virtual Columns позволяет определить новые столбцы в какой-либо таблице, указывая столбцы, физически принадлежащие другой. Например, таким образом можно объединить две физические таблицы ORDERS и LINE_ITEMS и получить категорию ORDERS, которая содержит строки заказов так, как это привычно пользователю, и ему нет необходимости знать о существовании отдельной физической таблицы, хранящей эту информацию, и о связи между ORDERS и LINE_ITEMS. Более того, могут быть определены элементы категорий, значения которых получаются на основе выражения, допустимого для SQL-процессора используемой СУБД. Например, после добавления к таблице PRODUCTS столбца TOTALQTY и определения его выражением SUM (LINE_ITEMS.QTY_ORDERED), пользователь сможет видеть в категории PRODUCTS общее заказанное количество по данной позиции. В случае существования нескольких связей между двумя таблицами, как, например, между PRODUCTS и VENDORS задается специальная функция LOOKUP_TABLE для указания того, какой внешний ключ использовать для выбора значений из таблицы, в которой определен первичный ключ.
Администратор указывает в формах No Display Tables и No Display Columns те таблицы и столбцы соответственно, которые не обязательно непосредственно видны пользователю при работе в среде Query System.
Форма Join Path Definitions заполняется при существовании более чем одной возможности соединений таблиц для построения требуемого SQL-оператора. Например, при выполнении запроса на языке Esperant: "show order number and order dollars sorted by salesperson name" "Показать номер заказа и сумму заказа, упорядоченными по имени продавца" система потребует от пользователя дополнительную информацию, поскольку между таблицами SALESPEOPLE и ORDERS существует две возможности для соединения таблиц. Первая, непосредственное соединение между SALESPEOPLE и ORDERS, вторая, от таблицы SALESPEOPLE к таблице CUSTOMERS и от последней к ORDERS. Данная информация и задается в форме Join Path Definitions. Далее, в зависимости от выбора соединения SQL генератор создаст одно из двух SQL-предложений. В первом случае
SELECT T1.NAME, T2.ORDER#,
T2.ORDER_DOLLARS
FROM SALESPEOPLE T1, ORDERS T2
WHERE T1.SALESPERSON# =
T2.SALESPERSON#
ORDER BY 1
во втором,
SELECT T1.NAME, T2.ORDER#,
T2.ORDER_DOLLARS
FROM SALESPEOPLE T1, ORDERS T2,
CUSTOMERS T3
WHERE T1.SALESPERSON# =
T3.SALESPERSON#
AND T3.CUSTOMER# =
T2.CUSTOMER#
ORDER BY 1
Форма Non-Equijoins Form позволяет определить не-эквисоединения для таблиц, соединение между которыми возможно, но основано не на соотношении первичный ключ/внешний ключ. Например, имеются две таблицы, одна описывает финансовые документы (проводки) BSE, одним из ее атрибутов является дата документа (DOCDATE), другая, BSP, определяет интервалы отчетных периодов и содержит даты начала и конца отчетного периода. Для того чтобы соотнести каждый документ отчетному периоду в Non-Equijoins Form включается фраза WHERE для выполнения требуемого соединения, которая используется при генерации SQL-предложений. Более того, добавление в форму Virtual Columns столбца из таблицы интервалов BSP.PERIOD, идентифицирующего период, в таблицу документов (виртуальный столбец FP) при создании метамодели дает возможность пользователю непосредственно видеть исходные документы и период, к которому они относятся (рис. 8). На этом же рисунке видно построенное SQL-предложение на основании пользовательского запроса. Выражение в фразе WHERE сконструировано из Join Expression (Выражение соединения таблиц).
Заполнение некоторых форм происходит автоматически, так, например, при выборе функции AutoBuild при наличии ODBC-интерфейса формы Tables, Columns, Primary Keys, Foreign Keys будут заполнены автоматически на основании информации из каталога. Администратор может непосредственно строить SQL-предложения для выборки описательной информации из каталога СУБД, CASE-словаря или из любого набора таблиц. Более того, возможно написание программы генерации файлов, описывающих DataView (формат файлов, соответствующих формам, представляет собой разделенные запятыми значения полей форм), а затем с помощью функции импорта в среде Administrative System или в прикладной программе, используя Esperant API (функция EsperantBuildApp), завершить построение DataView. И наконец, часть информации непосредственно вносится самим администратором.
Опишем теперь более подробно работу Query System, построение отчетов, возможность взаимодействия с другими прикладными программами Windows. Для работы с системой запросов пользователю достаточно выбрать необходимое DataView, при загрузке представления произойдет подсоединение к источнику данных, связанного с данным представлением, и с этого момента пользователь может строить необходимые ему запросы, отчеты, загружать и выполнять сохраненные запросы и т. д. Выбрав работу с использованием ассистента запросов, пользователь получает возможность строить запросы на основе интуитивного интерфейса без знания языка запросов Esperant и, тем более, SQL. Query Assistant предоставляет четыре предопределенных типа запросов, которые пользователь может конструировать с его использованием, а именно:
Легко заметить, что запросы на Esperant формулируются на языке, близком к английскому, таким образом, пользователь может свободно создавать свой запрос, не вдаваясь в технические аспекты языка SQL. Более того, запросы формулируются легко не только синтаксически, но, что более важно, пользователь свободно выражает суть запроса, сосредотачиваясь лишь на предметной области, данные о которой ему необходимы. Ясно, что построение соответствующего SQL-запроса далеко не очевидно и требует определенных знаний и опыта в области СУБД. Язык Esperant является средством, на основе которого построена система запросов программного продукта Esperant, причем легкость формулировки определяется тесной связью с метамоделью. При построении запроса с помощью Query Assistant пользователь выбирает требуемый тип запроса и затем в диалоге указывает участвующие в запросе элементы категорий, критерии выборки во фразе For, выбирая ключевые слова и значения параметров условия. При указании значений параметров есть возможность получить их из БД и из полученного множества выбрать требуемое. Условия выборки выражаются фразами языка Esperant, такими как THAT HAVE (имеет), DO NOT HAVE (не имеет), MORE THAN (больше чем) и т. п. Возможно использование логических операторов AND и OR. Фраза Sorted By позволяет получить требуемую сортировку. Esperant предусматривает использование функций: Total, Average, Max и Min, а также вычисляемых арифметических выражений. Во время создания запроса (используя Query Assistant) SQL Expert контролирует его корректность, и выполнить запрос можно будет лишь после того, как он будет до конца и правильно построен.
Построение законченной системы для получения отчетов основано на использовании таких средств, как Batch Server, Executive Desktop, возможности создания иконок запросов прямо на рабочем столе Windows.
Пакетная обработка запросов и получение отчетов в определенные пользователем моменты времени позволяет получать требуемые данные в нужное время автоматически. Далее, запланированный запрос может быть выполнен на удаленном PC сервере, освобождая тем самым компьютер пользователя. Для реализации пакетной обработки в Esperant включен специальный язык. Скрипт на этом языке позволяет исполнять различные операции, входящие в Esperant, а также запускать внешние программы. Построение скрипта пользователь может осуществить либо с помощью опции запись макро, либо в среде специального графического редактора.
Используя эту возможность создания скриптов, можно построить компонент front-end, который будет вызываться пользователем просто нажатием кнопки мыши. В результате будут выполнены действия, описанные в скрипте. При выполнении скрипта возможно передавать параметры, т. е. у пользователя можно запросить дополнительную информацию для выполнения данного запроса. Доступ к таким компонентам осуществляется с использованием Executive Desktop. Возможность передачи параметров в командной строке при запуске Esperant позволяет выполнять запросы прямо из Диспетчера программ Windows. Это свойство также дает возможность интегрировать Esperant в прикладную программу. Поддержка интерфейсов OLE2 и DDE дает возможность интеграции различных программных продуктов. Например, Esperant результат запроса помещает в таблицу Excel, внешний объект встраивается в отчет, построенный Esperant и т. п.
Рассмотрим пример того, как Esperant позволяет предотвратить получение неправильных результатов. Можно построить синтаксически верный SQL-оператор, в результате выполнения которого будет получен ложный результат. Предположим, имеется три таблицы Заказчики (CUSTOMERS), Заказы (ORDERS), Строки заказов (LINE_ITEMS). Требуется построить SQL-оператор, который для каждого заказчика возвращает общую сумму по всем сделанным им заказам и общее количество заказанных позиций. Большинство инструментальных средств для построения запросов могут сгенерировать следующий SQL-оператор:
SELECT T1.NAME,
SUM(T2.ORDER_DOLLARS),
SUM(T3.QTY_ORDERED)
FROM CUSTOMERS T1, ORDERS T2,
LINE_ITEMS T3
WHERE T1.CUSTOMER# =
T2.CUSTOMER#
GROUP BY T1.NAME
где столбцы CUSTOMER# - код заказчика, NAME - наименование, ORDER_DOLLARS - сумма заказа, QTY_ ORDERED - заказанное количество принадлежат соответствующим таблицам. При выполнении этого SQL-оператора будет получено неверное значение для сумм заказов, поскольку в результате соединения трех таблиц перед выполнением GROUP BY значение поля ORDER_DOLLARS продублируется для каждой строки таблицы LINE_ITEMS, содержащей строки заказов. Только опытный пользователь, знающий SQL, сможет разобраться в происшедшем и понять, что суммирование на нескольких уровнях детализации (в данном случае на двух) в одном SELECT-предложении приведет к неправильным результатам. Esperant SQL Expert предотвратит возникновение такой ситуации: при построении запроса с помощью Query Assistant после выбора суммирования по суммам заказов выбрать операцию суммирования по QTY_ORDERED будет невозможно. Итак, полученный запрос на языке Esperant будет выглядеть следующим образом:
SHOW CUSTOMER NAME AND THE TOTAL
ORDER DOLLARS
и соответственно SQL-генератор построит следующий SQL-оператор, возвращающее правильные значения для сумм заказов:
SELECT T1.NAME,
SUM(T2.ORDER_DOLLARS)
FROM CUSTOMERS T1, ORDERS T2
WHERE T1.CUSTOMER# =
T2.CUSTOMER#
GROUP BY T1.NAME
В Esperant встроен мощный SQL-генератор, позволяющий генерировать коррелированные подзапросы, строить запросы, в результате трансляции которых получается последовательность из нескольких SQL-операторов. Ниже приведен пример сложного запроса, показывающего использование нескольких операторов SELECT, CREATE/DROP VIEW, UNION и содержащий трехуровневые коррелированные подзапросы.
Пример сложного запроса a) сформулированного на языке Esperant и b) соответствующий сгенерированный SQL запрос:
a)
COMPARE THE AVERAGE CUSTOMER BALANCE FOR CUSTOMERS THAT HAVE ORDERS FOR EVERY PRODUCT AGAINST THE AVERAGE CUSTOMER BALANCE FOR CUSTOMERS THAT DO NOT HAVE ORDERS FOR EVERY PRODUCT SORTED BY SALESPERSON NAME
b)
DROP TABLE SG0837659763950
DROP TABLE SG1837659763950
DROP TABLE SG2837659763950
DROP TABLE SG0837659763950
CREATE VIEWTABLE SG0837659763950
SELECT T5.NAME, AVG (T1.BALANCE)
FROM CUSTOMERS T1, SALESPEOPLE T5
WHERE NOT EXISTS (
SELECT *
FROM PRODUCTS T2
WHERE NOT EXISTS (
SELECT *
FROM ORDERS T3, LINE_ITEMS T4
WHERE T3.ORDER# = T4.ORDER#
AND T2.PRODUCT# =
T4.PRODUCT#
AND T1.CUSTOMER# =
T3.CUSTOMER#))
AND T5.SALESPERSON# =
T1.SALESPERSON#
GROUP BY T5.NAME
DROP TABLE SG1837659763950
CREATE VIEWTABLE SG1837659763950
SELECT T10.NAME, AVG
(T6.BALANCE)
FROM CUSTOMERS T6,
SALESPEOPLE T10
WHERE NOT (NOT EXISTS (
SELECT *
FROM PRODUCTS T7
WHERE NOT EXISTS (
SELECT *
FROM ORDERS T8, LINE_ITEMS T9
WHERE T8.ORDER# = T9.ORDER#
AND T7.PRODUCT# =
T9.PRODUCT#
AND T6.CUSTOMER# =
T8.CUSTOMER#)))
AND T10.SALESPERSON# =
T6.SALESPERSON#
GROUP BY T10.NAME
DROP TABLE SG2837659763950
CREATE VIEWTABLE SG2837659763950
SELECT T11.COL0, T11.COL1,
T12.COL0, T12.COL1
FROM SG0837659763950 T11,
SG1837659763950 T12
WHERE T11.COL0 = T12.COL0
UNION
SELECT T11.COL0, T11.COL1, " ",
NULL
FROM SG0837659763950 T11
WHERE (NOT EXISTS (
SELECT *
FROM SG1837659763950 T12
WHERE T11.COL0 = T12.COL0))
UNION
SELECT " ", NULL, T12.COL0,
T12.COL1
FROM SG1837659763950 T12
WHERE (NOT EXISTS (
SELECT *
FROM SG0837659763950 T11
WHERE T11.COL0 = T12.COL0))
SELECT SG2837659763950.COL0,
SG2837659763950.COL1,
SG2837659763950.COL2,
SG2837659763950.COL3,
(SG2837659763950.COL1 -
SG2837659763950.COL3)
FROM SG2837659763950
WHERE SG2837659763950.COL0 <> " " OR
SG2837659763950.COL2 <> " "
ORDER BY 1
DROP TABLE SG0837659763950
DROP TABLE SG1837659763950
DROP TABLE SG2837659763950
Таким образом Esperant позволяет строить сложные запросы. В данном случае выполняется сравнение числовых величин, причем весь запрос выполняется непосредственно на сервере БД.
Esperant имеет следующие интересные особенности.
|
|