1.1. Системы управления базами данных В подавляющем

1.1.
Системы управления базами данных
В подавляющем большинстве случаев при решении хозяйственных,
экономических и финансовых задач приходится иметь дело с обширными
специфически структурированными и взаимозависимыми массивами данных.
При этом данные рассматриваются как информационные ресурсы для
разноаспектного и многократного использования. Принцип интеграции
предполагает организацию хранения информации в виде банка данных (БнД),
где все данные собраны в едином интегрированном хранилище и к
информации как важнейшему ресурсу обеспечен широкий доступ различных
пользователей.
Таким образом, банк данных – это система специальным образом
организованных данных и совокупность программных, технических,
языковых, организационно-методических средств, предназначенных для
обеспечения централизованного накопления и коллективного многоцелевого
использования данных.
Любой банк данных в своем составе всегда содержит два основных
компонента: базу данных и систему управления базами данных. Так
реализуется концепция отделения самих данных от процедур по их
обработке.
База данных (БД) – систематизированное хранилище информации.
Обычно база данных создается для одной конкретной предметной области,
организации или конкретной прикладной задачи.
Для автоматизации работы с базами данных используются системы
управления базами данных (СУБД, англоязычная аббревиатура DBMS —
Database Management System) — специальные пакеты программ,
обеспечивающие ввод, поиск, хранение, пополнение, корректировку данных,
формирование отчетов и ответов на запросы пользователей баз данных.
Большинство современных экономических и информационно-справочных
программных комплексов реализовано на основе применении той или иной
СУБД.
Теория управления базами данных как самостоятельная дисциплина
начала развиваться приблизительно с начала 50-х годов двадцатого столетия.
За это время в ней сложилась определенная система фундаментальных
понятий. Рассмотрим некоторые из них.
1.1.1.
Основные понятия теории баз данных
Объектом (сущностью) называется элемент информационной системы,
сведения о котором накапливаются и хранятся в базе данных. Таким образом,
предметная область рассматривается как некоторая совокупность объектов.
Выбор объектов производится в соответствии с целевым назначением
1
системы. Например, для учетной информационной системы объектами
являются счет, проводка, операция. Различают тип сущности («Сотрудник»,
«Кафедра») и экземпляры сущности. Последние характеризуют конкретное
значение сущности (например, для сущности «Кафедра» экземплярами будут
«кафедра высшей математики», «кафедра экономической информатики»,
"кафедра финансов" и т.д.)
Каждый объект в конкретный момент времени характеризуется
определенным состоянием. Это состояние описывается с помощью набора
свойств-атрибутов и связей с другими объектами базы данных. Обычно
отношения представляются в БД как двумерные таблицы.
Свойство (атрибут) – это некоторая характеристика объекта,
позволяющая установить его сходства и различия по отношению к другим
объектам. Каждый объект характеризуется некоторым набором атрибутов.
Так, например, в качестве атрибутов объекта «Студент» можно использовать:
фамилию, имя, отчество; дату рождения; год поступления в учебное
заведение; группу; домашний адрес и телефон и т.д. Выделяют общие и
индивидуальные свойства. Общими свойствами обладают, например, товары
одного
наименования.
Индивидуальные
свойства
позволяют
идентифицировать отдельные объекты в моделях предметной области.
Связь. Различают внутренние и внешние связи. Например, связь «Счет –
субсчет» является внутренней, «Счет – проводка» – внешней. Связи в
большинстве баз данных организуются с помощью, так называемых
ключевых атрибутов (или ключей).
Запись данных (экземпляр сущности) — это совокупность значений
связанных атрибутов объекта.
Атрибуты (поля)
№ зачетной
Код
книжки
дисциплины
Записи
О
ценка
980375
ЕН 01
4
980375
ЕН 03
5
980381
СД 01
4
980381
ОП 01
3
Различают три типа связей.
Связь «Один к одному». Один экземпляр сущности. А идентифицирует
один и только один экземпляр сущности Б. Такая связь существует,
например, между фамилиями зарегистрированных на рейс пассажиров и их
местами в самолете. По номеру телефона можно определить адрес, по
которому этот телефон установлен.
2
Связь «Один ко многим». В этом случае каждый экземпляр сущности. А
может быть связан с несколькими экземплярами сущности Б. На одной
кафедре трудится несколько преподавателей, один поставщик поставляет
много различных товаров, книга написана несколькими авторами.
Связь «Многие ко многим». Примером этого типа связей может служить
связь между сущностями «Студент» и «Преподаватель»: один студент
обучается у многих преподавателей, один преподаватель обучает многих
студентов.
Ключевым элементом данных называется такой атрибут (или группа
атрибутов), который позволяет определить значения других элементов
данных.
Атрибут (или несколько атрибутов), значения которого однозначно
идентифицирует каждую запись отношения, называется ключевым или
просто ключом. Ключевой атрибут может быть простым (представленным
только одним атрибутом) или составным (представляющим собой
совокупность двух и более атрибутов).
Код
товара
001
002
003
Наимен
ование
Кнопки
Скрепки
Скрепки
Ц
Единица
ена
измерения
2
Пачка
-00
Пачка
2
Пачка
-80
2
-50
Простой
ключ
Код
товара
001
002
003
Наимен
ование
Кнопки
Скрепки
Скрепки
Ц
Единица
ена
измерения
2
Пачка
-00
Пачка
2
Пачка
-80
2
-50
Составной ключ
Различают первичные и вторичные ключи. Те и другие имеют вполне
определенное назначение.
3
Первичный ключ – это атрибут (или группа атрибутов), который
уникальным образом идентифицирует каждый экземпляр объекта (запись).
Например, для объекта «Студент» в качестве первичного ключа можно
использовать атрибут «Номер зачетной книжки».
Часто в качестве первичного ключа в описание объекта вводят
специальный атрибут. Так, например, в качестве первичного ключа объекта
«Товар» нельзя использовать его наименование – одни и те же товары могут
иметь разных поставщиков, в различные периоды времени один и тот же
товар может иметь разные цены поставки и т.д. В данном случае в качестве
первичного ключа лучше ввести атрибут «Код товара», который будет иметь
уникальное значение для каждого экземпляра сущности.
Вторичным ключом называется атрибут (или группа атрибутов),
назначение которых – обеспечить связь данного отношения с другими
отношениями. Значение вторичного ключа может повторяться для
нескольких записей (если, например, один поставщик поставляет несколько
различных товаров). Вторичные ключи используются в операциях поиска
записей.
Отношение «Поставщики»
Код
Наименова
поставщика
ние
поставщика
1
ОАО
2
«Сибирь»
3
ЗАО
«Прогресс»
ЧП
«Смирнов»
Связь по ключу
Первичный ключ
Код
товар
а
001
002
003
Отношение «Товары»
Наимен
Ц
Еди
ование
ена
ница
изме
рения
Кнопки
2
Пач
Скрепки -00
ка
Скрепки
2
Пач
-80
ка
2
Пач
-50
ка
Код
поста
вщика
2
2
1
Вторичный ключ
4
Процедуры хранения данных в базе должны подчиняться некоторым
общим принципам, среди которых в первую очередь следует выделить:
•
целостность и непротиворечивость данных, под которыми
понимается как физическая сохранность данных, так и предотвращение
неверного использования данных, поддержка допустимых сочетаний их
значений, защита от структурных искажений и несанкционированного
доступа;
• минимальная избыточность данных означает, что любой элемент
данных должен храниться в базе в единственном виде, что позволяет
избежать необходимости дублирования операций, производимых с ним.
Программное обеспечение, осуществляющее операции над базами
данных, получило название СУБД — система управления базами данных.
Очевидно, что его работа должна быть организована таким образом, чтобы
выполнялись перечисленные принципы.
1.1.2.
Модели организации данных
В теории систем управления базами данных выделяют модели трех
основных типов: иерархическую, сетевую и реляционную.
В иерархической модели элементы связаны отношениями подчиненности
и при этом любой элемент может подчиняться только одному какому-нибудь
другому элементу. Такую форму зависимости удобно изображать с помощью
древовидного графа. Пример иерархической структуры базы данных
приведен на рис. 4.1.
К недостаткам иерархической модели следует отнести сложность
отображения связей «Многие ко многим», а также сложность операций
включения новых объектов.
Рис 4.1. Схема иерархической модели данных
Типичным представителем семейства баз данных, основанных на
иерархической модели, является Information Management System (IMS)
фирмы IBM, первая версия которой появилась в 1968 г.
5
Концепция сетевой модели данных связана с именем Ч. Бахмана.
Сетевой подход к организации данных является расширением
иерархического. В иерархических структурах запись-потомок должна иметь
в точности одного предка; в сетевой структуре данных потомок может иметь
любое число предков (рис. 4.2).
Рис.4.2. Схема сетевой модели данных
База данных, основанная на сетевой модели данных, состоит из набора
записей и набора связей между этими записями, точнее – из наборов
экземпляров записей заданных типов (из допустимого набора типов) и
набора экземпляров из заданного набора типов связей.
Примером системы управления данными с сетевой организацией
является Integrated Database Management System (IDMS) компании Cullinet
Software Inc., разработанная в середине 70-х годов. Она предназначена для
использования на «больших» вычислительных машинах. Архитектура
системы основана на предложениях Data Base Task Group (DBTG),
Conference on Data Systems Languages (CODASYL), организации,
ответственной за определение стандартов языка программирования Кобол.
Среди достоинств систем управления данными, основанных на
иерархической или сетевой моделях, могут быть названы их компактность и,
как правило, высокое быстродействие, а среди недостатков –
неуниверсальность, высокая степень зависимости от конкретных данных.
Концепции реляционной модели впервые были сформулированы в
работах американского ученого Э. Ф. Кодда (отсюда происходит ее второе
название – модель Кодда).
В реляционной модели объекты (сущности) и взаимосвязи между ними
представляются с помощью реляционных таблиц (рис. 4.3). Для ее
формального определения используется фундаментальное понятие
отношения. Собственно говоря, термин «реляционная» происходит от
английского relation — отношение.
6
Рис. 4.3. Схема реляционной модели данных
Основным достоинством реляционной модели является ее простота.
Именно благодаря ей она положена в основу подавляющего большинства
реально работающих СУБД.
Атрибуты в реляционных таблицах носят название полей. В
реляционной базе данных каждая таблица должна иметь первичный ключ
(ключевой атрибут) — поле или комбинацию полей, которые единственным
образом идентифицируют каждую строку (запись) в таблице.
Важнейшей проблемой, решаемой при проектировании баз данных,
является создание такой их структуры, которая бы обеспечивала
минимальное дублирование информации и упрощала процедуры обработки и
обновления данных. Коддом был предложен некоторый набор формальных
требований универсального характера к организации данных, которые
позволяют эффективно решать перечисленные задачи. Эти требования к
состоянию таблиц данных получили название нормальных форм.
У каждой таблицы-отношения должен быть уникальный ключ (простой
или составной), который однозначно идентифицирует записи этого
отношения. Зачастую составной ключ просто заменяют на служебный
атрибут. Например, код товара.
Для каждого набора связанных атрибутов следует создавать отдельное
отношение. Например, такие характеристики товара, как его наименование,
цвет, размер, модель, единица измерения, желательно не включать в
отношение, содержащее атрибуты, связанные с движением товара
(количество, номер склада, дата поступления, дата продажи).
Если атрибут связан только с частью составного ключа, переместите его
в отдельную таблицу.
Проверяйте любые оставшиеся группы информации! Если атрибуты не
вносят своей доли в описание ключа, перемещайте их в отдельные таблицы.
7
1.1.3.
Основные компоненты СУБД (на примере СУБД Access)
Любая система управления базами данных для реализации своих
основных функций содержит:
•
средства описания структуры базы данных и средства
обеспечения целостности данных (таблицы);
•
средства
конструирования
экранных
форм,
предназначенные для ввода и редактирования данных, их просмотра
и обработки в диалоговом режиме (формы);
•
средства создания запросов, предназначенные для выборки
данных, удовлетворяющих заданным условиям, а также выполнению
операций по их обработке (запросы);
•
средства создания отчетов, предназначенные для просмотра
и печати результатов обработки данных в табличном или
графическом виде (отчеты);
•
средства реализации нестандартных алгоритмов обработки
данных (макросы);
•
средства создания приложений пользователя, например,
меню, пользовательских панелей управления и т.д., позволяющих
объединить различные операции по обработке данных в единый
технологический процесс (модули)
Рассмотрим эти компоненты подробнее.
Таблицы. Таблица базы данных Access хранит сведения по конкретному
вопросу. Например, таблица «Товары» содержит данные только о товарах;
таблица «Поставщики» содержит данные о поставщиках этих товаров. В
Access атрибуты (столбцы) носят названия полей, кортежи (строки) –
названия записей. Для идентификации и связывания таблиц используют
ключевые поля (простые и составные, первичные и вторичные).
В таблицах хранятся необработанные данные. Вводимые данные в
Access группируются по определенным критериям. В таблице информация
группируется по строкам, которые называются записями, и столбцам,
называемым полями.
Каждое поле имеет определенный тип данных (текст, число, дата и т.д.),
длину и уникальное имя, которое идентифицирует хранящуюся в этом поле
информацию. Таблицы в Access содержат правила проверки данных для
предотвращения введения некорректных значений.
Каждая запись считается отдельной величиной, к которой можно
получить доступ и по которой можно отсортировать таблицу. Все поля,
содержащие информацию об определенном объекте, содержатся внутри
конкретной записи.
8
В то время как поля различаются по имени, записи обычно
идентифицируются по некоторой уникальной характеристике. Для
однозначного определения каждой записи таблица должна иметь уникальный
ключ.
В базе данных, как правило, содержится не одна, а несколько таблиц
(логически сгруппированных данных). Связи между таблицами дают
возможность совместно использовать данные из разных таблиц. Связь
каждой пары таблиц обеспечивается одинаковыми полями в них – ключом
связи (внешним ключом). Приложение, использующее несколько таблиц,
может манипулировать данными более эффективно, чем при использовании
одной большой таблицы. Множественные таблицы упрощают ввод данных и
создание отчетов, уменьшая ввод избыточных данных. Размещение сведений
о каждом объекте в отдельной таблице и связывание таблиц позволяет
избежать повторение значений данных в разных таблицах и упрощает
процесс их обновления и поиска в базе.
Формы. Формы ввода данных помогают пользователям быстро, легко и
без ошибок поместить информацию в таблицу базы данных. Формы ввода и
отображения данных обеспечивают более структурированный подход, чем
использование режима таблицы. Тем не менее по-прежнему можно
просматривать, добавлять, изменять или удалять записи базы данных.
Использование форм ввода данных — самый распространенный способ
внесения данных в таблицу базы данных.
Формы ввода данных можно использовать для ограничения доступа к
определенным полям в таблице. Кроме того, формы можно применять и для
контроля правильности данных до их внесения в таблицу базы данных.
Формы ввода данных можно сделать похожими на обычные бумажные
документы, что делает ввод данных интуитивно понятным пользователю,
позволяет автоматически перемещать фокус ввода на нужные поля
обновляемой таблицы.
Формы только для отображения позволяют увидеть лишь определенные
поля данной таблицы. С другой стороны, отображение одних полей и
сокрытие других означает, что можно ограничить доступ пользователя к
важным данным, в то же время допуская запрос других полей.
Запросы. Для извлечения информации из базы данных используется
запрос. Запросы создаются пользователем для выборки нужных данных из
одной или нескольких связанных таблиц. С его помощью можно выбрать и
определить группу записей, удовлетворяющих определенному условию.
Использование запросов перед печатью отчета позволяет выводить на печать
только нужные данные. Запросы можно использовать и в процедурах,
изменяющих, добавляющих или уничтожающих записи базы данных.
Выбранные записи называются динамическим набором, который может
изменяться вместе с данными в оригинальных таблицах. После окончания
9
работы запроса можно использовать получившийся динамический набор в
форме либо напечатать его в отчете. Таким образом, можно ограничить
доступ пользователя только к тем данным, которые соответствуют критерию,
заданному при создании динамического набора.
Отчеты. Отчеты используются для формирования выходного
документа, предназначенного для вывода на печать. В одной базе данных
можно создать несколько типов отчетов. Например, в отчете могут
перечисляться все записи конкретной таблицы. Можно также создать отчет, в
котором перечислены только записи, отвечающие заданному критерию. Это
делается путем встраивания в отчет запроса.
Отчеты могут включать данные из разных таблиц, чтобы более полно
представить сложные зависимости между различными наборами данных.
При проектировании таблиц данных важно предусмотреть, в каком виде
будет получен результат.
Макросы и модули. Макросы содержат описание действий, которые
должны быть выполнены в ответ на некоторое событие. Каждое действие
реализуется макрокомандой. Выбор макрокоманд и задание параметров,
используемых ими при выполнении, является простой автоматизированной
операцией. Макрос позволяет объединить разрозненные операции обработки
данных в одном приложении.
Модули содержат программы на языке Visual Basic, которые могут
разрабатываться пользователем для реализации нестандартных процедур при
создании конкретных программных приложений.
1.1.4.
Программные системы управления базами данных
Кратко остановимся на конкретных программных продуктах,
относящихся к классу СУБД. На самом общем уровне все СУБД можно
разделить:
•
на профессиональные, или промышленные;
•
персональные (настольные).
Профессиональные (промышленные) СУБД представляют собой
программную основу для разработки автоматизированных систем
управления крупными экономическими объектами. На их базе создаются
комплексы управления и обработки информации крупных предприятий,
банков или даже целых отраслей. Первостепенными условиями, которым
должны удовлетворять профессиональные СУБД, являются:
•
возможность организации совместной
работы большого количества пользователей;
параллельной
•
масштабируемость, т.е. возможность роста
пропорционально расширению управляемого объекта;
10
системы
•
переносимость на различные аппаратные и программные
платформы;
•
устойчивость по отношению к сбоям различного рода, в
том числе наличие многоуровневой системы резервирования
хранимой информации;
•
обеспечение безопасности хранимых данных и развитой
структурированной системы доступа к ним.
Промышленные СУБД к настоящему моменту имеют уже достаточно
богатую историю развития. В частности, можно отметить, что в конце 70-х –
начале 80-х годов в автоматизированных системах, построенных на базе
больших вычислительных машин, активно использовалась СУБД Adabas. В
настоящее время характерными представителями профессиональных СУБД
являются такие программные продукты, как Oracle, DB2, Sybase, Informix,
Ingres, Progress.
Персональные системы управления данными — это программное
обеспечение, ориентированное на решение задач локального пользователя
или компактной группы пользователей, и предназначенное для
использования на микроЭВМ (персональном компьютере). Это объясняет и
их второе название — настольные. Определяющими характеристиками
настольных систем являются:
•
относительная простота эксплуатации, позволяющая
создавать на их основе работоспособные приложения как
«продвинутым» пользователям, так и тем, чья квалификация
невысока;
•
относительно ограниченные требования к аппаратным
ресурсам.
Исторически первой среди персональных СУБД, получивших массовое
распространение, стала Dbase фирмы Ashton-Tate (впоследствии права на нее
перешли к фирме Borland, а с 1999 г. данная программа поддерживается
фирмой dBASE Inc.). В дальнейшем серия реляционных персональных СУБД
пополнилась такими продуктами, как FoxBase/FoxPRO (Fox Software, в
дальнейшем -Microsoft), Clipper (Nantucket, затем –Computer Associates),
R:base (Microrim), Paradox (Borland, на настоящий момент правами владеет
фирма Corel), Access (Microsoft), Approach (Lotus).
Несмотря на неизбежные различия, обусловливавшиеся замыслами
разработчиков, все перечисленные системы в ходе своей эволюции
приобрели ряд общих конструктивных черт, среди которых, прежде всего,
могут быть названы:
•
наличие визуального интерфейса, автоматизирующего
процесс создания средств манипуляции данными, — экранных форм,
шаблонов отчетов, запросов и т. п.;
11
•
наличие инструментов создания объектов базы данных в
режиме диалога: Exoerts в Paradox, Wizards в Access, Assistants в
Approach;
•
наличие развитого инструментария создания программных
расширений в рамках единой среды СУБД: язык разработки
приложений PAL в Paradox, VBA (Visual Basic for Applications) в
Access, Lotus Script в Approach;
•
встроенная поддержка универсальных языков управления
данными, например SQL или QBE (Query By Example).
Среди СУБД, которые, условно говоря, занимают промежуточное
положение между настольными и промышленными системами, могут быть
названы SQLWindows/ SQLBase фирмы Centura (до 1996 г. Gupta), InterBase
(Borland), наконец, Microsoft SQL Server.
В последние годы наметилась устойчивая тенденция к стиранию четких
граней между настольными и профессиональными системами. Последнее, в
первую очередь, объясняется тем, что разработчики в стремлении
максимально расширить потенциальный рынок для своих продуктов
постоянно расширяют набор их функциональных характеристик.
На сегодня существует более 50% промышленно поставляемых СУБД.
Выбор СУБД для конкретного предприятия (фирмы) основывается на
следующих критериях:
•
среда функционирования (платформа) – это класс
компьютеров и операционных систем, с которыми может работать
СУБД. СУБД Access функционирует на персональном компьютере
под управлением операционных систем Windows;
•
тип поддерживаемой СУБД модели данных (существует
СУБД, поддерживающая иерархические, сетевые и реляционные
модели данных). 90% СУБД поддерживают реляционные модели;
•
наличие средств конструирования таблиц, форм, запросов,
отчетов, уровень развития диалоговых средств;
•
возможность работы с нетрадиционными данными в
корпоративных сетях (сообщения электронной почты, изображения,
звуки, видеоклипы, Internet-станицы (HTNA) и т.д.);
•
уровень использования (настольная однопользовательская
СУБД, обеспечивающая работу локальной сети, реализующая
технологию клиент-сервер);
•
интеграция с другими приложениями (например, СУБД
Access совместима со всеми компонентами Microsoft Office).
В последнее время резко возрос интерес к технологиям хранилищ
данных, что обусловливается требованиями менеджеров к улучшению
12
процессов поддержки принятия решений. Главная цель создания хранилищ
данных состоит в том, чтобы сделать все значимые для управления бизнесом
данные доступными в стандартизированной форме, пригодными для
моделирования, анализа и получения необходимых отчетов. Хранилища
данных можно назвать оптимально организованной базой данных,
обеспечивающей максимально быстрый доступ к информации, необходимой
для принятия решений.
В общих чертах процесс создания хранилища данных состоит из
следующих основных этапов — проектирования и загрузки данных.
Проектировщики, тесно взаимодействуя с бизнес-аналитиками, очерчивают
круг бизнес-понятий, процессов и объектов, принятых в конкретной
организации, формулируют и описывают потоки данных. При этом
определяются
бизнес-цели,
критические
для
успеха
факторы,
разрабатывается предварительная бизнес-модель.
Так же как и любая информационная система, хранилище данных
требует поддержания его в актуальном состоянии, т. е. для некоторых
приложений необходимо ежемесячное обновление данных, для других —
ежедневные обновления либо обновления по событию.
С помощью централизованного хранилища данных решаются такие
задачи, как анализ ценовой политики, стратегическое и тактическое
планирование, телемаркетинговая служба, ориентированные при этом на
разные группы пользователей (физические лица, небольшие компании или
крупные корпорации).
1.1.5.
Перспективы развития СУБД
Будучи
основным
фундаментальным
средством
построения
информационных систем, используемых в производстве, бизнесе и научной
деятельности, базы данных и системы управления ими постоянно
совершенствуются.
Несмотря на то, что реляционные СУБД давно и прочно заняли
основные позиции на рынке программного обеспечения по обработке
данных, в этой области остается много нерешенных проблем. Во-первых, это
касается нового стандарта языка запросов SQL-3, возможности которого
должны быть расширены за счет работы с объектами и расширения типов
обрабатываемых данных (большие массивы текстовых данных, графические
объекты, слабо структурированные объекты и т.д.). Во-вторых, движение в
сторону открытых систем предполагает пересмотр организации серверов баз
данных. В-третьих, обозначилась проблема использования старых баз
данных в рамках новых программных продуктов.
Значительное
число
разработок
осуществлено
в
области
постреляционных баз данных. Появились базы данных сложных объектов
(реляционная модель с отказом от первой нормальной формы), нашедшие
13
применение в нетрадиционных приложениях, требующих операций со
сложно структурированными объектами; активные базы данных, для
которых СУБД выполняет не только указанные пользователем действия, но и
дополнительные действия в соответствии с правилами, заложенными в саму
базу данных; темпоральные базы данных как надстройка над реляционной
базой данных, позволяющие поддерживать ретроспективные данные
системы; интегрированные системы, обеспечивающие решение задачи
интеграции неоднородных баз данных в единую глобальную систему.
Особое место в СУБД следующего поколения занимают объектноориентированные базы данных. Их возникновение определяется
потребностями
практики:
необходимостью
разработки
сложных
информационных систем, для которых технология предшествующих баз
данных не была удовлетворительной. В таких СУБД должны быть решены
проблемы поддержки иерархии и управления сложными объектами. Однако
для решения этих задач существуют значительные ограничения, а именно:
отсутствие общепринятой объектно-ориентированной модели данных,
декларативного языка запросов и т. п. Разработчики в области баз данных
отводят объектно-реляционным и объектно-ориентированным базам данных
значительное место на рынке в ближайшее десятилетие.
Распределенные базы данных представляют еще одну разновидность
системы управления базами данных. Применение протоколов синхронизации
транзакций, сокращение расходов на пересылку данных между узлами
вычислительной сети в ходе выполнения распределенного запроса
посредством репликации данных — далеко не все возможные проблемы в
данной области.
14