Сложные базы данных

О том, что объёмы данных, сложность их структуры, сложность связей между ними растут совершенно невероятными темпами, пишут на каждом заборе уже много лет. Вопрос же о том, что делать со всей этой свалкой обычно повисает в воздухе. Или, точнее, упирается в понятие «модель данных». Хотя формально моделей данных великое множество (сетевая модель Ч. Бахмана, реляционная модель Э. Кодда, ER-модель П. Чена, различные объектные модели, что-то специализированное под темпоральные и пространственные данные, многомерные кубы и т.д.), все они, за исключением первых двух, предназначены для представления данных конечному пользователю и/или их аналитической обработки прикладными утилитами, а на уровне доступа к данным они опираются на одну из базовых (обычно РМД).

Что такое модель данных, толком не знает никто. Существует множество определений, однако единая общепризнанная формулировка отсутствует. Сам автор термина «модель данных», Эдгар Кодд (он же автор РМД), определяет его как комбинацию трёх компонентов:
1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой БД данной модели.
2. Коллекции общих правил целостности, ограничивающих набор экземпляров этих типов объектов.
3. Коллекции операций, применимых к таким экземплярам.
Современные определения мало отличается от вышеприведённого. Если объединить все характеризующие понятие признаки в общую формулировку, определение выглядит приблизительно так: «Модель данных — это логическое определение объектов, операторов и правил, в совокупности составляющее для пользователя абстрактную машину доступа к данным».

Такое определение, по сути, не говорит вообще ни о чём. Никому. Между тем, Кристофер Дейт как-то сказал замечательную фразу: «Модель данных есть теория, или средство моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке». Как видим, Дейт, сам того не желая, дал совершенно блестящее определение модели данных, очень компактное и понятное даже ребёнку: модель — это язык!

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

Сетевая модель

Графовое представление данных (на первый взгляд) несложно в реализации на компьютере и более естественно во многих ситуациях. Веб-сайты, XML-документы, реляционные и текстовые данные могут быть смоделированы как граф. Общепризнанными достоинствами сетевой модели являются гибкость и разнообразие хранимых структур данных, высокая скорость доступа. К её недостаткам относят необходимость поэлементной обработки данных, большую трудоёмкость разработки процедур их обработки и, как ни странно, сложность модификации схемы БД, обусловленную потребностью модификации рёбер графа при обновлении данных или изменении их структуры.

Пожалуй, основными претензиями к сетевой модели является то, что логика процедуры выборки данных (якобы) зависит от их физической организации, а также, что там (якобы) ослаблен контроль целостности данных из-за допустимости установки произвольных связей между элементами. Эти претензии справедливы лишь в том случае, если под сетевой моделью понимать её эталонный вариант, описанный в отчёте рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL. Между тем, подход CODASYL далеко не единственный: можно спроектировать множество других реализаций сетевой модели, в том числе свободных от большинства приписываемых ей недостатков.

Забавно, но определение сетевой модели данных дал главный её конкурент, всё тот же Кодд. Ещё более забавно, что до сих пор при сравнении этих моделей противопоставляется абстрактная РМД конкретным спецификациям CODASYL (сам Кодд называл это «сравнением яблок с апельсинами»!), что есть фактически жульничество и принижение реальных возможностей сетевой модели, которая может составить куда более серьёзную конкуренцию РМД, чем сейчас. К сожалению, эта «клевета» Кодда на сетевую модель попала чуть ли не во все учебники и напрямую связана с отождествлением сетевой модели с подходом CODASYL. Если для РМД «получение физического доступа к кортежу не является вопросом модели данных», то для сетевой модели «изменение структуры БД требует больших усилий и времени, поскольку операции модификации и удаления данных требуют перестановки указателей» — очевидное передёргивание. Или ещё одно: «Указатели не обязательно должны быть представлены на физическом уровне хранения как указатели, однако пользователи обязаны относиться к ним, как к реальным указателям — такова сетевая модель». Не «сетевая модель», а лишь представление о ней Кодда!

Реляционная модель

