Язык запросов в субд называется

История языков программирования: 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.

Процедурное расширение SQL, разработанное Oracle, называется PL/SQL (Procedural Language/Structured Query Language) и основано на синтаксисе языков Ada и Pascal. Третьим ключевым языком, использующийся в СУБД Oracle наравне с SQL и PL/SQL, является Java.

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, в коммерческих реализациях устоялся и более или менее соответствует стандарту.

Источник

Языки баз данных: DDL, DML, 4GL и другие

Внутренний язык СУБД для работы с данными состоит из двух частей: языка опре­деления Данных (Data Definition Language — DDL ) и языка манипулирования Данны­ми (Data Manipulation Language — DML ). Язык DDL используется для определения схемы базы данных, а язык DML — для чтения и обновления данных, хранимых в ба­зе.

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

Результатом компиляции DDL-операторов является набор таблиц, хранимый в особых файлах, называемых системным каталогом. В системном каталоге интегрированы метаданные — т.е. данные, которые описывают объекты базы данных, а также позволяют упростить способ доступа к ним и управления ими. Метадан­ные включают определения записей, элементов данных, а также другие объекты, представляющие интерес для пользователей или необходимые для работы СУБД. Перед доступом к реальным данным СУБД обычно обращается к системному ката­логу. Для обозначения системного каталога также используются термины словарь Данных и каталог Данных, хотя первый из них (словарь данных) обычно относит­ся к программному обеспечению более общего типа, чем просто каталог СУБД. Системные каталоги более подробно обсуждаются в разделе 2. 7.

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

Язык DML. Язык, содержащий набор операторов для поддержки основных опе­раций манипулирования содержащимися в базе данными.

К операциям управления данными относятся:

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

Процедурные языки DML

С помощью процедурного языка DML пользователь, а точнее — программист, указывает на то, какие данные ему необходимы и как их можно получить. Это значит, что пользователь должен определить все операции доступа к данным (осуществляемые посредством вызова соответствующих процедур), которые должны быть выполнены для получения требуемой информации. Обычно такой процедурный язык DML позволяет извлечь запись, обработать ее и, в зависимости от полученных результатов, извлечь другую запись, которая должна быть подвергнута аналогичной обработке, и т.д. Подобный процесс извлечения дан­ных продолжается до тех пор, пока не будут извлечены все запрашиваемые дан­ные. Обычно операторы процедурного языка DML встраиваются в программу на языке программирования высокого уровня, которая содержит конструкции для обеспечения циклической обработки и перехода к другим участкам кода. Языки DML сетевых и иерархических СУБД обычно являются процедурными (раздел 2.3).

Непроцедурные языки DML

Непроцедурные языки DML позволяют определить весь набор требуемых дан­ных с помощью одного оператора выборки или обновления. С помощью непроце­дурных языков DML пользователь указывает, какие данные ему нужны, без оп­ределения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затре­бованным набором записей. Такой подход освобождает пользователя от необхо­димости знать подробности внутренней реализации структур данных и особенно­сти алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя становится в определенной степени независимой от данных. Непроцедурные языки часто также называют Деклара­тивными языками. Реляционные СУБД в той или иной форме обычно включают поддержку непроцедурных языков манипулирования данными — чаще всего это язык структурированных запросов SQL (Structured Query Language) или язык запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно проще понять и использовать, чем процедурные языки DML, поскольку пользо­вателем выполняется меньшая часть работы, а СУБД — большая. Более подроб­но язык SQL рассматривается в главах 5, 6 и 21, а язык QBE — в главе 7.

Языки 4GL

Аббревиатура 4GL представляет собой сокращенный английский вариант на­писания термина язык четвертого поколения (Fourth-Generation Language). Четкого определения этого понятия не существует, хотя, по сути, речь идет о некотором стенографическом варианте языка программирования. Если для орга­низации некоторой операции с данными на языке третьего поколения ( 3GL ) типа COBOL потребуется написать сотни строк кода, то для реализации этой же опе­рации на языке четвертого поколения достаточно 10-20 строк.

