Добавить комментарий

Концепции разработки идеальной БД

Здравствуйте. Как-то настораживает, что здесь просто МЕРТВАЯ тишина, но, возможно, это и к лучшему. Я хотел бы обсудить концепции построения моделей и баз данных, сформулировать требования к идеальной БД. По всей цепочке: от ядра до конечного пользователя. Но только концепции - иначе мгновенно утонем.

В первую очередь я хотел бы удостовериться в наличии живых людей вообще на форуме. Особо прошу откликнуться тех, которым данная проблема представляется интересной.

Вместо предисловия

Полистал я несколько рекомендованных ссылок (в том числе три "местных"), а именно:


  • Проектирование баз данных: новые требования, новые подходы
  • Аномалии в реляционных базах данных
  • Кризис баз данных и проблема выбора
  • Базы данных: достижения и перспективы на пороге 21-го столетия
  • Реализация ядра безопасности в информационной системе
  • Словарь метаданных документно-ориентированной информационной системы
  • Управление качеством данных на основе алгоритмов нечеткого поиска

Все, за что глаз зацепился, выкладываю "оптом", без привязки к работе, с комментариями (не всегда совпадающими с авторскими), так что далее идут ИМЕННО МОИ мысли. Впрочем, нет - "местные" я прокомментировал "по месту". Публикации старые, но это не является минусом. Итак, подборка цитат:

  • Двадцать лет практики обучили нас, что иногда нормализованные таблицы это правильно, а иногда нет; базы данных будущего должны предоставлять такой выбор.
  • Большинство организаций сейчас хранят больше данных на десктопах, чем в своих БД. Этими данными на десктопах, часто хорошо структурированными по своей природе, управляет все, что угодно, но не системы управления базами данных.
  • Сегодня объектно-ориентированные базы данных поддерживают один стиль навигации; сетевые СУБД и ISAM - другой. Реляционные базы данных, с другой стороны, обеспечивают запросы и операции на множествах. Высокоуровневые процессоры запросов могут ориентироваться либо на операции со множествами, либо на навигацию указателей или на то и другое. Пользователь может выбирать.
  • Поэлементный навигационный стиль и вычисления, основанные на запросах и ориентированные на множества одинаково нужны. Часто подход, основанный на запросах, - наилучший путь первоначального указания множества записей, в то время как навигационные операции - единственный путь дальнейшей работы с полученными в результате данными в манере достаточно развитой, чтобы удовлетворить потребностям сложных приложений. Чем раньше мы избавимся от необходимости выбора, тем лучше.
  • SQL и надстраиваемые над ним языковые формы более высокого уровня хороши для доступа к традиционным записям данных. Когда речь идет о мультимедийных данных, то здесь часто необходимы совершенно другие формы пользовательских интерфейсов.
  • Одной из самых актуальных задач является создание методики проектирования хороших схем реляционных БД. Вопрос о проектировании "хороших" схем реляционных баз данных изучается в литературе уже свыше двадцати лет. К сожалению, к настоящему моменту так и не появилось общепринятой на практике методики проектирования схем. Проектирование схем БД превращается в искусство. Его результаты полностью зависят от опыта и мастерства проектировщика.
  • Средств для работы с абстрактными типами данных в реляционных СУБД практически нет

Etc., etc., etc. Резюмирую: хватит играть в реляционные погремушки!

Идеальная БД

Идеальная БД: БД, которая не вызывает ни у одного из ее многочисленных пользователей никаких иных чувств, кроме восторга.
Пользователь:

  • Умный Профессионал (все знает, и все умеет).
  • Глупая Кухарка (ни хрена не умеет, ни хрена не соображает).
  • Средний Юзер (любое промежуточное состояние).
  • Любознательный Компьютер (самый активный пользователь).

Поскольку посты вроде как можно редактировать - будем пополнять и модифицировать. Если этот пост можно редактировать только мне - пишите заявки. Кстати, я хотел бы, чтобы ветка была модерируемой - мусор потихоньку вычищался, формулировки вылизывались... это возможно (я имею в виду, технически)?

Добиваем РМД

