sql история развития языка
История языков программирования: SQL- стандартизация длиною в жизнь
По мнению аналитиков CodingDojo, SQL — самый важный и нужный язык запросов среди языков программирования, как бы странно это ни звучало. Рейтинг CodingDojo учитывает статистику востребованности языков программирования на рынке труда.
Ведь СУБД – MySQL, PostgreSQL и Microsoft SQL Server – распространены повсеместно: в крупном и малом бизнесе, в больницах, банках, университетах и так далее. В принципе, SQL не ограничивается только настольными девайсами: СУБД SQLite с успехом заняла свое место на Android-смартфонах и мобильных устройствах Apple. Соответственно, такие приложения, как Skype и Dropbox, постоянно к ней обращаются.
Однако были времена, когда не было смартфонов, а этот язык уже существовал. История SQL – это не годы, но десятилетия. Поверили в него не сразу.
System R и IBM
Первые упоминания об этом языке датируются 1974 годом. SQL создавался в рамках проекта экспериментальной реляционной СУБД System R. Занималась этим проектом компания IBM.
Первоначально язык назывался SEQUEL (Structured English Query Language), но потом слово «English» пропало из этого словосочетания, а аббревиатура приобрела тот вид, к которому мы давно уже привыкли. С одной стороны, SQL был ориентирован на удобную и понятную пользователям формулировку запросов к реляционным БД. С другой стороны, практически с самого начала он был так называемым «полным языком БД». Это означает, что SQL включал:
• средства определения и манипулирования схемой БД;
• средства определения ограничений целостности и триггеров;
• средства определения представлений БД;
• средства определения структур физического уровня, поддерживающих эффективное выполнение запросов;
• средства авторизации доступа к отношениям и их полям;
• средства определения точек сохранения транзакции и выполнения фиксации и откатов транзакций.
Правда, в нем не были реализованы средства синхронизации доступа к объектам БД со стороны параллельно выполняемых транзакций. Дело в том, что разработчики изначально рассчитывали, что необходимую синхронизацию неявно выполняет СУБД.
Язык реализован в подавляющем большинстве СУБД – как в реляционных, так и нереляционных. Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования.
Разработкой языка запросов занимались Дональд Чэмбэрлин (Donald D. Chamberlin) и Рэй Бойс (Ray Boyce).
SEQUEL был не единственным языком подобного назначения. В Калифорнийском Университете Беркли была разработана некоммерческая СУБД Ingres, которая являлась реляционной СУБД, но использовала свой собственный язык QUEL, который, однако, не выдержал конкуренции по количеству поддерживающих его СУБД по сравнению с языком SQL.
В System R была реализована наиболее сложная и полная версия SQL. Чуть меньше функциональности было в SQL/DS и DB2 от той же IBM. Из SQL System R были удалены только те части, которые были недостаточно проработаны (например, точки сохранения) или реализация которых вызывала слишком большие технические трудности (например, ограничения целостности и триггеры).
Коммерческий успех
Поэтому путь к коммерческой реализации SQL, который прошла IBM, называют движением «сверху вниз».
Oracle, Informix и Sybase пошли по другому пути – «снизу вверх»: в первых версиях этих систем, выпущенных на рынок, использовалось существенно ограниченное подмножество SQL System R. А далее они начали постепенно расширяться. Однако в первой коммерческой реализации SQL в СУБД Oracle в операторах выборки не допускалось использование вложенных подзапросов и отсутствовала возможность формулировки запросов с соединениями нескольких отношений.
Распеределение рыночных долей по состоянию на 2011 год
Растущая заинтересованность рынка в скорейшем переходе к реляционным системам управления базами данных позволила разработчикам перечисленных выше компаний добиться коммерческого успеха. Это произошло, скорее, вопреки тому, что СУБД были тогда очень далеки от совершенства. Ну а теперь Oracle, Informix, Sybase и Microsoft SQL Server поддерживают достаточно мощные диалекты SQL.
Стандартизация
Появление многочисленных диалектов SQL и их разрастание должно было привести к проблемам совместимости и прочим противоречиям.
Однако деятельность по стандартизации языка SQL началась очень вовремя – практически одновременно с появлением его первых коммерческих реализаций. В 1982 году комитету по базам данных Американского национального института стандартов (ANSI) было поручено разработать спецификацию стандартного языка реляционных баз данных.
После отклонения ряда неудачных версий стандарта в 1986 году эксперты пришли к единому знаменателю. А в 1987 году стандарт SQL/86 был одобрен Международной организацией по стандартизации (ISO).
За основу стандарта нельзя было брать SQL System R. Во-первых, этот вариант языка был недостаточно проработан технически. Во-вторых, его слишком сложно было бы реализовать. Поэтому за основу был взят диалект языка SQL, сложившийся в IBM к началу 1980-х годов. В сущности, этот диалект представлял собой подмножество SQL System R.
Стандарт SQL1
К 1989 году стандарт SQL/86 был несколько расширен, после чего появился следующий стандарт, получивший название ANSI/ISO SQL/89.
SQL/89 стал первым всемирно принятым стандартом языка SQL. У этого языка имеется масса недостатков: многие важные понятия не определены, много отдано на откуп реализациям. В этом стандарте полностью отсутствуют такие важные разделы, как манипулирование схемой БД и динамический SQL.
Но тем не менее он сыграл свою роль в становлении действительно стандартизованных реляционных систем управления базами данных. Более того, с появлением стандарта SQL/89 стало возможно проектировать, разрабатывать и сопровождать информационные системы, не слишком привязанные к конкретному производителю СУБД. В некотором смысле появление SQL/89 явилось продвижением технологии баз данных в сторону открытых систем.
Возможно, наиболее важными достижениями стандарта SQL/89 являются четкая стандартизация синтаксиса, семантики операторов выборки данных и манипулирования данными, а также фиксация средств ограничения целостности БД.
В стандарте определяются два уровня языка и отдельное средство поддержания целостности. Уровень 2 — это полный язык баз данных SQL, не включающий средство поддержания целостности. Уровень 1 — это специфицированное подмножество уровня 2.
Средство поддержания целостности включает возможности определения:
• требуемых ограничений на ссылки между таблицами;
• проверочных ограничений на строки таблицы;
• значений столбца по умолчанию при занесении строки в таблицу.
Средства определения внешних ключей позволяют легко формулировать требования так называемой ссылочной целостности БД. Это распространенное в реляционных БД требование можно было сформулировать и на основе общего механизма ограничений целостности SQL System R, но формулировка на основе понятия внешнего ключа более проста и понятна.
Возможности операции Join в разных стандартах
Стандарт SQL2 и его дополнения
Осознавая неполноту стандарта SQL, специалисты различных компаний начали работу над очередным стандартом, который получил название SQL2. Эта работа также длилась несколько лет, было выпущено множество проектов стандарта, пока наконец в марте 1992 года не был принят окончательный проект стандарта (SQL/92). Этот стандарт существенно полнее стандарта SQL/89 и охватывает практически все аспекты, необходимые для реализации приложений: манипулирование схемой БД, управление транзакциями (появились точки сохранения) и сессиями (сессия – это последовательность транзакций, в пределах которой сохраняются временные отношения), подключения к БД, динамический SQL. Наконец, были стандартизованы отношения-каталоги БД, что вообще-то не связано непосредственно с языком, но очень сильно влияет на реализацию.
В 1995 году стандарт был дополнен спецификацией интерфейса уровня вызова (Call-Level Interface – SQL/CLI). SQL/CLI представляет собой набор спецификаций интерфейсов процедур, вызовы которых позволяют выполнять динамически задаваемые операторы SQL. По сути дела, SQL/CLI представляет собой альтернативу динамическому SQL.
Стандарт SQL/CLI послужил основой для создания повсеместно распространенных сегодня интерфейсов ODBC (Open Database Connectivity) и JDBC (Java Database Connectivity).
В 1996 году к стандарту SQL/92 был добавлен еще один компонент – SQL/PSM (Persistent Stored Modules). Основная цель этой спецификации – стандартизировать способы определения и использования хранимых процедур, то есть специальным образом оформленных программ, включающих операторы SQL, которые сохраняются в базе данных, могут вызываться приложениями и выполняются внутри СУБД.
Oracle является одной из наиболее популярных СУБД. Более того, именно там впервые была реализована совместимость со стандартом SQL/92.
А изначально первой СУБД, поддерживающей язык SQL, стала Oracle V2, разработанная для машин VAX. Это было еще в в 1979 году.
Oracle поддерживает ряд различных платформ, включая Windows, Linux, Max OS X и Sun Solaris.

