Предисловие (стр. 29 )

На основе объектных моделей в конце 80-х - начале 90-х гг. возникла новая категория СУБД. Кроме того, разработаны технологии неоднородных распределенных интероперабельных систем, новые методологии анализа и проектирования сложных программных и информационных систем. Создание такой объектной инфраструктуры способствует расширению сферы применения объектных СУБД.

В связи с появлением к началу 90-х годов ряда коммерческих объектных СУБД и обнаружившимися перспективами расширения производства программного обеспечения для объектных систем баз данных актуальной стала проблема стандартизации объектной модели данных. Эту задачу решил учрежденный в 1991 году индустриальный консорциум ODMG (Object Database Management Group, переименованный позднее в Object Data Management Group).

Стандарт ODMG содержит: описание объектной модели ODMG на содержательном уровне; спецификации синтаксиса языковых средств, воплощающих эту модель, которые включают язык описания данных и язык запросов; они называются здесь языком определения объектов ODL (Object Definition Language) и объектным языком  запросов OQL (Object Query Language); спецификации интерфейсов репозитория схем объектных баз данных, представленных средствами языка ODL; эти интерфейсы обеспечивают доступ к хранимым в репозитории схемам; определения отображений спецификации языков ODL, OQL и интерфейсов репозитория схем в объектные языки программирования C++, Smalltalk и Java, называемые спецификациями связывания для указанных языков программирования; спецификации синтаксиса формата обмена объектами OIF (Object Interchange Format) для дампа текущего состояния объектной базы данных в файл (множество файлов) и для загрузки объектов из такого файла (множества файлов) в базу данных, а также для обмена объектами между системами.

Если перефразировать приведенное выше общее определение понятия модели данных для случая объектного подхода, то можно сказать, что объектная модель данных – это некоторая система типов данных [4].

Объектно-реляционная модель. Это - гибридная модель данных, сочетающая возможности реляционных моделей с объектными свойствами данных. Такие модели стали использоваться как паллиатив, обеспечивающий преодоление ограниченных возможностей реляционной модели (являющихся оборотной стороной ее достоинств), препятствующих эффективной реализации многих приложений, - слабая система типов данных, отсутствие возможностей определения новых типов пользователем, сложности интеграции в новые технологические среды, которые основаны, главным образом, на объектных моделях. Шаги, предпринятые ведущими поставщиками реляционных серверов баз данных и направленные на включение в их программные продукты объектных расширений языка SQL, привели к включению таких функциональных возможностей в новый стандарт языка SQL:1999.

Многомерные модели данных. Такие модели стали основой инструментальных средств поддержки принятия решений. Они оперируют многомерными представлениями данных (в виде гиперкуба). Разновидности многомерной модели стали широко использоваться в середине 90-х г. в связи с развитием технологий OLAP.

Основные понятия многомерной модели данных - измерение и ячейка. Каждое измерение представляет собой множество однородных значений данных, образующее грань гиперкуба. Обычно значениями измерений являются признаковые данные. Примерами измерений являются годы, месяцы, кварталы, регионы, города, районы, названия предприятий, виды продукции и т. п. Измерения играют роль индексов, совокупности значений которых идентифицируют в гиперкубе конкретные его ячейки, или осей координат в многомерной системе координат гиперкуба. Ячейки (называемые также показателями) представляют собой, как правило, числовые величины - литералы, переменные либо формулы.

Операционные возможности многомерных моделей данных, используемых в OLAP, ориентированы на поддержку анализа данных. Предусматривается конструирование разнообразных агрегаций данных в рамках заданного гиперкуба, построение различных его проекций - подмножеств гиперкуба, полученных путем фиксации значений каких-либо измерений, детализация (дезагрегация) данных и вращение (изменение порядка измерений) гиперкуба, а также ряд других операций.

Модель сущностей-связей. Разновидности этой модели широко используются в инструментальных средствах CASE. Первоначальная ее версия была предложена Питером Ченом в 1976 г. В дальнейшем были предложены различные ее расширения.

Эта модель данных, кратко называемая ER-моделью, предназначена, по замыслу автора, для описания концептуальной модели предметной области в процессе проектирования базы данных. Однако ER-модель была использована позднее в ряде экспериментальных СУБД в качестве модели данных внешнего уровня системы для поддержки пользовательского интерфейса.

