Базы данных    
Конспект лекций
назад | содержание | вперед

 

Тема 1.5. Модели баз данных

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

Модель базы данных это совокупность логических конструкций, используемых для представления структуры данных и отношений между ними внутри БД. Модели баз данных можно подразделить на две категории: концептуальные модели и модели реализации.

    • Концептуальная (понятийная) модель нацелена на логическую природу представления данных. Поэтому в концептуальной модели основное внимание уделяется тому, что представлено в БД, а не как это представлено. К концептуальным моделям относятся модель "сущность-связь" (ER-модель) и объектно-ориентированная модель.
    • Модель реализации, в отличие от концептуальной модели, ставит во главу угла способ представления данных в БД или то, как реализовать структуры данных, чтобы получить представление о том, что мы моделируем. К моделям реализации БД относятся иерархическая модель, сетевая модель, реляционная модель и объектно-ориентированная модель.

Разработчики баз данных берут концептуальную модель за основу для проектирования БД. В концептуальной модели используются три типа связей для описания отношений между данными: один-ко-многим, многие-ко-многим и один-к-одному. Проектировщики баз данных обычно используют для этого сокращенные обозначения — 1:М, M:N и 1:1 соответственно. Следующие примеры показывают, в чем состоит разница между этими связями.

    • Один-ко-многим. Художник может написать много различных картин, но каждая из них написана одним художником. Следовательно, художник ("один") связан картинами ("многие"). Поэтому проектировщик баз данных обозначает связь "ХУДОЖНИК пишет КАРТИНУ" как 1:М. Точно так же в учетной записи клиента ("один") может содержаться множество счетов, но данные счета ("многие") относятся к единственному клиенту. Связь "КЛИЕНТУ выписан СЧЕТ" также относится к типу 1:М.
    • Многие-ко-многим. Служащий может повышать квалификацию по нескольким направлениям, в то же время на занятиях по каждому направлению могут присутствовать многие служащие. Проектировщики баз данных обозначают связь "СЛУЖАЩИЕ повышают КВАЛИФИКАЦИЮ" как M:N. Так же студент может изучать несколько предметов, и на занятиях по каждому предмету может быть много студентов, поэтому связь "СУДЕНТЫ изучают ПРЕДМЕТ" следует обозначить как M:N.
    • Один-к-одному. Структура отдела продаж предприятия может быть организована так, что каждым магазином заведует один сотрудник. В свою очередь каждый заведующий (естественно, являющийся сотрудником) управляет одним магазином. Поэтому связь "СОТРУДНИК заведует МАГАЗИНОМ" обозначается как 1:1.

Поскольку у каждой модели базы данных есть предшественники, в этой главе мы вкратце исследуем все модели. Опыт показывает, что изучение основных понятий структуры каждой модели данных позволит лучше понять методы проектирования проблемы управления современных баз данных. На самом деле многие "новые" концепции баз данных имеют поразительное сходство с некоторыми "старыми" идеями и структурами. Например, можно обнаружить несомненное сходство между некоторыми концепциями иерархической модели базы данных и реализацией объектно-ориентированной структуры.

 

1.5.1. Иерархическая модель

Компания North American Rockwell была основным подрядчиком проекта Apolk кульминацией которого стала высадка астронавтов на Луне в 1969 году. Для успешного завершения такого грандиозного проекта необходимо было обрабатывать информацию о миллионах деталей. Информация о деталях была организована как сложная компьютерная система файлов. Однако, как мы уже отмечали, иcпoльзoвaние системы файлов ведет к избыточности хранимой информации, сопровождаемой соответствующими аномалиями данных.Когда компания North American Rockwell приступила к разработке собственной системы базы данных, проверка компьютерных носителей информации показала, что избыточность данных достигала 60%. Проблемы, являвшиеся следствием избыточности данных, вынудили компанию выработать альтернативную стратегию управления таким огромным объемом информации. Взяв за основу уже имевшиеся в то время идеи баз данных, компания разработала программное обеспечение GUAM (Generalized Update Access Method — обобщенный метод доступа и модификации), заложив в его основу принцип агрегатности, когда множество небольших деталей составляют узел, который в свою очередь включается в узлы более высокого уровня (сборки), эти узлы входят в еще более сложные компоненты (агрегаты) и т. д., а все компоненты, собранные воедино, и образуют конструкцию в целом.

В середине 1960-х годов компания IBM объединилась с компанией North American Rockwell с целью дальнейшего развития системы GUAM и заменила носители информации на магнитных лентах более современными жесткими дисками, что позволило разработать сложную систему указателей.

Примечание. Указатель (pointer) это справочное устройство, которое точно "указывает" на местоположение определенных данных на устройстве хранения. Это напоминает глоссарий терминов в книге, который позволяет вам производить поиск среди терминов, расположенных в глоссарии по алфавиту, и затем по имеющемуся номеру страницы найти в книге необходимые сведения. Хотя компьютерная система указателей гораздо сложнее, принцип ее работы тот же.Результат объединенных усилий получил известность как Information Management System (IMS — информационно-управляющая система). С учетом растущего влияния компании IBM на рынок, IMS стала мировым лидером среди иерархических систем баз данных для универсальных машин в 70-х годах и в начале 80-х годов прошлого столетия.Иерархическая модель базы данных основана на структуре, имеющей сходство с перевернутым деревом, где от ствола отходят ветви, от которых в свою очередь отходят другие ветви. Хотя иерархическая модель базы данных и не играет существенной роли на современном рынке БД, есть ряд причин, по которым стоит изучить ее основные свойства.

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

Основные понятия. Базовая логическая структура иерархической модели станет понятнее, если провести аналогию с неким производственным процессом. Рассмотрим упрощенную процедуру создания картотеки.

  1. Картотечный шкаф состоит из нескольких узлов (components): каркас, набор выдвижных ящиков и направляющие для этих ящиков.
  2. Каждый узел может состоять из множества более мелких сборок. Например, у каждого ящика имеются ручка с защелкой, несколько роликов, с помощью которых он перемещается по направляющим, и разделительные пластинки.
  3. Каждая сборка может состоять из нескольких деталей. К примеру, каждый ролик состоит из небольшого колесика, оси и крепежной скобы.
  4. Процесс производства картотечного шкафа состоит в сборке всех частей, взаимосвязи между которыми постоянны во времени. Когда бы ни был собран данный картотечный шкаф, сегодня или завтра, одни и те же детали собираются вместе тем же способом, образуя сборку, сборки собираются в узел, а все узлы собираются воедино, образуя тем самым картотечный шкаф.

