Таким образом, информационная схема состоит из набора SQL-таблиц, содержимое которых фактически отражает (точно определенным образом) все определения из всех остальных схем рассматриваемого каталога. ... Для поддержки схемы определения реализация не требуется, но она требуется, во-первых, для поддержки некоторого вида "схемы определения" и, во-вторых, для поддержки представлений такой "схемы определения", которые имеют вид, подобный представлениям информационной схемы [7].
В стандарте SQL2 появляется возможность определения динамических массивов с элементами любого допустимого в SQL типа, кроме типа массива. Тип массива образовывался с помощью конструктора типов массивов ARRAY.
Таким образом, значением атрибута может быть не атомарным!
Это изменение настолько важно, что К. Дж. Дейт пишет в своем последнем издании:
“Основной причиной того, что здесь явно рассматривается возможность использования отношений с атрибутами, принимающими в качестве значений отношения, является то, что исторически в большинстве публикаций по базам данных (включая предыдущие издания настоящей книги) это считалось недопустимым (а в большинстве изданий считается таковым и поныне). Вот, например, несколько отредактированная цитата из предыдущего издания этой книги.
' Обратите внимание на то, что все значения столбцов атомарные... Это значит, что на каждом месте в столбце или строке всегда находится ровно одно значение, а не группа из нескольких значений... В реляционных базах данных повторяющиеся группы недопустимы, поэтому использование второго варианта таблицы в рамках реляционной модели запрещено.
Вот еще одна цитата из той же книги.
[Домены] состоят только из атомарных значений... [Поэтому] отношения не содержат повторяющихся групп. Отношение, отвечающее этим условиям, называется нормализованным или, что равносильно, отношением в первой нормальной форме... Под термином отношение в контексте реляционной модели всегда будет подразумеваться нормализованное отношение.
Однако, по крайней мере, в целом, эти высказывания неверны. Они являются следствием ошибочного понимания автором истинной природы типов и предикатов” [7].
В стандарте SQL2 появляется также возможность определения собственного типа данных: домен — это не что иное, как тип данных (или, для краткости, — просто тип); в частности, возможно, простой, определяемый системой, подобно типам INTEGER и CHAR. В общем случае этот тип определяется пользователем, как, например, типы Si, Pi, WEIGHT и QTY в базе поставщиков и деталей. В действительности термины домен и тип данных взаимозаменяемы [7].
Наиболее серьезные изменения языка SQL, относящиеся к описанию данных в SQL3, касаются следующих аспектов:
· типы данных;
· расширенные возможности оператора CREATE TABLE;
· новый объект схемы – генератор последовательностей;
· новые виды столбцов – идентифицирующие столбцы (identity column) и генерируемые столбцы (generated column);
Все наиболее очевидные аспекты новизны в языке SQL3 связаны с типами данных. Появились новые встроенные типы данных, точнее — новые встроенные скалярные типы данных, а также новые генераторы типов, которые в языке SQL3 называются конструкторами типа. Оператор CREATE TYPE позволяет пользователям определять собственные типы (конечно, имеется и соответствующий оператор DROP TYPE) [7].
Стандарт SQL3 расширяет возможности использования коллекций в двух важных направлениях. Во-первых, вводится новый конструктор типов мультимножеств MULTISET. Во-вторых, типом элементов любого типа коллекций теперь может быть любой допустимый в SQL тип данных, кроме самого конструируемого типа коллекции. Тем самым, в базе данных допускается произвольная вложенность таблиц. Возможности выбора структуры базы данных безгранично расширяются.
В SQL3 появилась возможность определения нового вида объектов базы данных – генераторов последовательностей (sequence generators). Такого рода объекты производят изменяемые во времени точные числовые значения
Наконец, один или несколько столбцов определяемой базовой таблицы могут быть специфицированы как генерируемые столбцы (generated columns).
Развитие реализации реляционного представления данных СУБД MySQL
СУБД MySQL классифицируется как реляционная система управления базами данных (RDBMS— relational database management system). Эта аббревиатура разбивается на части следующим образом.
• База данных (БД) (DB в RDBMS) — это совокупность информации, разбитой простым, регулярным образом.
• Совокупность данных в базе данных объединена в таблицы.
• Таблица состоит из строк и столбцов.
• Строка таблицы является ее записью.
• Записи содержат несколько единиц информации, каждый столбец таблицы содержит одну такую единицу.
• Система управления (СУ) (MS — management system) является программным обеспечением, позволяющим вставлять, выбирать, модифицировать и удалять записи.
• Слово "реляционная" обозначает популярную разновидность СУБД, в которых отслеживается "соответствие" записей в одной таблице на "соответствие" записей в другой таблице. Мощь реляционных СУБД заключается в их способности выбирать соответствующие данные из этих таблиц и создавать ответы на вопросы, которые нельзя получить только из одной такой таблицы [10].
Одна из главных задач при разработке этого [СУБД MySQL] продукта состоит в том, чобы продолжать работу в направлении максимального соответствия стандарту SQL, однако, не жертвуя при этом производительностью и надежностью [1]
Основываясь на теоретических положениях, производители реляционных баз данных разрабатывают конкретные реализации СУБД, в которых для описания данных используется реляционная модель. При этом постоянно происходит расширение (развитие) реализации реляционной модели, в том числе за счет появления реализации представления новых объектов.
Развитие реализации реляционной модели в СУБД MySQL происходило следующим образом:
Домен:
В СУБД MySQL поддерживается множество типов столбцов различных категорий: числовые типы, типы даты и времени и строковые (символьные) типы [2]. Тем самым СУБД MySQL, реализует заранее определенные домены, но не позволяет определять домен, то есть множество значений данного атрибута. Данное ограничение присутствует и в текущей реализации этого продукта.
Приближенной и неполной реализацией домена является два типа данных: ENUM и SET, позволяющие задавать множество из различных строковых элементов. Но это совершенно не отвечает требованиям реляционной модели.
Атрибут:
Атрибут (столбец) в СУБД MySQL может принимать только скалярные значения и не допускает возможность использования множественных или табличных типов.
Данное ограничение также присутствует и в текущей реализации этого продукта.
Отношение:
Инструкция CREATE TABLE создает таблицу с указанным именем и перечнем столбцов [2]. Возможности детализации описания таблицы заметно увеличились по сравнению с первыми версиями системы.
Первичный ключ отношения:
Уникальность каждой записи таблицы выполняется на физическом уровне реализации СУБД. Тем самым, таблицы могут содержать строки одинаковых значений. На практике, уникальность каждой строки таблицы можно определить с помощью задания первичного ключа, который может состоять как из одного столбца таблицы, так и из группы столбцов. Определенный таким способом первичный ключ, позволит СУБД автоматически отслеживать уникальность вводимых в таблицу значений. Кроме этого, реализована возможность автоматической генерации первичного ключа. Ограничением на автоматически генерируемое значение является то, что оно является целым числом. В последующих версиях реализации СУБД MySQL, это ограничение стало еще строже: значение автоматически генерируемого первичного ключа является натуральным.
Внешний ключ отношения:
В первых версиях возможность определения внешнего ключа не поддерживалась и перекладывалась на разработчика базы данных. В версии MySQL 4.0 впервые появилась возможность определять внешние ключи и обеспечивать ссылочную целостность баз данных.
Каталог:
Возможность определения каталогов была реализована в СУБД MySQL только в версии 5.0, c введением объекта INFORMATION SCHEMA.
Современные СУБД последовательно включают в свой состав новые и все более сложные элементы реляционной модели представления данных.
Эффективная реализация конкретного объекта реляционной модели зачастую требует больших временных затрат, которые складываются из времени проектировании, внедрения и отладки конкретного программного обеспечения.
Пути развития современных реализаций реляционных СУБД
Как отмечалось во введении к этой главе, язык SQL далек от совершенства и имеет недостатки, вызванные многочисленными недоделками и переделками. ... Здесь лишь отметим, что основной недостаток заключается в том, что, строго говоря, язык SQL, в целом, некорректно поддерживает реляционную модель. Поэтому возникает сомнение, заслуживают ли современные SQL-продукты права называться действительно реляционными. Фактически, насколько это известно автору, на сегодняшний день на рынке нет ни одного продукта, который поддерживал бы реляционную модель в полном объеме. Мы не хотим этим сказать, что какие-то аспекты реляционной модели не важны; как раз наоборот, каждый элемент в модели важен. Более того, каждый из ее элементов важен по чисто практическим соображениям. Нельзя не подчеркнуть тот непреложный факт, что назначение реляционной теории состоит не в том, чтобы просто быть "теорией для теории". Вовсе нет, ее назначение — обеспечить базу для построения систем, которые будут практическими на все сто процентов. Но, как это ни печально, со стороны изготовителей продуктов еще не сделано реальных шагов к решению проблемы реализации реляционной теории во всей ее полноте. В результате "реляционные" продукты сегодняшнего дня все как один по тем или иным причинам оказываются неспособными реализовать преимущества, которые теоретически могут быть получены в результате использования реляционной технологии [7].