В этот пост я намерен собрать аргументацию против сторонников РМД - практика показывает, что их даже слишком много. Впрочем, аргументации тоже немало. Вот, например:


  • Сделать многие приложения доступными для непрограммистов в тех случаях, когда ранее программисты были бы необходимы. Благороднейшая цель! Слова самого Кодда: "Важно помнить, что базы данных появились, чтобы приносить пользу конечным пользователям, а не для прикладных программистов, которые сегодня выступают в качестве посредников (middle-men)". И... полностью противоположный заявленной цели результат: именно благодаря Кодду в приложения БД буквально ломанулась целая толпа посредников, благо требования к их квалификации резко снизились.
  • редставления самого Кодда о том, что такое RDM, неоднократно менялись в течение всей жизни. Например, Стоунбрейкер писал, что "можно видеть четыре разных версии" модели. До сих пор это понятие не имеет однозначного толкования. По-видимому, наиболее "классическим" определением следует считать Третий Манифест, поскольку Дейт писал (немного перефразировано): "Мы с Хью Дарвеном хотели, чтобы Манифест отчасти рассматривался бы как определительная формулировка, что такое реляционная модель".
  • Маниакальная борьба Кодда с навигацией (да и сложностью) явно обусловлена знанием о существовании концепций БД от CODASYL, стремлением избавиться от ее недостатков (как и появление 3-го Манифеста обусловлено знанием о существовании SQL, с которым Дейт энд кампани ведут борьбу не на жизнь, а на смерть). Кодд сам отвергал возможность компромисса, любую попытку объединения двух подходов, поскольку в результате "мы получаем ненужную сложность".
  • Авторы Третьего Манифеста прямо говорят, что "сфера их интересов - это абстрактная модель, а не вопросы реализации". Тем не менее, они указывают, что "существует ряд вопросов, на которые пока еще нет удовлетворительных ответов в доступной литературе". Даже при такой, предельно упрощенной постановке вопроса (ведь реализация абстрактных положений может оказаться неэффективной, практически непригодной, или даже вообще невозможной!), Манифест буквально пестрит фразами типа "данный вопрос требует дальнейшего изучения", "эта проблема требует дополнительного изучения", "набросок возможной модели наследования можно получить у авторов" и т.п. Иными словами, авторы открытым текстом признают, что недостаточно разбираются в проблеме - позиция, достойная всяческого уважения, рядом с которой соседствуют наивные, детские попытки "запрещать, и не пущать". Почему "РМ-предписания и запреты не могут быть предметом компромисса"? С какой стати "любые(!) основы для будущего управления данными должны твердо(!) корениться в РМД"? Кто сказал, "направления будущего развития СУБД" должны непременно базироваться на том, что было "впервые представленной миру Коддом в 1969 году"? Мир не обязан все время играть в одни и те же погремушки.

Итак, "новая реляционная алгебра" (по Кузнецову, ее создание относится к высшим достижениям авторов) НЕ ЕСТЬ "оригинальная алгебра Кодда", и отличается от нее "четырьмя основными аспектами". Факт, бесспорно, положительный. Я бы даже сказал - знаковый, символизирующий агонию РМД.

Очередные соображения на тему идеальной БД

  1. Поскольку идеальная БД (СУБД) должна идеально обслуживать любого клиента (при этом информационные потребности пользователей разные, и они изменяются со временем), то все разговоры о "галерах, с цепью на ноге, к другому концу которой приковано ядро" или, другими словами, о "пересечении требований, предъявляемых разными потребителями к базе" есть полнейшая глупость. Идеальная СУБД должна идеально обслуживать ЛЮБОГО пользователя. Это называется "персонификация UI" или, говоря словами для кухарки, "каждому по потребностям". Возражения?
  2. База данных в общем случае является многопользовательской, распределенной, мультимодельной, мультиплатформенной мультибазой данных (совокупность баз данных есть тоже база данных). Каких-либо ограничений на поддерживаемые типы данных, размеры элементов и число связей между ними, на число пользователей и компьютеров распределенной СУБД, платформы и операционные системы, количество баз данных и метаданных в мультибазе не накладывается.
  3. СУБД должна обеспечивать быстрый доступ к данным и высокую релевантность ответов даже при наличии ошибок в запросах и данных, а также эффективную реализацию алгоритмов обработки вновь поступающей (в произвольные моменты времени) информации, верификации БД, коррекции ошибок в данных (в т.ч. изменение структуры БД) и защиты данных. Эффективность алгоритмов не должна ухудшаться с ростом объема данных и сложности их структуры.
  4. СУБД построена по технологии "клиент-сервер". Клиентская часть СУБД не является ее составной частью и должна быть стандартной и аппаратно независимой (броузер). Серверная часть обеспечивает санкционированный доступ к базам данных с целью занесения, удаления, редактирования, поиска, верификации данных, а также модификации схемы БД при необходимости.
  5. Данные в БД могут быть любого типа (числа, строки, графика, музыка, сайты, даты, деньги - любые оцифрованные данные), и образовывать сложные типы данных, представляющих произвольные комбинации данных более простых типов (массивы, списки, деревья, отношения и т.п.).
  6. Данные имеют переменную структуру полей, и каждое поле может быть связано с любыми другими полями БД по разным измерениям, образуя многомерный граф произвольной сложности (мультиграф, псевдограф, циклический граф, бесконечный граф - как угодно), каждый узел которого имеет, в общем случае, переменное количество сязей с другими узлами (ребер), в т.ч. нулевое.