Описание формирования деталей, сборок и узлов, которое мы только что привели, помогает представить весь этот логический процесс в виде перевернутого "дерена", которое называют иерархической структурой (рис.1.7). На рисунке каждый компонент структуры обозначен соответствующим образом, чтобы помочь разобраться в основной терминологии иерархической БД.

Рис. 1.7. Иерархическая структура

Если внимательно посмотреть на рис. 1.7, то можно заметить, что с точки зрения пользователя иерархическая база данных представляет собой иерархию сегментов. Сегмент (segment) эквивалентен записи в системе файлов. Другими словами, иерархическая база данных это совокупность записей, которые логически организованы с целью отображения структуры перевернутого дерева (иерархической структуры), представленной на рис. 1.7. Внутри этой иерархии верхний слой (корень, root) воспринимается как предок (parent) сегмента, находящегося непосредственно под ним. Например, на рис. 1.7 корневой сегмент является предком сегментов уровня 1, которые в свою очередь являются предками сегментов уровня 2 и т. д. Сегменты, расположенные под другим сегментом, являются потомками (дочерними сегментами, child) сегмента, находящегося над ними.

Вкратце можно сказать, что:

    • каждый предок может иметь несколько потомков;
    • каждый потомок имеет только одного предка.

В такой иерархической структуре достаточно просто проследить и компоненты базы данных, и существующие между ними связи типа 1:М.Необходимо иметь в виду, что древовидная структура, представленная на рис. 1.7, не может быть непосредственно воспроизведена в компьютерном устройстве хранения. Компьютер не может, как человек, увидеть логическую структуру. Вместо этого дерево определяется цепочкой, отображающей маршрут от сегмента-предка к сегменту-потомку, начиная слева. Эта упорядоченная последовательность сегментов, отображающая иерархическую структуру, называется иерархическим маршрутом. Например, иерархический маршрут к сегменту с именем "Деталь D" на рис. 1.7 может быть представлен следующим образом:

ИзделиеÒ Узел АÒ Сборка АÒ Деталь АÒ Деталь ВÒ Узел ВÒ Узел СÒ Сборка ВÒ Деталь СÒ Деталь D

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

ИзделиеÒ Узел СÒ Сборка ВÒ Деталь D

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

Иерархическая модель эффективна в независимости от количества транзакций, в которые вовлечены остающиеся постоянными во времени связи 1:М. Например, система учета банковских счетов хорошо укладывается в иерархическую модель:

    • банковский счет каждого клиента может быть предметом множества операций (связь "один-ко-многим");
    • операции над счетом могут совершаться или по дебиту, или по кредиту. Поэтому основные связи между банковским счетом клиента и операциями, которые по нему совершаются, фиксированы;
    • банк, как правило, имеет множество счетов клиентов, и каждый такой счет может стать предметом множества операций (транзакций). Поэтому общее число транзакций может, по всей вероятности, быть очень большим.

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

    • Простота идеи. Структура иерархической модели, отношения между различными слоями интуитивно понятны. Поэтому достаточно легко мысленно представить себе всю базу данных, что упрощает ее проектирование.
    • Безопасность базы данных. Безопасность базы данных обеспечивает СУБД. Поэтому безопасность едина для всей системы и не требует никаких усилий от программистов, у которых могут быть различные взгляды на способы защиты.
    • Независимость данных. СУБД создает среду, которая может обеспечить независимость данных, существенно упрощая этим работу программистов (независимость данных имеет место, если изменение типа данных вызывает его автоматическое изменение с помощью СУБД во всей базе данных, исключая таким образом, необходимость модифицировать участки программ, которые используют эти данные).
    • Целостность данных. Взаимоотношение предок/потомок всегда предполагает наличие связи между сегментом-предком и его дочерними сегментами (потомками). Поскольку дочерний сегмент всегда автоматически связан со своим предком, иерархическая модель тем самым всегда обеспечивает целостность БД.
    • Эффективность. Иерархическая модель базы данных очень эффективна, когда в БД содержится большой объем данных со связью 1:М и когда пользователи выполняют большое число транзакций, используя объекты, связи между которыми фиксированы во времени.

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

Недостатки. Хотя в настоящее время иерархические базы данных и их приложения еще существуют, все же иерархическая модель стала быстро терять популярность в конце 1970-Х и начале 1980-х годов по нескольким важным причинам.

    • Сложность реализации. Несмотря на то, что СУБД иерархической модели упрощает работу проектировщиков и программистов при решении проблем обработки данных, от них все же требуется высокий профессионализм при организации физического хранения данных. Поэтому задача реализации проекта БД может оказаться достаточно сложной.
    • Сложность управления. Любые изменения в структуре БД, например, перемещение сегментов, вызовут необходимость изменений во всех прикладных программах, получающих доступ к базе данных. Следовательно, управление базой данных может стать трудной задачей. И хотя иерархическая структура стимулирует целостность базы данных, в то же время она дает возможность удалить один сегмент, что приведет к невольному удалению всех сегментов под ним — ошибка, которая может дорого стоить!
    • Недостаток структурной независимости. Структурная независимость имеет место, если изменения в структуре базы данных не влияют на возможность доступа СУБД к данным. Иерархическую базу данных еще называют навигационной системой, поскольку доступ к данным предполагает, что для "навигации" по заданным сегментам используется маршрут физического хранения. Внутри навигационной системы базы данных программист должен знать такой маршрут к соответствующим сегментам (для того, чтобы получить доступ к дочерней записи, прежде необходимо обеспечить доступ к предку), чтобы извлекать данные из БД. Изменения в структуре БД могут привести к проблемам с прикладными программами, которые до этого работали правильно; за преимущество независимости по данным приходится расплачиваться структурной зависимостью.
    • Сложность программирования и использования приложений. В структуре навигационной базы данных прикладные программисты и конечные пользователи должны точно знать, каким образом физически данные размещены в БД для того, чтобы получить к ним доступ. Даже если им известен маршрут доступа к данным, получение данных требует знания сложной системы указателей. Поэтому говорят, что иерархические базы данных были созданы программистами для программистов.
    • Ограничение в реализации. Многие связи не могут быть изображены схемой 1:М, на которой основана иерархическая БД. Например, рассмотрим список студентов университета. На каждую дисциплину может записаться много студентов, и каждый студент может проходить обучение по нескольким дисциплинам. Такую связь "многие-ко-многим" (M:N) трудно реализовать в иерархической модели.
    • Недостаток стандартизации. Хотя основные концепции иерархической модели используются повсюду в программном обеспечении БД, все-таки не существует стандартизированного набора ключевых понятий и компонентов, на базе чего можно было создать модель, в которую было бы включено описание всех необходимых стандартов. Проблемы с реализацией БД вызывали особенное раздражение, поскольку компоненту администрирования базы данных явно недоставало и стандартного языка определения данных (data definition language, DDL) для определения компонентов БД и языка манипулирования данными (data manipulation language, DML) для работы с содержимым БД. Несмотря на то что программное обеспечение IMS, разработанное совместно компаниями IBM и North American Rockwell, фактически стало играть роль СУБД в конце 60-х и начале 70-х годов прошлого века, параллельно, вне рамок концепций и терминологии, определенных в IMS, использовалось множество менее заметных программ. Поэтому переход с одной иерархической БД на другую был весьма трудной задаче переносимость таких баз данных была ограничена.

