|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #04/97
|
|
Исследования и разработки в области систем баз данных были чрезвычайно успешными на протяжении их тридцатилетней истории. Они привели к появлению 10-миллиардной индустрии, обладающей сформировавшимся фундаментом и фактически затрагивающей каждую более или менее важную компанию в мире. Было бы немыслимо управлять большим объемом ценной информации, которую корпорации продолжали бы накапливать без поддержки средствами коммерческих систем управления базами данных (СУБД).
В настоящее время область исследований баз данных в значительной мере определяется ее предыдущими успехами, и большинство проводимых сейчас исследований нацелено на развитие функциональных возможностей и повышение производительности СУБД. СУБД является весьма сложной системой, объединяющей богатое множество технологий. Эти технологии объединялись, исходя из потребностей обеспечения идеальных условий для решения проблем управления крупными объемами данных в корпоративной обстановке. Однако СУБД, как и любой другой крупный инструмент, предъявляет определенные требования к той среде, в которой она используется. Применение СУБД приводит к некоторым эксплуатационным накладным расходам, часто требует достаточно высокого уровня компетентности для установки и сопровождения, позволяет управлять только такими данными, которые представлены в файлах весьма специфических форматов.
В то же время данные, которыми необходимо управлять, радикальным образом изменяются и хранятся в местах, иных чем системы баз данных (например, в файлах). Их получают также в больших объемах из внешних источников, подобных различным датчикам. Несмотря на то, что имеются тенденции построения более мощных систем управления базами данных, существует также и необходимость в управлении данными в ситуациях, при которых являются неприемлемыми накладные расходы полномасштабных СУБД. Во многих случаях требуются значительно более легковесные решения.
Иногда вместо использования существующего инструментария при создании некоторого нового приложения лучше воспользоваться встраиванием повторно используемых компонентов для того, чтобы добиться сокращения времени отклика разрабатываемой системы. В некоторых случаях технология, предусматривающая встраивание инструментария, применяется для того, чтобы обеспечить в наибольшей мере возможности повторного использования. Мы утверждаем, что это наблюдение справедливо для многих новых приложений с повышенными требованиями к управлению данными. Хотелось бы повторно использовать компоненты систем баз данных, но когда это оказывается неуместным, нам следует быть готовыми повторно использовать наши технические приемы и наш опыт новыми способами.
Если теперь рассмотреть ту информацию, которую люди используют, то можно встретить много примеров, в которых бросается в глаза отсутствие систем баз данных. Одним из наиболее впечатляющих примеров является World Wide Web. Хотя справедливо утверждать, что поставщики СУБД делают свои продукты применимыми в среде Web (Web-enable), принятый ими подход состоит в том, чтобы оснастить лучшие Web-серверы. Такая возможность представляет собой лишь весьма небольшой шаг в направлении развития управления огромными объемами нестандартных данных, существующих в Web. Сомнительно, чтобы этот шаг заставил сотни тысяч Web-узлов перейти к использованию функционально полных систем баз данных, ориентированных на рынок обработки деловых данных.
К числу других примеров приложений, в рамках которых можно было бы извлечь пользу из технологий управления данными, но которые обычно в полной мере не используют программных продуктов, предназначенных для систем баз данных, относятся персональные информационные системы, службы новостей и научные приложения. В случае персональных информационных систем можно мыслить лишь об информации, которая хранится в обычной персональной ЭВМ. Электронная почта имеет огромное личное значение для многих пользователей, но когда сохраняются сообщения, они запоминаются чаще всего в файловой системе. Было бы чрезвычайно полезно иметь такие средства СУБД, как индексирование и обработка запросов, доступными для использования в электронной почте. Хотя появляется некоторая поддержка более организованного подхода к хранению и выборке электронной почты (например, в Lotus Notes), более утонченные средства запросов пока еще хорошо не проработаны.
В других недавних отчетах [Gray95, SSU91, SSU95] были охарактеризованы направления исследований в области баз данных, а также великолепно проведена работа по определению приоритетов текущих исследовательских проблем и по установлению новых факторов, связанных с их влиянием на индустрию систем баз данных. В этом отчете решается несколько иная задача - показать, что исследования в области баз данных должны быть посвящены проблемам управления данными, независимо от того, где и в какой форме данные могут находиться. Мы не должны строго ограничиваться сформировавшимся пространством продуктов или широко поддерживаемым мнением о том, что наша работа заключается в управлении очень большими совокупностями структурированных записей в управляемой среде. Вместо этого мы должны использовать наши профессиональные знания для новых сред управления данными, которые потенциально требуют радикально новых подходов к архитектурам программного обеспечения.
Технология баз данных возникла в конце 60-х годов с реализацией IMS, программного продукта компании IBM, который обеспечивал управление данными, организованными в форме иерархий2. Хотя позднее оказалось, что иерархии слишком ограничены, важным вкладом IMS стало широко признанное открытие, констатирующее, что данные имеют самостоятельную ценность и что они должны управляться независимо от какого-либо отдельного приложения. До этого приложения обладали собственными файлами данных, которые часто дублировали данные из других файлов. При использовании СУБД данные не должны логически тиражироваться, что облегчает их поддержку. Для создания совместно используемых баз данных стали необходимыми анализ и проектирование, которое бы балансировало требования множества приложений и тем самым улучшало бы общее управление ресурсами данных.
Модели данных как IMS, так и ее весьма широко известного преемника - CODASYL3, основывались на графовых структурах данных. Хотя идея навигационных связей была интуитивно привлекательной, при ее использовании было трудно выражать взаимодействие с базой данных независимо от существующих алгоритмов, которые были необходимы для реализации таких связей.
В 1970 году Тэд Кодд опубликовал свою историческую статью [Codd70], в которой была показана возможность управления данными на существенно более высоком уровне благодаря их концептуализации в терминах математической теории отношений. Эта статья вызвала большой интерес в научном сообществе в 70-е годы и стремление практически воплотить такой подход. В настоящее время реляционная модель имеет наиболее широкую поддержку среди поставщиков коммерческих СУБД. Благодаря простоте и ясным концептуальным основам реляционной модели вокруг нее развернулись активные теоретические исследования. Исследователями было получено много важных результатов, в том числе, были разработаны теория проектирования баз данных, теория выразимости и сложности языков запросов, а также расширение реляционных языков, названное Datalog. Теоретические разработки продолжаются во многих направлениях, например, исследования ограничений в базах данных и запросов с неполной информацией.
В начале 80-х годов появилась новая модель, которая основывалась на принципах объектно-ориентированного программирования. Объектно-ориентированная модель данных была первой попыткой создания расширяемой модели данных. Для того, чтобы дать пользователям возможность создавать их собственные специфические для конкретных приложений типы, которыми могла бы управлять данная СУБД, использовались механизмы абстракции данных. В последние пять-шесть лет появилось несколько компаний-поставщиков объектно-ориентированных систем управления базами данных, и комитет, сформированный из их представителей, разработал некоторый стандарт (ODMG). Совсем недавно появилась гибридная модель, широко известная как объектно-реляционная модель данных, в которой объектно-ориентированные возможности встраиваются в реляционный контекст.
Использование объектов демонстрировалось также как способ достижения интероперабельности в неоднородных базах данных и модульности в самой СУБД. Объектная модель обеспечивает очень мощный инструментарий для создания интерфейсов, которые не зависят от аспектов представления. Неоднородность в представлениях объектов может быть скрыта благодаря объектно-ориентированной схеме, определенной над фактически хранимыми данными. Модули СУБД могут описываться в объектно-ориентированных терминах, что облегчает их экспорт в другие системы.
Системы управления базами данных имели дело в значительной степени с проблемами производительности, корректности, с возможностями поддержки и надежности. Высокая производительность должна быть достижима даже в тех случаях, когда объем данных оказывается значительно большим, чем вмещается в физическую память, и даже когда данные распределены среди множества машин. Корректность достигается за счет более жестких ограничений целостности (например, целостности по ссылкам) и сериализации транзакций. Возможности поддержки достигаются благодаря разделению логических и физических структур данных, а также с помощью большой коллекции инструментальных средств, призванных облегчить осуществление таких функций, как проектирование базы данных и обеспечение необходимого уровня производительности системы. Наконец, надежность достигается обычно за счет комбинации такого механизма, как журнализация с упреждающей записью, с транзакциями, которые могут поддерживать непротиворечивость данных, невзирая на отказы оборудования и ошибки в исполнении программ.
В исследованиях и разработках систем баз данных указанные проблемы изучались с точки зрения сравнительно медленных устройств памяти, которые должны были совместно использоваться множеством одновременно работающих пользователей. Были также разработаны системы баз данных в контексте, где не имеется какого-либо контроля над выполнением их клиентов. Этот подход привел к созданию множества специальных возможностей и методов, которые могут быть применены и расширены для решения других проблем. Ниже описываются эти возможности и методы.
Моделирование данных. Модель данных состоит из языка для определения структуры базы данных (языка определения данных) и языка для манипулирования этими структурами (языка манипулирования данными, например, языка запросов). Схема определяет конкретную базу данных в терминах языка определения данных. Благодаря удовлетворению требования о том, чтобы все данные описывались схемой, СУБД может обеспечить разделение между хранимыми структурами данных и абстракциями уровня приложений. Такая независимость данных облегчает поддержку, поскольку хранимые структуры могут изменяться, не оказывая какого-либо влияния на приложения.
Хорошая модель данных должна быть достаточно выразительна для того, чтобы охватывать широкий класс приложений, и кроме того должна допускать эффективную реализацию. Несмотря на то, что реляционная модель была доминирующей на протяжении последнего десятилетия, имеются явные признаки появления необходимости в более мощных и гибких моделях. Разработка и использование моделей данных являются важными темами исследований в сообществе специалистов по базам данных, а расширение этих моделей с целью включения в них более претенциозных типов данных, таких как электронные таблицы и потоки видеоданных, является важным направлением для изучения в будущих реализациях.
Языки запросов. Запрос представляет собой программу, которая записывается на языке высокого уровня и обеспечивает поиск данных в базе данных. Структура запроса в системах баз данных относительно проста, что позволяет легко его понимать, автоматически генерировать и оптимизировать. Многие современные языки запросов (например, SQL) являются декларативными, поскольку они выражают, что должно быть возвращено из базы данных, однако, без каких-либо ссылок на структуры хранения или алгоритмы доступа к этим структурам. Так как никакой способ реализации не может быть показан на уровне запроса, процессор запросов свободен в выборе стратегии обработки. Более того, отделение запроса от реализации означает, что структуры хранения могут изменяться, не аннулируя существующих выражений запросов.
Оптимизация и обработка запросов. Реляционные базы данных стали коммерческой реальностью благодаря хорошо продуманным оптимизаторам для реляционных языков запросов и разработке эффективных алгоритмов обработки запросов. Способность компилировать запросы в планы исполнения на основе форм запросов, а также текущих структур хранения на диске, является важной составной частью разработки систем баз данных. Технология оптимизации является особенно важной для поиска и манипулирования данными в тех случаях, когда степень риска выбора неэффективной стратегии является высокой, и всякий раз, когда могут изменяться условия среды, на которых основан планисполнения.
Представления, основанные на состоянии. Возможно определять ограниченные и, может быть, реорганизованные представления базы данных с использованием языка запросов. Такие представления, основанные на состоянии, часто используются для ограничения доступа к данным. Мы можем, например, ограничить использование представления, содержащего среднюю зарплату по отделу, исключив доступ к нему тех отделов, в которых менее трех служащих. В файловых системах санкционирование доступа обычно управляется привилегиями доступа, ассоцируемыми с каждым файлом, независимо от содержания файла.
Управление данными. В системах баз данных всегда уделялось внимание автоматической поддержке структур данных, подобных индексам, и эффективному перемещению данных в и из системных буферов. Обычно такие средства управления данными обладают высокой степенью настраиваемости на конкретные используемые запоминающие устройства. Подобного рода подход, обеспечивающий заботливое использование ресурсов, может быть расширен на другие области, в которых устройства включают такие вещи, как коммуникационные связи и третичную память.
Транзакции. Сообщество баз данных разработало концепцию транзакции в ответ на возникновение проблем корректности, связанных с параллельным доступом и обновлением. Принятие критерия корректности, основанного на атомарности транзакций, упростило программирование, поскольку программист больше не должен был беспокоиться относительно помех, порождаемых другими программами.
Транзакции использовались также в качестве единиц восстановления. После того, как транзакция зафиксирована, гарантируется, что внесенные ею изменения сохраняются даже в случае какого-либо отказа оборудования или ошибки в исполнении программ.
Недавно исследовались также другие более широкие концепции транзакции. Они основываются обычно на задаваемом пользователем понятии корректности.
Распределенные системы. Системы баз данных должны иметь дело с проблемами, возникающими в связи с наличием данных, которые распределены на множестве машин. Протокол двухфазной фиксации позволяет системе сохранять преимущества атомарных транзакций в случае распределенных и, возможно, склонных к отказам деятельностей. К числу других областей, которые подверглись исследованиям в распределенном контексте, относятся обработка запросов, обнаружение тупиковых ситуаций, а также интеграция неоднородных данных.
Масштабируемые системы. Базы данных всегда имели дело с очень большими наборами данных. Системы баз данных настраивались, по большей части, на эффективное и надежное управление такими объемами данных, которые превышают размер физической памяти на несколько порядков. Такой подход использовался, главным образом, по той причине, что системы баз данных с успехом находили применение в реальных коммерческих средах.
Мы не предполагаем, что приведенный список является исчерпывающим. Скорее, он иллюстрирует некоторые важные технологии, которые были созданы специалистами, занимающимися исследованиями и разработками в области баз данных. Исследовались также и другие области, в частности, активные базы данных и "добыча" данных.
В этом разделе мы опишем два приложения технологии баз данных, которые иллюстрируют направления, пропагандируемые нами в данном отчете. Думается, что они являются исключительно многообещающими. Мы полагаем, что представленные здесь возможности показывают характер будущих систем управления базами данных, и технологии, которые будут поддерживать рассматриваемые сценарии, представляют собой содержание исследований на следующее десятилетие.
"Индустриальное виртуальное предприятие" (Industrial Virtual Enterprise, IVE) - это группа компаний, которая не функционирует установленным образом как некая производственная единица, а собирается вместе для того, чтобы отреагировать на заказ клиента или запросить предложения. Характерным примером среды, требующей кооперации типа IVE является автоматизированное интегрированное производство (Computer Integrated Manufacturing, CIM). Среда CIM включает многие специализированные отделы и подсистемы. С технологической стороны в нее входят автоматизированное проектирование, производство и страхование качества. В то же время, управленческая часть включает планирование производства, управление производством, а также управление ресурсами. Перечисленные составляющие подсистемы относятся к различным организациям, каждая из них располагает собственными пользовательским интерфейсом, моделью данных, специализированными операциями и организацией среды хранения.
Во многих областях коммерческой деятельности для компаний, входящих в IVE, необходимо будет обмениваться и на кооперативных началах управлять большими объемами данных. Маловероятно, что информационные системы будут интегрироваться друг с другом в то время, когда принимается решение относительно сотрудничества в продаже или в заявке на торгах. Даже в рамках одной компании с автоматизированным интегрированным производством будет существовать множество неоднородных баз данных. Тем не менее, совместное использование данных и обмен данными между организациями-участниками, а также координация этой информации, являются крайне необходимыми.
Далее мы приведем пример сценария для индустриального виртуального предприятия с автоматизированным интегрированным производством (CIM IVE). Затем примеры из этого сценария будут использованы для иллюстрации тех областей, где применение функциональных возможностей баз данных является необходимым для таких данных, которые в настоящее время не обязательно находятся под контролем СУБД.
Итак, пусть компания A строит нефтяной трубопровод и нуждается для этого проекта в 600 вентилях большого диаметра. Она запросила заявки для торгов, выпустив запрос предложений (Request For Proposal, RFP), специфицирующий размеры, механизм соединения, рабочие температуры, диапазоны давления, требования по устойчивости от коррозии и т.д. Компания инженерного профиля Q имеет намерение создать некоторое IVE для ответа на данный запрос предложений. Инженеры в Q используют Internet для поиска компаний, уже разработавших конструкцию такого рода вентилей, которая может быть использована. Оказалось, что компания R имеет намерение лицензировать такую разработку. Компания Q планирует самостоятельно выполнить работы по модификации предлагаемой конструкции, но будет контактировать с компанией S в части выполнения технологического анализа модифицированной конструкции и трансформации технической документации в производственный план. Компания T берет на себя фактический выпуск изделий, но намерена заключить контракт с компанией U на изготовление пресс-форм и отливку. Наконец, компании V и W также собираются кооперироваться: компания V предоставит услуги по конвертированию файлов технической документации в формате того пакета системы автоматизации проектирования (Computer Aided Design, CAD), который используется компанией R, в формат системы CAD, которую планирует использовать компания Q. В свою очередь, компания W предоставит документацию и услуги по архивированию для таких документов, как инструкция и руководства по эксплуатации.
Теперь мы приведем пример тех видов возможностей баз данных, которые при этом необходимы как на этапе подготовки совместной заявки, так и при выполнении контракта (если будет выигран тендер).
Когда компания Q искала существующие разработки вентилей, она выполняла запрос. Ряд аспектов этого запроса порождает весьма интересные проблемы: некоторые его части основаны на близком, а не на точном соответствии. Запрос касается разработок многих компаний, которые предположительно имеются во многих различных репозитариях. Кроме того, сведения о разработке компании R могут храниться не в среде какой-либо СУБД, а в индивидуальных файлах, для которых может не иметься аналога схемы базы данных. Поиск по сходству требует утонченного индексирования, основанного на многих дескрипторах и векторах свойств большой размерности. Уже этот аспект проблемы побуждает к размышлению. Более того, интересный момент заключается здесь в том, что мы должны обеспечивать запрос и поддержку индексирования на внешних объектах. Какую бы утонченную поддержку индекса мы не изобрели, должны отслеживаться изменения внешних объектов, и индекс должен поддерживать соответствие с ними.
Для того, чтобы компания S могла оценить стоимость технологического анализа и производственных планов, ей необходимо видеть первоначальную техническую документацию, но в форме, которая совместима с ее инструментальными средствами. Таким образом, при подготовке совместной заявки возникает необходимость в услугах по трансляции данных, подобных предоставляемым компанией V. Однако для этого требуется знать формат проектных файлов компании R. Возможно, эти файлы представлены в каком-либо самоописываемом обменном формате, но возможно также и то, что должна быть добавлена какая-либо дескриптивная информация. Часто для описания и для обмена данными продуктов CIM используются такие стандарты, как STEP/EXPRESS5. Однако для того, чтобы дать возможность компании R ограничить выдаваемую информацию некоторым подмножеством схемы, выделенным по принципу "необходимо знать", должны обеспечиваться некоторые дополнительные механизмы. Едва ли можно себе представить, что компания R будет готова сообщить все детали своей разработки только для целей подготовки совместной заявки.
Если IVE, руководимое компанией Q, выигрывает тендер, возникает необходимость в координации и управлении конфигурацией, поскольку первоначальная разработка должна быть сначала модифицирована для того, чтобы она удовлетворяла спецификациям, а затем должна подвергнуться дальнейшей модификации на основе анализа, проведенного компанией S, и обратной связи по результатам работы компаний T и U, связанной с оценкой возможностей производства. Множество зависимостей между данными в различных компаниях IVE должно координироваться (например, должна иметься координация между объектами в различных подсистемах). Должны моделироваться и поддерживаться связи и ограничения целостности (по ссылкам), не требуя при этом, однако, создания традиционной глобальной базы данных. Изменения какого-либо объекта в одной подсистеме требуют изменений в одном или более связанных с ним объектах в других подсистемах. Изменения во внешних системах должны отслеживаться и должны потенциально распространяться на другие системы. Если, например, компания U изменяет шпиндель вентиля, связанная с ним документация вентиля должна быть изменена компанией W. Доступ к сведениям о шпинделе в компании U может быть ограничен до тех пор, пока документация не будет обновлена компанией W. И снова компания U экспортирует информацию только в соответствии с принципом "необходимо знать" (т.е. только информацию, необходимую для указанного обновления документации).
Предположим теперь, что компания Q решает заменить шпиндель t, поставляемый компанией T, шпинделем t" другой компании T', поскольку t" в некотором смысле эквивалентен, но стоит дешевле. Это изменение может стать причиной изменений в конструкциях всех типов вентилей, где использовался t, что приводит в результате к конфликту между маркетинговым решением компании Q и конструкторской деятельностью компании S. Поддержка деятельности по разрешению таких конфликтов имеет важнейшее значение для IVE. Например, в указанном случае должно быть принято решение определить, действительно ли конструкции всех типов вентилей должны измениться, и t" должен использоваться вместо t, либо некоторые конструкции вентилей могут не подвергнуться изменениям, что приводит к необходимости повторных переговоров с компанией T. Отслеживание релевантных изменений и выявление конфликтов - это функциональная возможность систем баз данных, которую следует здесь использовать.
В то время как IVE функционирует, имеется также необходимость в обеспечении безопасности и управления доступом к информации. Возможен, например, такой случай, когда компании R и T являются конкурентами, и поэтому R готова позволить компаниям Q и S видеть первоначальную конструкцию, но не хочет предоставлять к ней доступ для компании T.
Наконец, компания A нуждается в гарантиях, что информация относительно конструкции и производства вентилей будет доступна даже после расформирования IVE. Поэтому, возникает необходимость в архивировании информации, которая, возможно, является независимой от какой-либо из входящих в IVE компаний. Такой архив является базой данных.
Персональные информационные системы - это системы, которые обеспечивают информацию, приспособленную для некоторого индивидуума и доставляемую непосредственно этому индивидууму с помощью портативных персональных информационных устройств (Personal Information Device, PID) таких, как персональные цифровые ассистенты, карманные персональные компьютеры или портативные персональные ЭВМ. PID может либо переноситься индивидуумом, либо перемещаться в автомобиле, и будет оснащаться средствами беспроводного сетевого соединения. Оно будет также располагать сетевыми портами для подключения ("plugging in") в случае, когда доступны стационарные сетевые соединения.
Пользователь, оснащенный PID, сможет в ближайшем будущем иметь доступ к Internet откуда угодно и в любое время. Однако при этом в широком диапазоне будут варьироваться такие характеристики физических связей, как пропускная способность канала связи (от нескольких килобит/сек до нескольких мегабит/сек) и превалирующая частота ошибок. Весьма разнообразными будут также тарифы и схемы оплаты. Некоторые поставщики могут взимать плату за количество пакетов, в то время как другие - за время соединения. Помимо этого, широкий спектр возможностей будут охватывать методы доставки информации - от периодических радиосеансов (через сеть спутников, принудительное избирательное распространение информации и т.д.) до стандартных сценариев в среде клиент-сервер, основанных на запросах. Будут также широко доступны глобальные системы позиционирования, и имеются все основания предполагать, что в ближайшие несколько лет каждая портативная персональная ЭВМ будет оснащена GPS-картой6. Таким образом, местоположение станет важным параметром в селекции информации, особенно для информационных услуг, зависимых от местоположения.
Нам представляется, что персональные информационные услуги должны быть тесно интегрированы с деятельностью индивидуумов от времени утреннего пробуждения, на протяжении повседневной деятельности и до времени отхождения ко сну. Эти услуги будут осуществляться в интересах данного лица, даже во время его сна.
Утром эти услуги могут включать местный прогноз погоды, список напоминаний о специальных событиях текущего дня (например, о днях рождения или годовщинах друзей и родственников), список утренних рабочих совещаний и визитов (например, к зубному врачу), а также предложенную личным медицинским консультантом диету на этот день.
Доставка персональных информационных услуг будет продолжаться, когда данное лицо отправится на работу. PID сможет определить ему лучший маршрут от дома до работы на основе текущих условий трафика с показом ожидаемых задержек в пути на карте города (лучший маршрут может использовать комбинацию личного и общественного транспорта). Оно (PID) может предоставить персонализированный список заголовков новостей из национальных газет, например, "Нью-Йорк таймс", "Уол-Стрит Джорнал", а также заголовки международных сообщений из таких газет, как "Глоб" и "Мейл". По понедельникам предоставляемый отчет будет включать сводку международных спортивных событий за выходные дни (например, об итальянской футбольной лиге). Он может предоставлять персонализированные сведения об инвестициях, содержащие рекомендации по инвестициям на данный день, которые предложены личным финансовым советником. К тому времени, когда данное лицо прибывает на работу, оно полностью осведомлено о представляющих для него интерес событиях и новостях.
Предоставление персональных информационных услуг будет продолжаться в течение всего дня. После прибытия в офис могли бы поступить список задач на день, список покупателей, с которыми нужно связаться, напоминание о необходимости договориться относительно визита к зубному врачу для периодической проверки, сводка объявленных новостей, информация о начале распродажи из местного магазина фурнитуры по конкретному изделию домашней фурнитуры, а также уведомление о приобретении лучшего авиабилета в связи с предстоящим отпуском. Если данному лицу придется в течение дня куда-либо ехать на машине, ему будут предоставлены сведения о лучшем маршруте, которые всегда основаны на текущей информации о трафике.
В конце дня персональная информационная служба предоставит предварительное расписание на следующий день, предложение по балансу личной дневной диеты от личного медицинского консультанта, а также сведения о встречах и делах на следующий день.
PID должно непрерывно издавать запросы к удаленным базам данных и отслеживать широковещательную информацию. Поэтому персонализированные информационные системы значительно обострят сегодняшние проблемы производительности систем с архитектурой клиент-сервер, а также проблемы масштабируемости и надежности. Серверы, которые распространяют ("push") информацию клиентам и отвечают на запросы клиентов ("pull"), будут играть важную роль в доставке персонализированных услуг. Нагрузка на эти серверы потенциально будет значительно большей и запросы будут, вероятно, значительно более утонченными. К числу архитектурных проблем, возникающих в средах, подобных рассмотренным, относится решение таких вопросов, как должны ли данные находиться на PID или на сервере, и какие задачи должны выполнять PID в отличие от сервера.
СУБД обеспечивает строго контролируемую и в высокой степени унифицированную среду. Всякий доступ к данным осуществляется через верхний уровень системы, что позволяет относительно легко контролировать все появления определенного класса событий. Например, легко можно выявлять обновления, и таким образом может быть сделана управляемой поддержка индексов. Формат данных в файлах известен, содержимое буферов данных находится под строгим контролем СУБД, и все хранимые данные соответствуют явнозаданной схеме.
Жизнь становится более сложной, когда мы пытаемся обеспечить функциональные возможности систем баз данных вне границ СУБД. Мы имеем в виду переход к среде, в которой может не быть никакого централизованного контроля и которая может быть в значительной мере не унифицированной. Поэтому здесь нужно специально договариваться относительно соглашений и предположений, которых придерживаются в СУБД и которые могут использоваться ее компонентами. Подобным же образом, унифицированность либо должна обнаруживаться пост-фактум, либо должны быть изобретены новые способы обеспечения функциональных возможностей, которые могут справляться с разнообразием.
Для того, чтобы адекватным образом воплотить те представления, которые отражены в наших сценариях, следует устранить ряд технических препятствий. Эти препятствия обычно являются результатом новых требований приложений, которыми еще не успели заняться ранее, или необходимости новых архитектур СУБД. В данном разделе будут в общих чертах представлены некоторые из этих препятствий.
Современная СУБД является результатом значительных усилий специалистов по разработке программного обеспечения. Для ее создания требуются трудозатраты в сотни человеко-лет и весьма серьезная технологическая база. Управление корпоративной информационной системой без такого инструмента было бы нелепостью. Затраты на создание специализированной СУБД, как правило, являются неоправданными.
Однако многие разработчики приложений отворачиваются от этой сферы индустрии в связи с тем, что современная система баз данных является весьма тяжеловесным ресурсом. Для многих разрабатываемых приложений накладные расходы, связанные с системными требованиями, экспертизой, планированием, трансляцией данных, а также с финансовыми затратами, оказываются слишком значительными. Например, разработчик персонализированной службы обработки газетных материалов может принять решение об отказе от использования СУБД по той причине, что в этом случае нет необходимости во многих из наиболее важных их функциональных возможностей. Для создания рассматриваемой системы представляет интерес лишь фильтрация потоко-ориентированных данных (как это делается, например, в телеграфных службах).
Тем не менее, некоторые подмножества услуг традиционных СУБД оказываются необходимыми для многих новых приложений. Идеальным вариантом было бы предоставление совокупности модулей СУБД таким образом, чтобы можно было их комбинировать для формирования конфигурации, которая была бы в такой мере ограничена в своих возможностях или функционально полна, в какой это необходимо. Например, для телеграфной службы необходимы лишь общая модель данных и основанные на потоках возможности запросов.
Представляющие интерес среды баз данных требуют от нас переосмысления ожиданий, связанных с размерами. Некоторые приложения управляют весьма небольшими базами данных, для которых накладные расходы, связанные с управлением средствами полной СУБД, являются весьма разорительными. Действительно, во многих случаях преимущества СУБД не используются просто потому,что слишком велики накладные расходы.
На другом конце спектра объем данных в будущих приложениях может быть на много порядков выше, чем тот, с которым обычно имеют дело сегодня приложения баз данных. Если мы собираемся помещать информацию в Internet, мы должны быть готовыми, по крайней мере, концептуально к тому, чтобы управлять многими петабайтами данных. Объем этих данных растет с непредсказуемой скоростью, над которой мы не имеем какого-либо контроля.
Число клиентских и серверных узлов также является во много раз большим по сравнению с тем, с которым мы имели дело в какой-либо корпоративной сети. В современных системах с архитектурой клиент-сервер обычно имеется очень малое число серверов (чаще всего, один) для предоставления данных умеренному числу клиентов. В наших сценариях могут иметься сотни или тысячи серверов, а количество клиентов может быть даже еще большим.
Характер распределения в этом новом мире является географически значительно в большей мере рассредоточенным, чем во всех случаях, с которыми мы имели дело до сих пор. Поставщики информации могут находиться где угодно во всем мире. Неограниченное использование узлов в удаленных местах означает, что стоимость доступа к источнику информации может зависеть от предоставляемой пропускной способности входных и выходных каналов связи этих узлов. Такая фактическая пропускная способность может изменяться в зависимости от времени дня и популярности данного узла.
Поскольку все эти параметры порождают большие трудности, связанные с оптимизацией, станет настоятельной необходимостью запрещение больших неограниченных поисков по многим узлам. Вместо этого должна иметься возможность заранее подготавливать большую часть информации, представляющей интерес, и сохранять ее в нескольких наиболее удобных местах.
В сценарии персональных информационных систем ясно, что серверам потребуется иметь дело с количеством запросов, на несколько порядков большим, чем это делают серверы сегодня. Представим себе персональные информационные устройства, установленные в каждом автомобиле, непрерывно запрашивающие информацию от сервера или серверов, географически распределенных в городе. Потребуются разработки устойчивых и масштабируемых серверов, для которых объем обрабатываемых запросов возрастает вместе с объемом доступных ресурсов сервера.
Время от времени будут появляться серверы, которые становятся горячими точками, например, такие как сервер службы спасения 911 или сервер, находящийся поблизости от футбольного стадиона или баскетбольного зала, перегруженный, когда проводится игра. В таких случаях широковещательная, а не двухточечная коммуникация, может быть альтернативой для удовлетворения обычно ожидаемых запросов, снижая в то же время и рабочую нагрузку на сервер. Становится важным понимание того, когда использовать широковещательные коммуникации, как их организовать и как лучше использовать локальную память клиентов.
Стандартная парадигма баз данных предусматривает прежде всего создание схемы базы данных, которая описывает ее структуру, а уже после этого - наполнение базы данных с помощью интерфейса, предоставляемого схемой7. При этом СУБД отображает вводимые данные в фактическую структуру хранения.
Теперь все более часто придется сталкиваться с ситуацией, когда мы не будем иметь такой роскоши, как априорная схема. В настоящее время многие приложения создают данные независимо от какой-либо системы базы данных8 (например, научные приложения), и поскольку информация получается более легким путем для сбора, передачи и хранения, такое несоответствие будет только усиливаться. По этой причине возникает необходимость отображения в схему (и, возможно, в новые структуры хранения) данных, сгенерированных вне системы, пост-фактум. Этот подход "снизу-вверх" к наполнению баз данных не часто поддерживается в современных системах. Тем не менее, весьма важно обеспечить простые механизмы, позволяющие сделать внешние источники данных доступными системам баз данных с тем, чтобы иногда реализовать нечто подобное сценариям IVE. Для обеспечения такой возможности необходимы сложные процедуры отображения данных. Мы ведем здесь речь о создании того, что является, по существу, базоданновым представлением внешних данных, но такое представление должно конструироваться над данными в произвольных форматах.
Может оказаться, что данные, получаемые из какого-либо источника, например, из узла Web, имеют некоторую структуру. Фрагменты текста кодируются тегами, описывающими их роль. К сожалению, использование этих тегов может в значительной степени варьироваться. Тот факт, что на какой-либо одной странице используется тег H3 для заголовков, совсем не обязательно имеет силу для других страниц, и может быть даже из того же самого узла. Такая вариация в использовании кодирования страниц затрудняет конструирование нечто такого, что мы могли бы понимать как схему, которая описывает такие вещи, как Web-страницы.
Более того, когда к таким источникам данных добавляются новые данные, мы можем обнаружить, что схема неполна или несовместима. Поэтому практикуемая в настоящее время жесткость схем баз данных становится препятствием в использовании систем баз данных для удовлетворения потребностей многих информационных систем. Нам необходимы средства управления схемой, которые могут элегантно адаптироваться к динамической природе внешних данных. Кроме того, схема должна допускать различные форматы и различные множества свойств данных, когда они появляются в среде СУБД.
Информация, доступная из территориальной сети, может быть различного качества. Качество имеет отношение к своевременности, полноте и непротиворечивости данных. Информационные системы будущего должны быть способны оценивать качество источника данных и реагировать на него. Источник данных часто будет предоставлять некоторые сведения, касающиеся качества данных. Метаданные, характеризующие качество данных, должны поддерживаться и обрабатываться некоторым способом, который в максимально возможной степени прозрачен для пользователя.
Современная технология баз данных обеспечивает слабые возможности для поддержки и оценки непротиворечивости данных. Поддержка ограничений в коммерческих системах сводится к нескольким простым типам ограничений таким, как уникальность ключа и целостность по ссылке. Даже если бы имелся способ использования какой-либо метрики качества вместе со значениями данных, в существующих системах нет возможности включить его в процесс обработки данных из несопоставимых источников. Так, например, мы могли бы не пожелать, чтобы два значения принимали участие в операции соединения, если их метрики качества значительно отличаются.
Сообщество баз данных осознало некоторое время назад, что данные существуют во многих формах. Для того, чтобы дать возможность приложениям иметь доступ к комбинированным источникам данных некоторым унифицированным способом и с помощью средств высокого уровня, эти разнородные форматы должны быть интегрированы. Однако, автономия информационных узлов не позволяет предписать стандартизацию силами какой-либо централизованной власти.
Представим себе архив событий из газетных материалов, охватывающий последние двадцать лет. Этот архив содержит также дескриптивную информацию, указывающую, когда и где происходили обсуждаемые события, источник статей, автора, а также другие относящиеся к данной теме статьи. Было бы достаточно трудно обеспечить единый интерфейс ко всей этой информации из-за ее полуструктурированного характера. Такая природа данных означает, что их структура является менее унифицированной, чем в случае, с которым мы имеем дело в традиционных СУБД. Например, запросто могут опускаться некоторые поля или они могут иметь изменяющуюся семантику.
Хотя проводилось довольно много исследований, посвященных интеграции данных из неоднородных источников и операциям над ними, программные продукты с такими возможностями только начинают появляться. Нам представляется, что доминирующим подходом является управление распределенными объектами, которое обеспечивается продуктами, поддерживающими CORBA, SOM И OLE. Каждый из этих подходов предоставляет некоторую объектно-ориентированную модель, на которой базируется общий язык описания интерфейсов распределенных объектов. Хотя эти стандарты и поддерживающие их системы прошли долгий путь в интеграции различных систем программного обеспечения, они лучше всего подходят для обеспечения унифицированных синтаксических интерфейсов новых или существующих приложений. Эти подходы обеспечивают общий протокол для передачи сообщений между объектами в распределенной среде, однако в них не предпринимается попыток решить трудную проблему разрешения семантических противоречий. Они не могут быть также использованы для интеграции или создания унифицированных данных из различныхисточников. В общем, утонченный инструментарий для того, чтобы иметь дело с неоднородностью данных, должен тем не менее быть надстройкой над интерфейсами CORBA, SOM или OLE.
Проблема оптимизации запросов принимает в будущих средах совершенно иные черты, в связи с которыми обычные оптимизаторы становятся неадекватными. Во-первых, те типы, которые должны приниматься во внимание в нашем новом мире, включают различные множественные типы, такие как последовательности, деревья и многомерные массивы. Во-вторых, другие типы, которые должны храниться, будут в большой мере ориентированы на приложения. Они будут экземплярами произвольных абстрактных типов данных.
При обычной оптимизации запросов пытаются минимизировать число доступов к дискам. Сетевая оптимизация могла бы базироваться на совсем иных критериях. Например, пользователь мог бы в большей мере быть заинтересованным в получении ответа таким способом, при котором минимизировался бы общий "информационный счет" за обработку этого запроса. Если имеется два источника, каждого из которых достаточно для обработки некоторого запроса, оптимизатор должен найти такой из них, который даст в результате более низкие затраты. Эти затраты могут включать в качестве компонентов стоимость обработки, использования данных и коммуникации.
Оптимизаторам будет также необходимо использовать различные стратегии для учета новых форм данных и характеристик новых компьютерных сред. Стандартные методы оптимизации запросов мало что могут дать для запросов, связанных с большими временными рядами, или для запросов, которые, возможно, должны будут транслировать несколько наборов данных в некоторую каноническую форму перед продуцированием результата. Ситуации, подобные этим, весьма вероятно, могут возникать в сценарии IVE.
Если мы рассмотрим, например, сценарий персональных информационных систем, мы обнаружим необходимость в более гибких методах оптимизации запросов, которые будут принимать во внимание изменения в стоимости широковещательной среды (например, основанной на радио или сотовых коммуникациях) при перемещении PID. Степень детализации или точности, обеспечиваемая сервером, может основываться на величине той суммы, которую желает платить данное лицо. Таким образом, модели оптимизации должны принимать во внимание не только формулировки запросов, но также и описание целей оптимизации. Эти цели могли бы выражаться в терминах расхода ресурсов (например, оптимизировать по критерию минимизации затрат памяти и максимизации использования сети) или в виде ограничений на исполнение, основанных на точности ответа или допустимого расхода ресурсов 9.
Несмотря на то, что имеются огромные достижения, связанные с облегчением установки, управления и использования СУБД, особенно тех, которые работают на персональных компьютерах или рабочих станциях, во многих приложениях все еще предпочитают использовать файловую систему, а не СУБД. Существует молчаливое предположение о том, что с СУБД должен иметь дело хорошо обученный персонал, работающий на полной ставке, и что большинство пользователей баз данных не обладает, однако, какой-либо подготовкой в технологиях баз данных. Пользователи пока еще считают трудным подключение к СУБД, нахождение нужного каталога или имен баз данных, где хранятся данные, а также формулирование запросов и обновления базы данных. Подключение к файловой системе и парадигма доступа является значительно более легкой для понимания. Существенное облегчение использования систем баз данных представляло бы благоприятную возможность для их более распространенного использования.
Если бы такое сложное и критичное по времени приложение, как представленное, например, в сценарии IVE, потребовало бы сложных усилий в части программирования, оно никогда бы не было осуществимым. Вместо этого необходимо простое множество интерфейсов, позволяющих менеджерам индустриального виртуального предприятия специфицировать в терминах высокого уровня требования к таким вещам, как проект требуемого вентиля.
Все процедуры отображения и сопоставления данных из многих распределенных источников, необходимые для нахождения подходящих проектов, должны быть прозрачными для пользователя.
Системы баз данных были бы более легкими для использования, если, например, имелась бы возможность приспосабливать их к интересам отдельного пользователя. В случае персональных информационных систем можно было бы иметь какой-либо способ для сервера принимать во внимание различные персональные профили. Персональные профили могли бы включать маршруты поездок по городу в различное время дня, недели или месяца (например, из дома на работу в утренние и вечерние часы, посещение клиента А в среду и т.д.), местонахождение отделений банка, банкоматов, любимых ресторанов или кинотеатров. Сервер мог бы посылать персональному информационному устройству изменяющуюся во времени информацию, релевантную профилю пользователя, и эту информацию можно было бы показывать на карте города. Благодаря таким возможностям представление базы данных было бы доступно пользователю в форме, легкой для ее использования в решении проблемы управления его распорядком дня.
World Wide Web (WWW) поддерживает быстрый и эффективный доступ к большому числу распределенных взаимосвязанных информационных источников. Поскольку объем совместно используемой информации растет, возникает необходимость ограничить доступ для определенных пользователей или для определенных видов использования. Неунифицированный характер документов в WWW и физическое распределение относящейся к делу информации значительно затрудняют такую защиту.
Модели санкционирования, разработанные для реляционных или объектно-ориентированных систем управления базами данных, по ряду причин не могут быть применены для обеспечения безопасности гипертекстовых документов. Во-первых, в определении подходящей модели санкционирования должна быть ясно определена семантика элементов данных и должны быть указаны всевозможные действия, которые могут выполняться над ними. Определение и семантика концептуальных элементов гипертекстового документа неунифицированы и изменяются от системы к системе. Вторая трудность вытекает из того факта, что "элементы данных" гипертекстового документа семантически не структурированы как в случае данных в системах управления базами данных. Как было показано ранее (раздел 5.3), не имеется также и эквивалента "схемы базы данных". В связи с этим администрирование санкционированием доступа становится более трудным. В-третьих, в модели санкционирования для гипертекста необходимо поддерживать различные уровни гранулярности как в целях повышения производительности, так и для удобства пользователя. Например, должна иметься возможность спецификации санкционирования не только для единичного гипертекстового узла, но и для части узла, таким, однако, способом, чтобы не возникала вынужденная необходимость неестественным образом разбивать такой узел на множество частей.
Управление транзакциями обеспечивает гарантии того, что в результате действий пользователя база данных будет оставаться в допустимом состоянии. Зафиксированные транзакции переводят базу данных из одного допустимого состояния в другое. В противном случае гарантируется, что аварийно завершившаяся транзакция оставит базу данных в состоянии, предшествующем исполнению этой транзакции. Для параллельно работающих пользователей являются видимыми только допустимые состояния базы данных.
Управление транзакциями - это чрезвычайно успешная область с хорошо понятной и надежной теорией, обладающая утонченной техникой для высокопроизводительных реализаций. Ее успехи подтверждаются весьма впечатляющими характеристиками производительности обработки транзакций в существующих программных продуктах для систем баз данных.
Тем не менее, несмотря на успехи, управление транзакциями может стать препятствием как в обеспечении производительности систем, так и для способности специфицировать допустимые исходы транзакций. Сегодняшние подходы к транзакциям связывают воедино атомарность, изолированность и долговременность хранения. Такая взаимосвязь приводит не только к издержкам в части производительности, но и к жесткости в аспекте ее требований к результатам транзакции. Более того, управление транзакциями в настоящее время сосредоточено на аспектах базы данных, и в силу этого большая часть транзакционных данных находится "в трудном положении".
Новые приложения и новые системные среды требуют новой или усовершенствованной технологии управления транзакциями. Для долговременно исполняемых приложений требуется определить приемлемые исходы, более слабые, чем сериализуемость, поскольку ситуации, при которых данные оказываются недоступными в течение долгого периода времени (изоляция), оказываются неприемлемыми. Далее, аварийное завершение полных транзакций перед лицом потенциально неприемлемых исходов, является слишком суровой мерой. Нам необходимо исключить потери полезной работы и освободить конечного пользователя от необходимости иметь дело со случаями неудачно завершившихся транзакций, т.е. транзакций, которые требуют перезапуска.
В настоящее время территориальные сети, главным примером которых является Internet, дают возможность заниматься совместной деятельностью в большой мере изолированным индивидуумам и организациям. Однако существующий стандартный протокол обработки распределенных транзакций (протокол двухфазной фиксации) воздвигает препятствие для участия компонентных систем, поскольку это - протокол блокирования ресурсов, который нарушает автономию участников. Это создает даже еще большую проблему, когда компонентные системы подключаются только перемежающимся образом или если степень их надежности и заслуживаемого доверия весьма изменчива. По этим причинам сегодняшние средства управления транзакциями часто считаются неподходящими для таких современных распределенных приложений, которые обсуждались в разделе 4.
Наряду с перечисленными выше специфическими препятствиями имеются также некоторые барьеры между научными исследованиями и индустрией. Исследователи не обладают достаточными знаниями в области методов и решений, необходимых для индустрии, а индустрия в недостаточной мере использует результаты научных исследований. Усугубляет эти проблемы и монолитная структура СУБД. Каждое усовершенствование оказывает влияние на многие части основного программного кода, и это приводит поставщиков в нерешительность при попытках практического использования находок, сгенерированных академическим сообществом. Исследователи вообще в малой степени понимают такие сложные взаимосвязи. Наконец, многое из коммерчески доступного в технологии баз данных, продиктовано стандартами, в которые мало привносится исследовательским сообществом.
Для того, чтобы добиться практического воплощения наших представлений и преодолеть указанные препятствия, следует заняться рядом центральных исследовательских проблем. Ниже мы перечислим наиболее существенные из них.
Расширяемость и компонентизация. В то время, как в данном отчете высказывается убеждение в том, что компоненты СУБД должны использоваться для обеспечения более легковесной поддержки новых приложений, существует также и связанная с этим необходимость в подходе к конструированию СУБД по модульному принципу. Начинает наблюдаться появление упрощенных средств управления базами данных у некоторых поставщиков, которые начали заниматься этим делом. Даже для таких приложений, которым требуется полная функциональность системы управления базами данных, часто имеется необходимость в расширении этой функциональности средствами поддержки, учитывающими специфику приложения.
Хотя сегодня уже имеются расширяемые СУБД, которые допускают определение новых типов данных (например, абстрактных типов данных) или которые обеспечивают встроенную поддержку для таких новых типов, как текст, пространственные, аудио и видео данные, эти расширения и службы являются доступными лишь с помощью их внутренних специфических способов. Необходимо создать системы, которые дают возможность разработчику легко вводить новые типы данных, порожденных вне данной СУБД, которыми можно манипулировать внутри базы данных наравне с ее собственными полноправными типами. Подобным же образом, нам необходимо найти способы сделать архитектуру СУБД открытой таким образом, чтобы могли подключаться новые функциональные компоненты и чтобы функциональные возможности системы базы данных могли конфигурироваться более гибкими способами, в соответствии с потребностями приложений.
Необходимы также исследования для нахождения способов кооперирования компонентов СУБД с функциональными компонентами, не входящими в СУБД, такими как операционные системы, системы программирования и сетевые инфраструктуры. Так, например, средства обработки запросов и компоненты, обеспечивающие перемещение данных, должны быть способны воспользоваться преимуществами усовершенствованных сетевых средств для того, чтобы согласовать качество услуги и пропускную способность, и взаимодействовать с ними.
Неточные результаты. В сегодняшних СУБД мы ожидаем результы,обладающие стопроцентной точностью. Иначе говоря, мы предполагаем, что существует единственный правильный и полный ответ на запрос. Однако в Web или в других больших информационных источниках эта степень точности может оказаться невозможной или нежелательной. В самом деле, многие поисковые системы для текстового и мультимедийных типов не обеспечивают стопроцентной точности. Были проведены исследования запросов по сходству, но полученные результаты, вообще говоря, выделяются и основываются на особенностях специфических типов данных (например, графических образов, текста). Нет ничего общего для того, чтобы связать воедино специфические для различных типов методы. Нужно разработать общую теорию неточности.
Бессхемные базы данных. Для того, чтобы применить возможностибаз данных к данным, созданным вне СУБД, нам потребуются достаточно сложные средства отображения. В идеале, хотелось бы, чтобы такие инструментальные средства отображения были бы декларативными и, таким образом, комбинируемыми с языком запросов, как это делается в SQL.
Когда структура данных динамически эволюционизирует, трудно удержать ее в рамках фиксированной схемы. Хорошим примером таких данных является Web. Тем не менее, расширения существующей техники баз данных могут быть использованы для запросов и для трансформации такого рода неструктурированных данных.
Легкость использования. Если мы намерены достигнуть такого проникновения в сферу персонального использования вычислительной техники, какое имели другие инструментальные средства, подобные системам электронных таблиц и текстовым процессорам, то для СУБД нужны гораздо лучшие интерфейсы. Мы не можем рассчитывать на то, что пользователь будет писать на SQL. Подобным же образом, важно воплотить теоретические представления в используемых технологиях. Так, например, была разработана теория функциональных зависимостей в реляционных базах данных. Она лежит в основе средств проектирования баз данных многих СУБД для персональных ЭВМ, не вынуждая при этом пользователя быть экспертом в области этой теории.
Новые модели транзакций. Новые модели транзакций дают возможность воплощать определяемые пользователем представленияо корректности и допускают вложенные транзакции. Они часто разделяют атомарность транзакций и изоляцию. Они обычно дают возможность реализовать идеи, подобные семантической сериализуемости и семантической атомарности. Такие модели позволяют специфицировать компенсацию/откат, являющиеся локальными в некоторых пределах. Необходимо разработать механизмы для такого рода моделей, которые поддерживали бы частичные откаты с последующей возможностью перехода вперед к допустимому состоянию, который не только обеспечивает непротиворечивость базы данных, но также и доводит до конца полезную работу для конечного пользователя.
В новых моделях транзакций предприняты попытки преодолеть блокировки в протоколе двухфазной фиксации с тем, чтобы они допускали больше автономии за счет ранних фиксаций, возможно, однако, ценой потенциальных компенсаций. Необходимо исследовать требования к свойствам подсистемы, при удовлетворении которых она может быть включена в такую распределенную транзакцию. Помимо этого, нужно изучить требования к планированию и к корректности, которые могут выходить за традиционные рамки.
Оптимизация запросов. Должны быть расширены средства обработки запросов с тем, чтобы охватывать более широкий состав типов данных, чем те, с которыми имеют дело в сегодняшних коммерческих СУБД. Например, становятся более важными запросы, связанные с последовательностями (в частности, с временными рядами). Оптимизация в случае работы с такими структурами потребует новых методов индексирования и новых стратегий обработки запросов.
К тому же, могут измениться критерии оптимизации. В прошлом оптимизаторы пытались сократить полное время отклика путем сокращения общего расхода ресурсов (в котором доминирует, вероятно, число доступов к диску), требуемых для обработки запроса. Пользователи могут пожелать минимизировать их общие расходы на информацию, используя такие источники, которые являются более дешевыми, но могут иметь гораздо большее время отклика. В иных случаях пользователь может быть в большей мере озабочен точностью и полнотой, чем стоимостью, требуя тем самым, чтобы оптимизатор нашел наиболее надежные и актуальные источники.
Помимо этого, в случае использования мобильных средств вычислительной техники или беспроводных коммуникаций оптимизация запросов должна быть чувствительной к факторам пропускной способности и энергообеспечения. Для того, чтобы достигнуть необходимой пропускной способности, позволяющей доставлять большие объемы данных в мобильную среду, могут потребоваться спутниковые широковещательные коммуникации. В дополнение к этому алгоритмы обработки запросов должны быть способны учитывать вопросы, связанные с потреблением энергии батарей на мобильных компьютерах.
Перемещение данных. В сильно распределенной среде стоимость перемещения данных может быть чрезвычайно высокой. Поэтому оптимальное использование линий коммуникации и кэширования на различных промежуточных узлах становится важным фактором обеспечения эффективности. Хотя эти соображения относятся к оптимизации распределенных запросов, мы должны здесь принимать во внимание модели полного доступа в системе, а не ограничиваться рассмотрением обработки единственного запроса. Необходимо также учитывать существование асимметричных коммуникационных каналов, используемых в случае линий с низкой пропускной способностью и/или высоко загруженных серверов.
Безопасность. К числу проблем, связанных с управлением доступом в распределенных гипертекстовых системах, относятся:
"Добыча" данных в базах данных. "Добыча" данных является другой быстро прогрессирующей областью исследований, которую также можно считать нетрадиционной. Она основана на совместном использовании машинного обучения, статистического анализа и технологий баз данных. Такие поисковые задачи, как генерация правил (ассоциаций правил), классификация и группирование, могут рассматриваться как случайные запросы, для которых необходимы новые семейства языков запросов. Обработка таких запросов требует использования индуктивных алгоритмов машинного обучения на больших базах данных. К числу исследовательских задач в этой области относится разработка адекватного набора простых примитивов запросов и нового поколения методов оптимизации запросов.
Решение проблем в какой-либо из названных выше областей будет также оказывать положительное влияние на внедрение новых технологий. Например, расширяемость даст возможность использовать в системах баз данных совершенно новые, пока еще не разработанные подходы к индексированию, не оказывая при этом какого-либо влияния на другие компоненты существующих СУБД. Кроме того, сообщество исследователей должно принимать более активное участие в деятельности, связанной со стандартизацией, и сформировать более тесные партнерские отношения с индустрией.
В этом отчете мы показали, что исследования в области баз данных должны проводится в более широких границах, чем это было в прошлом. Обсуждалась идея о том, что сообщество специалистов по базам данных должно использовать свои опыт и знания в новых проблемных областях, что потребует, вероятно, новых решений, реализованных такими способами, которые не похожи на используемые в существующих системах баз данных.
Относительно долговременной перспективы представляется, что сообщество специалистов по базам данных может внести существенный вклад в решение таких весьма важных проблем, как масштабируемость, эффективность и надежность информационных систем. Информация должна определяться в более широких терминах, позволяющих включать большое разнообразие семантических типов, которые существуют во многих формах. Мы предвидим появление технологий, обеспечивающих поддержку приложений функциональности баз данных путем интеграции небольших модулей, которые предоставляют в точности необходимые возможности. Такие модули должны также воплощать унифицированную теорию информации, которая дает возможность запрашивать информацию любых типов без необходимости переключения языков или парадигм.
Редакторы хотели бы подчеркнуть, что этот отчет был подготовлен на основе обсуждений, замечаний и непосредственного вклада членов рабочей группы. Мы хотели бы также высказать благодарность Дэвиду ДеВитту, Джиму Грею, Гейлу Митчелу и Питеру Вегнеру за полезные замечания по ранним версиям этого отчета.
*) В июне 1996 года Лаборатория информатики Массачусетского технологического института (США) при поддержке ACM, National Science Foundation и ряда других организаций провела симпозиум "Strategic Directions in Computing Research". На симпозиуме были представлены обзорные доклады о стратегических направлениях развития практически по всем крупным разделам информатики. Для подготовки докладов было создано более двух десятков рабочих групп, в состав которых вошли известные специалисты в соответствующей области. Предлагаемая читателю статья представляет собой отчет, подготовленный рабочей группой по базам данных под редакцией авторов. От этой рабочей группы в симпозиуме участвовали Д.Блейкли, П.Бунеман, У.Дейал, Т.Имилинский, С.Джаджодиа, Х.Корс, Г.Ломан, Д.Ломэ, Д.Майер, Ф.Манола, Т.Озу, Р.Рамакришнан, К.Рамамритен, Х.Шек, А.Зильбершац (сопредседатель), Р.Снодграсс, Д.Ульман, Д.Видом и С.Здоник (сопредседатель). Материалы симпозиума были опубликованы в упомянутом выше специальном выпуске журнала ACM Computing Surveys, v.28, no.4, December 1996. - Прим. пер.
1) Avi Silbershatz (Bell Laboratories), Stan Zdonik (Brown University). Database Systems - Breacking Out of the Box. SIGMOD Record, v.26, no.3, September 1997. (С) Пер. с англ. М.Р.Когаловского. Первоначально статья была напечатана в посвященном 50-летию ACM специальном выпуске журнала ACM Computing Surveys, v.28, no.4, December 1996. Переведено с разрешения ACM (c) 1997 ACM, Inc.
2) Вряд ли можно согласиться с этим мнением авторов. Хотя создание системы IMS (1969 год) действительно было значительным событием в становлении технологии баз данных, однако, еще до появления этой системы был осуществлен ряд других весьма значимых разработок в этой области. В частности, примерно за шесть лет до выпуска IMS была реализована система IDS (Integrated Data Storage), ставшая прототипом подхода CODASYL, оставившего не менее глубокий след в технологии баз данных, чем создание системы IMS. Руководитель этой разработки - Ч.Бахман - стал впоследствии лауреатом премии Тьюринга за работы в области систем баз данных, основанных на подходе CODASYL. Описание возможностей системы IDS и ряда других ранних СУБД можно найти в изданном в русском переводе техническом отчете Системного комитета CODASYL 1971 года "Feature Analysis of Generalized Data Base Management Systems" (см. Информационные системы общего назначения. Пер. с англ. - М.: Статистика, 1975). Нужно упомянуть также, что еще в 1963 и в 1965 годах компания System Development Corporation (США) провела два симпозиума по управлению базами данных, где были представлены конкретные реализованные проекты систем баз данных. Таким образом, технология баз данных возникла еще задолго до появления системы IMS. - Прим. пер.
3) Здесь мы снова вынуждены возразить авторам. Подход CODASYL вовсе не является преемником IMS. В идейном плане он, как уже мы указывали, скорее, последователь идей системы IDS (см. предыдущую сноску). Кроме того, авторы противоречат и хронологии событий. Первая версия системы IMS была выпущена компанией IBM в 1969 году. Первый отчет CODASYL DBTG, содержащий не только основные концепции предложенного DBTG подхода (кстати говоря, существенно более продвинутого, с архитектурной точки зрения, по сравнению с IMS), но и начальный вариант спецификаций языка определения данными схемы, а также языка манипулирования данными и языка определения данных подсхемы для включающего языка COBOL, был опубликован также в 1969 году. Таким образом, эти работы проводились, по крайней мере, одновременно. - Прим. пер.
4) В оригинале дважды повторена опечатка. Вместо "Industrial Virtual Enterprise" (индустриальное виртуальное предприятие), о котором в этом разделе работы идет речь, в тексте указано "Instant Virtual Enterprise". - Прим. пер.
5) STEP и EXPRESS - это представители ряда протоколов, которые имеют статус индустриальных стандартов, принятых NIIIP (The National Industrial Information Infrastructure Protocol). Этот консорциум был образован в 1994 году с целью разработки и исследования протоколов, необходимых для поддержки индустриальных виртуальных предприятий. - Прим. пер.
6) Технология глобальных систем позиционирования (Global Positioning System, GPS) активно развивается в настоящее время. Она основана на спутниковых системах, генерирующих и посылающих абонентам специальные сообщения, позволяющие с высокой точностью определять их географическое местоположение. Абонентом такой системы может быть пользователь мобильного компьютера, персонального цифрового помощника или другого вычислительного устройства, оснащенного принимающей и интерпретирующей спутниковые сообщения GPS-картой и специальным программным обеспечением. При этом абонент может находиться в любом месте и пользоваться услугами системы в любое время. GPS-технологии становятся чрезвычайно важными в судовождении, авиации и других сферах. С ними связывают также большие перспективы в мобильных информационных системах, о которых здесь говорят авторы. - Прим. пер.
7) Не следует здесь понимать авторов буквально. Схема базы данных вовсе не предоставляет никакого интерфейса. Она является дескриптивным компонентом системы базы данных и используется средствами системных интерфейсов для интерпретации.
8) Такая ситуация является главной причиной того, что большие компоненты этих приложений сегодня вообще не используют систем баз данных.
9) Обратим внимание на допущенную авторами неточность. Спецификация цели (критерия) является необходимым компонентом постановки задачи на оптимизацию. При этом, естественно, могут задаваться и какие-либо ограничения. Однако, ограничения никаким образом не являются выражением цели оптимизации, а выполняют функцию задания области поиска оптимума. - Прим. пер.
|
|