Специалисты ряда фирм (например, Microsoft) работают сейчас над переосмыслением самого значения термина «база данных». В процессе этого переосмысления они столкнулись с рядом важных проблем, решение которых определяет будущее БД и систем распределенной обработки.
Составные БД. Сейчас каждая СУБД является вещью в себе. Первая задача десятилетия – это разработка баз данных на основе концепции многоуровневых систем, состоящих из взаимодействующих компонентов.
Интероперабельные БД. Составные БД с открытым интерфейсом являются, по определению, интероперабельными БД. Процессор запросов может извлекать данные от поставщиков записей любого вида. Может быть разработано множество типов поставщиков запросов. Электронная таблица может выдавать себя за БД, действуя как соответствующий компонент, т.е. в среде интероперабельной БД пользователь может, например, создавать и работать с финансовыми данными в электронной таблице, работающей в данном случае как электронная таблица. В то же время Финансовый Директор может консолидировать данные из многих электронных таблиц (и менеджеров проектов, и БД), используя классический реляционный механизм запросов, обращаясь к электронным таблицам как к БД.
Географический процессор запросов может извлекать данные из ниже лежащего уровня хранения также легко, как и реляционный процессор запросов, т.е. в среде интероперабельной БД вывод данных на карту и обработка географических запросов также просты, как обработка иерархических и навигационных запросов, а также гипертекстовых запросов.
Распределенные БД. Ожидается, что в ближайшее время будут функционировать десятки (а может быть и сотни) миллионов БД в различных областях. Из этого следует, что БД должны быть распределенными. Во-первых, это означает, что они должны быть полностью самоустанавливающимися и самоуправляемыми. Во-вторых, взаимодействие между БД должно быть автоматическим и высоконадежным. Но прежде всего это означает, что такая распределенная инфраструктура должна быть очень хорошо сбалансирована.
|
|
Процессы, а не задачи. Классические БД и мониторы транзакций обрабатывают транзакции и задачи в реальном времени. По определению, транзакция рассматривается как атомарное действие, одиночное событие, которое либо происходит целиком, либо не выполняется вообще. Реальный мир, однако, состоит из последовательностей задач, выполняющихся в течение очень больших интервалов времени (например, выплата страховки, обмен жилплощади). Базы данных и окружающая их инфраструктура должны быть разработаны так, чтобы обрабатывать длинные последовательности транзакций с возможностью отката на несколько транзакций назад.
Сложные модели данных. Нормализация таблиц БД позволяет упростить задачу обеспечения целостности БД. Однако часто сложные (ненормализованные) структуры данных являются и более естественными, и более эффективными. Это видно из объектно-реляционных моделей БД и соответствующих продуктов, например, UniSQL и Montage. Таким же образом представление связей «многие-ко-многим» часто бывает рискованным, но часто дает и преимущества. Двадцать лет практики научили нас, что иногда нормализованные таблицы или связи «многие-ко-многим» это правильно, а иногда нет. Базы данных будущего должны предоставлять такой выбор.
|
|
Базы данных, а не языки. Одним из следствий модели составной БД является то, что лежащая ниже БД становится независимым и отдельным компонентом от любой высокоуровневой языковой среды. Сегодня большинство современных БД тесно ограничены либо SQL, либо некоторым объектно-ориентированным языком типа C++/Smalltalk. Такое связывание имеет большие преимущества для многих приложений, но иногда разработчик хочет использовать только менеджер БД, не желая выбирать определенный язык, объектную модель или дисциплину разработки и как следствие – создание нового класса поставщиков записей, каждый из которых унаследует всю среду более высоких уровней. Таким образом, разработчик нового менеджера проекта, используя, например, соответствующие методы, может создать компонент, поставляющий записи. Среда языка высокого уровня, базирующаяся на SQL или на объектно-ориентированном подходе, может обращаться к этому поставщику записей также, как и к любому другому.
Навигация и запросы. Сегодня объектно-ориентированные БД поддерживают один стиль навигации, сетевые СУБД (т.е. поддерживающие сетевую модель данных) и метод доступа ISAM – другой. Реляционные БД обеспечивают запросы и операции на множествах. В составной БД разработчик не выбирает, т.е. низкоуровневые компоненты БД обеспечивают такие же навигационные возможности, как и ISAM. Высокоуровневые процессоры запросов ориентируются либо на операции со множествами, либо на навигацию указателей, либо на то и другое. Поскольку это очень важно, усилия специалистов в следующем десятилетии будут направлены на поддержку поэлементного навигационного стиля и вычислений, основанных на запросах. Часто подход, основанный на запросах, – наилучший путь первоначального указания множества записей, в то время как навигационные операции – единственный путь дальнейшей работы с полученными в результате данными в манере достаточно развитой, чтобы удовлетворить потребностям сложных приложений.
|
|
Память. Предположим, что мощный сервер с 500 Мбайт ОП поддерживает работу ста настольных компьютеров, каждый из которых имеет 50 Мбайт ОП. В этой ситуации совместная память персональных компьютеров составляет 5000 Мбайт, что значительно превышает объем памяти сервера. Сейчас этим пользуются брокеры объектных запросов (менеджеры баз данных). В перспективе все приложения переместят большую часть своих частных структур данных под управление менеджеров БД.
Контрольные вопросы
1. Назовите достоинства и недостатки файлового сервера БД.
2. Для решения каких проблем была разработана модель сервера приложений?
3. Перечислите особенности, присущие открытой системе.
4. Каковы перспективы развития систем распределенной обработки данных?