Лекция по истории науки на тему: “Развитие реляционной модели представления данных ” Санкт-Петербургский политехнический университет Факультет управления и информационных технологий Кафедра компьютерных интеллектуальных технологий в проектировании по истории науки на тему: “Развитие реляционной модели представления данных ” научный руководитель, к.т.н., проф.: Курочкин М.А. выполнила, асп.: Петрова М.А. Санкт-Петербург 2006 БАЗЫ ДАННЫХ, РЕЛЯЦИОННАЯ МОДЕЛЬ, СУБД, СТАНДАРТ SQL, ЯЗЫК ОПИСАНИЯ ДАННЫХ. , страниц: 17, литература: 10 источников. посвящён. Содержание Реляционная модель данных Базой данных (БД) называют специальным образом форматированную информацию, хранимую на машинном носителе... С базой данных непосредственно работает система управления базой данных (СУБД) [8]. В широком смысле система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенных для создания и эксплуатации базы данных. В узком смысле СУБД - это комплекс программ, обеспечивающих интерфейс (взаимосвязь) прикладных программ и базы данных во время ее эксплуатации [8]. В состав СУБД входит язык определения данных - Data Definition Language (DDL) [8]. Данные и доступ к ним могут быть организованы разными способами, что определяется моделью данных, которую поддерживает конкретная СУБД. Приведенное ниже определение, позволяет эффективно разделить модель данных и ее реализацию. Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абст­рактную машину, с которой взаимодействует пользователь. Упомянутые объекты позволяют моделировать структуру данных, а операторы — поведение данных [7]. Реализация (implementation) заданной модели данных — это физическое вопло­щение на реальной машине компонентов абстрактной машины, которые в сово­купности составляют эту модель [7]. Каждая СУБД использует одну, редко несколько моделей данных. Модель данных CУБД реализуется двумя языками - языком определения данных (ЯОД) и языком манипулирования данными (ЯМД), т.е. модель данных СУБД - это упорядоченная пара: áЯОД СУБД, ЯМД СУБДñ [8]. В начале 70-80-х годов существовало множество различных моделей данных, наиболее популярными из которых являлись: иерархическая модель данных, сетевая модель данных и реляционная модель данных [2]. Эволюция развития различных моделей данных хорошо прослеживается в книгах К. Дж. Дейта «Введение в теорию баз данных», которые являются классическим учебниками по курсу «Теория баз данных» на протяжении последних 30 лет. Если в первых изданиях книги все три подхода рассматривались равноценно, то в последних изданиях иерархическая и сетевая модели данных описываются как альтернативные дополнительные подходы: прежде всего, старые (дореляционные) системы можно разделить на три большие категории, а именно: системы инвертированных списков (inverted list), иерархические (hierarchic) и сетевые (network). В данной книге мы не будем подробно рассматривать эти категории, по­скольку, по крайней мере, с точки зрения технологии, их можно считать устаревшими [7]. В настоящее время большинство современных систем управления базой данных основаны на реляционной модели данных. Реляционная модель данных была впервые описана доктором Э.Ф. Коддом в 1970 году. Изначально реляционная модель вызвала больше академический (статья доктора Э. Ф. Кодда вызвала волну исследований в области реляционных баз данных, включая большой исследовательский проект компании IBM. Цель этого проекта, названного System/R, заключалась в том, чтобы доказать работоспособность реляционной модели и приобрести опыт реализации реляционной СУБД.[4]), чем практический интерес. В процессе исследования вновь появившейся модели, ряд компаний, заметив явные ее преимущества, поспешили предложить собственные коммерческие реализации этого реляционного подхода. Однако не все разработанные СУБД реализовывали реляционную модель полностью. Чтобы избежать некорректного использования термина «реляционный» в 1985 году доктор Кодд написал статью, где сформулировал 12 правил, которые должны быть необходимо выполнены в любой реляционной СУБД. Данные 12 правил считаются определением реляционной СУБД. Для дальнейшего рассмотрения, можно воспользоваться упрощенным определением: Реляционной называется база данных, в которой все данные, доступные пользователю, организованы в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами [4]. В основе представления и обработки данных в виде таблиц лежит абстрактная теория данных, основанная на некоторых положениях математики (в основном, теории множеств и логики предикатов) [7]. Таким образом, объекты реляционной модели имеют точное формальное математическое описание, на основе которого и был разработан стандарт языка описания данных, позволяющий описывать таблицы и связи между ними в современных СУБД. Несмотря на то что, математическая теория предоставила инструменты для точного и полного описания методов представления и обработки данных, реализация реляционного подхода в СУБД происходила эволюционно: В начале 60-х и начале 70-х годов стали появляться специализированные компьютерные программы, предназначенные для решения этой [хранение и обработка данных] задачи и известные под названием системы управления базами данных (СУБД) [4]. Исследуя возможности упрощения структуры базы данных, научный сотрудник компании IBM доктор Э.Ф. Кодд, предложил использование новой реляционной модели представления данных. В июне 1970 года доктор Э.Ф. Кодд опубликовал в журнале Communications of the Association for Computing Machinery статью под названием «Реляционная модель для больших банков совместно используемых данных» («A Relational Model of Data for Large Shared Data Banks»), в которой в общих чертах была изложена математическая теория хранения данных в табличной форме и их обработки. От этой статьи ведут свое начало реляционные базы данных и SQL… Статья доктора Кодда вызвала волну исследований в области реляционных баз данных, включая большой исследовательский проект компании IBM. … Кроме разработки самой СУБД в рамках проекта System/R проводилась работа над созданием языков запроса к базе данных.[4] Первая статья с описанием языка запроса вышла в 1974 году. Опытная эксплуатация проекта System/R состоялась в 1978 году, а в 1979 году уже появилась первая коммерческая версия реляционной СУБД компании Oracle. В начале 80-х годов появляется еще несколько реализаций реляционных СУБД и в 1986 году ANSI принимает первый стандарт SQL1. С этого момента начинается коммерческое признание реляционных СУБД и активное развитие реляционной модели представления данных. Реляционная модель данных Математической абстракцией реляционной модели данных является реляционная алгебра [8]. Если A1 , A2 , ¼, An ¾ множества, то любое подмножество a Í A1 ´A2 ´ ¼ ´An , или любой элемент булеана (множества всех подмножеств) a Î P (A1 ´A2 ´ ¼ ´An ), называют отношением между множествами A1 , A2 , ¼, An , т. е. отношение ¾ это множество упорядоченных «кортежей», в которых первый член является элементом множества A1 , второй ¾ элементом множества A2 и т.д. [8]. Таким образом, можно сказать, что отношение состоит из ряда атрибутов, а степень отношения есть число атрибутов в отношении. В свою очередь, совокупность всех кортежей для отношения называется таблицей, а определение совокупности отношений оставляет определение базы данных [9]. Атрибут есть неразложимый элемент именованных данных [9]. Несущее множество реляционной алгебры состоит из элементов, которые конструируются из элементов двух словарных множеств. Одно из этих множеств обозначим N и будем называть множеством имен атрибутов , а другое обозначим V и будем называть множеством значений атрибутов [8]. Тогда отображение Dom : N ® P(V) определяется условием: если A Î N, то Dom(A) = imT A. Пару á A, Dom(A)ñ называют атрибутом с именем A и доменом Dom(A). [8]. Из этого определения также видно, что домен есть совокупность значений, которые можно ассоциировать с одним или более атрибутом [9]. Функция Dom : N ® P (V) разбивает множество N на классы эквивалентности имен атрибутов. Эквивалентность атрибутов A, B Î N означает, что Dom(A) = Dom(B) , т. е. этим именам атрибутов назначена одна и та же область значений. Например, именам атрибутов ВЕС и ВЫСОТА может быть назначена одна и та же область значений ¾ множество положительных вещественных чисел [8]. В реляционной модели отношения обладают определенными свойствами, причем все они очень важны и вытекают непосредственно из приведенного выше определения отношения: - все кортежи отношения различны; - все атрибуты отношения различны; - кортежи отношения не имеют упорядоченности; - каждый кортеж содержит ровно одно значение для каждого атрибута, - отношение может не содержать ни одного кортежа (так как пустое множество также есть отношение); - отношение должно содержать, по крайней мере, один атрибут; - множество атрибутов различных отношений могут пересекаться; - множества кортежей различных отношений могут пересекаться. Так как все кортежи отношения необходимо различны, то каждое отношение будет иметь некоторую комбинацию атрибутов, которые, взятые вместе, будут однозначно идентифицировать кортеж в отношении [5]. Такая комбинация атрибутов в реляционной модели называется первичным ключом. Первичный ключ отношения может состоять как из одного атрибута, так и из всех атрибутов отношения. Если отношение содержит несколько комбинаций атрибутов однозначно идентифицирующих кортеж, то такие комбинации называют возможными ключами. Понятие первичного ключа позволяет устанавливать связи между отношениями: атрибут отношения R1 является внешним ключом, если этот атрибут – не первичный ключ отношения R1, но его значения являются значениями первичного ключа некоторого отношения R2 [5]. Дополнительным объектом, включенным в реляционную модель представления данных, является каталог. Каталог — это набор системных переменных-отношений, содержащих метаданные о различных элементах, важных для системы (базовых переменных-отношениях, пред­ставлениях, индексах, пользователях и т.д.). [7] Замечательным свойством реляционных систем является то, что их каталог также состоит из переменных-отношений (точнее, из системных переменных-отношений, на­званных так для того, чтобы отличать их от обычных пользовательских). В результате пользователь может обращаться к каталогу так же, как к своим данным. Например, в ка­талоге обычно содержатся системные переменные-отношения TABLES и COLUMNS, назна­чение которых — описание известных системе таблиц (т.е. переменных-отношений) и столбцов этих таблиц. (Мы говорим "обычно", потому что каталоги в различных систе­мах разные, так как существенная часть информации каталога является специфической для конкретной системы.) [7]. Таким образом, реляционная модель представления данных вводит понятия: Домен Атрибут Отношение Первичный ключ отношения Внешний ключ отношения Каталог Конкретная реализация реляционной СУБД, как правило, включает также возможность определения дополнительных объектов. Таким образом, в 70-х годах была сформулирована математическая теория, основоположником которой является доктор Э.Ф. Кодд, на основе которой была разработана реляционная модель и средства ее описания, легшие в основу современных СУБД. Язык описания данных в стандарте 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) . Развитие реализации реляционного представления данных СУБД 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]. Сегодня конкуренция между поставщиками СУБД лежит в области производительности, новых возможностей, специализированных средств разработки, качества служб технической поддержки и т. п., о соответствии правилам Кодда упоминают редко. Тем не менее, они остаются важной частью истории реляционной модели данных [4]. В 90-х годах реляционным СУБД составили конкуренцию СУБД, основанные на принципах объектно-ориентированного программирования. В настоящее время данные принципы внедряются в реляционную модель, модифицируясь в ее составную часть. Таким образом, развитие современных СУБД происходит на текущий момент в следующих направлениях: · Развитие реализации реляционной модели, с целью наиболее полного соответствия реляционной алгебры, без потерь производительности и эффективности программных продуктов. · Развитие реляционно-объектных СУБД. · Совмещение реализации реляционной алгебры с современными технологиями программирования. Фактически введение реляционной модели в 1969 и 1970 годах было, несо­мненно, наиболее важным событием в истории развития теории баз данных [7]. Список литературы [1] – MySQL. Руководство администратора. : Пер. с англ. – М. : Издательский дом «Вильямс», 2005. [2] – MySQL. Справочник по языку. : Пер. с англ. – М. : Издательский дом «Вильямс», 2005. [3] – Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом. Система баз данных. Полный курс.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. [4] – Дж. Грофф, П. Вайнберг. Энциклопедия SQL. 3-е издание. – СПб.: Питер, 2003. [5] – К. Дейт. Введение в системы баз данных, 2-е издание: М.: 1980. [6] – К. Дж. Дейт. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. [7] – К. Дж. Дейт. Введение в системы баз данных, 7-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2001. [8] – В. П. Евменов. Базы данных, часть 1, Методология теории баз данных. Учебное пособие. – СПб, СПбГПУ, 2005 [9] – Т. В. Олле. Предложение КОДАСИЛ по управлению базами данных. : Пер. с англ. – М.: Финансы и статистика, 1981. [10] – Джо Селко. Программирование на SQL для профессионалов. 2-е издание: Пер. с англ. – М.; Издательство «Лори», 2004.