Опубликован: 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. К ним относится Oracle. Все такие системы наследуют у реляционного моделирования важные свойства. Например:

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

Упомянутые понятия SQL (таблицы, уникальные столбцы, внешние ключи) являются неточными параллелями понятий реляционной модели (отношения, ключи, "реляционные" внешние ключи соответственно), однако имеют их своими прообразами и действительно воспроизводят некоторые их важные качества.

Наработки по проектированию "баз данных отношений" в целом переносятся на системы типа SQL. В частности, для БД типа SQL также желательны устранение избыточности, нормализация и ортогонализация, но уже таблиц.

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

  • в таблицах первичные ключи необязательны, а значит, допускаются повторяющиеся строки (в отношениях наборы величин суть истинные высказывания о предметной области, а повторение факта логически бессмысленно, но есть и другие препятствия к оправданию повторений);
  • понятие реляционных "доменов" (типов данных) недореализовано или реализовано с ошибками (встроенные типы данных примитивны и нарушают строгую типизацию, а объектные типы не обязаны поддерживать сравнение);
  • требуется "ручная" оптимизация запросов (а полагалось, что формулировка запроса выбирается программистом из соображения удобства восприятия, а оптимизация выполнения — забота исключительно СУБД);
  • другие.

Неприятные практические последствия подобных отличий и противоречий описаны в литературе.

