Безопасность
Всемирная Паутина поддерживает быстрый и эффективный доступ к большому числу распределенных взаимосвязанных информационных источников. Поскольку объем совместно используемой информации растет, возникает потребность в ограничении доступа для определенных пользователей или для определенных видов использования. Неунифицированный характер документов в WWW и физическое распределение относящейся к делу информации значительно затрудняют такую защиту.
Модели авторизации, разработанные для реляционных или объектно-ориентированных систем управления базами данных, по ряду причин не могут быть применены для обеспечения безопасности гипертекстовых документов. Во-первых, в определении подходящей модели авторизации должна быть ясно определена семантика элементов данных, и должны быть указаны возможные действия, которые могут выполняться над ними. Определение и семантика концептуальных элементов гипертекстового документа не унифицированы и изменяются от системы к системе.
Вторая трудность вытекает из того факта, что "элементы данных" гипертекстового документа не являются такими систематически структурированными, как данные в системах управления базами данных. Как отмечалось ранее (), не имеется также и эквивалента "схемы базы данных". В связи с этим администрирование санкционированием доступа становится более трудным.В-третьих, в модели авторизации для гипертекста требуется поддерживать различные уровни гранулярности как в целях повышения производительности, так и для удобства пользователя. Например, должна иметься возможность спецификации авторизации не только для единичного гипертекстового узла, но и для части узла таким способом, чтобы не возникала вынужденная необходимость неестественным образом разбивать такой узел на несколько частей.
Что мы умеем?
Системы управления базами данных имели дело в значительной степени с проблемами производительности, корректности, с возможностями поддержки и надежности. Высокая производительность должна быть достижима даже в тех случаях, когда объем данных оказывается значительно большим, чем вмещается в физическую память, и даже когда данные распределены между несколькими машинами. Корректность достигается за счет поддержки ограничений целостности (например, целостности по ссылкам) и сериализации транзакций. Возможности поддержки достигаются благодаря разделению логических и физических структур данных, а также с помощью большого набора инструментальных средств, призванных облегчить осуществление таких функций, как проектирование базы данных и обеспечение необходимого уровня производительности системы. Наконец, надежность достигается обычно за счет комбинации такого механизма, как журнализация с упреждающей записью, с транзакциями, которые могут поддерживать согласованность данных, невзирая на отказы оборудования и ошибки в исполнении программ.
В исследованиях и разработках систем баз данных указанные проблемы изучались с точки зрения сравнительно медленных устройств памяти, которые должны были совместно использоваться множеством одновременно работающих пользователей. Были также разработаны системы баз данных в контексте, где не имеется какого-либо контроля над выполнением их клиентов. Этот подход привел к созданию множества специальных приемов и методов, которые могут быть применены и расширены для решения других проблем. Ниже описываются эти приемы и методы.
Моделирование данных. Модель данных состоит из языка определения структуры базы данных (языка определения данных) и языка манипулирования этими структурами (языка манипулирования данными, например, языка запросов). Схема определяет конкретную базу данных в терминах языка определения данных. Благодаря удовлетворению того требования, чтобы все данные описывались схемой, СУБД может обеспечить разделение между хранимыми структурами данных и абстракциями уровня приложений.
Такая независимость данных облегчает поддержку, поскольку хранимые структуры могут изменяться, не оказывая какого-либо влияния на приложения.
Хорошая модель данных должна быть достаточно выразительна для того, чтобы охватывать широкий класс приложений, и, кроме того, должна допускать эффективную реализацию. Несмотря на то, что реляционная модель была доминирующей на протяжении последнего десятилетия, имеются явные признаки потребности в более мощных и гибких моделях. Разработка и использование моделей данных являются важными темами исследований в сообществе специалистов по базам данных, а расширение этих моделей с целью включения в них более сложных типов данных, таких как электронные таблицы и потоки видеоданных, является важным направлением исследований для построения будущих реализациий.
Языки запросов. Запрос представляет собой программу, которая записывается на языке высокого уровня и обеспечивает выборку данных из базы данных. Структура запроса к базе данных относительно проста, что позволяет легко его понимать, автоматически генерировать и оптимизировать. Многие современные языки запросов (например, SQL) являются декларативными, поскольку они выражают, что должно быть возвращено из базы данных, без каких-либо ссылок на структуры хранения или алгоритмы доступа к этим структурам. Поскольку на уровне запроса не может указываться какой-либо способ его реализации, процессор запросов свободен в выборе стратегии обработки. Более того, отделение запроса от реализации означает, что структуры хранения могут изменяться, не приводя к недействительности существующих выражений запросов.
Оптимизация и обработка запросов. Реляционные базы данных стали коммерческой реальностью благодаря хорошо продуманным оптимизаторам реляционных языков запросов и разработке эффективных алгоритмов обработки запросов. Способность компилировать запросы в планы исполнения на основе форм запросов, а также текущих структур хранения на диске, является важной составной частью разработки систем баз данных.
Технология оптимизации является особенно важной для выборки данных и манипулирования ими в тех случаях, когда степень риска выбора неэффективной стратегии является высокой, и всякий раз, когда могут изменяться условия среды, на которых основан план исполнения.
Представления, основанные на состоянии. C использованием языка запросов можно определять ограниченные и, может быть, реорганизованные представления базы данных. Такие представления, основанные на состоянии, часто используются для ограничения доступа к данным. Мы можем, например, ограничить использование базы данных представлением, содержащим средние значения зарплаты по отделам, исключив из него отделы, в которых работает менее трех служащих. В файловых системах авторизация доступа обычно основывается на привилегиях доступа, ассоцируемыми с каждым файлом, независимо от его содержимого.
Управление данными. В системах баз данных всегда уделялось особое внимание автоматической поддержке структур данных, подобных индексам, и эффективному перемещению данных в системные буфера и из них. Обычно эти средства управления данными хорошо настраиваются на конкретные используемые запоминающие устройства. Такой подход к бережному использованию ресурсов может быть расширен на другие области, в которых в состав устройств включают, например, линии связи и третичная память.
Транзакции. Сообщество баз данных разработало концепцию транзакции в ответ на возникновение проблем корректности, связанных с параллельным доступом и обновлением. Принятие критерия корректности, основанного на атомарности транзакций, упростило программирование, поскольку программист больше не должен беспокоиться относительно помех, порождаемых другими программами.
Транзакции используются также в качестве единиц восстановления. После того, как транзакция зафиксирована, гарантируется, что внесенные ею изменения сохраняются даже в случае какого-либо отказа оборудования или ошибки в исполнении программ.
В последнее время исследуются также и другие, ослабленные концепции транзакций.
Обычно они основываются на понятии корректности, задаваемом пользователями.
Распределенные системы. Системы баз данных должны иметь дело с проблемами, возникающими в связи с наличием данных, которые распределены между несколькими машинами. Протокол двухфазной фиксации (two-phase commit) позволяет системе сохранять преимущества атомарных транзакций при наличии распределенных и, возможно, ненадежных активностей. К числу других областей, исследовавшихся в распределенном контексте, относятся обработка запросов, обнаружение тупиковых ситуаций, а также интеграция неоднородных данных.
Масштабируемые системы. Базы данных всегда имели дело с очень большими наборами данных. Системы баз данных настраивались, по большей части, на эффективное и надежное управление такими объемами данных, которые превышают размер физической памяти на несколько порядков. Такой подход использовался, главным образом, по той причине, что системы баз данных с успехом находили применение в реальных коммерческих средах.
Мы не считаем приведенный список исчерпывающим. Скорее, он иллюстрирует некоторые важные технологии, которые были созданы специалистами, занимающимися исследованиями и разработками в области баз данных. Исследовались также и другие области, в частности, активные базы данных и интеллектуальный анализ данных (data mining).
1
В июне 1996 года Лаборатория информатики Массачусетского технологического института (США) при поддержке ACM, National Science Foundation и ряда других организаций провела симпозиум "Strategic Directions in Computing Research". На симпозиуме были представлены обзорные доклады о стратегических направлениях развития практически по всем крупным разделам информатики. Для подготовки докладов было создано более двух десятков рабочих групп, в состав которых вошли известные специалисты в соответствующей области. Предлагаемая читателю статья представляет собой отчет, подготовленный рабочей группой по базам данных под редакцией авторов. От этой рабочей группы в симпозиуме участвовали Х.Блейкли (Jose Blakeley), П.Бунеман (Peter Buneman), У.Дайал (Umesh Dayal), Т.Имилинский (Tomasz Imielinski), С.Джаджодиа (Sushil Jajodia), Х.Корт (Hank Korth), Г.Лохман (Guy Lohman), Д.Ломе (Dave Lomet), Д.Майер (Dave Maier), Ф.Манола (Frank Manola), Т.Озу (Tamer Ozsu), Р.Рамакришнан (Raghu Ramakrishnan), К.Рамамритан (Krithi Ramamritham), Х.Шек (Hans Scheck), А.Зильбершац (Avi Silberschatz, сопредседатель), Р.Снодграсс (Rick Snodgrass), Д.Ульман (Jeff Ullman), Д.Вайдом (Jennifer Widom) и С.Здоник (Stan Zdonik, сопредседатель).
Материалы симпозиума были опубликованы в специальном выпуске журнала ACM Computing Surveys, v.28, no.4, December 1996. – Прим. пер.
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 году.Таким образом, эти работы проводились, по крайней мере, одновременно. – Прим. пер.
Гарантирование допустимых последствий
Управление транзакциями обеспечивает гарантии того, что в результате действий пользователя база данных будет оставаться в допустимом состоянии. Зафиксированные транзакции переводят базу данных из одного допустимого состояния в другое. В противном случае гарантируется, что аварийно завершившаяся транзакция оставит базу данных в состоянии, предшествующем исполнению этой транзакции. Для параллельно работающих пользователей являются видимыми только допустимые состояния базы данных.
Управление транзакциями – это чрезвычайно успешная область с хорошо понятной и надежной теорией, обладающая усложненными методами для высокопроизводительных реализаций. Ее успехи подтверждаются весьма впечатляющими характеристиками производительности обработки транзакций в существующих программных продуктах управления базами данных.
Тем не менее, несмотря на успехи, управление транзакциями может стать препятствием как в обеспечении производительности систем, так и для способности специфицировать допустимые последствия транзакций. Сегодняшние подходы к транзакциям связывают воедино атомарность, изолированность и долговременность хранения. Такая взаимосвязь приводит не только к издержкам в части производительности, но и к жесткости в аспекте ее требований к результатам транзакции. Более того, управление транзакциями в настоящее время ориентированно на работу с базами данных, т.е. большая часть транзакционных данных находится "в футляре".
Новые приложения и новые системные среды требуют новой или усовершенствованной технологии управления транзакциями. Для долговременно исполняемых приложений требуется определить приемлемые последствия, более слабые, чем сериализуемость, поскольку ситуации, при которых данные оказываются недоступными в течение долгого периода времени (изоляция), оказываются неприемлемыми. Кроме того, аварийное завершение полных транзакций перед лицом потенциально неприемлемых последствий является слишком суровой мерой. Нам необходимо исключить потери полезной работы и освободить конечного пользователя от необходимости иметь дело со случаями неудачно завершившихся транзакций, т.е. транзакций, для которых требуется повторное выполнение.
В настоящее время территориально распределенные сети, важнейшим примером которых является Internet, дают возможность заниматься совместной деятельностью в значительной степени изолированным индивидуумам и организациям. Однако существующий стандартный протокол обработки распределенных транзакций (протокол двухфазной фиксации) воздвигает препятствие для участия систем-компонентов, поскольку это – протокол блокирования ресурсов, который нарушает автономию участников. Это создает даже еще большую проблему, когда системы-компоненты подключаются только периодически, или если степень их надежности и заслуживаемого доверия весьма изменчива. По этим причинам сегодняшние средства управления транзакциями часто считаются неподходящими для таких современных распределенных приложений, которые обсуждались в .
Исследования
Чтобы добиться практического воплощения наших представлений и преодолеть указанные препятствия, следует заняться рядом центральных исследовательских проблем. Ниже мы перечислим наиболее существенные из них.
Расширяемость и компонентизация. В то время, как в данном отчете высказывается убеждение в том, что компоненты СУБД должны использоваться для обеспечения более легковесной поддержки новых приложений, существует также и связанная с этим необходимость в подходе к конструированию СУБД по модульному принципу. Начинает наблюдаться появление упрощенных средств управления базами данных у некоторых поставщиков, которые начали заниматься этим делом. Даже для тех приложений, которым требуется полная функциональность системы управления базами данных, часто требуются расширения этой функциональности средствами поддержки, учитывающими специфику приложения.
Хотя сегодня уже имеются расширяемые СУБД, которые допускают определение новых типов данных (например, абстрактных типов данных) или обеспечивают встроенную поддержку для таких новых типов, как текст, пространственные, аудио- и видеоданные, эти расширения и службы являются доступными лишь с помощью внутренних проприетарных способов. Необходимо создать системы, которые дают возможность разработчику легко вводить новые типы данных, разработанные вне данной СУБД, которыми можно манипулировать внутри базы данных наравне с ее собственными полноправными типами. Подобным же образом, нам необходимо найти способы сделать архитектуру СУБД открытой таким образом, чтобы могли подключаться новые функциональные компоненты, и чтобы функциональные возможности системы базы данных могли конфигурироваться более гибкими способами в соответствии с потребностями приложений.
Необходимы также исследования для нахождения способов кооперирования компонентов СУБД с функциональными компонентами, не входящими в СУБД, такими как операционные системы, системы программирования и сетевые инфраструктуры. Так, например, средства обработки запросов и компоненты, обеспечивающие перемещение данных, должны получить возможность пользоваться преимуществами усовершенствованных сетевых средств, чтобы согласовать качество обслуживания и пропускную способность, и взаимодействовать с ними.
Неточные результаты. В сегодняшних СУБД мы ожидаем результы, обладающие стопроцентной точностью. Иначе говоря, мы предполагаем, что существует единственный правильный и полный ответ на запрос. Однако в Web или в других больших информационных источниках этот уровень точности может оказаться невозможным или нежелательным. В самом деле, многие поисковые системы для текстового и мультимедийных типов не обеспечивают стопроцентной точности. Были проведены исследования запросов по сходству, но полученные результаты, вообще говоря, являются изолированными и основываются на особенностях конкретных типов данных (например, графических образов, текста). Нет ничего такого, что позволило бы связать воедино методы, специфичные для различных типов. Нужно разработать общую теорию неточности.
Бессхемные базы данных. Чтобы применить средства баз данных к данным, созданным вне СУБД, нам потребуются достаточно сложные средства отображения. В идеале, хотелось бы, чтобы такие инструментальные средства отображения были бы декларативными и, таким образом, комбинируемыми с языком запросов, как это делается в SQL.
Когда структура данных динамически эволюционизирует, трудно удержать ее в рамках фиксированной схемы. Хорошим примером таких данных является Web. Тем не менее, расширения существующей техники баз данных могут быть использованы для запросов и для трансформации такого рода неструктурированных данных.
Простота использования. Если мы намерены достигнуть такого проникновения в сферу персонального использования вычислительной техники, какое имеют другие инструментальные средства, подобные системам электронных таблиц и текстовым процессорам, то для СУБД нужны гораздо лучшие интерфейсы. Мы не можем рассчитывать на то, что пользователь будет писать на SQL. Подобным же образом, важно воплотить теоретические представления в используемых технологиях. Так, например, в теории реляционных баз данных был разработан механизм функциональных зависимостей. Они лежат в основе средств проектирования баз данных многих СУБД для персональных ЭВМ, не вынуждая при этом пользователя быть экспертом в области этой теории.
Новые модели транзакций. Новые модели транзакций допускают определяемые пользователем представления о корректности и вложенные транзакции. В них часто разделяются атомарность и изоляция. Они обычно допускают возможности семантической сериализуемости и семантической атомарности. Такие модели позволяют специфицировать компенсацию/откат, являющиеся локальными в некоторых пределах. Требуется разработать механизмы для такого рода моделей для поддержки частичных откатов с последующей возможностью перехода вперед к допустимому состоянию, которые не только обеспечивает согласованность базы данных, но также и выполняют полезную работу для конечного пользователя.
В новых моделях транзакций предпринимаются попытки преодолеть блокировки в протоколе двухфазной фиксации с тем, чтобы они допускали больше автономии за счет ранних фиксаций, возможно, ценой потенциальных компенсаций. Требуется исследовать требования к свойствам подсистемы, при удовлетворении которых она может быть включена в такую распределенную транзакцию. Помимо этого, нужно изучить требования к планированию и к корректности, которые могут выходить за традиционные рамки.
Оптимизация запросов. Должны быть расширены средства обработки запросов с тем, чтобы охватывать более широкий состав типов данных, чем те, с которыми имеют дело сегодняшние коммерческие СУБД. Например, становятся более важными запросы, связанные с последовательностями (например, с временными рядами). Оптимизация при работе с такими структурами потребует новых методов индексирования и новых стратегий обработки запросов.
К тому же, могут измениться критерии оптимизации. В прошлом оптимизаторы пытались сократить полное время отклика путем сокращения общего расхода ресурсов (в котором доминирует, вероятно, число доступов к диску), требуемых для обработки запроса. Пользователи могут пожелать минимизировать их общие расходы на информацию, используя такие источники, которые являются более дешевыми, но могут иметь гораздо большее время отклика. В иных случаях пользователь может быть в большей мере озабочен точностью и полнотой, чем стоимостью, требуя тем самым, чтобы оптимизатор нашел наиболее надежные и актуальные источники.
Помимо этого, при использования мобильного или беспроводного компьютинга оптимизация запросов должна быть чувствительной к факторам пропускной способности и энергопотребления. Чтобы достигнуть необходимой пропускной способности, позволяющей доставлять большие объемы данных в мобильную среду, могут потребоваться спутниковые широковещательные коммуникации. Кроме того, в алгоритмах обработки запросов должны учитываться вопросы, связанные с потреблением энергии батарей мобильных компьютеров.
Перемещение данных. В сильно распределенной среде стоимость перемещения данных может быть чрезвычайно высокой. Поэтому оптимальное использование линий коммуникации и кэширования на различных промежуточных узлах становится важным фактором обеспечения эффективности. Хотя эти соображения относятся к оптимизации распределенных запросов, мы должны здесь принимать во внимание модели полного доступа в системе, а не ограничиваться рассмотрением обработки единственного запроса. Необходимо также учитывать существование асимметричных коммуникационных каналов, используемых в случае линий с низкой пропускной способностью и/или высоко загруженных серверов.
Безопасность. К числу проблем, связанных с управлением доступом в распределенных гипертекстовых системах, относятся:
формулирование модели авторизации доступа; расширение этой модели для того, чтобы принять во внимание аспекты распределенности; интероперабельность между различными стратегиями безопасности и изыскание стратегий управления доступом, основанных на мандатах.
Интеллектуальный анализ данных в базах данных. Интеллектуальный анализ данных (data mining) является другой быстро прогрессирующей областью исследований, которую также можно считать нетрадиционной. Она основана на совместном использовании машинного обучения, статистического анализа и технологий баз данных. Такие поисковые задачи, как генерация правил (ассоциаций правил), классификация и группирование, могут рассматриваться как случайные запросы, для которых необходимы новые семейства языков запросов.Обработка таких запросов требует использования индуктивных алгоритмов машинного обучения на больших базах данных. К числу исследовательских задач в этой области относится разработка адекватного набора простых примитивов запросов и нового поколения методов оптимизации запросов.
Решение проблем в какой-либо из названных выше областей будет также оказывать положительное влияние на внедрение новых технологий. Например, расширяемость даст возможность использовать в системах баз данных совершенно новые, пока еще не разработанные подходы к индексированию, не оказывая при этом какого-либо влияния на другие компоненты существующих СУБД. Кроме того, сообщество исследователей должно принимать более активное участие в деятельности, связанной со стандартизацией, и сформировать более тесные партнерские отношения с индустрией.
Качество данных
Информация, доступная из территориально распределенной сети, может быть различного качества. Качество имеет отношение к своевременности, полноте и согласованности данных. Информационные системы будущего должны быть способны оценивать качество источника данных и реагировать на него. Источник данных часто будет предоставлять некоторые сведения, касающиеся качества данных. Метаданные, характеризующие качество данных, должны поддерживаться и обрабатываться некоторым способом, который в максимально возможной степени прозрачен для пользователя.
Современная технология баз данных обеспечивает слабые возможности для поддержки и оценки согласованности данных. Поддержка ограничений в коммерческих системах сводится к нескольким простым типам ограничений, таким как уникальность ключа и целостность по ссылкам. Даже если бы имелся способ использования каких-либо показателей качества вместе со значениями данных, в существующих системах нет возможности включить его в процесс обработки данных из разрозренных источников. Так, например, можно было бы не захотеть, чтобы два значения принимали участие в операции соединения, если их показатели качества значительно отличаются.
Литература
[Codd70] E. F. Codd. "A Relational Model for Large Shared Databanks", Communications of the ACM, 13:6, (June 1970), pp. 377-387. Есть русский перевод: Е.Ф. Кодд. . [Gray95] J. Gray. Database Systems: A Textbook Case of Research Paying Off. [SSU91] A. Silberschatz, M. Stonebraker, and J. Ullman.
Database Systems: Achievements and Opportunities. SIGMOD Record, 19:4, pp. 6-22. Also in CACM, 34:10 (Oct., 1991), pp. 110-120. [SSU95] A. Silberschatz, M. Stonebraker, and J. Ullman. Database Systems: Achievements and Opportunities Into the 21st Century. Есть русский перевод: Ави Зильбершатц, Майкл Стоунбрейкер, Джефф Ульман. Базы данных: достижения и перспективы на пороге 21-го столетия, СУБД, 3, 1996, с. 103-117.
Масштаб
Представляющие интерес среды баз данных требуют от нас переосмысления ожиданий, связанных с размерами. Некоторые приложения управляют весьма небольшими базами данных, для которых накладные расходы, связанные с управлением средствами полной СУБД, являются весьма разорительными. Действительно, во многих случаях преимущества СУБД не используются просто потому,что слишком велики накладные расходы.
На другом конце спектра объем данных в будущих приложениях может быть на много порядков выше, чем тот, с которым обычно имеют дело сегодня приложения баз данных. Если мы собираемся помещать информацию в Internet, мы должны быть готовыми, по крайней мере, концептуально к тому, чтобы управлять многими петабайтами данных. Объем этих данных растет с непредсказуемой скоростью, над которой мы не имеем никакого контроля.
Число клиентских и серверных узлов также является во много раз большим по сравнению с тем, с которым мы имели дело в какой-либо корпоративной сети. В современных системах с архитектурой клиент-сервер обычно имеется очень малое число серверов (чаще всего, один) для предоставления данных умеренному числу клиентов. В наших сценариях могут иметься сотни или тысячи серверов, а количество клиентов может быть еще большим.
Данные в этом новом мире географически рассредоточены в значительно большей степени, чем во всех случаях, с которыми мы имели дело до сих пор. Поставщики информации могут находиться где угодно по всему миру. Неограниченное использование узлов в удаленных местоположениях означает, что стоимость доступа к источнику информации может зависеть от предоставляемой пропускной способности входных и выходных каналов связи этих узлов. Такая фактическая пропускная способность может изменяться в зависимости от времени дня и популярности данного узла.
Поскольку все эти параметры порождают большие трудности, связанные с оптимизацией, станет настоятельной необходимостью запрещение крупного неограниченного поиска по многим узлам. Вместо этого должна иметься возможность заранее подготавливать большую часть информации, представляющей интерес, и сохранять ее в нескольких наиболее удобных местах.
В сценарии персональных информационных систем ясно, что серверам потребуется иметь дело с количеством запросов, на несколько порядков большим, чем это делают серверы сегодня. Представим себе персональные информационные устройства, установленные в каждом автомобиле, непрерывно запрашивающие информацию от сервера или серверов, географически распределенных в городе. Потребуются разработки устойчивых и масштабируемых серверов, для которых объем обрабатываемых запросов возрастает вместе с объемом доступных ресурсов сервера.
Время от времени будут появляться серверы, которые становятся горячими точками, например, такие как сервер службы спасения 911 или сервер, находящийся поблизости от футбольного стадиона или баскетбольного зала, перегруженный, когда проводится игра. В таких случаях широковещательная, а не двухточечная коммуникация, может быть альтернативой для удовлетворения обычно ожидаемых запросов, снижая в то же время и рабочую нагрузку на сервер. Становится важным понимание того, когда следует использовать широковещательные коммуникации, как их организовать и как лучше использовать локальную память клиентов.
"Мгновенное" виртуальное предприятие
"Мгновенное виртуальное предприятие" (Instant 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/EXPRESS4. Однако для того, чтобы дать возможность компании 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 компаний. Такой архив является базой данных.
Накладные расходы
Современная СУБД является результатом значительных усилий специалистов по разработке программного обеспечения. Для ее создания требуются трудозатраты в сотни человеко-лет и весьма серьезная технологическая база. Управление корпоративной информационной системой без такого инструмента было бы нелепостью. Затраты на создание специализированной СУБД, как правило, являются неоправданными.
Однако многие разработчики приложений отворачиваются от этой сферы индустрии в связи с тем, что современная система баз данных является весьма тяжеловесным ресурсом. Для многих разрабатываемых приложений накладные расходы, связанные с системными требованиями, экспертизой, планированием, трансляцией данных, а также с финансовыми затратами, оказываются слишком значительными. Например, разработчик персонализированной службы обработки газетных материалов может принять решение об отказе от использования СУБД по той причине, что в этом случае не требуются их многие развитые функциональные возможности. Для создания такой службы представляет интерес лишь фильтрация потоко-ориентированных данных (как это делается, например, в телеграфных службах).
Тем не менее, некоторые подмножества услуг традиционных СУБД оказываются востребованными многими новыми приложениями. Идеальным вариантом было бы предоставление совокупности модулей СУБД таким образом, чтобы можно было их комбинировать для формирования конфигурации, которая была бы в такой мере ограничена в своих возможностях или функционально полна, в какой это требуется. Например, для телеграфной службы необходимы лишь общая модель данных и возможности запросов к потокам данных.
Неоднородность
Сообщество баз данных осознало некоторое время назад, что данные существуют во многих формах. Чтобы дать приложениям возможность доступа к комбинированным источникам данных некоторым унифицированным способом и с помощью средств высокого уровня, эти разнородные форматы должны быть интегрированы. Автономия информационных узлов не позволяет предписать стандартизацию силами какой-либо централизованной власти.
Представим себе архив событий из газетных материалов, охватывающий последние двадцать лет. Этот архив содержит также дескриптивную информацию, указывающую, когда и где происходили обсуждаемые события, источник статей, автора, а также другие статьи, относящиеся к данной теме. Было бы достаточно трудно обеспечить единый интерфейс ко всей этой информации из-за ее полуструктурированного (semi-structured) характера. Такая природа данных означает, что их структура является менее унифицированной, чем в случае, с которым мы имеем дело в традиционных СУБД. Например, запросто могут опускаться некоторые поля, или они могут иметь изменяющуюся семантику.
Хотя проводилось довольно много исследований, посвященных интеграции данных из неоднородных источников и операциям над ними, программные продукты с такими возможностями только начинают появляться. Нам представляется, что доминирующим подходом является управление распределенными объектами, которое обеспечивается продуктами, поддерживающими CORBA, SOM И OLE. Каждый из этих подходов предоставляет некоторую объектно-ориентированную модель, на которой базируется общий язык описания интерфейсов распределенных объектов.
Хотя эти стандарты и поддерживающие их системы прошли долгий путь в интеграции различных систем программного обеспечения, они лучше всего подходят для обеспечения унифицированных синтаксических интерфейсов новых или существующих приложений. Эти подходы обеспечивают общий протокол для передачи сообщений между объектами в распределенной среде, однако в них не предпринимается попыток решить трудную проблему разрешения семантических противоречий. Они не могут быть также использованы для интеграции или создания унифицированных данных из различныхисточников. В общем, усложненный инструментарий для работы с неоднородными данными должен, тем не менее, являться надстройкой над интерфейсами CORBA, SOM или OLE.
Организация схемы
Стандартная парадигма баз данных предусматривает, прежде всего, создание схемы базы данных, которая описывает структуру базы данных, а уже после этого – наполнение базы данных с помощью интерфейса, обеспечиваемого схемой6. При этом СУБД отображает вводимые данные в фактическую структуру хранения.
Теперь все более часто придется сталкиваться с ситуацией, когда мы не будем иметь такой роскоши, как априорная схема. В настоящее время многие приложения создают данные независимо от какой-либо системы базы данных7
(например, научные приложения), и поскольку информация получается более легким путем для сбора, передачи и хранения, такое несоответствие будет только усиливаться. По этой причине возникает необходимость отображения в схему (и, возможно, в новые структуры хранения) данных, сгенерированных вне системы, пост-фактум. Этот подход "снизу-вверх" к наполнению баз данных не часто поддерживается в современных системах.
Тем не менее, весьма важно обеспечить простые механизмы, позволяющие сделать внешние источники данных доступными системам баз данных с тем, чтобы можно было реализовать нечто, подобное сценариям IVE. Для обеспечения такой возможности необходимы сложные процедуры отображения данных. Мы ведем здесь речь о создании того, что является, по существу, представлением внешних данных в духе баз данных, но такое представление должно конструироваться над данными в произвольных форматах.
Может оказаться, что данные, получаемые из какого-либо источника, например, из узла Web, имеют некоторую структуру. Фрагменты текста кодируются тегами, описывающими их роли. К сожалению, использование этих тегов может в значительной степени варьироваться. Тот факт, что на какой-либо одной странице используется тег H3 для заголовков, совсем не обязательно имеет силу для других страниц, и может быть даже из того же самого сайта. Такая вариация в использовании кодировки текстов затрудняет конструирование чего-либо такого, что мы могли бы понимать как схему, которая описывает как Web-страницы.
Кроме того, когда к таким источникам данных добавляются новые данные, мы можем обнаружить, что схема неполна или несовместима. Поэтому практикуемая в настоящее время жесткость схем баз данных становится препятствием в использовании систем баз данных для удовлетворения потребностей многих информационных систем. Нам необходимы средства управления схемой, которые могут элегантно адаптироваться к динамической природе внешних данных. Кроме того, схема должна допускать различные форматы и различные множества свойств данных, когда они появляются в среде СУБД.
Персональные информационные системы
Персональные информационные системы – это системы, которые обеспечивают информацию, рассчитанную для некоторого индивидуума и доставляемую непосредственно этому индивидууму с помощью портативных персональных информационных устройств (Personal Information Device, PID) таких, как персональные цифровые ассистенты, карманные персональные компьютеры или лаптопы. PID может либо переноситься индивидуумом, либо устанавливаться в автомобиле и будет оснащаться средствами беспроводного сетевого соединения. Оно будет также располагать сетевыми портами для подключения в случаях, когда доступны стационарные сетевые соединения.
Пользователь, оснащенный PID, сможет в ближайшем будущем иметь доступ к Internet где угодно и в любое время. Однако при этом в широком диапазоне будут варьироваться такие характеристики физических связей, как пропускная способность канала связи (от нескольких килобит/сек до нескольких мегабит/сек) и превалирующая частота ошибок. Весьма разнообразными будут также тарифы и схемы оплаты. Некоторые поставщики могут взимать плату за количество пакетов, в то время как другие – за время соединения.
Помимо этого, широкий спектр возможностей будут охватывать методы доставки информации – от периодических радиосеансов (через сеть спутников, принудительное избирательное распространение информации и т.д.) до стандартных сценариев в среде клиент-сервер, основанных на запросах. Будут также широко доступны глобальные системы позиционирования, и имеются все основания предполагать, что в ближайшие несколько лет каждая портативная персональная ЭВМ будет оснащена GPS-картой5. Таким образом, местоположение станет важным параметром в отборе информации, особенно для информационных услуг, зависимых от местоположения.
Нам представляется, что персональные информационные услуги должны быть тесно интегрированы с деятельностью индивидуумов от времени утреннего пробуждения, на протяжении повседневной деятельности и до времени отхождения ко сну. Эти сервисы будут работать от имени данного лица, даже во время его сна.
Утром эти услуги могут включать местный прогноз погоды, список напоминаний о специальных событиях текущего дня (например, о днях рождения или годовщинах друзей и родственников), список утренних рабочих совещаний и визитов (например, к зубному врачу), а также предложенную личным медицинским консультантом диету на этот день.
Доставка персональных информационных услуг будет продолжаться, когда данное лицо отправится на работу. PID сможет определить ему лучший маршрут от дома до работы на основе текущих условий трафика с показом ожидаемых задержек в пути на карте города (лучший маршрут может использовать комбинацию личного и общественного транспорта). Оно (PID) может предоставить персонализированный список заголовков новостей из национальных газет, например, "Нью-Йорк таймс", "Уол-Стрит Джорнал", а также заголовки международных сообщений из таких газет, как "Глоб" и "Мейл".
По понедельникам предоставляемый отчет будет включать сводку международных спортивных событий за выходные дни (например, об итальянской футбольной лиге). Он может предоставлять персонализированные сведения об инвестициях, содержащие рекомендации по инвестициям на данный день, которые предложены личным финансовым советником. К тому времени, когда данное лицо прибывает на работу, оно будет полностью осведомлено о представляющих для него интерес событиях и новостях.
Предоставление персональных информационных услуг будет продолжаться в течение всего дня. После прибытия в офис могли бы поступить список задач на день, список покупателей, с которыми нужно связаться, напоминание о необходимости договориться относительно визита к зубному врачу для периодической проверки, сводка объявленных новостей, информация о начале распродажи из местного магазина фурнитуры по конкретному изделию домашней фурнитуры, а также уведомление о приобретении лучшего авиабилета в связи с предстоящим отпуском. Если данному лицу придется в течение дня куда-либо ехать на машине, ему будут предоставлены сведения о лучшем маршруте, которые всегда основаны на текущей информации о трафике.
В конце дня персональная информационная служба предоставит предварительное расписание на следующий день, предложение по балансу личной дневной диеты от личного медицинского консультанта, а также сведения о встречах и делах на следующий день.
PID должно непрерывно издавать запросы к удаленным базам данных и отслеживать широковещательную информацию. Поэтому персонализированные информационные системы значительно обострят сегодняшние проблемы производительности систем с архитектурой клиент-сервер, а также проблемы масштабируемости и надежности. Серверы, которые распространяют ("push") информацию клиентам и отвечают на запросы клиентов ("pull"), будут играть важную роль в доставке персонализированных услуг. Нагрузка на эти серверы потенциально будет значительно большей и запросы будут, вероятно, значительно более утонченными. К числу архитектурных проблем, возникающих в средах, подобных рассмотренным, относится решение таких вопросов, как должны ли данные находиться на PID или на сервере, и какие задачи должны выполнять PID в отличие от сервера.
4) STEP и EXPRESS – это представители ряда протоколов, которые имеют статус индустриальных стандартов, принятых NIIIP (The National Industrial Information Infrastructure Protocol). Этот консорциум был образован в 1994 году с целью разработки и исследования протоколов, необходимых для поддержки индустриальных виртуальных предприятий. – Прим. пер.
5)
Технология глобальных систем позиционирования (Global Positioning System, GPS) активно развивается в настоящее время. Она основана на спутниковых системах, генерирующих и посылающих абонентам специальные сообщения, позволяющие с высокой точностью определять их географическое местоположение. Абонентом такой системы может быть пользователь мобильного компьютера, персонального цифрового помощника или другого вычислительного устройства, оснащенного принимающей и интерпретирующей спутниковые сообщения GPS-картой и специальным программным обеспечением. При этом абонент может находиться в любом месте и пользоваться услугами системы в любое время.GPS-технологии становятся чрезвычайно важными в судовождении, авиации и других сферах. С ними связывают также большие перспективы в мобильных информационных системах, о которых здесь говорят авторы. – Прим. пер.
Предпосылки
Технология баз данных возникла в конце 60-х годов с реализацией IMS, программного продукта компании IBM, который обеспечивал управление данными, организованными в форме иерархий2. Хотя позднее оказалось, что иерархии слишком ограничены, важным вкладом IMS стало широко признанное открытие, констатирующее, что данные имеют самостоятельную ценность, и что они должны управляться независимо от какого-либо отдельного приложения. До этого приложения обладали собственными файлами данных, в которых часто дублировались данные из других файлов. При использовании СУБД данные не должны логически реплицироваться, что облегчает их поддержку. Для создания совместно используемых баз данных потребовались анализ и проектирование, балансирующие требования нескольких приложений и, тем самым, улучшающие бы общее управление ресурсами данных.
Модели данных как IMS, так и ее весьма широко известного преемника – CODASYL3, основывались на графовых структурах данных. Хотя идея навигационных связей была интуитивно привлекательной, при ее использовании было трудно выражать взаимодействие с базой данных независимо от существующих алгоритмов, которые были необходимы для реализации таких связей.
В 1970 году Тэд Кодд опубликовал свою историческую статью [Codd70], в которой была показана возможность управления данными на существенно более высоком уровне благодаря их концептуализации в терминах математической теории отношений. Эта статья вызвала большой интерес в научном сообществе в 70-е годы и стремление практически воплотить такой подход. В настоящее время реляционная модель имеет наиболее широкую поддержку среди поставщиков коммерческих СУБД. Благодаря простоте и ясным концептуальным основам реляционной модели вокруг нее развернулись активные теоретические исследования. Исследователями было получено много важных результатов, в том числе, были разработаны теория проектирования баз данных, теория выразимости и сложности языков запросов, а также расширение реляционных языков, названное Datalog.
Теоретические разработки продолжаются во многих направлениях, включая, например, исследования ограничений в базах данных и запросов с использованием неполной информации.
В начале 80-х годов появилась новая модель, которая основывалась на принципах объектно-ориентированного программирования. Объектно-ориентированная модель данных была первой попыткой создания расширяемой модели данных. Чтобы дать пользователям возможность создавать их собственные специфические для конкретных приложений типы, которыми могла бы управлять данная СУБД, использовались механизмы абстракции данных. В последние пять-шесть лет появилось несколько компаний-поставщиков объектно-ориентированных систем управления базами данных, и комитет, сформированный из их представителей, разработал некоторый стандарт (ODMG). Совсем недавно появилась гибридная модель, широко известная как объектно-реляционная модель данных, в которой объектно-ориентированные возможности встраиваются в реляционный контекст.
Использование объектов демонстрировалось также как способ достижения интероперабельности в неоднородных базах данных и модульности в самой СУБД. Объектная модель обеспечивает очень мощный инструментарий для создания интерфейсов, которые не зависят от аспектов представления. Неоднородность в представлениях объектов может быть скрыта благодаря объектно-ориентированной схеме, определенной над фактически хранимыми данными. Модули СУБД могут описываться в объектно-ориентированных терминах, что облегчает их экспорт в другие системы.
Препятствия
СУБД обеспечивает строго контролируемую и в высокой степени унифицированную среду. Всякий доступ к данным осуществляется через верхний уровень системы, что позволяет относительно легко контролировать все появления определенного класса событий. Например, легко можно выявлять обновления, и таким образом может быть сделана управляемой поддержка индексов. Формат данных в файлах известен, содержимое буферов данных находится под строгим контролем СУБД, и все хранимые данные соответствуют явно заданной схеме.
Жизнь становится более сложной, когда мы пытаемся обеспечить функциональные возможности систем баз данных вне границ СУБД. Мы имеем в виду переход к среде, в которой может не быть никакого централизованного контроля и которая может быть в значительной мере не унифицированной. Поэтому здесь нужно специально договариваться относительно соглашений и предположений, которые поддерживаются в СУБД и могут использоваться ее компонентами. Подобным же образом, унифицированность либо должна обнаруживаться пост-фактум, либо должны быть изобретены новые способы обеспечения функциональных возможностей, которые могут справляться с разнообразием.
Чтобы адекватным образом воплотить те представления, которые отражены в наших сценариях, следует устранить ряд технических препятствий. Эти препятствия обычно являются результатом новых требований приложений, которыми еще не успели заняться ранее, или потребности в новых архитектурах СУБД. В данном разделе будут в общих чертах представлены некоторые из этих препятствий.
Простота использования
Несмотря на то, что имеются огромные достижения, связанные с облегчением установки, управления и использования СУБД, особенно тех, которые работают на персональных компьютерах или рабочих станциях, во многих приложениях все еще предпочитают использовать файловую систему, а не СУБД. Существует молчаливое предположение о том, что с СУБД должен иметь дело хорошо обученный персонал, работающий на полной ставке, и что большинство пользователей баз данных не обладает какой-либо подготовкой в технологиях баз данных. Пользователи пока еще считают трудным подключение к СУБД, нахождение нужного каталога или имен баз данных, где хранятся данные, а также формулировку запросов и операторов обновления базы данных. Парадигма подключения и доступа к файловой системе является значительно более легкой для понимания. Существенное упрощение использования систем баз данных представляло бы благоприятную возможность для их более распространенного использования.
Если бы такое сложное и критичное по времени приложение, как представленное, например, в сценарии IVE, потребовало бы сложных усилий в части программирования, оно никогда бы не было осуществимым. Вместо этого требуется простой набор интерфейсов, позволяющих менеджерам мгновенного виртуального предприятия специфицировать высокоуровневые требования к разработке, например, требуемого вентиля. Все процедуры отображения и сопоставления данных из многих распределенных источников, требуемые для нахождения подходящих разработок, должны быть прозрачными для пользователя.
Системы баз данных были бы более простыми для использования, если бы, например, имелась возможность приспосабливать их к интересам отдельного пользователя. В случае персональных информационных систем можно было бы иметь какой-либо способ для сервера принимать во внимание различные персональные профили. Персональные профили могли бы включать маршруты поездок по городу в различное время дня, недели или месяца (например, из дома на работу в утренние и вечерние часы, посещение клиента А в среду и т.д.), местонахождение отделений банка, банкоматов, любимых ресторанов или кинотеатров. Сервер мог бы посылать персональному информационному устройству изменяющуюся во времени информацию, релевантную профилю пользователя, и эту информацию можно было бы показывать на карте города. Благодаря таким возможностям представление базы данных было бы доступно пользователю в форме, простой для ее использования при решении проблемы управления его распорядком дня.
Сценарии
В этом разделе мы опишем два приложения технологии баз данных, которые иллюстрируют направления, пропагандируемые нами в данном отчете. Мы полагаем, что представленные здесь возможности показывают характер будущих систем управления базами данных, и технологии, которые будут поддерживать рассматриваемые сценарии, представляют собой программу исследований на следующее десятилетие.
Сложность запросов
Проблема оптимизации запросов принимает в будущих средах совершенно иные черты, в связи с чем обычные оптимизаторы становятся неадекватными. Во-первых, в число типов, которые должны приниматься во внимание в нашем новом мире, входят различные массовые типы, такие как последовательности, деревья и многомерные массивы. Во-вторых, другие типы данных, которые должны сохраняться в базах данных, будут в большой мере ориентированы на приложения; они будут экземплярами произвольных абстрактных типов данных.
Обычная оптимизация запросов ориентирована на минимизацию числа обменов с дисками. Сетевая оптимизация могла бы базироваться на совсем иных критериях. Например, пользователь мог бы быть в большей мере заинтересован в получении ответа таким способом, при котором минимизируется общий "информационный счет" за обработку этого запроса. Если имеется два источника, каждого из которых достаточно для обработки некоторого запроса, оптимизатор должен найти такой из них, который позволит снизить затраты. Эти затраты могут включать в качестве компонентов стоимость обработки, использования данных и коммуникации.
Оптимизаторам будет также необходимо использовать различные стратегии для учета новых форм данных и характеристик новых компьютерных сред. Стандартные методы оптимизации запросов мало что могут дать для запросов, связанных с большими временными рядами, или для запросов, которые, возможно, должны будут транслировать несколько наборов данных в некоторую каноническую форму перед продуцированием результата. Ситуации, подобные этим, весьма вероятно, могут возникать в сценарии IVE.
Если мы рассмотрим, например, сценарий персональных информационных систем, то обнаружим потребность в более гибких методах оптимизации запросов, в которых будут приниматься во внимание изменения в стоимости широковещательной среды (например, основанной на радио или сотовых коммуникациях) при перемещении PID. Степень детализации или точности, обеспечиваемая сервером, может основываться на величине той суммы, которую желает платить данное лицо. Таким образом, в моделях оптимизации должны приниматься во внимание не только формулировки запросов, но также и описание целей оптимизации. Эти цели могли бы выражаться в терминах расхода ресурсов (например, оптимизировать по критерию минимизации затрат памяти и максимизации использования сети) или в виде ограничений на исполнение, основанных на точности ответа или допустимого расхода ресурсов 8.
Стратегические направления в системах баз данных
А.Зильбершац, С.Здоник
Перевод: М.Р. Когаловский
Источник: журнал Системы Управления Базами Данных # 4/1997, издательский дом «Открытые системы»
Новая редакция: Сергей Кузнецов, 2009 г.
Оригинал: Avi Silberschatz, Stan Zdonik. Database Systems Breaking Out of the Box. ACM Computing Surveys, v.28, no.4, December 1996. Текст доступен здесь.
Внедрение технологий
Наряду с перечисленными выше конкретными препятствиями имеются также некоторые барьеры между научными исследованиями и индустрией. Исследователи не обладают достаточными знаниями в области методов и решений, необходимых для индустрии, а индустрия в недостаточной мере использует результаты научных исследований. Усугубляет эти проблемы и монолитная структура СУБД. Каждое усовершенствование оказывает влияние на многие части основного программного кода, и это приводит поставщиков в нерешительность при попытках практического использования находок, сгенерированных академическим сообществом. Исследователи вообще в малой степени понимают такие сложные взаимосвязи. Наконец, многое из коммерчески доступного в технологии баз данных, продиктовано стандартами, в которые мало что привносится исследовательским сообществом.
6) Не следует здесь понимать авторов буквально. Схема базы данных вовсе не предоставляет никакого интерфейса. Она является дескриптивным компонентом системы базы данных и используется средствами системных интерфейсов для интерпретации. – Прим. пер.
7) Такая ситуация является главной причиной того, что большие компоненты этих приложений сегодня вообще не используют систем баз данных. – Прим. пер.
8)
Обратим внимание на допущенную авторами неточность. Спецификация цели (критерия) является необходимым компонентом постановки задачи на оптимизацию. При этом, естественно, могут задаваться и какие-либо ограничения. Однако ограничения никаким образом не являются выражением цели оптимизации, а выполняют функцию задания области поиска оптимума. – Прим. пер.
в области систем баз данных
Исследования и разработки в области систем баз данных были чрезвычайно успешными на протяжении их тридцатилетней истории. Они привели к появлению 10-миллиардной индустрии, обладающей сформировавшимся фундаментом и фактически затрагивающей каждую более или менее важную компанию в мире. Было бы немыслимо управлять большим объемом ценной информации, обеспечивающей работоспособность корпораций, без поддержки средствами коммерческих систем управления базами данных (СУБД).
В настоящее время область исследований баз данных в значительной мере определяется ее предыдущими успехами, и большинство проводимых сейчас исследований нацелено на развитие функциональных возможностей и повышение производительности СУБД. СУБД является весьма сложной системой, объединяющей множество технологий. Эти технологии объединяются, исходя из потребностей обеспечения идеальных условий для решения проблем управления крупными объемами данных в корпоративных условиях. Однако СУБД, как и любой другой крупный инструмент, предъявляют определенные требования к той среде, в которой они используются. Применение СУБД приводит к некоторым эксплуатационным накладным расходам, часто требует достаточно высокого уровня компетентности для установки и сопровождения, позволяет управлять только такими данными, которые представлены в файлах весьма специфических форматов.
В то же время, данные, которыми требуется управлять, радикальным образом изменяются и хранятся в местах, отличных от систем баз данных (например, в файлах). Их получают также в больших объемах из внешних источников, например, от сенсоров. Хотя имеется тенденция к построению более мощных систем управления базами данных, существует также и потребность в управлении данными в ситуациях, при которых являются неприемлемыми накладные расходы полномасштабных СУБД. Во многих случаях требуются значительно более легковесные решения.
Иногда, вместо использования в новом приложении какого-либо существующего инструментария, лучше встроить в него повторно используемые компоненты, чтобы сделать систему более реактивной.
В некоторых случаях наибольшей повторной используемостью обладают методы реализации инструментальных средств. Мы утверждаем, что это наблюдение справедливо для многих новых приложений, требующих обработки большого количества данных. Хотелось бы повторно использовать компоненты систем баз данных, но когда это оказывается неприемлемым, нам следует быть готовыми повторно использовать свои методы и опыт новыми способами.
Если теперь посмотреть на ту информацию, которую используют люди, то можно встретить много примеров, в которых бросается в глаза отсутствие систем баз данных. Одним из наиболее впечатляющих примеров является World Wide Web. Хотя справедливо утверждать, что поставщики СУБД делают свои продукты применимыми в среде Web (Web-enable), из подход состоит в том, чтобы обеспечить улучшенные Web-серверы. Такая возможность представляет собой лишь весьма небольшой шаг в направлении развития управления огромными объемами нестандартных данных, существующих в Web. Сомнительно, чтобы этот шаг заставил сотни тысяч Web-узлов перейти к использованию функционально полных систем баз данных, ориентированных на рынок обработки бизнес-данных.
К числу других примеров приложений, в рамках которых можно было бы извлечь пользу из технологий управления данными, но которые обычно в полной мере не используют программных продуктов, предназначенных для систем баз данных, относятся персональные информационные системы, службы новостей и научные приложения. В случае персональных информационных систем можно мыслить лишь об информации, которая хранится в обычной персональной ЭВМ. Электронная почта имеет огромное личное значение для многих пользователей, но когда сохраняются сообщения, они запоминаются чаще всего в файловой системе. Было бы чрезвычайно полезно иметь такие средства СУБД, как индексирование и обработка запросов, доступными для использования в электронной почте. Хотя появляется некоторая поддержка более организованного подхода к хранению и выборке электронной почты (например, в Lotus Notes), более утонченные средства запросов пока еще хорошо не проработаны.
В других недавних отчетах [Gray95, SSU91, SSU95] были охарактеризованы направления исследований в области баз данных, а также великолепно проведена работа по определению приоритетов текущих исследовательских проблем и по установлению новых факторов, связанных с их влиянием на индустрию систем баз данных. В этом отчете1 решается несколько иная задача – показать, что исследования в области баз данных должны быть посвящены проблемам управления данными, независимо от того, где и в какой форме данные могут находиться. Мы не должны строго ограничиваться сформировавшимся пространством продуктов или широко поддерживаемым мнением о том, что наша работа заключается в управлении очень большими совокупностями структурированных записей в управляемой среде. Вместо этого мы должны использовать наши профессиональные знания для новых сред управления данными, которые потенциально требуют радикально новых подходов к архитектурам программного обеспечения.
В этом отчете мы показали,
В этом отчете мы показали, что исследования в области баз данных должны проводится в более широких границах, чем это было в прошлом. Обсуждалась идея о том, что сообщество специалистов по базам данных должно использовать свои опыт и знания в новых проблемных областях, что потребует, вероятно, новых решений, реализованных такими способами, которые не похожи на способы, используемые в существующих системах баз данных.
Относительно долговременной перспективы представляется, что сообщество специалистов по базам данных может внести существенный вклад в решение таких весьма важных проблем, как масштабируемость, эффективность и надежность информационных систем. Информация должна определяться в более широких терминах, позволяющих включать большое разнообразие семантических типов, которые существуют во многих формах. Мы предвидим появление технологий, обеспечивающих поддержку приложений функциональности баз данных путем интеграции небольших модулей, которые предоставляют в точности необходимые возможности. Такие модули должны также воплощать унифицированную теорию информации, которая дает возможность запрашивать информацию любых типов без необходимости переключения языков или парадигм.