В то время как языки третьего поколения являются процедурными, языки 4GL выступают как непроцедурные, поскольку пользователь определяет, что должно быть сделано, но не сообщает, как именно должен быть достигнут же­лаемый результат. Предполагается, что реализация языков четвертого поколе­ния будет в значительной мере основана на использовании компонентов высоко­го уровня, которые часто называют «инструментами четвертого поколения». Пользователю не требуется определять все этапы выполнения программы, необ­ходимые для решения поставленной задачи, а достаточно лишь задать нужные параметры, на основании которых упомянутые выше инструменты автоматиче­ски осуществят генерацию приложения. Ожидается, что языки четвертого поко­ления позволят повысить производительность работы на порядок, но за счет ог­раничения типов задач, которые можно будет решать с их помощью. Выделяют следующие типы языков четвертого поколения:

Генераторы форм

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

Генераторы отчетов

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

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

Генераторы графического представления данных

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

Генераторы приложений

Генератор приложений представляет собой инструмент для создания про­грамм, взаимодействующих с базой данных. Применяя генератор приложений, можно сократить время, необходимое для проектирования полного объема тре­буемого прикладного программного обеспечения. Генераторы приложений обыч­но состоят из предварительно созданных модулей, содержащих фундаменталь­ные функции, которые требуются для работы большинства программ. Эти моду­ли, обычно создаваемые на языках высокого уровня, образуют «библиотеку» доступных функций. Пользователь указывает, какие задачи программа должна выполнить, а генератор приложений определяет, как их следует выполнить.

Источник

Языки запросов традиционных СУБД.

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

В явном виде операции реляционной представлены на уровне интерфейса сделаны в Paradox. В Paradox реализован отличный от SQL язык запросов QBE (англ. Query By Example — запрос по образцу) Для того, чтобы выполнить операцию соединения, выбираются таблицы, их образцы в виде незаполненных шаблонов представляются на экране и пользователю для соединения достаточно указать один и тот же идентификатор в соединяемых полях. В Paradox операции пересечения так и задаются: пересечь таблицу A с таблицей B.

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

2) Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными.

В SQL определены два подмножества языка:

Синтаксис оператора создания таблицы имеет следующий вид:

[UNIQUE | PRIMARY KEY]

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

— один из взаимоисключающих параметров UNIQUE (значение каждого элемента столбца должно быть уникальным) или PRIMARY KEY (столбец является первичным ключом). Заметим, что в популярной реляционной СУБД Visual FoxPro параметр UNIQUE используется в ином смысле; вместо него используется параметр CANDIDATE;

B) Оператор создания индексов

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

C) Построение запросов

Для извлечения записей из таблиц в SQL определен оператор SELECT.

SELECT [ALL | DISTINCT]

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

— описание полей данных в результате;

— список источников данных;

— условия связи между различными источниками данных;

— условия выборки данных;

— условия группирования данных;

— задание порядка записей в результате.

Некоторые задачи нельзя решить с использованием только операторов сравнения. Для решения этой задачи предназначено ключевое слово LIKE. Фраза WHERE в этом случае имеет следующий вид:

EXISTS просто устанавливает факт существования записи в наборе данных, соответствующем внутреннему запросу (поэтому EXISTS зачастую называют предикатом)

FROM auto А WHERE NOT EXISTS

(SELECT * FROM moto В WHERE A.client_id = B. client_id)

INTO DBF tempi ORDER BY A.client_fio

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

WHERE client_id NOT IN

(SELECT client_id FROM moto)

ORDER BY client_fio

При выполнении соединения двух и более таблиц допускаются различные варианты объединения данных из разных таблиц в результирующее отношение. Различают внутреннее и внешнее соединения. По умолчанию устанавливается внутреннее соеди-нение (INNER JOIN). Внешние соединения бывают правыми

(RIGHT OUTER JOIN) и левыми (LEFT OUTER JOIN). Имеет место также полное соединение (FULL OUTER JOIN) данных.

Группировка данных в операторе SELECT задается предложениями GROUP BY и HAVING. GROUP BY разделяет данные в таблице на группы, фраза HAVING задает условия, которые накладываются на группы данных.

Для сортировки данных, получаемых при помощи оператора SELECT, служит ключевое слово ORDER BY.

В SQL предусмотрена возможность выполнения операции реляционной алгебры «ОБЪЕДИНЕНИЕ» (UNION) над отношениями, являющимися результатами выполнения оператора SELECT. Естественно, эти отношения должны иметь одинако-вую структуру, так как операция объединения реляционных от-ношений аналогична операции объединения множеств в теории множеств.

Дата добавления: 2018-05-13 ; просмотров: 483 ; Мы поможем в написании вашей работы!

Источник