Поскольку сейчас почти все СУБД именно реляционные, естественно предположить, что у РМД есть ряд важных преимуществ (прежде всего, высокая степень независимости данных). Тем более что многим клиентам удобно представление данных в простых отношениях, с ясными структурами данных и привычным языком запросов SQL (Structured Query Language). Но и недостатков у РМД множество, и они достаточно очевидны: отсутствие прямых ссылок на поля кортежа, неприлично высокий уровень затрат на создание или модернизацию схемы БД, причём изменение схемы иногда невозможно без отказа от старых данных, т.к. структурная информация в них вообще отсутствует. Широко распространённая ситуация для реальных табличных данных, когда невозможно однозначно идентифицировать элемент по данным его атрибутов, в РМД просто запрещена. Операция соединения по одному или более атрибутам, главный механизм, используемый в реляционной модели, чтобы связать данные различных отношений, выполняется всегда к целому кортежу, но не к его части. Запросы по множеству таблиц выполняются очень долго: концептуально реляционная алгебра оперирует понятием «Декартова произведения», использовать которое слишком дорого, поэтому применяют разные техники оптимизации запросов. Нормальные формы, иерархичные по природе, тоже приводят к ограничению сложности поддерживаемых структур данных. Между тем, идея самого Кодда состояла в том, что «при выборе логических структур данных должно присутствовать лишь одно соображение — удобство большинства пользователей». Подобная жёсткость подхода к простоте представления данных (которые всё это время имели явную тенденцию к усложнению), дополненная появлением нормальных форм, уже привела к ситуации, что ни одна (!) реальная РСУБД в действительности РМД не поддерживает. В частности, обычным явлением стал отказ от нормализации таблиц.

Сам Кодд пропагандировал трёхзначную логику (истина, ложь и NULL), а в 1990 даже четырёхзначную, однако из-за высокой сложности (!) в «Третьем Манифесте» К. Дейта и Х. Дарвена запрещены как неопредёленные значения, так и многозначная логика! Цитирую:
Третий манифест
Х. Дарвин и К. Дэйт, Перевод: М.Р. Когаловский
РМ-запреты
4. Каждый атрибут каждого кортежа каждого отношения должен иметь значение, которое является значением из соответствующего домена.
Комментарии (там же):
Иными словами, больше никаких неопределенных значений и больше никакой многозначной логики!

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

Цель Кодда — «переместить прикладное программирование на уровень, где отношения трактуются как операнды, а не обрабатываются поэлементно». Замечательная цель: язык, позволяющий работать с множествами, бесспорно, удобен. РМД, однако, предполагает работу только с множествами: никаких покортежных операций, единичный кортеж есть просто частный случай множества, запрещается концепция курсора и т.д. А в таких «коротких штанишках» становится уже тесно даже SQL — ближайшему родственнику РМД, хотя в математике (и в SQL, с которым реляционщики вроде Дейта ведут борьбу не на жизнь, а на смерть) кортежи упорядочены, разрешаются их дубли. Мало того, сам Кодд первоначально определял кортежи именно так! Отказ от упорядочивания рассматривается Дейтом как «величайший вклад (!) Кодда в РМД». В ООБД, однако, «почему-то» вновь требуется поддержка индивидуальности объектов, т.е. «объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов». Почему? Да потому, что «величайший вклад» есть полная фикция!

Предположим, мы имеем РБД, состоящую всего лишь из одного отношения. Заведём дополнительный столбец, значениями которого будут порядковые номера кортежей (с единицы). Именами столбцов также установим их порядковые номера (с нуля). Определим нулевой столбец как первичный ключ (или «суррогатный», или «системно-генерируемый», как «весьма настоятельно» рекомендуют авторы «Третьего Манифеста»). Теперь мы можем получать доступ к столбцам и кортежам по их номеру (как и в SQL), но в строгом соответствии с РМД. Что же изменилось? Мы всего лишь утратили возможность прямого доступа к полям и кортежам (т.к. РМ-предписания запрещают упорядочение атрибутов или кортежей), и автоматически перестали бояться дубликатов кортежей и неопределенных значений. А где же преимущества того, что наше отношение теперь идеально соответствует требованиям «Третьего Манифеста»? Их нет! Вне РМД мы можем точно так же ссылаться на кортежи этого отношения из других (или из него самого), можем вычислять физический адрес кортежа по значению суррогатного ключа (и контролировать его при желании по значению нулевого столбца), т.е. внешний ключ реально становится указателем. Таким образом, концепции, воплощённые в SQL, как минимум, не хуже РМД. Так почему же «безнадёжно следовать извращению РДМ, воплощенному в SQL», как писали Дейт с Дарвеном? С какой стати «чтобы выдержать испытание временем, следует недвусмысленно отвергнуть SQL»? Что-то здесь не так!

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

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