PL/SQL поддерживает программные блоки, а также разнообразные типы данных для хранения чисел, строк и дат, операторы управления потоком вычислений (в том числе условные переходы и циклы) и три типа контейнеров (коллекций) — массивы переменной длины, ассоциативные массивы и вложенные таблицы.
Стандарт SQL3
Каждый новый вариант стандарта языка SQL был существенно объемнее предыдущих версий. Так, если стандарт SQL/89 занимал около 600 страниц, то объем SQL/92 составлял на 300 с лишним страниц больше.
Самые первые проекты SQL3 занимали около 1500 страниц.
Однако разработчики SQL3 пришли к выводу, что при таких объемах стандарта вероятность его принятия и последующей успешной поддержки заметно уменьшается. Поэтому они решили разбить стандарт на относительно независимые части, которые можно было бы разрабатывать и поддерживать по отдельности.
В 1999 году были приняты пять частей стандарта SQL:1999.
Первая часть (SQL/Framework) посвящена описанию концептуальной структуры стандарта. В этой части приводится развернутая аннотация следующих четырех частей и формулируются требования к реализациям, претендующим на соответствие стандарту.
Вторая часть SQL:1999 (SQL/Foundation) образует базис стандарта. Вводится система типов языка, формулируются правила определения функциональных зависимостей и возможных ключей, определяются синтаксис и семантика основных операторов SQL:
• операторов определения и манипулирования схемой базы данных;
• операторов манипулирования данными;
• операторов управления транзакциями;
• операторов управления подключениями к базе данных и т. д.
Третью часть занимает уточненная по сравнению с SQL/92 спецификация SQL/CLI. В четвертой части специфицируется SQL/PSM – синтаксис и семантика языка определения хранимых процедур. Наконец, в пятой части – SQL/Bindings – определяются правила связывания SQL для стандартных версий языков программирования.
В стандарт SQL:1999 должны были войти еще несколько частей. Среди них спецификации следующих средств:
• управление распределенными транзакциями (SQL/Transaction);
• поддержка темпоральных свойств данных (SQL/Temporal);
• управление внешними данными (SQL/MED);
• связывание с объектно-ориентированными языками программирования (SQL/OLB);
• поддержка оперативной аналитической обработки (SQL/OLAP).
SQL в XXI веке
В конце 2003 года был принят и опубликован новый вариант международного стандарта SQL:2003. Многие специалисты считали, что в варианте стандарта, следующем за SQL:1999, будут всего лишь исправлены неточности SQL:1999. Но на самом деле, в SQL:2003 специфицирован ряд новых и важных свойств, с небольшими модификациями, внесёнными позже в 2008 году.
Наиболее серьезные изменения языка SQL, специфицированные в части 2 стандарта SQL:2003, касаются следующих аспектов:
• типы данных;
• подпрограммы, вызываемые из SQL;
• расширенные возможности оператора CREATE TABLE;
• новый объект схемы – генератор последовательностей;
• новые виды столбцов – идентифицирующие столбцы (identity column) и генерируемые столбцы (generated column);
• новый оператор MERGE;
Претерпела некоторые изменения общая организация стандарта. Стандарт SQL:2003 состоит из следующих частей:
• 9075-1, SQL/Framework;
• 9075-2, SQL/Foundation;
• 9075-3, SQL/CLI;
• 9075-4, SQL/PSM;
• 9075-9, SQL/MED;
• 9075-10, SQL/OLB;
• 9075-11, SQL/Schemata;
• 9075-13, SQL/JRT;
• 9075-14, SQL/XML.
Части 1-4 и 9-10 с необходимыми изменениями остались такими же, как и в SQL:1999. Часть 5 (SQL/Bindings) перестала существовать; соответствующие спецификации включены в часть 2.
Раздел части 2 SQL:1999, посвященный информационной схеме, выделен в отдельную часть 11. Появились две новые части – 13 и 14.
Часть 13 полностью называется «SQL Routines and Types Using the Java Programming Language» («Использование подпрограмм и типов SQL в языке программирования Java»). Появление такой части стандарта оправдано повышенным вниманием к языку Java со стороны ведущих производителей SQL-ориентированных СУБД.
Наконец, последняя часть SQL:2003 посвящена спецификациям языковых средств, позволяющих работать с XML-документами в среде SQL.
Несмотря на старания разработчиков, процесс стандартизации явно не поспевает за происходящими изменениями.
Основные моменты в истории SQL
Тем не менее, можно сказать, что базовый набор операторов SQL, включающий операторы определения схемы БД, выборки и манипулирования данными, авторизации доступа к данным, поддержки встраивания SQL в языки программирования и операторы динамического SQL, в коммерческих реализациях устоялся и более или менее соответствует стандарту.
Тема 3. Язык SQL. Формирование запросов к базе данных
Оглавление
Цель: изучить язык работы с реляционными базами данных SQL в рамках существующих стандартов.
Задачи:
3.1. История развития SQL. Стандарты языка
SQL (Structured Query Language) — структурированный язык запросов — стандартный язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры. Его прототип был разработан в конце 70-х гг. в компании IBM Research. Он был реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот язык применялся во многих коммерческих СУБД и в силу своего широкого распространения постепенно стал стандартом «де-факто» для языков манипулирования данными в реляционных СУБД.
Первый международный стандарт языка SQL был принят в 1989 г. (далее мы будем называть его SQL/89 или SQL1). Иногда стандарт SQL1 также называют стандартом ANSI/ISO. Подавляющее большинство доступных на рынке СУБД поддерживают этот стандарт полностью. Однако развитие информационных технологий, связанных с базами данных, и необходимость реализации переносимых приложений потребовали в скором времени доработки и расширения первого стандарта SQL.
В конце 1992 г. был принят новый международный стандарт языка SQL, который в дальнейшем будем называть SQL/92 или SQL2. И он не лишен недостат ков, но в то же время является существенно более точным и полным, чем SQL/89. В настоящий момент большинство производителей СУБД внесли изменения в свои продукты, чтобы они в большей степени удовлетворяли стандарту SQL2.
В 1999 г. появился новый стандарт, названный SQL3. Если отличия между стандартами SQL1 и SQL2 во многом были количественными, то стандарт SQL3 имеет качественные преобразования. В SQL3 введены новые типы данных, при этом предполагается возможность задания сложных структурированных типов данных, которые в большей степени соответствуют объектной ориентации. Наконец, добавлен раздел, который вводит стандарты на события и триггеры, которые ранее не затрагивались в стандартах, хотя давно уже широко использовались в коммерческих СУБД. В стандарте определены возможности четкой спецификации триггеров как совокупности события и действия. В качестве действия могут выступать не только последовательность операторов SQL, но и операторы управления ходом выполнения программы. В рамках управления транзакциями произошел возврат к старой модели транзакций, допускающей точки сохранения (savepoints). Возможность указания в операторе отката ROOLBACK точек возврата позволит откатывать транзакцию не в начало, а в промежуточную ранее сохраненную точку. Такое решение повышает гибкость реализации сложных алгоритмов обработки информации.
Зачем нужны эти стандарты? Зачем их изобретают и почему надо их изучать? Текст стандарта SQL2 занимает 600 станиц сухого формального текста, это очень много, и кажется, что это просто происки разработчиков стандартов, а не то, что необходимо рядовым разработчикам. Однако ни один серьезный разработчик, работающий с базами данных, не должен игнорировать стандарт, и для этого существуют весьма веские причины. Разработка любой информационной системы, ориентированной на технологию баз данных (а других информационных систем сегодня нет), является трудоемким процессом, занимающим несколько десятков и даже сотен человеко-месяцев. Следует отдавать себе отчет, что нельзя разработать сколько-нибудь серьезную систему за несколько дней. Кроме того, развитие вычислительной техники, систем телекоммуникаций и программного обеспечения столь стремительно, что проект может устареть еще до момента внедрения. Но развивается не только вычислительная техника, изменяются и реальные объекты, поведение которых моделируется путем использования как самой БД, так и процедур обработки информации в ней, т. е. конкретных приложений, которые составляют реальное наполнение разрабатываемой информационной системы. Именно поэтому проект информационной системы должен быть рассчитан на расширяемость и переносимость на другие платформы.
Большинство поставщиков аппаратуры и программного обеспечения следуют стратегии поддержки стандартов, в противном случае пользователи просто не будут их покупать. Однако каждый поставщик стремится улучшить свой продукт введением дополнительных возможностей, не входящих в стандарт. Разработчики, следовательно, могут или ориентироваться только на экзотические особенности данного продукта, или стараться в основном придерживаться стандарта. Во втором случае весь интеллектуальный труд, вкладываемый в разработку, становится более защищенным, так как система приобретает свойства переносимости. И в случае появления более перспективной платформы проект, ориентированный в большей степени на стандарты, может быть легче перенесен на нее, чем тот, который в основном ориентировался на особенности конкретной платформы. Кроме того, стандарты — это верный ориентир для разработчиков, так как все поставщики СУБД в своих перспективных разработках обязательно следуют стандарту, и можно быть уверенным, что в конце концов стандарт будет реализован практически во всех перспективных СУБД. Так произошло со стандартом SQL1, так происходит со стандартом SQL2 и так будет происходить со стандартом SQL3.
Для поставщиков СУБД стандарт — это путеводная звезда, которая гарантирует правильное направление работ. А вот эффективность реализации стандарта — это гарантия успеха.
SQL нельзя в полной мере отнести к традиционным языкам программирования, он не содержит традиционные операторы, управляющие ходом выполнения программы, операторы описания типов и многое другое, он содержит только набор стандартных операторов доступа к данным, хранящимся в базе данных. Операторы SQL встраиваются в базовый язык программирования, которым может быть любой стандартный язык типа C++, PL, COBOL и т. д. Кроме того, операторы SQL могут выполняться непосредственно в интерактивном режиме.
3.2. Структура SQL
В отличие от реляционной алгебры, где были представлены только операции запросов к БД, SQL является полным языком, в нем присутствуют не только операции запросов, но и операторы, соответствующие DDL (Data Definition Language) — языку описания данных. Кроме того, язык содержит операторы, предназначенные для управления (администрирования) БД.
SQL содержит разделы, представленные в табл.3.1 — 3.6.
Структурированный язык запросов SQL
Материал из ПИЭ.Wiki
SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.
Вопреки существующим заблуждениям, SQL в его чистом (базовом) виде является информационно-логическим языком, а не языком программирования. Вместе с тем стандарт языка спецификацией SQL/PSM предусматривает возможность его процедурных расширений, с учётом которых язык уже вполне может рассматриваться в качестве языка программирования.
SQL основывается на реляционной алгебре.
Содержание
Краткая история развития SQL
SQL ведет свою историю с начала 1970-х годов, когда в исследовательской лаборатории компании IBM в штате Калифорния была разработана его первая версия. Первая публикация описания языка относится к 1974 году. В то время его назвали SEQUEL (Structured English Query Language — структурированный английский язык запросов). Сначала он был реализован в экспериментальной реляционной СУБД System/R, проект которой инициировала в середине 70-х годов компания IBM в исследовательской лаборатории в Сан-Хосе. При реализации последующей версии System/R язык был переименован в SQL. Исследовательский проект System/R был завершен в 1979 году. Он подтвердил возможность создания эффективных промышленных реляционных СУБД.
В 1977 году небольшая, только что организованная фирма Relational Software приступила к созданию промышленной реляционной СУБД на основе SQL. Поставки этой СУБД, получившей название Oracle, начались в 1979 году. Вскоре и сама фирма была переименована в Oracle. С тех пор она является крупнейшим поставщиком реляционных СУБД на базе SQL.
В середине 70-х годов в исследовательской лаборатории Калифорнийского университета в Беркли был открыт проект по созданию реляционной СУБД. В этой лаборатории, как и в компании IBM, создали экспериментальную СУБД, получившую название Ingress, на которой отрабатывались результаты научных исследований в области реляционных баз данных. В 1980 году часть сотрудников этой лаборатории организовали фирму Relational Technology, которая в 1981 году выпустила промышленную СУБД Ingress. Первоначально эта СУБД использовала реляционный язык QUEL, однако в 1986 году была переведена на SQL.
К середине 80-х годов SQL уже общепризнан как язык реляционных СУБД, а его диалект, поддерживаемый СУБД DB2, фактически стал стандартом для управления реляционными базами данных. К этому времени реляционные базы данных господствовали среди СУБД других типов и считались основной технологией баз данных будущего.
Стандартизация SQL
К началу 80-х годов в связи с широким распространением реляционных СУБД появилась необходимость анализа возможной стандартизации языка для управления реляционными базами данных и разработки такого стандарта, если это будет признано целесообразным. В связи с этим в 1982 году Американский национальный институт стандартов (American National Standards Institute — ANSI) создал комитет ХЗН2, перед которым была поставлена эта задача. Комитет принял к рассмотрению различные реляционные языки, которые были описаны и реализованы к тому времени. Однако, учитывая широкую распространенность SQL в промышленных СУБД и тот факт, что он фактически уже стал стандартом к тому времени, комитет остановился на этом языке. Взяв за основу его диалект, реализованный в СУБД DB2, комитет постарался его обобщить, учитывая реализованные в других реляционных СУБД возможности. После четырех лет работы, в 1986 году предложенный комитетом вариант SQL был официально утвержден как стандарт ANSI, а в 1987 году он был принят в качестве стандарта Международной организацией стандартов (International Standards Organization — ISO). Затем стандарт ANSI/ISO приняло правительство США как федеральный стандарт в области обработки информации (Federal Information Processing Standard — FIPS). В 1989 году стандарт был незначительно изменен и получил название SQL-89 (или SQL1).
При разработке стандарта SQL-89 члены комитета ХЗН2 столкнулись с многообразием диалектов языка в реализованных на то время СУБД. В состав комитета входили представители ведущих фирм — производителей СУБД, и многие вопросы, касающиеся отличительных особенностей диалектов, не удалось согласовать. В связи с этим было принято компромиссное решение, согласно которому стандартизовано было ядро языка, а существующие различия отнесли к особенностям реализации. Это решение удовлетворило разработчиков СУБД, так как их варианты SQL оказались совместимыми со стандартом, но это же сделало стандарт SQL слабым.
Последующая деятельность этого комитета, который со временем получил название ANSI ТС NCITS H2, была направлена на устранение недостатков стандарта. В 1992 году ANSI принял новый стандарт, который был назван SQL-92 (или SQL2). В этом стандарте комитет не пошел на поводу производителей СУБД и предусмотрел возможности, которые выходили за рамки имеющихся в промышленных СУБД, — были расширены способы ограничения целостности, введена поддержка различных языков программирования, предусмотрена обработка транзакций и многое другое. В связи с существенным расширением языка было введено три уровня совместимости стандартов. Нижний уровень (Entry Level) предполагает минимальные дополнения к стандарту SQL-89. Промежуточный уровень (Intermediate Level) существенно расширяет SQL-89, но не затрагивает сложных элементов языка. Третий уровень (Full Level) представляет полную спецификацию нового стандарта.
В 1992 году комитет приступил к решительным изменениям в SQL, которые отразились в стандарте SQL-99 (или SQL3). Первое принципиальное изменение заключается в том, что SQL стал поддерживать модель данных, выходящую за рамки реляционной. В соответствии с SQL3, ячейки таблиц могут быть многозначными, что позволяет представлять иерархическую и сетевую модели. Кроме того, язык расширен до возможности представления объектной модели данных и манипулирования ею. Во-вторых, он был структурирован — стал состоять из отдельных частей (parts), составляющих его основу (foundation), которая дополняется независимо определенными модулями (packages).
Возможности SQL
В начале 70-х годов SQL являлся лишь языком запросов (ЯЗ). Он, по сути, содержал только предложение SELECT, которое позволяло формулировать запросы для выборки данных из базы. Затем язык был дополнен двумя другими компонентами, необходимыми для работы с базами данных. Первый из них — средства для определения структуры базы данных, которые в терминологии теории баз данных называются языком определения данных (ЯОД). Второй — средства, позволяющие заполнять базу данными, изменять их и удалять. Этот компонент в теории баз данных называется языком манипулирования данными (ЯМД). Также было принято решение, что весь интерфейс с базами данных должен обеспечиваться одним языком, вследствие чего SQL оброс множеством функций, необходимых для управления базами данных. Приведем некоторые из них:
SQL существует в двух формах. В интерактивном SQL пользователь непосредственно вводит команды и получает результат. Команды встроенного SQL включаются в тексты программ на других языках. В этом случае обращение к базе данных, а также обработка результатов производится этими программами.
Типы команд SQL
Обсудим основные категории команд, реализующих в SQL выполнение различных функций. Среди таких функций — построение объектов базы данных, управление объектами, пополнение таблиц базы данных новыми данными, обновление данных, уже имеющихся в таблицах, выполнение запросов, управление доступом пользователей к базе данных, а также осуществление общего администрирования базы данных.
Такими категориями являются:
Определение структур базы данных (DDL)
Язык определения данных (DDL) является частью SQL, дающей пользователю возможность создавать различные объекты базы данных и переопределять их структуру, например, создавать или удалять таблицы.
Среди основных команд DDL:
Команда создания таблицы CREATE
Таблицы создаются командой CREATE TABLE. Эта команда создает пустую таблицу — таблицу без строк. Значения вводятся с помощью DML команды INSERT. Команда CREATE TABLE в основном определяет имя таблицы, в виде описания набора имен столбцов указанных в определенном порядке. Она также определяет типы данных и размеры столбцов. Каждая таблица должна иметь, по крайней мере, один столбец. Синтаксис команды CREATE TABLE:
Эта команда будет создавать таблицу Продавцов:
Порядок столбцов в таблице определяется порядком, в котором они указаны. Имя столбца не должно разделяться при переносе строки, но отделяется запятыми.
Индексы
Индекс — это упорядоченный (буквенный или числовой) список столбцов или групп столбцов в таблице. Таблицы могут иметь большое количество строк, а, так как строки не находятся в каком-нибудь определенном порядке, их поиск по указанному значению может потребовать значительного времени. Когда вы создаете индекс в поле, ваша база данных запоминает соответствующий порядок всех значений этого поля в области памяти. Предположим, что наша таблица Заказчиков имеет тысячи входов, а вы хотите найти заказчика с номером cnum=299. Так как строки не упорядочены, ваша программа будет просматривать всю таблицу, строку за строкой, проверяя каждый раз значение поля cnum на равенство значению 299. Однако если бы имелся индекс в поле cnum, то программа могла бы выйти на номер 299 прямо по индексу и дать информацию о том, как найти правильную строку таблицы. В то время как индекс значительно улучшает эффективность запросов, использование индекса несколько замедляет операции модификации DML INSERT, UPDATE и DELETE, что вполне понятно, поскольку при модификации таблицы должен модифицироваться и индекс, а сам индекс занимает объем памяти. Следовательно, каждый раз, когда вы создаете таблицу, Вы должны принять решение, индексировать ее или нет. Синтаксис для создания индекса — обычно следующий (помните, что это не ANSI стандарт):
Таблица, конечно, должна уже быть создана и должна содержать имя столбца. Имя индекса не может быть использовано для чего-то другого в базе данных (любым пользователем). Однажды созданный, индекс будет невидим пользователю. Сервер SQL сам решает, когда он необходим, чтобы ссылаться на него, и делает это автоматически. Если, например, таблица Заказчиков будет наиболее часто упоминаемой в запросах продавцов к их собственной клиентуре, было бы правильно создать такой индекс в поле snum табли- цы Заказчиков.
Теперь, тот продавец, который имеет отношение к этой таблице, сможет найти собственную клиентуру очень быстро.
Удаление индексов Главным признаком индекса является его имя, поэтому он может быть удален. Обычно пользователи не знают о существовании индекса. SQL автоматически определяет, позволено ли пользователю использовать индекс, и если да, то разрешает использовать его. Однако, если вы хотите удалить индекс, вы должны знать его имя. Этот синтаксис используется для удаления индекса:
Удаление индекса не воздействует на содержание полей.
Изменение существующей таблицы ALTER TABLE
Команда ALTER TABLE не часть стандарта ANSI; но это — широко доступная, и довольно содержательная форма, хотя ее возможности несколько ограничены. Она используется, чтобы изменить определение существующей таблицы. Обычно, она добавляет столбцы к таблице. Иногда она может удалять столбцы или изменять их размеры, а также в некоторых программах добавлять или удалять ограничения. Типичный синтаксис, чтобы добавить столбец к таблице:
Удаление таблиц DROP
Вы должны быть собственником (т.е. быть создателем) таблицы, чтобы иметь возможность удалить ее. Поэтому не волнуйтесь о случайном разрушении ваших данных, SQL сначала потребует, чтобы вы очистили таблицу прежде, чем удалит ее из базы данных. Таблица с находящимися в ней строками, не может быть удалена.
При подаче этой команды, имя таблицы больше не распознается, и нет такой команды, которая могла бы быть дана этому объекту. Вы должны убедиться, что эта таблица не ссылается внешним ключом к другой таблице, и что она не используется в определении Представления.
реализациях SQL, поддерживаема и полезна. К счастью, она более проста, и, следовательно, более непротиворечива, чем ALTER TABLE. ANSI просто не имеет способа для определения разрушенных или неправильных таблиц. Примечание. Не все SQL-серверы требуют очистки таблицы перед ее удалением. Здесь нужно обратиться к документации по Вашей системе.
Язык манипулирования данными (DML)
Основными командами этой группы являются:
Добавить новую запись в таблицу INSERT
Список столбцов в данной команде не является обязательным параметром. В этом случае должны быть указаны значения для всех полей таблицы в том порядке, как эти столбцы были перечислены в команде CREATE TABLE, например:
Пример с указанием списка столбцов:
Модификация записей UPDATE
Если задано ключевое слово WHERE и условие, то команда UPDATE применяется только к тем записям, для которых оно выполняется. Если условие не задано, UPDATE применяется ко всем записям. Пример:
Эта команда находит в таблице publishers все неопределенные значения столбца url и заменяет их строкой «url not defined».
Удаление записей DELETE
Удаляются все записи, удовлетворяющие указанному условию. Если ключевое слово WHERE и условие отстутствуют, из таблицы удаляются все записи. Пример:
Эта команда удаляет запись об издательстве Super Computer Publishing.
Выборка данных SELECT
Для извлечения записей из таблиц в SQL определен оператор SELECT. С помощью этой команды осуществляется не только операция реляционной алгебры «выборка» (горизонтальное подмножество), но и предварительное соединение (join) двух и более таблиц. Это наиболее сложное и мощное средство SQL, полный синтаксис оператора SELECT имеет вид:
Порядок предложений в операторе SELECT должен строго соблюдаться (например, GROUP BY должно всегда предшествовать ORDER BY), иначе это приведет к появлению ошибок. Этот оператор всегда начинается с ключевого слова SELECT. В кострукции определяется столбец или столбцы, включаемые в результат. Он может состоять из имен одного или нескольких столбцов, или из одного символа * (звездочка), определяющего все столбцы. Элементы списка разделяются запятыми.
Пример: получить список всех авторов
получить список всех полей таблицы authors:
В том случае, когда нас интересуют не все записи, а только те, котрые удовлетворяют некому условию, это условие можно указать после ключевого слова WHERE. Например, найдем все книги, опубликованные после 1996 года:
Другой вариант этой команды можно получить с использованием логической операции проверки на вхождение в интервал:
При использовании конструкции NOT BETWEEN находятся все строки, не входящие в указанный диапазон. Еще один вариант этой команды можно построить с помощью логической операции проверки на вхождение в список:
Здесь мы задали в явном виде список интересующих нас значений. Конструкция NOT IN позволяет найти строки, не удовлетворяющие условиям, перечисленным в списке.
Некоторые задачи нельзя решить с использованием только операторов сравнения. Например, мы хоти найти web-site издательтва «Wiley», но не знаем его точного наименования. Для решения этой задачи предназначено ключевое слово LIKE, его синтаксис имеет вид:
Образец заключается в кавычки и должен содержать шаблон подстроки для поиска. Обычно в шаблонах используются два символа:
Попробуем найти искомый web-site:
В соотвествии с шаблоном СУБД найдет все строки включающие в себя подстроку «Wiley». Другой пример: найти все книги, название которых начинается со слова «SQL»:
Выборка из нескольких таблиц.
Для этого СУБД предварительно должна выполнить слияние таблиц titles и publishers, а только затем произвести выборку из полученного отношения.
Для выполнения операции такого рода в операторе SELECT после ключевого слова FROM указывается список таблиц, по которым произвоится поиск данных. После ключевого слова WHERE указывается условие, по которому производится слияние. Для того, чтобы выполнить данный запрос, нужно дать команду:
А вот пример, где одновременно задаются условия и слияния, и выборки (результат предыдущего запроса ограничивается изданиями после 1996 года):
Следует обратить внимание на то, что когда в разных таблицах присутствуют одноименные поля, то для устранения неоднозначности перед именем поля указывается имя таблицы и знак «.» (точка).
Вычисления внутри SELECT.
SQL позволяет выполнять различные арифметические операции над столбцами результирующего отношения. В конструкции можно использовать константы, функции и их комбинации с арифметическими операциями и скобками. Например, чтобы узнать сколько лет прошло с 1992 года (год принятия стандарта SQL-92) до публикации той или иной книги можно выполнить команду:
В SQL также определены так называемые агрегатные функции, которые совершают действия над совокупностью одинаковых полей в группе записей. Среди них:
Следует учитывать, что каждая агрегирующая функция возвращает единственное значение. Примеры: определить дату публикации самой «древней» книги в нашей базе данных
подсчитать количество книг в нашей базе данных:
Область действия данных функции можно ограничить с помощью логического условия. Например, количество книг, в названии которых есть слово «SQL»:
Групировка данных.
Группировка данных в операторе SELECT осуществляется с помощью ключевого слова GROUP BY и ключевого слова HAVING, с помощью которого задаются условия разбиения записей на группы.
GROUP BY неразрывно связано с агрегирующими функциями, без них оно практически не используется. GROUP BY разделяет таблицу на группы, а агрегирующая функция вычисляет для каждой из них итоговое значение. Определим для примера количество книг каждего издательства в нашей базе данных:
Kлючевое слово HAVING работает следующим образом: сначала GROUP BY разбивает строки на группы, затем на полученные наборы накладываются условия HAVING. Например, устраним из предыдущего запроса те издательства, которые имеют только одну книгу:
