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

. наличие развитых механизмов выборки информации, основанных на логических связках простых условий, накладываемых на содержание искомых документов; примерами простых условий является указание ключевых слов, характеризующих документ, или контекста, относящегося к содержимому документа.
ИПС по естественным причинам никогда не претендовали на роль СУБД. Однако обратное неверно, и многие производители СУБД пытаются ввести в состав своих продуктов возможности, позволяющие использовать их в качестве систем информационного поиска. Нужно заметить, что особых успехов в этой деятельности не видно. Главным образом, это связано с реляционной спецификой современных серверов баз данных, с их ориентацией на обеспечение эффективного доступа к структурированной информации. С другой стороны, многие возможности серверов баз данных в действительности не требуются для поддержки полнотекстовой информации. К таким возможностям можно отнести развитые средства управления транзакциями, организацию развитых средств динамического обновления данных, реализацию структурированных языков запросов и т.д.
В дальнейшем в этом разделе курса мы не будем затрагивать специфические свойства ИПС. Это связано не с тем, что мы считаем это направление недостаточно существенным для организации информационных систем. Все дело в том, что в настоящее время основной областью применения ИПС являются распределенные информационные системы, базирующиеся на Web-технологии.
Естественно, имеются смежные вопросы, касающиеся, например, возможностей доступа к традиционным базам данных в среде Internet. Тем не менее, однако, обе эти области достаточно широки по отдельности, чтобы можно было рассматривать их независимо.

8.1. Новые веяния в области серверов реляционных баз данных