Есть только один вид доступа к данным, пригодный для реально работоспособной СУБД, и называется он «прямой» (а концепция ключа, между прочим, его явно запрещает — в отличие от SQL). Третий Манифест: «РМ-предписания и запреты не могут быть предметом компромисса». Даже несчастный курсор «категорически запрещается», а уж более примитивной навигации просто не бывает в природе! РМД именно категорически запрещает их иметь, ибо концепция ключа сразу же превращает любые навигационные операции в рекурсивный SQL-запрос: раз кортежи идентификатора иметь не могут, нам придётся рыскать по значениям, хоть ключом их обзови. И обязательный первичный ключ на реляцию вынь, да положь. И одинаковых кортежей заводить не моги, худо будет. И никакие индексы, никакие костыли не спасут идеологически неполноценную конструкцию!

SQL

Отношение к SQL у разных пользователей весьма неоднозначное, иногда диаметрально противоположное. Лично мне ближе такая его характеристика: «SQL — один из самых убогих языков, кривое детище Дональда Чемберлена сотоварищи». Точнее, их последователей — те, по крайней мере, понимали, что никакой это не язык: «Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования». То есть это язык запросов, причём конечного пользователя! Назвать его «языком программирования» тогда никому и в страшном сне не могло присниться! А теперь та же Вики нагло утверждает, что «SQL можно назвать языком программирования», стыдливо добавляя, что «он не является тьюринг-полным».

Ещё одна фраза из Вики: «SQL (structured query language — язык структурированных запросов) — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных. Это единственный механизм связи между прикладным программным обеспечением и РБД».
Одуреть! В самой расшифровке языка говорится, что это язык ЗАПРОСОВ, а в «пояснении» — что это язык ПРОГРАММИРОВАНИЯ!

Стандарт SQL. Отдельная песня. Во-первых, он неприлично раздут в размерах при очень слабой функциональности языка (например, базовая часть стандарта SQL:2003 состоит из более чем 1300 страниц текста). Даже Великй и Могучий С потребует уж никак не больше десятка страниц! А здесь что? Один-единственный оператор SELECT? Что ещё? CREATE — INSERT — DELETE — UPDATE? GRANT — REVOKE? COMMIT — ROLLBACK — SAVEPOINT? Не смешите мои тапочки!

Версий стандарта языка превеликое множество. Туда пытались запихать эмуляцию графа (концепция первичного и внешнего ключей), контроль целостности (убогий до неприличия) и как-то расширить функциональность (поддержка регулярных выражений, рекурсивных запросов, триггеров, нескалярные типы данных, какие-то объектно-ориентированные возможности, расширения для работы с XML-данными, оконные функции, возможность совместно использовать в запросах SQL и XQuery и т.п.), но без особого успеха. К тому же, у разных производителей СУБД в ходу разные диалекты SQL, в общем случае между собой несовместимые. На текущий момент все усилия по проверке СУБД на соответствие стандарту ложатся на её производителя.

SQL не является истинно реляционным языком: он разрешает в таблицах строки-дубликаты, что в рамках реляционной модели данных (к слову, ещё более убогой, чем SQL) невозможно и недопустимо, поддерживает неопределённые значения (NULL) и многозначную логику, использует порядок столбцов и ссылки на колонки по номерам, разрешает колонки без имени и дублирующиеся имена столбцов. За это на него матерятся реляционщики-теоретики вроде Дейта с Дарвеном, что, в общем-то, понятно: ещё из школьного курса биологии известно, что «внутривидовая борьба — самая жестокая».

SQL изначально вообще не предлагал способов манипуляции даже иерархическими структурами, не говоря уже о графах общего вида. Даже рекурсивные запросы (которые дают экспоненциальное замедление производительности с увеличением глубины связей) появились в Microsoft SQL Server лишь в версии 2005. SQL не является привычным процедурным языком программирования (то есть не предоставляет средств для построения циклов, ветвлений и т. д.), поэтому производители СУБД вводят различные процедурные расширения — хранимые процедуры и процедурные языки-«надстройки». Практически в каждой СУБД применяется свой процедурный язык (Oracle — PL/SQL, Interbase и Firebird — PSQL, в DB2 — SQL PL, в MS SQL Server — Transact-SQL, в PostgreSQL — PL/pgSQL и т.д.). И нафига мы стандартизуем SQL с его фактически единственным оператором SELECT, который, к тому же, почти ничего не умеет делать?

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