В начале 70-х годов появилась сетевая модель базы данных.

 

1.5.2. Сетевая модель

Сетевая модель базы данных была разработана для того, чтобы более эффективно представлять сложные отношения данных, чем это можно было сделать в иерархической модели, а также для улучшения производительности БД и для стандартизации баз данных. Недостаток стандартизации вызывал нарекания программистов и прикладных разработчиков, поскольку это создавало проблемы с переносимость" приложений. Более того, отсутствие стандартных понятий и компонентов мешал поиску наилучших моделей БД. Беспорядок редко способствует прогрессу. Чтобы разработать стандарты для баз данных, в 1971 году была созвана конференция Conference on Data Systems Languages (CODASYL — постоянно действующая конференция по языкам обработки данных). В заключительном отчете DBTG описаны три ключевых компонента базы данных.

    • Схема, абстрактная организация базы данных с точки зрения администратора БД. В эту схему были включены определения имени базы данных, типа каждой записи и компонентов, которые заполняли эти записи.
    • Подсхема, определяющая фрагмент базы данных, "видимый" прикладными программами, которые фактически извлекают необходимую информацию из базы данных. Определения подсхемы позволяют всем прикладным программам упростить вызов подсхемы, необходимой для доступа к соответствующему файлу (файлам) БД.
    • Язык управления данными (data management language), предназначенный для определения свойств данных и их структуры, чтобы можно было манипулировать данными.

Чтобы выработать необходимый стандарт для каждого из этих трех компонентов, группой DBTG были также определены три отдельных компонента языка управления данными.

    • Схема языка определения данных (DDL, Data Definition Language), которая позволяет администратору определять компоненты схемы.
    • Подсхема DDL, дающая возможность прикладным программистам определить компоненты БД, которые будут использоваться.
    • Язык манипулирования данными (DML, data manipulation language) для работы с содержимым БД.

Основные понятия. Во многих отношениях сетевая модель базы данных сходна с иерархической моделью. Например, как и в случае иерархической модели, пользователь воспринимает БД как совокупность записей, между которыми существует связь 1:М. Однако в отличие от иерархической модели, записи сетевой модели могут иметь более чем одного предка. По терминологии сетевых БД связь называется множеством (set). Каждое множество состоит как минимум из двух типов записей: запись-владелец (owner), которая в иерархической модели соответствует предку, и запись-член (member), которая соответствует потомку в иерархической модели. Различие между иерархической и сетевой моделями состоит в том, что в последней, при некоторых условиях, запись (как запись-член) может появляться более чем в одном множестве. Другими словами, запись-член может иметь несколько записей-владельцев. Множество представляет связь 1:М между записью-владельцем и записью-членом. Пример такой связи представлен на рис. 1.8.

Рис. 1.8. Сетевая модель базы данных

Рис. 1.8 иллюстрирует пример сетевой модели базы данных типичного торгового предприятия. В этой модели Клиент, Торговый агент, Счет, Строка счета, Товар и Оплата представляют собой типы записей. Обратите внимание, что записью Счет "владеют" и Торговый агент, и Клиент. Подобным образом запись Строка счета имеет двух владельцев Товар и Счет. Обратите внимание, что сетевая модель может содержать связи с одним владельцем (например, клиент - производит оплату) характерные для иерархических моделей.Сетевая модель базы данных, представленная на рис. 1.8, иллюстрирует транзакции, основанные на сериях связей "один-ко-многим".

    • Агент может выписать множество бланков счетов, но каждый бланк выписан единственным агентом. Поэтому агенты и счета связаны как 1:М.
    • Клиент может делать покупки в различных обстоятельствах. При каждой покупке выписывается счет, т. е. клиент может создать за какое-то время множество счетов, но каждый счет принадлежит единственному клиенту. Поэтому между клиентом и счетом существует связь 1:М.
    • Каждый заказанный товар занимает соответствующую строку в счете. Поскольку клиент может за один раз купить несколько товаров (более одного) в каждом счете может быть одна или более строк. Но каждая строка конкретного счета принадлежит" этому счету.
    • Каждая строка счета ссылается на единственный товар. Но поскольку магазин может продать множество отверток за какой-то период времени, этот товар может появиться во многих разных счетах. Поэтому между товаром и строкой счета существует связь 1:М.
    • Клиент может сделать несколько платежей за некоторый период времени. Но только один клиент делает данный платеж. Поэтому между клиентом и оплатой имеется связь 1:М.

