Опубликован: 28.12.2011 | Доступ: свободный | Студентов: 7487 / 958 | Оценка: 3.81 / 3.53 | Длительность: 19:30:00
ISBN: 978-5-9963-0488-2
Лекция 1:

Диалект SQL фирмы ORACLE

Лекция 1: 1234 || Лекция 2 >
История и стандарты

Первая версия SQL была предложена в 1973 году фирмой IBM под названием Sequel. В 1980 году этой же фирмой язык был воплощен уже под нынешним названием в проекте System R по построению прототипа реляционной СУБД (неформальную персонализированную историю и обсуждение последствий создания см. на http://www.citforum.ru/database/digest/sql1.shtml). Успех System R дал начало многочисленным попыткам разных фирм воспроизвести эту систему, а вместе с ней SQL. Первый коммерческий результат такой деятельности принадлежит нынешней фирме Oracle. (Формулировки некоторых команд SQL в Oracle до сих пор напоминают о System R фирмы IBM.)

Для борьбы с несовместимостью воплощений SQL в разных системах язык вскоре оказался вовлечен в активную деятельность по стандартизации, проводившуюся разными организациями в разное время: в том числе X/Open Group, SQL Access Group, FIPS, Госстандарт РФ. Сейчас действуют два комитета по стандартизации SQL: ANSI (в США) и ISO (международный), работающие синхронно.

Основные вехи стандартизации перечислены ниже.

  • SQL-86 (1986/1987 гг.);
  • SQL-89 (1989 г.; фактически SQL-86 с малыми добавками);
  • SQL-92 (синонимы: SQL2, SQL92; 1992 г.):
    • Вводный уровень (Entry Level),
    • Переходный уровень (Transitional Level),
    • Промежуточный уровень (Intermediate Level),
    • Полный уровень (Full Compliance);
  • SQL:1999 (синонимы: SQL3, SQL-95, SQL1999, SQL-99, SQL99; главные дополнения — объектные возможности языка, хранимые процедуры):
    • Основной уровень (Core),
    • Расширенный уровень (Optional);
  • SQL:2003 (пример дополнений — возможности XML). С этого момента очередные версии стандарта выходят не в полном объеме, как прежде, а в виде "дополнительных частей";
  • SQL:2006 (развивает расширения, касающиеся XML, возникшие в SQL:2003);
  • SQL:2008 (ряд частных дополнений, как, например, TRUNCATE TABLE или выдача первых N записей).

На основе SQL-92 построен ГОСТ Р ИСО/МЭК 9075-93.

Максимально достигнутый промышленными поставщиками уровень соответствия стандарту в настоящее время — Core SQL:2008, да и то с отклонениями. Он является продолжением (с расширениями и поправками) Core SQL:1999, а тот — продолжением Entry Level SQL-92.

Исторически SQL — не единственный предлагавшийся язык доступа к БД, а по мнению некоторых специалистов — и не лучший. Стандартизация SQL — одна из причин, по которой именно он получил широкое признание. Теоретически стандартизация обеспечивает независимость прикладных программ от типа используемой СУБД. Практически же каждый разработчик СУБД, включая фирму Oracle, предлагает не чисто стандартную реализацию, а собственный диалект SQL.

Противоречивость процессов стандартизации состоит в том, что коммерческие фирмы-разработчики склонны в первую очередь к собственным решениям, и только во вторую заинтересованы в общих; потребители же в первую очередь заинтересованы в общих решениях, и только во вторую — в частных. Росту диалектов способствует отсутствие в стандартах SQL однозначных предложений для некоторых свойств, например:

  • выдача даты и времени суток,
  • порождение значений для искусственных ключей,
  • семантика некоторых типов данных.

Далее по тексту ссылки на "стандарт SQL" и "стандарт ANSI/ISO" относятся фактически к стандартам SQL:20xx. Ссылки на SQL-92, SQL:1999 и SQL:2003/8 уточняют время появления упоминаемого свойства стандарта SQL:20xx последней версии.

Исходное название — Sequel — происходит как сокращение от Structured English Query Language (так что некоторые ветераны программирования по сию пору произносят SQL как "сиквел"). Слово english в полном названии неслучайно: нынешний SQL замысливался в виде такого подмножества естественного языка, на котором потребитель данных мог бы обращаться к БД. Со временем метаморфоза произошла с "потребителем". Раньше полагали, что им будет конечный пользователь, а в наше время им оказался программист. Теперешний конечный пользователь как правило ничего не знает о SQL, работая с БД средствами графики или более высокого (по крайней мере архитектурно) уровня, построенными с помощью SQL, но уже программистом. Тем не менее, как и раньше, многие предложения на SQL действительно напоминают обычные человеческие высказывания. В этом таится большая опасность для программиста, так как на деле SQL — формальный язык (хоть и не самый сложный), который от человеческого отделяет пропасть. Выписывая предложение на SQL, программист нередко подсознательно пытается осмыслить написанное по-человечески, что иногда не страшно, но чаще совершенно искажает совершаемое СУБД на деле. Можно привести массу примеров, когда по-человечески воспринимаемая запись на SQL в действительности означает совсем иное. Заложенная когда-то в Sequel близость к формулировкам на английском языке вынуждает сегодняшнего программиста на SQL все время быть начеку. Показательно, что в расшифровке SQL (Structured Query Language) слово English выпало, но инерция развития языка сохраняется.

Диалект SQL в СУБД Oracle

СУБД Oracle версии 1 (под другим названием) появилась в 1978 г. и была написана на языке ассемблера для PDP-11 под ОС RSX. Oracle версии 2 появилась в 1979 г. и стала "первой коммерческой реляционной СУБД с использованием SQL", а в версии 3 ее ядро было переписано на языке С. С версии 8 фирма Oracle называет свою СУБД "объектно-реляционной". Фактически же это была и остается SQL-ориентированная СУБД, использующая собственный диалект SQL.

В силу истории происхождения диалект SQL фирмы Oracle естественно оценивать с трех сторон, определяющих одновременно и факторы влияния на существующий его вид:

  • реляционной теории,
  • стандартного SQL,
  • фирмы-разработчика.

Во всех случаях можно говорить о понимании вопроса соответствующей стороной и об усилиях на проработку того или иного свойства (а в случае фирмы-разработчика — еще и усилий на программирование).

Oracle "в значительной степени" (но не полностью и не в точности) поддерживает уровень Core SQL:2003, некоторые возможности уровня Optional Features SQL:2003 и набор собственных нестандартизованных свойств. Точное перечисление соответствия диалекта SQL Oracle стандарту приводится в документации по СУБД Oracle.

Некоторые собственные свойства диалекта SQL Oracle:

  • типы данных;
  • дополнительные к стандарту функции;
  • дополнительные конструкции SQL.

Объем диалекта SQL в Oracle по отношению к стандартам пояснен следующим рисунком.


Выход за пределы стандарта практикуется не только Oracle, но всеми без исключения производителями, что девальвирует стандарт.

К этому же можно добавить, что в очередных версиях своей СУБД фирма Oracle все больше и больше новых возможностей (чаще, правда, технологического характера) реализует не посредством SQL в рамках своего диалекта, а программно, с помощью встроенных в БД системных пакетов подпрограмм.

Три понятия — реляционная модель, стандартный язык SQL и диалект SQL в Oracle — безусловно связаны, но связи эти вольные. Стандарт SQL является промышленным стандартом, создаваемым под влиянием реляционной модели, но не воплощающим реляционного языка запросов. Одновременно диалект SQL в Oracle создается для СУБД конкретного типа под влиянием стандарта SQL, но не придерживаясь его как догмы. Стандарт SQL и диалекты SQL всех производителей (включая Oracle) существуют в большой степени самостоятельно, оказывая воздействие друг на друга, но не воспроизводя друг друга в точности.

PL/SQL

PL/SQL есть процедурный язык, встроенный в СУБД Oracle для возможности работать с хранимой в БД Oracle программной логикой. Наличие процедурного языка предусмотрено стандартом SQL (начиная с SQL:1999), однако все собственные реализации разработчиков имеют, в отличие от случая с SQL, крайне мало общего между собой и с описаниями стандарта.

Процедурный язык Oracle позволяет создавать в БД триггерные процедуры, моделировать логику предметной области ("бизнес-логику"), проявлять самодеятельность БД, например, в виде переноса данных или обращения к Интернету, организовывать более сложную, нежели табличную в SQL, защиту доступа.

Для проектировщика БД PL/SQL дополняет SQL и табличную организацию данных. Хотя все данные в БД Oracle хранятся исключительно в виде таблиц, для моделирования действий с данными по правилам предметной области возможностей SQL нередко не хватает. Это случается, например, когда единый с точки зрения приложения составной набор свойств хранится в виде совокупности значений в разных таблицах. Согласованное изменение таких свойств исключительно посредством команд SQL часто неудобно или даже невозможно. Это можно воспринимать как недостаточность языка SQL (хотя последняя отчасти и устраняется объектными возможностями языка). В таких случаях подобные изменения "запаковывают" в подпрограмму, к которой и будет прибегать прикладной разработчик для воздействия на данные. Сама фирма Oracle пользуется этим очень активно, что проявляется в наличии номенклатуры "встроенных пакетов" на PL/SQL, активно приумножающихся числом в каждой очередной версии СУБД. В версии 11 количество только документированных встроенных пакетов превышает 200. Большая часть из них осуществляет изменения данных в служебных таблицах БД через функции и процедуры PL/SQL.

Этим же путем — процедурного изменения данных в БД — часто следуют прикладные разработчики.

Операторы DML и SELECT из SQL могут употребляться на правах предложений языка PL/SQL. Это дает основание фирме Oracle иногда называть PL/SQL "процедурным расширением" SQL. Эффективность обработки СУБД таких операторов выше, чем у поступивших из внешней программы на общеупотребимом языке программирования.

Лекция 1: 1234 || Лекция 2 >
Ярослав Прозоров
Ярослав Прозоров

В лекции № 7 "Введение в Oracle SQL" в подразделе "Несамостоятельность группировки с обобщениями ROLLUP, CUBE и GROUPING SETS"  представленная таблица сравнения содержит ошибки - окончания запросов пропущены. Видимо, ошибки вызваны некорректным переносом материала лекции.

Володимир Миколайчук
Володимир Миколайчук
Помогите разобраться поетапно с логикой запроса
-------TOOLS
NAME PRICE TYPE
drill 155 A
sawzall 192 N
mitre saw 292 M
router 86 I
RAD 145 M
jigsaw 128 I
screwdriver 77 P
------TOOL_TYPES
TYPE USAGE
A Always
I Often
M Sometimes
N Rarely
P Never

Запрос SQL:
SELECT t.type, SUM(t.price)
FROM tools t
GROUP BY t.type
HAVING SUM(t.price) >= (SELECT AVG(price)
FROM tools
WHERE type IN (SELECT type
FROM tool_types
WHERE usage = 'Often'));

И сколько строк он все таки вернет