NoSQL

В последнее время термин «NoSQL» стал очень модным и популярным, активно развиваются и продвигаются всевозможные программные решения под этой вывеской, говорятся всякие «умные слова», вроде «линейная масштабируемость», «кластеры», «отказоустойчивость», нереляционность", NoSQL хранилище прижилось в качестве основной базы данных для социальных сетей Instagram и Facebook, но никакой «NoSQL-революции» не произошло — реляционные базы данных стабильно удерживают доминирующие позиции. И дело даже не в мощнейшем «реляционном лобби», а в том, что продукт этот достаточно сырой, ему не хватает множества базовых вещей — универсальности, надежности, целостности и предсказуемости. А потому трактовка термина «NoSQL» всё больше смещается в сторону «Not Only SQL», хотя изначально в качестве альтернативы предлагали даже «NonRel», но быстро успокоились, и сейчас более 90% действующих СУБД и БД построены по реляционному принципу, в основе которого лежит табличная схема компоновки данных — особенно, если учесть, что подавляющее большинство остальных решений, хотя и называются NoSQL, фактически оперируют всё равно с таблицами. Данные и там, и там ИДЕОЛОГИЧЕСКИ табличны! В полном соответствии с первым же из «12 правил Кодда», которое гласит: «Вся информация в реляционной базе данных на логическом уровне должна быть явно представлена единственным способом: значениями в таблицах».

Великий Спор

Сегодня уже основательно подзабытый, «Великий Спор» между Коддом и Бахманом состоялся в 1974 году на семинаре ACM SIGMOD, где каждый из докладчиков стремился показать преимущества своего подхода. Тогда современники говорили, что спор закончился вничью, поскольку никто из присутствующих (включая самих спорщиков) так ничего и не понял. Теперь, задним числом, принято считать, что победу одержал Кодд, ибо реально работающие СУБД сейчас почти все реляционные. Но до сих пор, как отголосок этого спора, при разговоре о моделях данных противопоставляют поэлементную и групповую обработку данных. На самом деле такое противопоставление есть просто глупость.

Общеупотребительным (хотя не всегда явно определённым) термином во всех моделях является поле — наименьший, неделимый, атомарный элемент данных заданного типа. При этом термин «тип данных» может нести весьма разнообразную смысловую нагрузку: он может определять объём памяти, занимаемый элементом, набор допустимых значений, набор ассоциированных с этим типом операций, дескриптор устройства, связь с другими элементами и многое другое. Кроме атомарных, существуют также элементы данных, представляющие собой группы полей, называемые разными авторами «сегментами», «наборами» и другими терминами. Существует два типа групп однородных элементов: массив (множество элементов заданного размера) и строка (размер этой группы определяется по заранее установленному значению терминатора). Группы же разнородных элементов фактически отличаются друг от друга лишь названием: узел (графовая модель), кортеж (реляционная модель), класс (объектный подход), структура (языки программирования).

После согласования терминов легко видеть всю нелепость предмета Великого Спора: проблема вовсе не в сравнении конкретных описаний CODASYL и абстрактной РМД. И не в том, что сравнивается табличное и графовое представление данных — в конце концов, это всего лишь абстракция. И не в принципиальных различиях понятий ключ и указатель — это лишь прямое следствие главной ошибки: сравнение групп с атомарными элементами. В РМД первичный элемент есть таблица, т.е. группа. Но если мы определим отношение как «массив кортежей», а сам кортеж как «совокупность полей», тогда, действительно, станет возможным реальное сравнение полей и кортежей РМД с узлами и рёбрами сетевой модели.