Основными элементами ER-модели являются именованные множества сущностей, множества связей между ними, которые могут быть двуместными или многоместными, ориентированными или неориентированными. Сущности и связи обладают атрибутами. В модели вводится ограничение целостности данных, ассоциируемое с двумя множествами сущностей, - зависимость по существованию. Это ограничение является близким по смыслу ограничению целостности по ссылкам в реляционной модели.

Контрольные вопросы

Какова роль моделей данных в системах баз данных?

В каких формах можно определить конкретную модель данных?

Из каких компонентов состоит модель данных?

Какова роль ограничений целостности данных в модели данных?

Чем различаются явные и неявные ограничения целостности данных?

Как трансформировалось содержание понятия модели данных в процессе развития технологий баз данных?

Назовите известные вам разновидности моделей данных, которые были созданы в прикладных и исследовательских целях?

Какие модели данных называют графовыми моделями, в чем состоят их особенности?

На каких моделях данных основано большинство СУБД, поставляемых в настоящее время?

Опишите в общих чертах возможности модели данных CODASYL.

Каковы главные особенности иерархических моделей данных?

Когда и кем была предложена реляционная модель данных?

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

Какова основная структура данных в реляционной модели данных?

Какие операции над таблицами предусмотрены в реляционной модели данных?

В чем заключаются особенности объектных моделей данных?

Почему в современных SQL-серверах баз данных стали использовать объектно-реляционную модель данных?

Какой международный стандарт языка запросов определяет объектно-реляционную модель данных, используемую в серверах баз данных, которые стали выпускать во второй половине 90-х годов?

Какова сфера применения многомерных моделей данных?

Для каких целей, кем и когда была предложена модель сущностей-связей?

8.7. Архитектура систем баз данных

Для понимания принципов функционирования систем баз данных необходимо теперь рассмотреть архитектурные особенности такой системы. Обсуждая этот вопрос, следует принимать во внимание, что архитектура систем баз данных имеет несколько важных аспектов. Мы будем далее различать функциональную архитектуру систем баз данных, их пространственную и информационную архитектуру. Эти аспекты архитектуры являются в значительной степени взаимосвязанными. Требуемая пространственная и информационная архитектура поддерживаются средствами функциональной архитектуры системы.

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

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

Одной из наиболее важных функций СУБД, оказавших решающее влияние на формирование сложившегося подхода к информационной архитектуре таких систем, является обеспечение возможностей абстракции данных. Именно механизмы абстракции данных, предоставляемые СУБД, служат средством поддержки независимости способов видения базы данных различными группами системного персонала и пользователей. Это свойство системы называется независимостью данных.

Действительно, пользователю СУБД, запрашивающему данные из базы данных, нет необходимости знать, каким образом организована база данных в среде хранения, как размещены запрашиваемые им данные в пространстве памяти. В то же время эти знания необходимы администратору системы базы данных, ответственному за использование системных ресурсов, за обеспечение высокой производительности системы.

В системах баз данных обычно имеют дело с иерархией абстракций данных. Поэтому уместно говорить об уровнях абстракции. Различным уровням абстракции данных соответствуют в системе базы данных различные уровни информационной архитектуры.

Введение каждого дополнительного уровня в архитектуру системы требует наличия специальных механизмов у СУБД и существенно усложняет ее реализацию и эксплуатацию, оказывает влияние на производительность системы. Однако такой шаг диктуется достаточно серьезными мотивами. Прежде всего, необходимо обеспечить адекватные способы видения базы данных для различных групп персонала и пользователей системы, создать инструментарий, эффективно удовлетворяющий их потребности, выраженные в терминах естественного для них представления базы данных. Кроме того, необходимо иметь возможность изменять некоторые характеристики системы баз данных, не затрагивая других ее характеристик, т. е. обеспечить независимость данных. Введение некоторых уровней архитектуры может быть также следствием "технологических" причин, когда дополнительные уровни вводятся в силу следования разработчиков СУБД принципам структурного программирования.

С каждым архитектурным уровнем системы базы данных связана некоторая модель, в терминах которой обеспечивается представление данных на этом уровне. Языковые средства этой модели данных, если они представляются разработчиком СУБД пользователям и системному персоналу, позволяют настраивать уровневые механизмы СУБД и управлять их функционированием. В частности, язык определения данных позволяет определять представление базы данных, ассоциируемое с этим уровнем архитектуры, а операторы языка манипулирования данными дают возможность выполнять различные операции над элементами этого представления.