КаталогИндекс раздела


Великая новость - реляционная модель умерла

1. Введение

Великая новость - реляционная модель умерла! Конечно, не полностью. Это означает, что реляционная модель, которую мы все знаем по ее языковому выражению, языку SQL, была "грандиозно расширена" Техническим Комитетом по Базам Данных H2 ANSI (ANSI H2 Technical Committee on Database). Самая интересная часть этого "грандиозного расширения" - то, что сейчас называется SQL/99, который отодвигает модель данных SQL в прошлое и там ее и оставляет. Чтобы понять, почему это "грандиозное расширение" оставляет в прошлом модель данных SQL, эта публикация представляет сокращенную версию статьи под тем же названием, обубликованной на сайте Whitemarch. Эта статья представляет:

  • обзор моделей данных;
  • язык SQL;
  • язык SQL/99;
  • влияние SQL/99 на реляционную модель данных;
  • влияние SQL/99 на приложения баз данных.

    2. Что такое модель данных

    Модель данных состоит из трех главных компонентов:

  • структуры записей;
  • отношения;
  • операции.

    2.1. Структуры записей

    Структура записи (в реляционных терминах - таблица) представляет набор полей данных (в реляционных терминах - колонок). Имеется несколько типов полей данных. В них включаются:

  • однозначные;
  • многозначные;
  • группы:
  • повторяющиеся группы;
  • вложенные повторяющиеся группы.

    2.2. Отношения

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

  • один-к-одному:
  • один-к-многим (единственный элемент):
  • один-к-многим (множественные элементы);
  • многие-к-многим;
  • специфические, единственный элемент;
  • специфические, множественные элементы;
  • выводимые;
  • рекурсивные.

    2.3. Операции

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

    Выбор реализации отношений определяет разницу между между двумя разными стилями операций: одна-запись-за-раз или множество-выбранных-записей. Запись-за-раз подразумевает, что пользовательская программа, ориентируясь в базе данных, использует такие операции, как GET OWNER, GET NEXT и GET MEMBER для выполнения продвижения. Множественные операции отношений создают ручной или математический набор операций над выбранным множеством записей. Включает в себя PROJECT, DIVIDE, JOIN, INTERSECTION и UNION. Если СУБД реализуют такой набор операций, они обеспечивают либо явный синтаксис, либо синтаксическую поддержку.

    Четыре модели данных

    СУБД разных производителей реализовывали разные комбинации характеристик моделей данных. С конца 1960-х до конца 19980-х попытка стандартизовать СУБД в соответствии с сетевой моделью данных была предпринята CODASYL (Comittee on Data Systems and Languages - ).

    Документы, выработанные CODASYL DDLC (data definition language committe - комитет по языку определения данных), назывались Journal of Development (журнал разработки). Они не были, однако, стандартом ANSI. Таким образом, производители придерживались JDS "духовно". Поскольку не было стандарта ANSI, то на протяжении 1955-1970 гг. не было и соответствующих тестов, для определения соответствия стандартам, и каждая СУБД в чем-то имела отличия. Несмотря на это, определились четыре главные модели данных:


    Рисунок 1. Характеристики четырех моделей данных

    Рисунок 1 представляет характеристики четырех основных моделей данных. Этот рисунок показывает четыре модели данных в виде столбцов и три главные характеристики, которыми являются структуры записи, отношения и операции, - в виде строк этой таблицы.


    Рисунок 2. Лексикон аббревиатур для Рисунка 1


    Рисунок 3. СУБД - по моделям данных и выполнению стандартов ANSI

    Рисунок 3 представляет разные СУБД по моделям данных. На этом рисунке данные соответствуют ранним версиям СУБД.

    4. Язык SQL

    Язык SQL, в оригинале известный как структурированный язык запросов, был разработан для поддержки реляционной модели данных. Этот язык был создан IBM в начале 1990-х. В конечном счете этот язык стал открытой собственностью IBM и был стандартизован Комитетом по Базам Данных H2 при ANSI NCITS (Национальный Комитет Стандартов для Информационных Технологий). Примечание: H2 не означает ничего, это просто "первичный ключ" комитета. Язык SQL состоит из следующих основных составляющих:

  • Определение структуры базы данных и записи данных, включая спецификации ссылочной целостности и виды.
  • Операции над записями для вставки, модификации и удаления и операции над отношениями, выполняющие JOIN, PROJECT, DIVIDE, INTERSECTION и DIFFERENCE.
  • Операции выборки записей данных - от одной записи до вложенных подзапросов, соединяющих данные из соотносящихся занисей.
  • Определение прав и управление правами.
  • Управление параллельным изменением и восстановлением данных.
  • Обработка транзакций.

    Поскольку язык SQL обычно работает через традиционные языки программирования, такие как COBOL, SQL содержит команды обработки "одна-запись-за-раз" - это операции с курсором, которые выполняются на выбранном множестве записей.

    Стандарт SQL/86 состоял только из тех свойств, с которыми могли согласиться производители - члены комитета H2. Его целью была стандартизация существующей практики. С 1986г. до следующего стандарта 1989г. были стандартизованы другие возможности, включая ссылочную целостность. Ссылочная целостность - старая концепция, которая сущесвовала в сетевых системах CODASYL с конца 1960-х.

    Следующий стандарт SQL был принят в 1992г. Это было значительной модификацией языка SQL. Расширения в основном были в ограничениях целостности, многоязыковой поддержке, полной ссылочной целостности и т.п. Фундаментальные компоненты базовых структур данных и обработки отношений остались те же. То есть, таблицы содержали только однозначные поля.


    Рисунок 4. Свойства SQL/86, 89 и 92

    5. Язык SQL/99

    Начиная с 1992г., комитет H2 начал разработку грандиозного расширения стандарта SQL/92. Наибольшее изменение в стандарте состоят в том, что он больше не придерживается реляционной модели данных 1970г. Второе наибольшее изменение - в том, что язык SQL/99 теперь состоит из отдельных частей, которые охватывают основу, и набора независимо специфицированных пакетов. Основные компоненты языка SQL/99 включают в себя:

  • Таблицы, которые расширены новыми встроенными типами данных (булевские, перечислимые, расширения для набора символов, перекодировки, сравнения).
  • Типы данных BLOB и CLOB.
  • Абстрактные типы данных (типы данных, определяемые пользователем, с поведением, инкапсулированные внутренние структуры и характеристики доступа - public, protect, private).
  • Массивы.
  • Функции, определяемые пользователем.
  • Типы строк (table person (SSN, name (first, middle,last), address (street, city, state, zip (four, five) ) ) ) ).
  • Расширения предикатов (для всех, для некоторых, такой же как, расширения курсора, неопределенные значения, утверждения, изменяемость видов, соединения).
  • Триггеры.
  • Роли (развитие безопасности) и точки сохранения.
  • Рекурсия.

    6. SQL/99 и реляционная модель данных

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

    SQL/99, однако, пошел дальше возможностей независимых логических файлов введением таких свойств, как типы, определяемые пользователем, встроенный программный язык, библиотеки SQL/99 определяют подпрограммы для таких областей, как сопровождение полного текста управление и пространственные данные. Сказать, что расширения SQL/99 являются просто "расширенной интерпретацией" реляционной модели данных - все равно, что сказать, что межконтинентальная баллистическая ракета является просто "расширенной интерпретацией" копья.

    Влияние на SQL/99 на СУБД сетевой и иерархической модели очень значительно. СУБД сетевой модели традиционно допуска сложные структуры записей с массивами, группами, повторяющимися группами и вложенными повторяющимися группами. Уникальной характеристикой SQL/99 является то, что он теперь разрешает массивы. Вдобавок, элементы массива могут быть внешними ссылками на другие данные. Поскольку элементы массива SQL/99 управляются СУБД SQL/99, массив с его внешними ссылками в сущности является набором CODASYL. Это грандиозный уход от реляционной модели.

    Единственными остающимися в эксплуатации сетевыми СУБД являются IDMS фирмы Computer Associates и СУБД Oracle (бывшая VAX DBMS). Обе имеют языковый интерфейс SQL уже около 10 лет. Как Computer Associates планирует получить преимущества от существующих возможностей IDMS с SQL/99 - неизвестно. Значительным пользователем СУБД Oracle (бывшая VAX DBMS для DEC) является Intel, который использует Consilium manyfacturing package для управления производством чипов. Как Oracle Corporation планирует получить преимущества от существующих возможностей VAX DBMS с SQL/99 - также неизвестно.

    На только две существующие иерархические СУБД, System 2000 и IBM IMS SQL/99, похоже, не будет никакого влияния вообще. System 2000 больше не развивается фирмой SAS, а IBM имеет полную реализацию DB2 на многих разных операционных системах.

    Влияние SQL/99 на СУБД независимых логических файлов, например, Adabas, Focus, Datacom/DB - значительно.Эти СУБД уже поддерживают многие из возможностей модели данных SQL/99. Кажется, эти СУБД смогут быстрее соответствовать стандарту SQL/99. Если их производители ухватятся за модель SQL/99, эти СУБД смогут заявить о соответствии скорее, чем существующий ряд реляционных СУБД.

    Констатируем, что язык SQL/99 определяет уникальную модель данных. Она содержит:

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

    Следовательно, можно сказать, что модель данных SQL/99 уникальна сама по себе. Понятно, что это не реляционная модель данных, не сеть CODASYL, не иерархическая модель или модель независимых логических файлов. Просто SQL/99 есть сам по себе модель данных.

    7. SQL/99 и приложения баз данных

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

    Если производители СУБД воплотят SQL/99, процесс проектирования баз данных трансформируется из разработки третьей нормальной формы с последующей денормализацией ее для получения эффективной выборки в последовательность действий, похожую на те, которые выполнялись при разработке баз данных с середины 1970-х до середины 1980-х гг. Теперь с таблицами SQL/99 мы можем больше знать о процессе обработки данных, чтобы получить преимущества от естественной иерархии структуры данных.

    Хотя в СУБД, соответствующих SQL/99, скорость обработки грандиозно улучшится, но грандиозно вырастет и трудоемкость и время, требуемое для завершения переработки и реорганизации баз данных.

    Короче, мы вернулись к прошлому. То есть, приняли структуру данных СУБД сетевых и независимых логических файлов. Хотя мы видим значительное увеличение производительности для хорошо спроектированных и настроенных баз данных, мы также видим возврат к значительным затратам времени аналитиков и проектировщиков при разработке и переработке баз данных.

    Keith Hare из JCC Consulting - член H2 в течение долгого времени и пользовательVAX DBMS - прекрасно определил это: "С SQL/99 вы можете получить все лучшее из двух миров и, конечно же, вы можете получить все худшее из двух миров. И это уж - на усмотрение практиков в базах данных - выбрать правильно."

    Полная версия (англ.) этой статьи доступна в разделе "What's New" на web- сайте Whitemarsh (http://www.wiscorp.com)


    Michael M. Gorman, председатель Whitemarsh Information Systems Corporation, занимается базами данных и СУБД более 30 лет. Michael M. Gorman был секретарем ANSI Database Languages Committee, X3Y2 в течение 19 лет.


    КаталогИндекс раздела