Теперь повторим попытку сравнения этих двух моделей, имея в виду, что узел может содержать не только атомарный элемент, но и структуру, а термин tuple эквивалентен struct (т.е. член группы тоже может быть группой). После этого мы не только сможем корректно сравнивать модели данных, но и совершенно автоматически получим объектную модель данных вместо реляционной (хотя и ценой уничтожения реляционной алгебры). И такое сравнение окажется отнюдь не в пользу РМД: мы сразу же увидим набор неоправданно жёстких ограничений на сложность данных в отношениях. В самом деле: почему разрешено комплектовать в единое отношение лишь однородные элементы? Почему нельзя адресоваться непосредственно к внутренним элементам кортежа? Почему кортежу запрещено иметь свой собственный, не зависящий от данных идентификатор? С какой стати мы должны упираться рогом в эту несчастную концепцию «ключа»? За какие провинности нам запретили иметь в кортеже структуры сложнее одноуровневого дерева? И зачем нам это прокрустово ложе нормальных форм? Ради чего? Ради упрощения формального аппарата алгебры отношений и реляционного исчисления? А кому они, собственно, нужны? Разработчикам СУБД? Администраторам? Пользователям?

Если же, наоборот, привести терминологию сетевой модели к реляционной (первичный элемент есть множество), мы также получим возможность корректного сравнения двух моделей, и оно снова будет не в пользу РМД! Нам потребуется явно прописать ссылки на соответствующие метаданные, т.к. в РМД механизм доступа к метаданным (именам таблиц, столбцов, типам данных столбцов) не специфицирован вообще никак. В любом случае, сетевая модель будет иметь более высокий уровень сложности элементов данных: здесь возможны группы узлов, в т.ч. не ограниченных требованием даже первой нормальной формы, возможны группы рёбер (каналы) и даже субграфов (элементов, размещённых сразу в нескольких узлах БД). Сама специфика сетевой модели (хранение данных вне таблиц) автоматически обеспечивает возможность формирования групп разнородных элементов с необязательными или множественными атрибутами. Сказка!

Поиск информации

При поиске информации графовая модель предоставляет более широкие возможности, поскольку позволяет создавать очень гибкие запросы, используя механизм преобразования типов и навигационные выражения. Например, возможно запросить всю информацию о текущем объекте базы данных, которая там вообще есть (что-то типа FIND.CURRENT.ALL), поскольку именно связи между элементами позволяют СУБД выявить (без какого-либо дополнительного поиска!) и сообщить пользователю эти сведения. Извлечь подобную информацию из аналогичной РБД практически невозможно. Кроме того, граф — это прекрасное подспорье для «чайника», который и знать не знает, как нужно спрашивать, чтобы получить то, что нужно именно ему, а вовсе не то, что поисковик думает по поводу его запроса. Наконец, запрос из разового становится итерационным — ответы сервера всё чаще содержат инофрмацию, интересующую именно потребителя.
Иллюстрация: юзер запросил слово «кофе». Поисковик ему что-то там прислал (по своим соображениям), но одновременно привёл список сопутствующих ключевых слов: сорта, рецепты, производители, кофемолки, технология выращивания, история и культура потребления, кофе-брейк, и даже чай (как альтернатива кофе). Да любой клиент с радостью уточнит запрос!

Верификация

Везде, где присутствует человек, любые средства интерфейса и входного контроля могут лишь снизить вероятность внесения ошибок, но никогда не устранят их полностью. Из выпадающего меню обязательно будет выбран соседний пункт (промах мышкой), в результате чего «улица маршала Рыбалко» превратится в «улицу маршала Соколовского» (реальный случай из практики), а пресловутый Вася Иванов обязательно получит «женский пол» в радиокнопке. Но самое неприятное, что неверно записанное значение какого-либо поля приводит к лавинообразному росту паразитных записей, и, как следствие, к наведённым ошибкам при поиске и анализе информации. Забавный пример: сотрудники два дня искали одного старичка с фамилией ИBАНОВ (в нижнем регистре иbанов). И стоит проблема верификации весьма остро!

В РСУБД средства верификации отсутствуют как класс. Мало того — вот ещё одна цитата из Вики: «В криптографии и информационной безопасности целостность данных (в широком смысле) — это сохранение данных в том виде, в каком они были созданы». Видали? Это фактически запрещает правку данных вообще! Обнаружили ошибку? Не моги исправлять! А то целостность данных будет нарушена (в широком смысле).

И ещё одна проблема: база данных развивается, состав и объём данных изменяется, и потому ясное представление о конечной структуре БД (и, соответственно, дизайн, спроектированный с учетом её особенностей) невозможен в принципе. Информационные потребности пользователей также разные, и они изменяются со временем. Следовательно, БД должна периодически перестраивать свою структуру согласно изменению их потребностей или вследствие изменения самих данных. Это уже не просто верификация — это ещё и реструктуризация, изменение схемы БД во время её эксплуатации!