О моделях данных

Кристофер Дейт: "Модель данных есть теория, или средство моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке".

Таким образом, сам того не желая, Дейт дал совершенно блестящее, понятное даже ребенку, определение модели данных: это именно язык! Или, точнее, семество языков: ЯОД - язык определения данных (Data Definition Language, DDL), ЯМД - язык манипуляции данными (Data Manipulation Lanfuage, DML) и... тут же выясняется, что не хватает еще одного языка - для третьего аспекта понятия "модель данных": языка описания правил или ограничений целостности. Можно с достаточной уверенностью предсказать появление таких языков в будущем.

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

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

Кроме атомарных, существуют также элементы данных, представляющие собой группы полей, называемые разными авторами "сегментами", "наборами" и другими терминами. В действительности же существует лишь два типа групп однородных элементов: массив (array) - множество элементов заданного размера, и строка (string) - множество, размер которого явно не задается, а определяется по заранее специфицированному значению элемента строки (терминатор, NULL).

Существуют также группы разнородных элементов, отличающиеся главным образом названием: это struct (языки программирования), class (объектная парадигма), tuple (кортеж, реляционная модель данных), node (узел, теория графов). В самом деле, понятие class отличается от struct лишь возможностью заполнять конкретными значениями поля структуры при ее описании ("в нагрузку", разумеется, получаем конструкторы с десктрукторами). Если мысленно разрешить узлы графа считать не только атомарными элементами, но и структурами, а понятие tuple также сделать полностью эквивалентным понятию struct (т.е. элементом группы может быть группа), мы получим возможность реально сравнивать любые модели данных (а заодно "совершенно бесплатно" получим объектную модель данных на месте реляционной - правда, ценой уничтожения реляционной алгебры).

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

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

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

РМД и SQL

В математике (и в SQL, с которым Дейт энд кампани ведут борьбу не на жизнь, а на смерть) кортежи "упорядочены", разрешаются их дубли. Мало того, сам Кодд первоначально определял кортежи именно так! Отказ от упорядочивания расматривается (кажется, Дейтом) как величайший вклад Кодда в РМД. В ООБД, однако, "почему-то" вновь требуется "поддержка индивидуальности объектов", т.е. "объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов". Иными словами, "величайший вклад" есть полная фикция.

Сам Кодд пропагандировал трехзначную логику (истина, ложь и NULL), а в 1990 даже четырехзначную, однако из-за высокой сложности(!) в Третьем Манифесте все это запрещено: "больше никаких неопределенных значений и больше никакой многозначной логики"! Тенденция к упрощению, доходящему до неприличия, проходит красной нитью через всю РМД, и это НЕИЗБЕЖНО приводит к ограничениям в сложности самих данных. Иными словами, данные в РБД хронически примитивны: сколько-нибудь сложных конструкций там держать нельзя. И ни сама СУБД, ни проектировщики БД не могут обойти это ограничение. Строго говоря, могут (Когаловский, во всяком случае, об этом говорил), но работать это не будет. Еще точнее - будет, но выполнение сложных запросов растянется на тысячелетия. И никакия "оптимизация" не поможет.

Лично я думаю, что отказ от упорядоченности есть НЕИЗБЕЖНОЕ СЛЕДСТВИЕ "структурного аспекта реляционной модели" (данные в базе данных представляют собой набор отношений, т.е. первичный элемент есть группа). В любом случае, наличие/отсутствие упорядоченности имеет принципиальное значение - это признается обеими сторонами (Дейт тоже категорически против компромиссов). Следовательно, чрезвычайно важно "не ошибиться с направлением" именно на этом "водоразделе".