Преимущества. В сетевой модели сохранились основные преимущества иерархической модели, в то же время в ней были исправлены многие недостатки, присущие иерархической модели.

    • Концептуальная простота. Как и в иерархической модели, абстрактное представление базы данных является достаточно простым, что упрощает проектирование.
    • Поддержка других типов связей. Связь M:N проще реализуется в сетевой модели, чем в иерархической. К примеру, сетевая база данных обрабатывает связь "данный товар может быть продан множеству клиентов, а данный клиент может сделать множество покупок" проще, поскольку в ней допускается наличие нескольких "владельцев" записи (см. рис. 8).
    • Гибкий доступ к данным. Гибкость доступа к данным в сетевой модели значительно выше, чем в иерархической модели и в системах файлов. Любое приложение может получить доступ к записи-владельцу и всем записям-членам внутри множества. Поэтому, если запись-член имеет двух или более владельцев, как это показано на рис. 8, можно напрямую перейти от одного владельца к другому (иначе говоря, в этом случае не потребуется долгий прямой обход).
    • Обеспечение целостности базы данных. Сетевая модель способствует соблюдению целостности базы данных, поскольку пользователь должен, прежде всего, определить запись-владельца, а уже потом записи-члены (запись-член не может существовать без записи-владельца).
    • Независимость данных. В сетевой модели обеспечена достаточная независимость Данных, которая, по крайней мере, частично избавляет от программирования сложных деталей, связанных с методами физического хранения информации. Поэтому изменения в свойствах данных не потребуют переделки тех участков прикладных программ, где выполняется доступ к данным.
    • Соответствие стандартам. Возникновение сетевой модели, по крайней мере, в некоторой части, связано со стандартами, разработанными и принятыми в семидесятых годах двадцатого века. Эти стандарты, включая DDL и DML, значительно улучшили возможности администрирования баз данных, а также их переносимость.

Недостатки. Все же сетевая модель обладает и рядом недостатков

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

Вследствие имеющихся серьезных недостатков в 1980-х годах сетевая модель была вытеснена реляционной моделью.

 

1.5.3. Реляционная модель

Поскольку разработчикам приходилось вникать в тонкости структуры базы данных, проектирование баз данных было очень трудным делом. Фактически, несмотря на свои сильные стороны, сложная структура сетевых БД позволяла лишь немногим пользователям и проектировщикам использовать их с максимальной эффективностью. По мере роста объема обрабатываемой информации и повышения требований к базам данных и приложениям, проектирование, управление и использование БД становились все более трудоемкими.Отсутствие возможности обработки нерегламентированных запросов заставляло программистов писать код даже для выпуска простейших отчетов. И хотя существующие БД обеспечивали ограниченную независимость по данным, любые структурные изменения в базе данных заставляли полностью переделывать все прикладные программы, получающие информацию из БД. Ветераны баз данных помнят бесконечные задержки в получении информации, возникающие в иерархических и сетевых средах.Реляционная модель, впервые предложенная Э. Коддом (Е. F. Codd, компания IBM), стала настоящим прорывом как для пользователей, так и для проектировщиков. Концептуальная простота реляционной модели подготовила почву для подлинной революции в сфере баз данных.

В 70-х годах прошлого века работа Э. Кодда считалась весьма остроумной, но абсолютно непрактичной. Внешняя концептуальная простота реляционной модели достигается за счет ресурсов компьютера, а компьютеры в то время не обладали достаточной мощностью для реализации реляционной модели. К счастью, возможности компьютеров стремительно росли вместе с ростом эффективности операционных систем. К тому же стоимость вычислительной техники снижалась даже быстрее, чем возрастали ее возможности. Сегодня даже настольные компьютеры, стоимость которых несоизмеримо ниже, чем у их предков — больших универсальных машин, могут работать с очень сложным программным обеспечением реляционных баз данных типа Informix, Oracle, Ingress, DB2 и пр.

Основные понятия. Реляционная модель базы данных реализуется с помощью сложнейшей системы управления реляционной базой данных (реляционная СУБД — РСУБД, RDBMS — Relational Database Management System). Кроме того, что РСУБД выполняет те же основные действия, что и СУБД в иерархической и сетевой моделях, в ее состав входят и дополнительные функции, делающие реляционную модель простой для понимания и внедрения.Возможно, наиболее важным преимуществом РСУБД является предоставленная пользователям и проектировщикам возможность оперировать обычными понятиями человеческой логики. РСУБД берет на себя управление всеми сложными деталями физической реализации БД. Поэтому реляционная база данных представляется пользователю в виде набора таблиц, в которых хранятся данные.Каждая таблица (table) представляет собой матрицу, содержащую набор пересекающихся строк и столбцов (row/columns). Таблицы, которые также называются отношениями (relation), связаны друг с другом через общие свойства объекта. Например, таблица CUSTOMER (клиенты), представленная на рис. 1.9, может содержать номера торговых агентов, которые содержатся и в таблице AGENT (агенты).Общая связь между таблицами CUSTOMER и AGENT дает возможность обеспечить соответствие клиента и его агента, несмотря на то, что данные по клиенту хранятся в одной таблице, а данные о торговом агенте — в другой. Например, мы легко можем определить, что агентом клиента Дунаев является Алексеев, потому что значение AGENT_CODE таблицы CUSTOMER для клиента Дунаев равно 501, что соответствует значению AGENT_CODE для агента Алексеев в таблице AGENT. Хотя таблицы полностью независимы одна от другой, мы можем очень просто связать данные между таблицами. Реляционная модель также устраняет избыточность, имеющую место в системах файлов.

Рис. 1.9. Связь реляционных таблиц

Связывая таблицы AGENT и CUSTOMER через AGE,NT_CODE, мы можем определить, что агент Насонов (AGENT_CODE = 502) работает с клиентами Романов (10010), Кузнецов (10012), Ольхин (10013) и Братов (10016). Мы можем также определить, что агентом клиента Бритов является Окопов и т. д.

Тип связи (1:1, 1:М или M:N) часто отображается в реляционной схеме (схеме отношений), пример которой приведен на рис. 1.8. В реляционной схеме показываются связанные поля (в данном случае AGENT_CODE) и тип связи. При создании рис. 1.10 использовалась СУБД Microsoft Access, в которой символ "¥ " обозначает "много". В этом примере таблица CUSTOMER представляет собой "многих", поскольку у агента (AGENT) может быть несколько клиентов (CUSTOMER). Co стороны таблицы AGENT связь обозначена как "1", поскольку с каждым клиентом (CUSTOMER) работает только один агент (AGENT).