Заключение

Нам представляется правильным вместо «Великого Спора» объявить «Великое Перемирие» не противопоставлять, а объединить реляционный и сетевой подходы в рамках единой модели данных. Если такая задача осуществима, то и все остальные модели данных наверняка укладываются в общую схему, поскольку все они базируются либо на табличном, либо на графовом представлении данных. Так можно ли «скрестить ежа с ужом», свести воедино модели Кодда и Бахмана, сохранив достоинства и устранив недостатки каждой из них? Вопрос нужно ставить даже не так: это нужно сделать!

В графовом представлении БД должна выглядеть как распределённый, многомерный, циклический, смешанный граф с разнородными элементами произвольной структуры, каждый узел которого имеет, в общем случае, переменное количество связей с другими узлами (рёбер), в т.ч. нулевое, при этом рёбра также могут иметь свои собственные «персональные» данные. Необходимо уйти от подхода CODASYL, включив отношения «многие-ко-многим». А с реляционной точки зрения те же данные, представляют собой единое отношение неоднородных кортежей, и для них, соответственно, допустима не только поэлементная, но и групповая (реляционная) семантика операций по обработке данных. В отличие от РМД, допускаются дубли кортежей, допускаются ссылки не только на кортежи, но и на их поля. Поскольку нормализация отношений часто затрудняет обработку сложно организованных данных, её следует отменить. В частности многозначные атрибуты и неатомарные поля данных вполне допустимы. Помимо прямого доступа к любому элементу данных, необходимо обеспечить возможность свободное изменение его размера, структуры и/или количества связей с другими элементами. Разнообразие типов данных может быть сколь угодно большим. Конечно, количество базовых типов (BOOLEAN, FLOAT, URL) относительно невелико — ведь при их определении приходится прописывать (а нередко и программировать) методы и правила их обработки, а это достаточно сложное и трудоёмкое занятие. А вот создание пользовательских типов (TUPLE, ENUM, RELATION) куда проще — здесь есть, где разгуляться! Можно определять как реляционные (именованная группа полей одного узла), так и графовые типы данных (именованная группа полей разных узлов). Например, тип ADDRESS может быть представлен как кортеж (Страна, Город, Улица, Дом, Квартира) или как субграф (Квартира -> Дом -> Улица -> Город -> Страна). И хотя для конечного пользователя эти два типа вряд ли различимы, уже сам факт использования графового типа ADDRESS позволяет выявлять логические ошибки в данных: СУБД просто не позволит внести неверные данные сообщением, вроде: «В этом городе такой улицы нет».

Данные, имеющие одинаковый семантический смысл, могут не только быть представлены в БД различными типами, но и поменять тип после их редактирования или реструктуризации БД. В нашем примере у одной семантической сущности «Адрес» в БД могут одновременно присутствовать иерархический (графовый) и реляционный тип данных в различных её элементах. Но эти различия не мешают организации доступа к ним однородным путем: результатом пользовательского запроса по ключевому слову «Адрес» должны быть все адреса, существующие в БД, при этом они будут абсолютно неразличимы для конечного пользователя. СУБД даже может самостоятельно обнаружить, что они представляют тот же самый объект, если имена всех классов и атрибутов, как и их значения, полностью эквивалентны и убрать «лишний» тип по Оккаму.

Применение суррогатного ключа в качестве идентификатора позволяет сохранить традиционные преимущества сетевой модели: прямой доступ к данным, навигационные выражения в запросах. Но теория операций групповой обработки данных по-прежнему представлена всё той же реляционной алгеброй. Более высокая потенциальная мощь сетевой модели сегодня не используется вообще из-за отсутствия соответствующего математического аппарата для работы с множествами. Проблема также и в том, что рёбра графа не могут быть представлены ни как ключи в РМД (теряется прямой доступ к данным), ни как указатели в CODASYL (нарушается принцип независимости данных, ведь указатели зависят от природы физического хранения данных и потому требуют перестройки при обновлении данных или изменении схемы БД). И вообще подобная модель содержит массу весьма сложных алгоритмических и технических проблем. Но ведь нужно же что-то делать с этой лавиной обрушившихся на нас данных, нужно как-то разгребать эту свалку! Хватит играть в реляционные погремушки!

Автор: rybvv

Источник