Попытки создать промышленную реляционную СУБД за всю историю существования реляционной теории не увенчались успехом. Они не прекращаются ( http://en.wikipedia.org/wiki/D_%28data_language_specification%29#Tutorial_D), но об использовании SQL в таких экспериментальных системах речи не идет.

Другие подходы к моделированию данных и другие типы СУБД

Наряду с реляционным подходом к моделированию данных существуют и другие, обладающие разной степени строгостью определения, распространенности и разными областями применения.

  • Объектный подход.
  • Объектно-реляционный подход.
  • Многомерное моделирование.
  • Дедуктивное моделирование.

Объектный подход к моделированию БД дополняет объектно-ориентированное программирование и имеет давнюю историю. В число основных понятий такого подхода входят такие как: объект, класс/тип, метод/оператор/функция, сообщения; инкапсуляция, уникальный идентификатор объекта, наследование, полиморфизм операций. Этот набор неоднозначен и сложен для начального освоения разработчиками, что отрицательно сказалось на распространении объектного подхода. Вторым отрицательным фактором является отсутствие методологии проектирования объектных БД; третьим — технические трудности реализации, вызванные необходимостью долговременного хранения объектов. В результате объектный подход в области баз данных в чистом виде не получил широкого распространения, чем решительно отличается от объектного же подхода, но в программировании, где объекты не требуется хранить продолжительное время.

Объектно-реляционный подход к моделированию БД еще менее отчетливо сформулирован, нежели чисто объектный. Практически он обернулся включением (во второй половине 90-х годов) в состав ведущих систем управления данными на основе SQL возможностей хранения объектных данных. Некоторые основы такого включения (например, приравнивание класса домену, или же объекта строке таблицы) остаются спорными. Фирма Oracle расширила табличные средства моделирования данных объектными возможностями в версии 8 своей СУБД, которую с этого времени стала именовать "объектно-реляционной". Поверхностное знакомство с объектными возможностями Oracle состоится в соответствующем разделе далее. Более плотное знакомство требует существенного увеличения объема материала.

Многомерное моделирование данных в базах данных имеет еще более давнюю, чем объектное, историю, уходящую корнями в 70-е годы. К его основным понятиям могут быть причислены: гиперкуб данных (или, по многомерной терминологии, "фактов"), измерения, иерархии, атрибуты. По большому счету (теоретически), оно не добавляет нового к тому, на что способны табличные СУБД, однако предлагает собственное представление данных и операции, что делает его удобным, а при соответствующей организации и эффективным в системах анализа данных. Фирма Oracle, купив в конце 90-х годов многомерную систему управления данными, встроила в свою СУБД основанную на функциональности купленной системы "машину OLAP" (on-line analytical processing). С версии 9 средства OLAP поставляются в составе Oracle Enterprise Edition. Они воплощены в двух исполнениях: унаследованном, предполагающим встроенную в СУБД самостоятельную систему хранения, и со сведением данных гиперкуба в привычную таблицу. Последнее исполнение рассчитано на работу с данными посредством SQL, слегка расширенного для этого случая фирмой-изготовителем. Это расширение специфично, несколько непоследовательно и далее не рассматривается.

Перечисленные подходы к моделированию данных существенно отличаются от реляционного тем, что не имеют математического обоснования, с вытекающими из этого последствиями:

  • отсутствием общепризнанной и экономной системы понятий,
  • невозможностью оценки создаваемых БД аналитическими средствами,
  • отсутствием методологии проектирования БД.

Из-за этого распространенность перечисленных подходов на практике ограничена.

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

Помимо указанного можно говорить о:

  • безмодельных БД;
  • слабоструктурированных БД.

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

Примером слабоструктурированных данных можно привести БД документов XML. Хранение документов XML в БД Oracle разрешила в версии 9.2 в двух вариантах: основном и продвинутом. Последний получил название XML DB, воплощая как бы "базу (XML) в базе (обычной)". Как и Oracle Text, XML DB поддерживается взаимодополняюще средствами SQL и встроенных программных пакетов, и по тем же причинам в этом материале она освещения не получила.

SQL

Что такое SQL?

Structured Query Language — язык, первоначально задумывавшийся как инструмент работы с реляционными базами данных, но с этой ролью в конце концов не справившийся.

Состоит из нескольких "подъязыков" разной функциональной направленности:

  • Запросы к данным БД (query language, QL) — выборка данных из таблиц предложением SELECT.
  • Язык манипулирования данными ("обработки данных"), ЯМД; Data Manipulation Language (DML) — изменение данных в существующих таблицах.
  • Язык управления транзакциями — например, фиксация или отмена произведенных программой изменений в БД.
  • Язык определения данных (ЯОД); Data Definition Language (DDL) — например, создание таблиц и прочих объектов хранения или изменение их свойств.
  • Язык управления данными (ЯУД; data control language, DCL) — управление разрешением доступа к данным путем выдачи или изъятия полномочий командами GRANT и REVOKE, заданием в системе пользователей данных.

Единицами языка являются "команды", или "предложения" (commands, они же statements), или же "операторы". Слово "запрос" (query) иногда трактуют расширительно, понимая под ним любую команду SQL как "запрос к БД". С другой стороны, предложения SELECT часто обсуждают вместе с предложениями категории DML и в таких случаях иногда причисляют к последним.

Общие структурные свойства предложений DML и запросов можно охарактеризовать следующим образом:

  • Непроцедурность. Проявляется двояко:
    • Каждое предложение SQL является самодостаточным; предложения SQL не предназначены для процедурного описания действий.
    • Считается, что запрос к данным в SQL формулируется не указанием процедуры вычисления результата, а описанием свойств результата (statement буквально "утверждение"); СУБД же по указанным программистом свойствам автоматически строит последовательность действий, приводящую к требуемому результату. Современный SQL содержит некоторые отклонения от такой непроцедурности.
  • Множественность. Запросы SQL на выборку и изменение данных есть операции со множествами строк, не предполагающими упорядоченности.
  • По способу использования предложения SQL разделяются на две разновидности:
  • Диалоговый SQL. Вариант формулировок предложений языка (на выборку и изменение данных), предполагающий диалог программиста с СУБД по схеме "вопрос-ответ". Пример — работа с БД через программу Oracle SQL*Plus.
  • Встроенный SQL. Вариант формулировок языка, предполагающий размещение предложений SQL в программе (на C, C++, Cobol, Java, PL/SQL и проч.).

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

Лекция 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'));

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