Рис. 1.10. Реляционная схема

В реляционной таблице хранятся наборы связанных логических объектов (сущностей, entities). В этом отношении таблица реляционной базы данных имеет сходство с файлом. Но есть одно очень важное отличие таблицы от файла: таблица обеспечивает полную независимость по данным, а также структурную независимость, поскольку является исключительно логической структурой. Пользователя проектировщика совершенно не касается, каким образом данные физически хранятся в базе данных; здесь принимается в расчет только их собственное представление о структуре данных. И это свойство реляционной модели стало источником настоящей революции в базах данных.

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

    • Структурная независимость. Поскольку реляционная модель базы данных не использует навигационную схему доступа к данным, маршрут доступа к данным не имеет значения для проектировщиков, программистов и конечных пользователей реляционной базы данных. Изменения в структуре реляционной БД ни в коем случае не влияют на доступ к данным со стороны СУБД. Поэтому в реляционной модели базы данных достигается структурная независимость, не свойственная сетевым и иерархическим моделям. (Структурная независимость имеет место, когда изменения в структуре БД не влияют на возможность доступа к данным со стороны СУБД. В отличие от реляционной базы данных, любые изменения в древовидной структуре иерархической базы данных или во множествах сетевой БД будут оказывать влияние на маршруты доступа к данным, что потребует изменений во всех программах доступа к данным.)
    • Концептуальная простота. Хотя иерархическая и сетевая модели понятнее системы файлов, на смену которой они пришли, на концептуальном уровне реляционная модель еще более проста для понимания. Поскольку реляционная модель дарует нам роскошь отрешения от подробностей физического хранения данных, мы можем целиком сосредоточиться на логическом представлении базы данных, т.е. можно уделить большее внимание нашему естественному представлению о хранении данных, а не методу "взгляда" на данные со стороны компьютера.
    • Простота проектирования, реализации, управления и использования. Поскольку в реляционной модели достигаются и независимость по данным, и структурная независимость, становится проще проектировать базу и управлять ее содержимым.
    • Нерегламентированные запросы. Реляционные базы данных заняли доминирующее положение на рынке не в последнюю очередь еще и потому, что обладают мощной и гибкой возможностью создания запросов. Для большей части программного обеспечения реляционных БД стандартным языком запросов является Structured Query Language (SQL — язык структурированных запросов). Сокращение "SQL" одни произносят как "сиквел" (sequel), другие как "эс-ку-эль", но как его ни назови, именно SQL сделал чистый язык нерегламентированных запросов реальностью. SQL относится к так называемым языкам четвертого поколения (4GL), которые дают возможность пользователям определить, что необходимо сделать, без указания того, как это надо сделать. В РСУБД язык SQL используется при трансляции запроса пользователя в специальный код, необходимый для извлечения запрошенной информации. Следовательно, запросы в реляционной базе данных требуют меньшего программирования, чем в любой другой базе или в среде системы файлов.
      Имейте в виду, что любое SQL-приложение реляционной БД состоит из трех частей: интерфейс пользователя, набор таблиц внутри БД и SQL-машина (SQL "engine"). Интерфейс включает в себя систему меню, операции запросов и генераторы отчетов. В основном такой интерфейс дает возможность конечному пользователю взаимодействовать с данными.
      В значительной степени скрытая от конечного пользователя SQL-машина выполняет трудную работу. Внутри РСУБД SQL используется для создания структуры таблиц, обслуживания словаря данных и системного каталога, обеспечения доступа к таблицам БД, а также для трансляции запросов пользователя в формат, пригодный для обработки компьютером. Обслуживание системы базы данных является важнейшей задачей, которую РСУБД выполняет в значительной степени скрытно от конечного пользователя.

    • Мощная система управления базой данных. Хорошая РСУБД является более сложной частью программного обеспечения, нежели СУБД иерархических и сетевых баз данных. Это связано с тем, что она выполняет гораздо больше задач (и значительно более сложных) как для проектировщиков, так и для пользователей. В результате хорошая РСУБД скрывает физический уровень сложности системы как от проектировщика, так и от пользователя.

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

    Недостатки. Несмотря на существенные преимущества реляционной модели перед иерархической и сетевой, она имеет и ряд недостатков.

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

    Поскольку недостатков у реляционной базы данных значительно меньше (и они не столь уж существенны), чем достоинств, реляционные модели стали быстро доминировать на рынке БД.

     

    1.5.4. Модель "сущность-связь"

    Концептуальная простота реляционной модели позволила расширить возможности баз данных. Поэтому внедрение реляционной технологии послужило поводом к появлению все более сложных транзакций и хранению более сложной информации. В свою очередь быстрое увеличение требований к транзакциям и хранимой информации вело к созданию более сложных структур базы данных, таким образом стимулируя появление все более изощренных и эффективных инструментальных средств проектирования БД. Для получения требуемых результатов сложнейшее проектирование должно было хоть как-то компенсироваться простотой концепции. Хотя реляционная модель была с понятийной точки зрения гораздо проще иерархической и сетевой моделей, ее достоинства все же были не столь велики, чтобы позволить ей стать эффективным инструментом проектирования. Поскольку проще исследовать структуру графически, чем описывать ее в текстовой форме, проектировщики БД посчитали удобным использовать соответствующие изобразительные средства, в которых логические объекты (сущности, entity) и их связи (relationship) могли изображаться графическими средствами.Несмотря на то, что в последнее десятилетие было разработано великое множестве инструментальных средств моделирования данных, модель "сущность-связь" (ER-модель) является, безусловно, самым широко распространенным и простым графическим инструментом моделирования данных для разработки реляционных БД.

    Питер Чен (Peter Chen) впервые ввел понятие ER-модели в 1976 году в своей основополагающей статье. Модель "сущность-связь" (ER-модель) дает графическое представление логических объектов (сущностей) и их отношений в структуре базы данных. Именно такое графическое представление данных сделало ER-диаграммы популярным средством на концептуальном уровне моделирования данных. Более того, ER-модель дополнила концепции реляционной модели, создав основы хорошо структурированной среды проектирования, гарантирующей надлежащую разработку реляционных баз данных.

    Основные понятия. ER-модели обычно представляются в виде диаграмм "сущность-связь" (ER-диаграмма, ERD). В ER-диаграмме используется графическое представление модели компонентов базы данных.Основу ER-модели составляют следующие компоненты.

      • Сущность. Ранее в этой главе мы определили сущность (логический объект), как "персону, местоположение или предмет, сведения о которых подлежат сбору и хранению. В ER-модели сущность представлена в виде прямоугольника. Название сущности (имя существительное) записывается в центре прямоугольника, как правило, заглавными буквами и предпочтительнее в единственном числе: Художник лучше| чем Художники и Сотрудник лучше чем Сотрудники. Обычно если ER-диаграмма связана с реляционной моделью, сущность отображается на реляционную таблицу. Каждая строка реляционной таблицы соответствует экземпляру сущности (entity instance или entity occurrence) в терминах ER-модели.

    Примечание. Совокупность подобных сущностей называется набором сущностей (entity set). Например, можно представить себе файл AGENT (см. рис. 3) как совокупность трех агентов (сущностей) в наборе сущностей AGENT. Формально говоря, ER-диаграмма описывает наборы сущностей. К сожалению, разработчики ER-диаграмм под "сущностью" понимают "набор сущностей", и мы будем следовать этой устоявшейся практике при обсуждении ER-диаграмм и их компонентов.Сущность описывается набором атрибутов. Каждый атрибут описывает отдельное свойство сущности. Например, сущность EMPLOYEE (сотрудник) имеет такие атрибуты, как номер социального страхования, фамилию и имя.

      • Связь описывает соединение между данными. Большинство связей описывает соединение между двумя сущностями. При обсуждении моделей баз данных мы указали три возможных типа связей между данными: "один-ко-многим" (1:М), "многие-ко-многим" (M:N) и "один-к-одному" (1:1). Разработчики ER-диаграмм для обозначения типа связи используют термин связность (на ER-диаграммах связность записывается рядом с прямоугольником, соответствующим сущности). Связь изображается на ER-диаграмме ромбом, соединенным с соответствующей сущностью. Название связи (в глагольной форме) записывается внутри ромба. Например, в каждом из подразделений компании работает множество сотрудников. А художник пишет много картин.

    На рис. 1.11 проиллюстрированы ER-диаграммы с использованием связей, которые мы обсуждали при знакомстве с моделями баз данных.Связь "один-ко-многим" (1:М): художник может написать много картин; каждая картина написана одним художником.

    Связь "многие-ко-многим" (M:N): сотрудник (EMPLOYEE) может изучать много специальностей (SKILL); каждую специальность могут изучать несколько сотрудников.

    Связь "один-к-одному" (1:1): сотрудник (EMPLOYEE) руководит одним магазином (STORE); каждым магазином управляет один сотрудник

    Рис. 1.11. Представление отношений на ER-диаграмме (модель Чена)

     

    ER-диаграмма, представленная на рис. 1.11, построена на основе так называемой модели Чена, описанной Питером Ченом в его вышеупомянутой работе. На ER-диаграммах, созданных на базе модели Чена, связи обозначаются ромбами, а сущности — прямоугольниками.Другой широко известный способ построения ER-диаграмм, называемый "птичья лапка", представлен на рис. 1.12. Название "птичья лапка" произошло от специфичного вида символа, которым обозначается связь в направлении "многие" (хотя мы будем пользоваться ER-диаграммами на основе модели Чена, все же необходимо уметь применять и другие модели).

    Рис. 1.12. Представление отношений на ER-диаграмме (модель "птичья лапка")

    Преимущества. Человеку удобнее работать с графическим изображением (любое самое подробное и полное описание дома не может сравниться с его изображением). Поэтому не удивительно, что ER-модель стало трудно отделить от ER-диаграмм, с помощью которых она изображается. Фактически проектировщики баз данных считают ER-модель и ER-диаграмму двумя сторонами одной медали. В любом случае мы можем указать их достоинства.

      • Исключительная концептуальная простота. Все модели баз данных обеспечивают лучшее логическое представление данных, чем система файлов. Однако ER-модель дает очень простое и наглядное представление об основных логических объектах БД и существующих между ними связях. Поэтому использование такой модели значительно упрощает разработку и организацию сложнейших баз данных.
      • Наглядное представление. ER-модель дает проектировщикам баз данных, программистам и конечным пользователям простое наглядное представление о данных и связях между ними. Поэтому ER-модель является чрезвычайно эффективным средством, интегрирующим различные представления о данных в единую рабочую среду.
      • Интеграция с реляционной моделью баз данных. ER-модель прекрасно увязывается с реляционной моделью БД. Такая интеграция помогает хорошо структурировать процесс проектирования реляционных БД.

    Недостатки. Несмотря на то что ER-моделирование и ER-диаграммы стали популярным средством в арсенале методов разработки баз данных, у проектировщиков все же имеется к ним ряд претензий.

      • Недостаточные возможности представления ограничений. С помощью этой модели легко изобразить ограничения, имеющие непосредственное отношение к связности. Например, ограничение "преподаватель может вести как несколько групп, так и ни одной группы (если он научный работник), но не более четырех групп" легко изображается средствами ER-модели. К сожалению, есть множество важнейших ограничений, которые невозможно смоделировать методами ER-модели, например: "оценки студентов варьируются в диапазоне от 0.0 до 4.0" и "пилот не может работать более 10 часов подряд". Такие ограничения должны обрабатываться на уровне приложений.
      • Ограниченные возможности представления отношений. Связи представляются как нечто происходящее между сущностями. Поэтому связи между атрибутами внутри сущностей не могут быть представлены средствами ER-модели. Например, нет способа отобразить связь между оценкой качества подготовки студента и количеством прослушанных им часов. К тому же когда сущности связаны множеством связей с другими сущностями, значение таких связей будет трудно оценить.
      • Отсутствие языка манипулирования данными. Сторонники реляционной модели обычно указывают на отсутствие команд манипулирования данными в ER-модели. Отсутствие таких команд делает ER-модель "неполной".
      • Утеря информационного наполнения. Эта модель сильно "переполняется", если в ней отобразить все ее атрибуты. Поэтому проектировщики баз данных обычно избегают полного отображения атрибутов, таким образом уменьшая информационное наполнение ER-модели.

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

     

    1.5.5. Объектно-ориентированная модель

    Все более усложняющиеся практические задачи стимулируют появление иных моделей данных, точнее отображающих реальный мир. Первой из таких моделей стала семантическая модель данных (semantic database model — SDM), разработанная M. Хаммером и Д. Маклеодом в 1981 году.SDM позволяет моделировать как данные, так и их отношения в единой структуре, называемой объектом. Поскольку основной структурой модели является объект, модель SDM получила название объектно-ориентированной модели базы данных (object-oriented database model, OODM). Управление OODM осуществляется с помощью системы управления объектно-ориентированной базой -данных (ООСУБД, OODBMS).

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

    Примечание Слово "семантика" означает смысл, значение. Поэтому в терминах объектно-ориентированной БД говорят, что объект имеет семантическое наполнение.

    Последующее развитие OODM дало возможность включить в содержимое объекта все операции, которые могут над ним выполняться, например, изменение значения, поиск величины, распечатка параметров. Поскольку объект включает в себя и данные, и различные типы связей, и процедуры, его можно рассматривать как самостоятельный модуль, который может (способен) стать основным функциональным блоком автономных структур.Хотя идеи OODM использовались уже начиная с 70-х годов двадцатого века, по крайней мере четыре фактора оказали влияние на значительное укрепление позиций этого подхода в 1990-х годах.

      • Растущая стоимость производства и необходимость поддержки все более сложного программного обеспечения привлекли основное внимание к возможности повторного использования кода. Разработка программ в виде самостоятельных модулей, выполняющих специфичные функции, оказала самое сильное влияние на возможность повторного использования кода. Такие модули могут затем "компоноваться" различными способами для создания широкого спектра приложений. Свойства объектно-ориентированной модели базы данных позволяли считать ее очень перспективной в сфере модульных концепций.
      • В современные базы данных зачастую включают графику, видео и звук в дополнение к текстовой и цифровой информации. Усложнение типов данных и повышение требований к системе перестало укладываться в рамки реляционного подхода. Поскольку OODM ставит своей целью как раз обработку сложных типов данных, она и стала естественной основой для создания объектно-ориентированной модели базы данных.
      • По мере того как информационная среда становилась все более сложной, возникла необходимость поддержки все более сложных транзакций, также повысились требования к качеству информации. Например, компания автомобильных грузоперевозок может счесть необходимой разработку специальных подробных компьютерных карт, на которых будут точно указаны местоположение трейлеров, пункт назначения каждого трейлера, его груз и примерное время доставки. Некоей машиностроительной компании может потребоваться покомпонентный вывод изображения изделия для разрешения по телефону проблем, возникших у клиента.
      • Возросшая мощность компьютеров позволяет выполнять на них огромную вычислительную работу при обработке сложных объектно-ориентированных данных, выполнении соответствующих процессов и процедур.

    Основные понятия. Основу объектно-ориентированной модели данных составляют следующие компоненты.

      • Объекты модели данных являются абстракциями сущностей и событий реального мира. В общих чертах любой объект может рассматриваться как эквивалент сущности ER-модели. Точнее, любой объект представляет только один экземпляр сущности (семантическое наполнение объекта определяется через несколько элементов этого списка).
      • Атрибуты описывают свойства объекта. Например, в объект PERSON (персона) включены атрибуты Name (имя), Social Security Number (номер социального страхования) и Date of Birth (дата рождения).
      • Объекты, которые совместно используют одни и те же характеристики, группируются в классы. Класс представляет собой совокупность подобных объектов со структурой совместного доступа (атрибуты) и поведением (методы). В общем случае класс напоминает набор сущностей ER-модели. Однако класс отличается от набора сущностей тем, что он содержит набор процедур, называемых методами. Метод класса представляет собой реальное действие, например, поиск заданного имени в объекте PERSON, изменение имени или распечатку адреса. Иначе говоря, методы эквивалентны процедурам в традиционных языках программирования. В терминах объектно-ориентированного подхода методы определяют поведение объекта (некоторые варианты OODM, например, семантическая модель объекта, не включают в себя понятие метода).
      • Классы организованы в иерархию классов. Иерархия классов похожа на перевернутое дерево, в котором каждый класс имеет только одного предка. Например, классы CUSTOMER и EMPLOYEE имеют родительский класс PERSON (обратите внимание на явное сходство с иерархической моделью!).
      • Наследование - это возможность объекта внутри иерархии классов наследовать атрибуты и методы классов, структурно расположенные выше его. Например, мы можем создать два класса CUSTOMER и EMPLOYEE как подклассы класс PERSON. В этом случае классы CUSTOMER и EMPLOYEE будут наследовать все атрибуты и методы от класса PERSON.

    Преимущества. Объектно-ориентированная модель данных имеет несколько важнейших преимуществ перед ER-моделью.

      • Добавление семантического наполнения. Добавление семантического наполнения делает модель данных более значимой.
      • Во внешнее представление включено семантическое наполнение. Как и ER-диаграммы, объектно-ориентированная модель представляет отношения в наглядной форме. Однако в наглядное представление объектно-ориентированной модели включается семантическое наполнение, что упрощает визуализацию сложных отношений внутри и между объектами.
      • Целостность базы данных. Так же как и иерархическая, объектно-ориентированная модель использует наследование для защиты целостности базы данных. Однако объекты OODM содержат большее число типов связей и более сложные связи.
      • Структурная независимость и независимость по данным. Автономия объекта объектно-ориентированной модели гарантирует структурную независимость и независимость по данным.

    Недостатки. Несмотря на впечатляющие достоинства объектно-ориентированной модели, она все же не смогла выиграть сражение с реляционными базами данных. Причин у этого поражения много, и недостатки OODM сыграли здесь не последнюю роль.

      • Отсутствие должной стандартизации. Пока не существует стандартов для объектно-ориентированной модели. Хуже всего то, что нет стандартного метода доступа к данным. Этот недочет создает проблемы при доступе к данным от различных источников (различные поставщики поддерживают различные методы доступа к данным, как правило, несовместимые).
      • Сложная навигация доступа к данным. Метод доступа к данным похож на стиль иерархической и сетевой модели.
      • Трудность изучения. Недостаток стандартизации и трудности, вызванные навигационным стилем доступа к данным, приводят к затруднениям в изучении объектно-ориентированной модели, даже большим, чем при изучении реляционной модели. Несмотря на то что мы с легкостью используем объекты — перетаскиваем объекты Windows на экране дисплея, не заботясь и не задумываясь о тех процессах, которые обеспечивают это действие, — моделирование данных и реализация объектно-ориентированных баз данных — это совершенно другая история. Объекты очень сложны, и тот факт, что они могут иметь большое семантическое наполнение, делает их трудными для проектирования и реализации. Такое "программистское" происхождение привело к тому, что конечные пользователи считают объектно-ориентированные системы трудными для понимания и использования.
      • Медленное выполнение транзакций. Объектно-ориентированные системы сложнее чем реляционные модели. Поэтому реализация такой модели требует солидных затрат на приобретение оборудования и операционной системы. Сложность конфигурации и повышенные системные требования приводят к замедлению выполнения транзакций. И поскольку транзакции являются основой рабочих баз данных, медленные транзакции для них просто недопустимы.

     

    Тема 1.6. Эволюция моделей данных

    Системы управления базами данных всегда эволюционировали в сторону поиска новых способов моделирования постоянно усложняющейся картины реального мира. Сводка наиболее известных моделей данных представлена на рис. 1.13.

    Рис. 1.13. Развитие моделей данных

    Каждая новая модель данных "обучалась" на недостатках предыдущих моделей. Сетевая модель сменила иерархическую, поскольку ее разработчики упростили представление сложных ("многие-ко-многим") связей. В свою очередь реляционная модель имеет преимущество перед иерархической и сетевой моделями, поскольку упрощает представление данных, обеспечивая высокую независимость и предоставляет в распоряжение пользователей относительно простой язык запросов. Хотя обсуждение достоинств и недостатков более старых иерархических и сетевых моделей и новейших реляционных моделей продолжается уже несколько лет, реляционная модель, тем не менее, сейчас является основной моделью баз данных для бизнес-приложений.

    В связи со значительным усложнением приложений появились две новые модели данных: объектно-ориентированная модель (OODM) и расширенная реляционная модель данных (Extended Relational Data Model — ERDM). Модель ERDM вышла победителем в соревновании этих двух моделей по признанию многих исследователей баз данных и стала ответом на вызов, сделанный приверженцами объектно-ориентированной модели. Эта модель включила в себя основные достоинства объектно-ориентированной модели, унаследовав простоту структуры реляционных баз данных. Вот почему СУБД, основанные на ERDM, часто называют объектно-реляционными системами управления базой данных (ОРСУБД).

    Принимая во внимание огромное количество установленных реляционных баз и появление ERDM, объектно-ориентированная модель встретила сильное сопротивление. Однако идеи объектно-ориентированной модели стали основой многих систем анализа баз данных и процедур проектирования. Вдобавок объектно-ориентированный подход используется во многих генераторах приложений и других инструментальных средствах.

    Однако OODM и ERDM различаются в своей основе и по стратегии, и по природе подхода к проблеме. Если ERDM основана на концепциях реляционной модели, то OODM базируется на концепциях объектно-ориентированной модели и семантической модели данных. Модель ERDM в основном приспособлена для бизнес-приложений, в то время как OODM используется в весьма специальных инженерных и научных приложениях. Наиболее вероятным сценарием завершения борьбы двух подходов представляется вариант постепенного слияния объектно-ориентированных и реляционных концепций, а также связанных с ними процедур.

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

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

      • Модель данных должна иметь достаточный уровень концептуальной простоты без ущерба для семантической полноты базы данных. Бессмысленно иметь модель данных, понять которую труднее, чем окружающую действительность.
      • Модель данных должна как можно точнее соответствовать реальному миру. Этой цели проще достичь, если вкладывать больше смысла (семантики) в представление данных модели (семантика имеет отношение к динамическому поведению данных, в то время как представление данных составляет статический аспект сценария реальной действительности).
      • Устойчивость и целостность любых моделей данных должны быть согласованы с представлением о преобразованиях (поведении) в реальном мире.

     

    1.6.1. Модели баз данных и Интернет

    Если что-то и есть постоянное в мире баз данных, так это то, что стратегии баз данных всегда находятся в движении. Использование Интернета как важнейшего инструмента для бизнеса радикально изменило роль и масштабы рынка баз данных. Фактически влияние, которое Интернет оказал на рынок баз данных, послужило поводом создания новых стратегий БД, в которых OODM и ERDM-O/RDM занимают скромное положение при разработке доступа к базам данных через Интернет. Поэтому теперь вместо продолжения дуэли баз данных "OODM против ERDM мы видим, что поставщики ведут основные разработки в направлении создания систем баз данных, обеспечивающих простой и удобный интерфейс с Интернетом. Говоря кратко, популярная база данных в "эпоху Интренета" должна иметь следующие свойства:

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

    Очевидно, что если база данных вписывается в общую структуру Интернета, то ее происхождение не имеет существенного значения. Это одна из причин преуспевания реляционной модели, которая заимствовала компоненты из других моделей баз данных. Например, новейшая база данных корпорации Oracle — Oracle 9 — содержит объектно-ориентированный компонент внутри структуры реляционной базы данных, точно так же, как текущая версия базы данных DB2 компании IBM. Может быть, самым главным препятствием господству OODM является то, что преимущества использования Интернета — а, следовательно, повышение значимости бизнеса — имеют большее значение, чем обеспечение чистых объектно-ориентированных инструментальных средств. Поэтому объектно-ориентированное моделирование нацелено сейчас в основном на поддержку работы в Интернете, вместо разработки баз данных, основанных на концепциях объектно-ориентированного моделирования.

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


назад | содержание | вперед