Недостатки реляционных СУБД

Поддержка доступа к данным с помощью Internet.

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

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

- Автоматизированное проектирование.

В БД для систем автоматизированного проектирования (Computer-Aided Design – CAD) должны храниться данные, относящиеся к проектам механических и электротехнических конструкций, например, зданий, самолетов или интегральных микросхем. Такие проекты имеют следующие общие характеристики:

1. Проектировочные данные характеризуются большим количеством разных типов, каждый из которых обладает небольшим количеством экземпляров.

2. Проекты могут быть очень большими, включающими миллионы элементов, часто со многими относительно независимыми подчиненными проектами.

3. Проект не является статичным и эволюционирует со временем. При изменении проекта любые последствия этих изменений должны быть отражены Вов сех представлениях проекта.

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

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

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

- Автоматизированное производство.

В БД для автоматизированного производства (Computer-Aided Manufacturing – CAM) хранятся данные, аналогичные данным CAD-систем, а также данные о дискретных (например, автомобилях на конвейере) или непрерывных (например, продукты химического синтеза) продуктах. В химической промышленности широко используются приложения, которые отслеживают информацию о состоянии системы: температура в реакторе, скорость потоков и уровень выхода продуктов реакции. Существуют также приложения, которые контролируют различные физические процессы, например, открытие клапанов, позволяющих передавать большое количество теплоты к реактору или увеличить поток в охлаждающий системах. Такие приложения часто имеют иерархическую структуру, в которой приложения высокого уровня отслеживают работу всего предприятия в целом, а приложения низкого уровня – отдельные производственные процессы. Эти приложения должны работать в режиме реального времени и быть способны эффективно управлять процессами для поддержания оптимальной производительности в рамках заданных допусков. Вычислительные системы должны хранить огромный объем данных с иерархической природой, а также сложные связи между данными.

- Автоматизированная разработка программного обеспечения.

В БД системы автоматизированной разработки программного обеспечения (Computer-Aided Software Engineering – CASE) хранятся данные, относящиеся к различным этапам жизненного цикла разработки программного обеспечения: планированию, сбору и анализу требований, проектированию, реализации, тестированию, сопровождению и документированию. CASE-проекты могут быть очень большими и для их реализации обычно применяется коллективная разработка.

- Офисные информационные системы и мультимедиа системы.

БД офисной информационной системы (Office Information System – OIS) хранит данные, которые относятся к управлению бизнес-информацией, с помощью компьютера, включая электронную почту, документы, счета и т. д. Для предоставления большей поддержки в этой области необходимо иметь дело с типами данных в более широком диапазоне, чем просто имена, адреса, даты и деньги. Современные системы способны работать с текстами произвольного формата, фотографиями, диаграммами, аудио- и видеозаписями. Например, мультимедиа-документ может содержать текст, фотографии, электронные таблицы и голосовые комментарии. Документы могут обладать особой структурой (HTML). Документы могут совместно использоваться многими пользователями с помощью таких средств, как электронная почта и электронные доски объявлений, функционирующие в среде Internet. Такие приложения должны уметь хранить данные с более богатой структурой, чем простейшие записи, состоящие из чисел и коротких текстовых строк.

- Цифровое издательское дело.

Постепенно становится возможным хранить книги, журналы, газеты и статьи в электронном виде, а также доставлять их клиентам по высокоскоростным сетям. аналогично офисным информационным системам, возможности цифрового издательского дела расширяются средствами обработки мультимедиа-документов, включающих текст, изображения, аудио- и видеоматериалы, анимацию. В некоторых случаях количество доступной в интерактивном режиме информации просто чудовищно, порядка петабайт
(10¹⁵ байт), что делает их самыми крупными БД, с которыми СУБД когда-либо приходилось иметь дело.

- Геоинформационные системы.

В БД геоинформационной системы (Geographic Information System – GIS) хранятся разные типы такой пространственной и временной информации, которая используется в землеустройстве и подводных изысканиях. Большинство данных в этих системах получено в результате геологических исследований и на основе аэрофотосъемки, поэтому они могут иметь очень большой объем.

Также имеются научные и медицинские приложения, в которых могут храниться комплексные данные, представляющие такие сложные системы, как молекулярные модели для синтезированных химических компонентов и генетических материалов; экспертные системы, в которых могут храниться знания и правила, предназначенные для использования в приложениях искусственного интеллекта, и др.

Реляционная модель данных и РСУБД имеют определенные недостатки:

- Слабое представление сущностей реального мира.

Процесс нормализации обычно приводит к созданию отношений, которые не соответствуют сущностям «реального мира». Фрагментация сущности «реального мира» на несколько отношений с физическим представлением, которое отражает эту структуру, является неэффективным и приводит к необходимости выполнения многих соединений в процессе обработки запросов.

- Семантическая перегрузка.

Реляционная модель обладает только одной конструкцией для представления данных и связей между данными – отношением. Например, для представления связи типа N:N между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье – для представления связи. Не существует никакого механизма для установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь типа 1:N может иметь разный смысл: имеет, владеет, управляет и т. д. Если бы подобные различия можно было отразить в схеме, то операциям можно было бы придать определенный семантический смысл. Из-за отсутствия подобных возможностей говорят, что реляционная модель семантически перегружена.

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

- Слабая поддержка ограничений целостности и корпоративных ограничений.

Многие коммерческие системы не полностью поддерживают ограничения целостности данных и их приходится встраивать в приложения. Это небезопасно и может привести к возникновению противоречивых состояний. В реляционной модели не предусмотрены никакие средства поддержки корпоративных правил, что опять означает необходимость их встраивания в СУБД или в приложение.

- Однородная структура данных.

Реляционная модель предполагает как горизонтальную, так и вертикальную однородность данных. Горизонтальная однородность данных означает, что каждая запись отношения должна состоять из одних и тех же атрибутов. А вертикальная однородность означает, что значения в некотором столбце отношения должны принадлежать одному и тому же домену. Более того, на пересечении строки и столбца должно находиться атомарное значение. Эта фиксированная структура является слишком жесткой и недостаточной для представления многих объектов «реального мира» с достаточно сложной структурой, что приводит к неестественным соединениям, которые весьма неэффективны. Одним из таких классических примеров является бурное увеличение количества частей при попытке представления некоторого объекта, например, самолета, который состоит из многих деталей и узлов, которые содержат другие детали и узлы, и т.д.

- Ограниченный набор операций.

Реляционная модель обладает только фиксированным набором операций, включающим операции с множествами и записями, определенные в спецификации SQL, которая не допускает определения новых операций. Это накладывает большие ограничения на моделирование поведения объектов «реального мира». Например, в GIS-приложении обычно используются точки, линии, группы линий и многоугольники, для работы с которыми требуются операции определения расстояния, нахождения пересечения и оценки включения.

- Трудности организации рекурсивных запросов.

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

- Проблема рассогласования.

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

1. Язык SQL является декларативным языком программирования, который оперирует строками данных, а такой высокоуровневый язык, как язык С, является процедурным языком программирования, который может управлять только одной строкой данных за один раз.

2. Язык SQL и языки третьего поколения используют разные модели представления данных. Например, в языке SQL предусмотрены встроенные типы данных Date и Interval, которых нет в традиционных языках программирования. Таким образом, прикладной программе потребуется преобразовывать данные между этими двумя представлениями, что неэффективно как в отношении затраченных на программирование усилий, так и в отношении использования вычислительных ресурсов.

3. Из-за использования двух различных типов систем невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом.

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

Вопросы для самоконтроля

1. Какие настольный СУБД Вам известны?