Язык описания данных в стандарте SQL

В статье, опубликованной в журнале Computerworld в 1985 году, доктор Э. Ф. Кодд сформулировал 12 правил, которым должна соответствовать реляционная база данных. Перечисленные правила основаны на теоретических основах реляционной модели данных:

Двенадцать правил Кодда, которым должна соответствовать реляционная база данных:

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

2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первично­го ключа и имени столбца.

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

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

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

a. определение данных;

b. определение представлений;

c. обработку данных (интерактивную и программную);

d. условия целостности данных;

e. идентификацию прав доступа;

f. границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, которые теоретиче­ски можно обновить, должны быть доступны для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отно­шением как с одним операндом должна существовать не только при выборке данных, по и при добавлении, обновлении и удалении данных.

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

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

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

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

12. Правило единственности. Если в реляционной системе есть низкоуровневый язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности данных, выраженные на реляционном языке высоко: уровня (обрабатывающем несколько записей за один раз) [4].       

Появление реляционных баз данных вызвало появление нескольких диалектов языка управления реляционными базами данных. Стандартом дефакто стал язык структурированных запросов (SQL). Работа над официальным стандартом SQL началась в 1982 году и первый стандарт был официально издан в 1986 году. Однако конкретные реализации значительно отличались от объявленного стандарта.

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

       Таблица                                                   -      Отношение

       Строка или запись                                 -      Кортеж

       Количество строк                                   -      Кардинальность

       Столбец или поле                                  -      Атрибут

       Количество столбцов                            -      Степень

       Уникальный идентификатор                 -      Первичный ключ     

Совокупность допустимых значений  -      Домен.

Для изменения и описания структуры базы данных предназначен набор инструкций SQL, который называется языком определения баз данных (ЯОД). В большинстве случаев инструкции ЯОД обеспечивают высокий уровень доступа к данным и позволяют пользователю не вникать в детали хранения информации в базе данных на физическом уровне [4].

       Основными операторами, реализуемыми в ЯОД являются:

§ Оператор создания объекта базы данных (CREATE)

§ Оператор удаления объекта (DROP)

§ Оператор модификации объекта (ALTER)

Практически все коммерческие СУБД поддерживают ЯОД как неотъемлемую часть языка SQL, хотя стандарт SQL1 этого не требует. В принятом в 1992 году стандарте SQL2 были определены те части ЯОД, которые являются независимыми от структур физического хранения, особенностей операционной системы и других специфических особенностей СУБД. В конкретных же реализациях СУБД включают множество дополнений ЯОД, связанных со спецификой реализации каждой конкретной СУБД [4].

Если рассмотреть три версии стандарта SQL (1986год, 1992 год, 2003 год), то можно проследить развитие реализации реляционной модели представления данных.

Стандарт SQL1

Реляционная модель данных не указывает на то, как различные отношения группируются в различные базы данных. Вследствие этого, в различных СУБД изначально применялись неодинаковые подходы к этому вопросу. В стандарте SQL1 содержится спецификация языка SQL, используемого для описания структуры базы данных, но не указывается способ создания базы данных [4]. В настоящее время, методы создания баз данных в различных СУБД также имеют явные различия:

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

В СУБД Oracle база данных создается в ходе процесса установки программного обеспечения, как и в DB2 [4] В последних версиях СУБД Oracle появилась инструкция CREATE DATABASE, которая определяется стандартом SQL2.

В СУБД MySQL при установке серверного обеспечения создается две системных базы данных: mysql – содержащая, системную информацию и test – тестовая база данных. Пользователь может создавать базы данных с помощью инструкции CREATE DATABASE или просто создав каталог с именем базы данных в каталоге данных сервера mysql.

Описание таблицы происходит с помощью специальной инструкции SQL: каждый оператор CREATE TABLE задает имя создаваемой базовой таблицы, имена и типы данных столбцов этой таблицы, а также первичный ключ таблицы и любые внешние ключи, присутствующие в ней [7].

При этом, важным отличием от реляционной модели является запрет на определение пользователем собственных типов данных. Для определения столбцов мож­но использовать только встроенные (определенные системой) типы [6].

Стандарт SQL2

В стандарте SQL2 умышленно не дано определения термина база данных, поскольку этот термин в различных СУБД трактуется по-разному. Вместо него употребляется термин каталог, означающий именованную коллекцию системных таблиц, описывающих структуру базы данных. В стандарте также не указано как должен создаваться и уничтожаться каталог [4].

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

Таким образом, информационная схема состоит из набора SQL-таблиц, содержи­мое которых фактически отражает (точно определенным образом) все определения из всех остальных схем рассматриваемого каталога. ... Для поддержки схемы определения реализация не требуется, но она требуется, во-первых, для поддержки некоторого вида "схемы определения" и, во-вторых, для поддержки представлений такой "схемы определения", которые имеют вид, подобный представлениям информационной схемы [7].

В стандарте SQL2 появляется возможность определения динамических массивов с элементами любого допустимого в SQL типа, кроме типа массива. Тип массива образовывался с помощью конструктора типов массивов ARRAY.

Таким образом, значением атрибута может быть не атомарным!

Это изменение настолько важно, что К. Дж. Дейт пишет в своем последнем издании:

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

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

Вот еще одна цитата из той же книги.

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

Однако, по крайней мере, в целом, эти высказывания неверны. Они являются следствием ошибочного понимания автором истинной природы типов и предикатов” [7].

В стандарте SQL2 появляется также возможность определения собственного типа данных: домен — это не что иное, как тип данных (или, для краткости, — просто тип); в частности, возможно, простой, определяемый системой, подобно типам INTEGER и CHAR. В общем случае этот тип определяется пользователем, как, например, типы Si, Pi, WEIGHT и QTY в базе поставщиков и деталей. В действительности термины домен и тип данных взаимозаменяемы [7].

Стандарт SQL3

Наиболее серьезные изменения языка SQL, относящиеся к описанию данных в SQL3, касаются следующих аспектов:

· типы данных;

· расширенные возможности оператора CREATE TABLE;

· новый объект схемы – генератор последовательностей;

· новые виды столбцов – идентифицирующие столбцы (identity column) и генерируемые столбцы (generated column);

Все наиболее очевидные аспекты новизны в языке SQL3 связаны с типами данных. Появились новые встроенные типы данных, точнее — новые встроенные скалярные типы данных, а также новые генераторы типов, которые в языке SQL3 называются конструкторами типа. Оператор CREATE TYPE позволяет пользователям определять собственные типы (конечно, имеется и соответст­вующий оператор DROP TYPE) [7].

Стандарт SQL3 расширяет возможности использования коллекций в двух важных направлениях. Во-первых, вводится новый конструктор типов мультимножеств MULTISET. Во-вторых, типом элементов любого типа коллекций теперь может быть любой допустимый в SQL тип данных, кроме самого конструируемого типа коллекции. Тем самым, в базе данных допускается произвольная вложенность таблиц. Возможности выбора структуры базы данных безгранично расширяются.

В SQL3 появилась возможность определения нового вида объектов базы данных – генераторов последовательностей (sequence generators). Такого рода объекты производят изменяемые во времени точные числовые значения

Наконец, один или несколько столбцов определяемой базовой таблицы могут быть специфицированы как генерируемые столбцы (generated columns).