Начнем с того, что текущее поколение программных продуктов, предназначенных для управления базами данных, практически полностью базируется на классической реляционной модели данных, которая в той или иной степени развивается и модифицируется в разных системах. Реляционная модель данных обладает большим числом достоинств и, конечно, многими недостатками. К числу достоинств можно отнести простую и вместе с тем мощную математическую основу модели, базирующейся на наиболее прочных аппаратах теории множеств и формальной логике первого порядка. Пожалуй, реляционная модель является исключительным примером соразмерности используемых математических средств и получаемых от этого преимуществ. Достоинством реляционного подхода является и его интуитивная ясность. Для того, чтобы начать грамотно использовать реляционную СУБД, совсем не требуется глубокое погружение в формальную математику. Достаточно понять житейский смысл объектов реляционных баз данных и научиться ими пользоваться. Проводятся интуитивные аналогии, не нарушающие смысл понятий, между отношениями-таблицами-файлами, атрибутами- столбцами-полями записей, кортежами-строками-записями файла и т.д.
Как всегда бывает в жизни, отрицательные качества реляционного подхода представляют обратную сторону его достоинств. Очень просто представлять информацию в виде регулярных плоских таблиц, в которых каждая строка имеет одну и ту же структуру, а в столбцах могут храниться только простые данные атомарной структуры. Но одновременно, при использовании реляционных баз данных для хранения сложной информации возникают сложности. Известный консультант и аналитик Эстер Дайсон сравнивает использование реляционных баз данных для хранения сложных объектов (объектов, для представления которых недостаточно использовать плоские таблицы) с необычным использованием гаража, когда каждый раз, устанавливая автомобиль в гараж, шофер полностью его разбирает, а утром выполняет полную процедуру сборки.
На самом деле, соответствующие процедуры сборки (соединения нескольких таблиц) являются наиболее трудоемкими в реляционных СУБД. Другая проблема состоит в том, что упрощенная структура реляционных баз данных не позволяет сохранить в базе данных ту семантическую информацию (знания), которыми располагал ее создатель при проектировании. Реально ситуация выглядит следующим образом. На первой, наиболее интеллектуальной фазе проектирования базы данных имеется существенный запас данных, почерпнутых проектировщиком в процессе анализа предметной области. Однако по мере перехода к определению реально хранимых структур эти знания теряются, оставаясь в лучшем случае в виде бумажной или не привязанной к базе данных электронной информации, использование которой необходимо в жизненном цикле базы данных и соответствующей информационной системы, но сильно затруднено.
Перечисленные положительные и отрицательные качества реляционных баз данных в большой степени влияли на развитие индустрии баз данных в последние годы.
Несколько лет тому назад казалось, что перевешивают отрицательные качества.
В результате появилось несколько новых направлений архитектур баз данных, каждое из которых принесло новые методы и алгоритмы, а также экспериментальные реализации. Мы не будем глубоко вдаваться в обсуждение этих подходов, но все же приведем их краткую характеристику.
В классической реляционной модели данных содержимым столбцов могут быть только значения базовых типов данных (целые и плавающие числа, строки символов и т.д.). Не допускается хранение в столбце таблицы массивов, множеств, записей и т.п. Собственно, это и означает, что таблицы классической реляционной модели являются абсолютно плоскими (по-другому это называется представлением таблиц в первой нормальной форме). Вся сложность структур предметной области уходит в динамику; требуется непрерывная сборка сложных объектов из их элементарных составляющих. Один из подходов к расширению возможностей реляционной модели данных заключается в отказе от требования первой нормальной формы. Значением столбца таблицы может быть любой объект, представляемый в виде строки, массива, списка и даже таблицы.
Понятно, что при использовании таким образом расширенной модели, в качестве строки таблицы может храниться уже собранный объект с произвольно сложной
(иерархической) структурой. Причиной того, что реляционные системы с отказом от требования первой нормальной формы не вошли в широкую практику, является прежде всего необходимость полного пересмотра внутренней организации СУБД (начиная со структур хранения). Кроме того, если для классических реляционных баз данных давно и тщательно отработана технология и методология проектирования, то проектирование ненормализованных реляционных баз данных недостаточно хорошо изучено даже на уровне теории.
Тем не менее, на рынке СУБД имеется продукт UniVerse компании VMark, в которой в ограниченных масштабах поддерживается хранение ненормализованными реляционными данными.
Понятно, что ограничением ненормализованных реляционных баз данных является обязательность иерархической организации хранимой информации. Конечно, это совсем другой уровень построения информации, чем тот, который поддерживался в дореляционных иерархических системах. Между элементами данных отсутствуют явно проводимые физические ссылки. Упрощена процедура реструктуризации данных (в частности, в ненормализованной реляционной модели предполагается наличие пары операций nest/unnest, позволяющих сделать существующую таблицу элементом, хранимым в столбце другой таблицы, или "вытянуть" на верхний уровень некоторую вложенную таблицу). Тем не менее, общая структура остается иерархической. Во многих случаях этого достаточно (в частности, для решения проблемы, упоминавшегося выше примера Эстер Дайсон).
Однако существуют потребности, выходящие за пределы возможностей иерархических организаций данных. Стандартным примером является необходимость в моделировании сложных объектов, в которые входит один и тот же подобъект. Например, объект "человек" может являться подобъектом объекта
"отдел", подобъектом объекта "семья" и т.д. Для определения требуемых структур недостаточна чисто иерархическая организация, требуется возможность построения сетевых структур. Соответствующее направление получило название "базы данных сложных объектов". Поскольку трудно сказать, насколько сложные структуры потребуются при реальном моделировании предметных областей, должен поддерживаться механизм произвольно сложной структуризации с поддержкой возможности определения структурных типов данных, типов массивов, списков и множеств, а также развитыми средствами использования указателей. Конечно, с учетом опыта реляционных баз данных в базах данных сложных объектов никогда не предполагалось использование адресных указателей физического уровня. Одним из естественных требований было наличие возможности взятия из базы данных произвольно сложного объекта с возможностью его перемещения в другую область внешней памяти или вообще в память другого компьютера. Основной проблемой баз сложных объектов являлось отсутствие простого и мощного интерфейса доступа к данным, хотя бы частично сравнимого с простотой и естественностью реляционных интерфейсов.
Возникновение направления объектно-ориентированных баз данных (ООБД) определялось прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем баз данных не была вполне удовлетворительной. Как мы видели, определенными недостатками обладали и классические реляционные системы, и системы, основанные на ненормализованной реляционной модели, и базы данных сложных объектов.
Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивался как предыдущими работами в области баз данных, так и давно развивающимися направлениями языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
Что касается связи с предыдущими работами в области баз данных, то наиболее сильное влияние на работы в области ООБД оказали проработки реляционных
СУБД и следующего хронологически за ними семейства БД, в которых поддерживалось управление сложными объектами. Эти работы обеспечили структурную основу организации OOБД.
Среди языков и систем программирования наибольшее первичное влияние на ООБД оказал Smalltalk. Этот язык сам по себе не являлся полностью пионерским, хотя в нем была введена новая терминология, являющаяся теперь наиболее распространенной в объектно-ориентированном программировании. На самом деле, Smalltalk основан на ряде ранее выдвинутых концепций.
В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42