Совершенно неизбежным и страшным следствием отсутствия упорядоченности является концепция "ключа". Подмена понятий (замена идентификатора ключом) имеет далеко идущие последствия. Понятие идентификатора, "жульническим" образом изъятое из модели данных, принципиально не может быть убрано также из РСУБД.

"Переместить прикладное программирование на уровень, на котором множества (и, более конкретно, отношения) трактуются как операнды, а не обрабатываются поэлементно" - замечательная цель: язык, позволяющий работать с множествами, бесспорно, удобен. РМД, однако, предполагает работу ТОЛЬКО с множествами (никаких покортежных операций, единичный кортеж есть просто частный случай множества, категорически запрещается концепция курсора). А в таких "коротких штанишках" становится уже тесно даже SQL - ближайшему родственнику РМД.

Нормальные формы (иерархичные по природе) приводят к ограничению сложности поддерживаемых структур данных. Между тем, идея самого Кодда состояла в том, что "при выборе логических структур данных должно присутствовать только одно соображение - удобство большинства пользователей".

Есть только один вид доступа к данным, пригодный для реально работоспособной СУБД, и он называется "прямой" (а концепция ключа, между прочим, его явно запрещает - в отличие от SQL). И никакие индексы, никакие костыли не спасут идеологически ублюдочную конструкцию!

Третий Манифест: "РМ-предписания и запреты не могут быть предметом компромисса". Даже несчастный курсор "категорически запрещается" (а уж более примитивной навигации просто не бывает в природе). РМД именно КАТЕГОРИЧЕСКИ запрещает их иметь, ибо концепция ключа мгновенно превращает навигационные операции в рекурсивный SQL-запрос: раз кортежи идентификатора иметь не могут - будь любезен рыскать по ЗНАЧЕНИЯМ, хоть ключом их обзови. И обязательный первичный ключ на реляцию вынь, да положь. И одинаковых кортежей заводить не моги - худо будет. Кодд ненавидел навигацию не меньше, чем Дейт SQL.

Подобная жесткость подхода к простоте представления данных (которые все это время обнаруживали явную тенденцию к усложнению), дополненная появлением различных нормальных форм, уже привела к ситуации, что реальные "реляционные" СУБД в действительности РМД не поддерживают. В частности, обычным явлением стал отказ от нормализации таблиц.

Вроде как реляционная алгебра (как и реляционное исчисление) обладают какой-то там "полнотой". Наверное, для каких-то там теоретических умозаключений это очень важно. На практике же РМД (как, скажем, и машина Тьюринга) на фиг никому не нужна. Типы данных (string, int, date, boolean, etc.) реляционной теории по барабану. Концептуально, реляционная алгебра оперирует понятием Декартова произведения, которое в реальных РСУБД использовать слишком дорого, поэтому используют различные техники "оптимизации запросов".

Если действительно "РМД лишь предписывает, чтобы результат, например, соединения отношений логически был эквивалентен произведению с последующим ограничением (выборкой)", то какого же черта Дейт страдает, что "Cartesian product and union are both noncommutative"? Чего он с такой ненавистью набрасывается на идентификаторы столбцов и кортежей в SQL? Какое его собачье дело?! РМД не только "никак не предписывает конкретную реализацию этих операций" - она вообще ничего полезного, практически пригодного не предписывает.

Получение физического доступа к кортежу есть вопрос реализации, а не вопрос модели данных. Реляционная модель данных предписывает ассоциативный доступ к данным, т.е. доступ на основе значений, а как это реализуется в конкретной системе - для модели совершенно неважно. Теоретики, блин!

Клевета Кодда на сетевую модель, попавшая чуть ли не во все учебники, НАПРЯМУЮ связана с тем, что "получение физического доступа к кортежу ЕСТЬ вопрос модели данных". Например: "изменение структуры базы по-прежнему требует значительных усилий и времени, поскольку операции модификации и удаления данных ТРЕБУЮТ ПЕРЕСТАНОВКИ УКАЗАТЕЛЕЙ" - очевидный идиотизм. Или еще один: Those "pointers" needn't be physically represented in storage by actual pointers, but the user can always think of them as actual pointers. (That's the network model!) А вот в РМД - "как это реализуется в конкретной системе - для модели совершенно неважно" - те самые "двойные стандарты", то самое жульничество.

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

Forums: