Введение в Oracle SQL

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

Разбить на страницы
Показывать лекцию целиком

Происхождение и объем диалекта SQL фирмы Oracle

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

База данных и модель данных

База данных

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

Общепринятого понятия базы данных, несмотря на широкое распространение самого явления, не существует. Вот некоторые примеры разнохарактерных определений.

  • "Обычно большое собрание данных, организованных для особо быстрого и удобного способа поиска и извлечения (например, из ЭВМ)" (Merriam-Webster's Collegiate Dictionary, www.merriam-webster.com/dictionary/database, датировано 1962 годом).
  • "Собрание структуризованных данных в ЭВМ, поддерживаемое СУБД, которая обеспечивает различным приложениям различный вид данных" (F. Pascal, Understanding Relational Databases with examples in SQL-92, New York, NY: John Whiley Sons, 1993).
  • "База данных — набор аксиом. Результат на запрос к базе есть теорема. Процесс вывода теоремы из аксиом есть доказательство. Доказательство осуществляется манипулированием символов по условленным математическим правилам. Доказательство [то есть результат запроса к базе] настолько же здраво и логично (consistent), насколько здравы и логичны правила" (H. Darwen. The Duplicity of Duplicate Rows. Relational Database Writings 1989-1991, Reading, MA: Addison-Wesley, 1992).
    •

    Возможное обобщение этих и других определений:

    "Совокупность всех данных некоторой прикладной области" [для использования в программных системах] (Филиппов В. И. Общее описание системы КОМПАС. // Автоматизация программирования. Москва: ВЦ АН СССР, 1989).

    Существенные элементы в определениях БД:

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

    Моделированием (например, составлением карт местности) человечество занимается не одну тысячу лет, и современные базы данных лишь переводят эту деятельность в компьютерную область. Но современное моделирование средствами БД наследует из далекого прошлого и несколько общих проблем. Например:

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

    • Последнее обстоятельство (необходимость внести в модель данных изменения) может быть вызвано как субъективными причинами, из-за небрежного начального проектирования модели, так и объективными — из-за изменения самой предметной области. Например, в базах личностных данных до 2000-х годов сведения о браке достаточно моделировались парой "муж—жена", тогда как с наступлением XXI века это все чаще становится неприемлемым, и старые базы требуется подправлять.

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

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

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

    СУБД

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

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

    • В число функций, которые обеспечивают современные СУБД, входят следующие:

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

    Реляционный подход к моделированию данных

    Наиболее существенное влияние на современные промышленные виды СУБД, включая Oracle, оказал реляционный подход к моделированию данных. Он основывается на использовании "реляционной теории", частью которой является "реляционная модель". Последняя берет свое начало со статьи своего основателя, Э. Кодда (E. F. Codd), "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", опубликованной в IBM Research Report RJ599 в 1969 году. Впоследствии реляционная модель пережила всплеск интенсивного изучения и уточнения широким кругом специалистов, а в настоящее время она развивается главным образом усилиями К. Дейта (C. J. Date), сподвижника и коллеги Кодда во времена создания модели.

    Реляционная модель данных

    Все, что я съел, и все, что я выпил, осталось со мною;

    Все остальное, что есть, право, не стоит щелчка.

    Выражение "модель данных" часто понимается в двух разных смыслах: как формальное описание некоторой конкретной предметной области и как инструмент для составления подобных описаний. Нужный смысл обычно приходится определять по контексту. Здесь выражение "реляционная модель данных" понимается как инструмент составления в БД конкретных описаний конкретных предметных областей.

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

  • "Тип данных" (type) — множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
  • "Отношение" (relation) — множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
  • "Переменная отношения" (relation variable) — переменная типа отношения конкретного вида, необходимое понятие для определения в базе данных действий по "обновлению отношений", "внесения изменений в данные". В нарушение точности и в силу поверхностно-ознакомительного характера настоящего материала далее вместо названия "переменная отношения" будет употребляться просто "отношение" (подобно вольному употреблению слова "целое" вместо "переменная целого типа").
  • "Ключ" (key) — группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
  • "Внешний ключ" (foreign key) — группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
  • "Операции" (operation) — множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
  • "Реляционная база данных" (relational database) — набор отношений.
    •

    "Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

    Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

    Все взаимоотношения данных описываются явно и только величинами в наборах (в других подходах к моделированию может быть иначе). Никаких "подразумеваемых" зависимостей (в том числе на уровне программной логики), кроме сформулированых переменными отношений, нет. Реляционный подход разграничивает описание данных и сопутствующую приложению программную логику (в противовес, например, объектному подходу).

    Приведенный взгляд на реляционную БД (набор отношений и операции) характерен для реляционной алгебры. Это не единственная точка зрения. Каждый набор величин в переменной отношения можно понимать как истинное высказывание ("предикат"): имеется такой-то сотрудник с такими-то свойствами; такой-то отдел и так далее. Тем самым реляционная база данных в каждый момент времени представляет собой набор истинных высказываний о предметной области, сформулированный через отношения. По сути, набор высказываний в переменных отношений и образует модель предметной области, представленную базой данных. Такой взгляд на реляционную БД характерен для реляционного исчисления. Оба взгляда на реляционную модель хорошо изучены и доказана их выразительная равносильность.

    Проектирование реляционной базы данных

    Задачей проектирования реляционной базы данных можно считать достижение такой системы

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

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

    Устранение избыточности

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

    Простой пример устранения избыточности показан ниже.

    Пусть в отношении, представляющем сведения о сотрудниках, есть атрибуты "зарплата", "комиссионные" и "доход". Если по правилам моделируемой предметной области доход сотрудника складывается исключительно из его зарплаты и комиссионных, один из перечисленных атрибутов следует из определения отношения убрать — скорее всего, это будет "доход":

    В других случаях устранение избыточности может выглядеть отнюдь не столь очевидно. Представьте, что в БД требуется хранить почтовый адрес, включая индекс. Часто для этого используют отдельные атрибуты для индекса и прочих частей адреса, таких как город, улица и так далее. Однако подобное хранение, строго говоря, избыточно, так как почтовый индекс однозначно определяется "словесной частью" адреса. Двойное хранение сведений будет держать открытой лазейку для появления содержательно неверных данных в БД, но чтобы воспрепятствовать этому, потребуется заметно усложнить схему и утяжелить БД (что же, идти на хранение ненужного для иной цели соответствия "словесной части" адреса почтовому индексу?) и, как следствие, — усложнить и замедлить, казалось бы, простые обращения к БД. В силу таких издержек разработчик в жизни нередко предпочитает простоту организации данных рискам, связанным с избыточностью (или, если удается, снимает проблему рассогласования данных с помощью ограничений целостности либо триггерных процедур).

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

    Нормализация реляционной базы данных

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

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

    Пусть в отношении с данными о сотрудниках присутствуют и номер отдела сотрудника, и название отдела. Чтобы устранить зависимость между номером и названием отдела в отношении "сотрудники", достаточно оставить в нем только один из двух атрибутов (скорее всего, это будет "номер отдела"), создать отношение "отделы" с атрибутами "номер отдела" и "название", объявить в нем "номер отдела" ключом. "Номер отдела" в "сотрудниках" следует объявить внешним ключом, связав его с "номером отдела" из "отделов":

    Избавляться от подобного рода функциональных зависимостей в отношениях можно, пока они не окажутся приведенными к "нормальной форме BCNF", Бойса-Кодда (Boyce-Codd); по праву первенства ее следовало бы назвать "нормальной формой Хита" (Heath). В таких отношениях, образно выражаясь, "каждое сведение относится к ключу, всему ключу (со всеми его атрибутами) и только к ключу" (в оригинальной фразе на английском вместо "сведения" дословно сказано "факт"), с тем добавлением, что ключей может быть несколько. Иными словами, в отношении, удовлетворяющем BCNF, произвол значений определяется только правилами ключа — возможно, внешнего ключа и типов атрибутов. Несколько менее строгий вариант BCNF именуется "3-й нормальной формой".

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

    Все предложенные нормальные формы линейно упорядочены, так что достижение в отношении какой-нибудь из них по определению означает выполнение ряда "предыдущих".

    Нормализация отношений способствует:

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

    Часто процесс устранения избыточности автоматически влечет за собой прочие перечисленные выгоды. Приведение отношений к нормальным формам неспособно устранить все виды избыточности, но считается действенным средством для достижения этой цели. Иногда нормализацию данных называют формализованным проявлением здравого смысла. В то же время:

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

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

    Ортогонализация отношений

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

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

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

    Программное воплощение реляционной СУБД

    Среди промышленных систем, наиболее распространенных на рынке, ближе всего к реляционным подошли системы, основанные на 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.

    История и стандарты

    Первая версия SQL была предложена в 1973 году фирмой IBM под названием ). Успех 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. Эффективность обработки СУБД таких операторов выше, чем у поступивших из внешней программы на общеупотребимом языке программирования.

    Страницы:

    Происхождение и объем диалекта SQL фирмы Oracle

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

    База данных и модель данных

    База данных

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

    Общепринятого понятия базы данных, несмотря на широкое распространение самого явления, не существует. Вот некоторые примеры разнохарактерных определений.

  • "Обычно большое собрание данных, организованных для особо быстрого и удобного способа поиска и извлечения (например, из ЭВМ)" (Merriam-Webster's Collegiate Dictionary, www.merriam-webster.com/dictionary/database, датировано 1962 годом).
  • "Собрание структуризованных данных в ЭВМ, поддерживаемое СУБД, которая обеспечивает различным приложениям различный вид данных" (F. Pascal, Understanding Relational Databases with examples in SQL-92, New York, NY: John Whiley Sons, 1993).
  • "База данных — набор аксиом. Результат на запрос к базе есть теорема. Процесс вывода теоремы из аксиом есть доказательство. Доказательство осуществляется манипулированием символов по условленным математическим правилам. Доказательство [то есть результат запроса к базе] настолько же здраво и логично (consistent), насколько здравы и логичны правила" (H. Darwen. The Duplicity of Duplicate Rows. Relational Database Writings 1989-1991, Reading, MA: Addison-Wesley, 1992).
    •

    Возможное обобщение этих и других определений:

    "Совокупность всех данных некоторой прикладной области" [для использования в программных системах] (Филиппов В. И. Общее описание системы КОМПАС. // Автоматизация программирования. Москва: ВЦ АН СССР, 1989).

    Существенные элементы в определениях БД:

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

    Моделированием (например, составлением карт местности) человечество занимается не одну тысячу лет, и современные базы данных лишь переводят эту деятельность в компьютерную область. Но современное моделирование средствами БД наследует из далекого прошлого и несколько общих проблем. Например:

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

    • Последнее обстоятельство (необходимость внести в модель данных изменения) может быть вызвано как субъективными причинами, из-за небрежного начального проектирования модели, так и объективными — из-за изменения самой предметной области. Например, в базах личностных данных до 2000-х годов сведения о браке достаточно моделировались парой "муж—жена", тогда как с наступлением XXI века это все чаще становится неприемлемым, и старые базы требуется подправлять.

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

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

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

    СУБД

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

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

    • В число функций, которые обеспечивают современные СУБД, входят следующие:

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

    Реляционный подход к моделированию данных

    Наиболее существенное влияние на современные промышленные виды СУБД, включая Oracle, оказал реляционный подход к моделированию данных. Он основывается на использовании "реляционной теории", частью которой является "реляционная модель". Последняя берет свое начало со статьи своего основателя, Э. Кодда (E. F. Codd), "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", опубликованной в IBM Research Report RJ599 в 1969 году. Впоследствии реляционная модель пережила всплеск интенсивного изучения и уточнения широким кругом специалистов, а в настоящее время она развивается главным образом усилиями К. Дейта (C. J. Date), сподвижника и коллеги Кодда во времена создания модели.

    Реляционная модель данных

    Все, что я съел, и все, что я выпил, осталось со мною;

    Все остальное, что есть, право, не стоит щелчка.

    Выражение "модель данных" часто понимается в двух разных смыслах: как формальное описание некоторой конкретной предметной области и как инструмент для составления подобных описаний. Нужный смысл обычно приходится определять по контексту. Здесь выражение "реляционная модель данных" понимается как инструмент составления в БД конкретных описаний конкретных предметных областей.

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

  • "Тип данных" (type) — множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
  • "Отношение" (relation) — множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
  • "Переменная отношения" (relation variable) — переменная типа отношения конкретного вида, необходимое понятие для определения в базе данных действий по "обновлению отношений", "внесения изменений в данные". В нарушение точности и в силу поверхностно-ознакомительного характера настоящего материала далее вместо названия "переменная отношения" будет употребляться просто "отношение" (подобно вольному употреблению слова "целое" вместо "переменная целого типа").
  • "Ключ" (key) — группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
  • "Внешний ключ" (foreign key) — группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
  • "Операции" (operation) — множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
  • "Реляционная база данных" (relational database) — набор отношений.
    •

    "Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

    Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

    Все взаимоотношения данных описываются явно и только величинами в наборах (в других подходах к моделированию может быть иначе). Никаких "подразумеваемых" зависимостей (в том числе на уровне программной логики), кроме сформулированых переменными отношений, нет. Реляционный подход разграничивает описание данных и сопутствующую приложению программную логику (в противовес, например, объектному подходу).

    Приведенный взгляд на реляционную БД (набор отношений и операции) характерен для реляционной алгебры. Это не единственная точка зрения. Каждый набор величин в переменной отношения можно понимать как истинное высказывание ("предикат"): имеется такой-то сотрудник с такими-то свойствами; такой-то отдел и так далее. Тем самым реляционная база данных в каждый момент времени представляет собой набор истинных высказываний о предметной области, сформулированный через отношения. По сути, набор высказываний в переменных отношений и образует модель предметной области, представленную базой данных. Такой взгляд на реляционную БД характерен для реляционного исчисления. Оба взгляда на реляционную модель хорошо изучены и доказана их выразительная равносильность.

    Проектирование реляционной базы данных

    Задачей проектирования реляционной базы данных можно считать достижение такой системы

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

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

    Устранение избыточности

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

    Простой пример устранения избыточности показан ниже.

    Пусть в отношении, представляющем сведения о сотрудниках, есть атрибуты "зарплата", "комиссионные" и "доход". Если по правилам моделируемой предметной области доход сотрудника складывается исключительно из его зарплаты и комиссионных, один из перечисленных атрибутов следует из определения отношения убрать — скорее всего, это будет "доход":

    В других случаях устранение избыточности может выглядеть отнюдь не столь очевидно. Представьте, что в БД требуется хранить почтовый адрес, включая индекс. Часто для этого используют отдельные атрибуты для индекса и прочих частей адреса, таких как город, улица и так далее. Однако подобное хранение, строго говоря, избыточно, так как почтовый индекс однозначно определяется "словесной частью" адреса. Двойное хранение сведений будет держать открытой лазейку для появления содержательно неверных данных в БД, но чтобы воспрепятствовать этому, потребуется заметно усложнить схему и утяжелить БД (что же, идти на хранение ненужного для иной цели соответствия "словесной части" адреса почтовому индексу?) и, как следствие, — усложнить и замедлить, казалось бы, простые обращения к БД. В силу таких издержек разработчик в жизни нередко предпочитает простоту организации данных рискам, связанным с избыточностью (или, если удается, снимает проблему рассогласования данных с помощью ограничений целостности либо триггерных процедур).

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

    Нормализация реляционной базы данных

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

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

    Пусть в отношении с данными о сотрудниках присутствуют и номер отдела сотрудника, и название отдела. Чтобы устранить зависимость между номером и названием отдела в отношении "сотрудники", достаточно оставить в нем только один из двух атрибутов (скорее всего, это будет "номер отдела"), создать отношение "отделы" с атрибутами "номер отдела" и "название", объявить в нем "номер отдела" ключом. "Номер отдела" в "сотрудниках" следует объявить внешним ключом, связав его с "номером отдела" из "отделов":

    Избавляться от подобного рода функциональных зависимостей в отношениях можно, пока они не окажутся приведенными к "нормальной форме BCNF", Бойса-Кодда (Boyce-Codd); по праву первенства ее следовало бы назвать "нормальной формой Хита" (Heath). В таких отношениях, образно выражаясь, "каждое сведение относится к ключу, всему ключу (со всеми его атрибутами) и только к ключу" (в оригинальной фразе на английском вместо "сведения" дословно сказано "факт"), с тем добавлением, что ключей может быть несколько. Иными словами, в отношении, удовлетворяющем BCNF, произвол значений определяется только правилами ключа — возможно, внешнего ключа и типов атрибутов. Несколько менее строгий вариант BCNF именуется "3-й нормальной формой".

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

    Все предложенные нормальные формы линейно упорядочены, так что достижение в отношении какой-нибудь из них по определению означает выполнение ряда "предыдущих".

    Нормализация отношений способствует:

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

    Часто процесс устранения избыточности автоматически влечет за собой прочие перечисленные выгоды. Приведение отношений к нормальным формам неспособно устранить все виды избыточности, но считается действенным средством для достижения этой цели. Иногда нормализацию данных называют формализованным проявлением здравого смысла. В то же время:

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

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

    Ортогонализация отношений

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

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

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

    Программное воплощение реляционной СУБД

    Среди промышленных систем, наиболее распространенных на рынке, ближе всего к реляционным подошли системы, основанные на 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.

    История и стандарты

    Первая версия SQL была предложена в 1973 году фирмой IBM под названием ). Успех 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. Эффективность обработки СУБД таких операторов выше, чем у поступивших из внешней программы на общеупотребимом языке программирования.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^