Гибкий.ру Иерархическая модель базы данных
Самой ранней моделью отображения сложной информационной структуры является иерархическая база данных. В иерархических базах данных существует организация данных на основе отношений “предок-потомок”.
Каждая запись имеет только одну родительскую и несколько дочерних записей. Физические указатели от одной записи к другой используются как ссылки на запись. Основным недостатком иерархической структуры базы данных является невозможность реализации отношений “многие-ко-многим”.
Базы данных с иерархиями. Перекрестие, составленное из объектов разных уровней, можно увидеть в представлении иерархической базы данных в виде перевернутого дерева. Один объект занимает верхний уровень (корни дерева), а объекты со второго уровня заполняют второй уровень.
Между объектами существуют связи, каждая из которых может включать несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект, более близкий к корню) и потомков (в случае, если объект-предок не имеет последующих). Объекты, имеющие общего предка и имеющие общих предков, являются близнецами.
Вы можете работать с каталогом папок Windows, иерархической базой данных, запустив File Explorer. На верхнем уровне расположены папки Мой компьютер, Мои документы и Корзина.
В свою очередь, папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков (Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам (сканер, bluetooth и.т.д.) – на
рис.
4.1.
Термины элемент, блок и запись (содержание) используются для определения элемента, агрегата или записи (группы), записи (суммы) и отношения группы.
Корневая запись каждого дерева должна содержать ключ с уникальным значением. Ключи некорневых записей имеют уникальное значение только в рамках группового отношения.
Групповые отношения изображаются графически как дуги ориентированного графа, а типы записей – как вершины (диаграмма Бахмана).
Иерархическая модель предлагает фиксированное членство и режим автоматического включения. В результате родительская запись любой неукорененной записи в базе данных должна присутствовать, чтобы ее запомнили.
Резюме и рекомендации
Каждая из трех рассмотренных технологий
представления и обработки данных в БД имеет свои
преимущества и недостатки. Реляционная модель,
сегодня наиболее укоренившаяся и
поддерживаемая, вероятно останется такой по
крайней мере еще несколько лет. Она также
является парадигмой наиболее строгой структуры,
что работает как в ее пользу, так и против нее.
Функциональные требования СУБД фактически
диктуют структуру базы данных, что приводит к
большему единообразию стиля, который легче
поддерживать. С другой стороны, данные,
естественным образом не укладывающиеся в
табличную схему, требуют особенно сложных
структур, которые не назовешь интуитивно
прозрачными, а значит, усложняющих сопровождение
БД.
Кроме того, реляционные базы почти полностью
определяются структурой, а не процедурами
(методами). Это упрощает документирование БД с
помощью утилит словаря данных и требует меньше
“внутреннего” программирования. С другой
стороны, если спецификации БД неустойчивы или
развиваются, то нужно произвести изменения на
уровне словарей данных, что обычно влечет за
собой временную недоступность данных и
пересмотр описания ее структуры.
БД с древовидной структурой (например, М) по
своей природе значительно менее
структурирована, чем эквивалентная реляционная
БД. Это допускает большую свободу в
конструировании БД, что в свою очередь позволяет
повысить эффективность и/или
“естественность” модели данных.
Кроме того,
гибкость и процедурная природа этих БД облегчает
их адаптацию к изменениям функциональных
спецификаций, неизбежным по мере развития базы
данных. Дополнительные и незапланированные
элементы данных зачастую могут добавляться без
закрытия доступа к БД, а новые операции – без
структурного изменения данных.
С другой стороны, повышенная гибкость ведет к
дополнительному “утяжелению” документации
в виде “местных” стандартов на структуры
данных и программ. Неспособность адекватно
задокументировать процедурно-структурный
характер базы данных приводит к значительно
большим проблемам на стадии сопровождения, чем в
случае реляционных БД.
Объектно-ориентированный подход к системам БД
широко разрекламирован как грядущая парадигма,
которая заменит реляционную модель через
несколько лет. Он действительно дает большую
гибкость по сравнению с реляционной моделью и
позволяет сосредоточить внимание при разработке
и документировании на описании отдельных типов
предметов, а не на общей структуре базы данных.
К сожалению, объектно-ориентированный подход
пока не столь широко испытан и не настолько
“зрел”, как остальные два подхода. Наиболее
доступный подход к объектно-ориентированной БД –
это наложить ее на реляционную или древовидную
модель. Так как ООП в большей степени связан с
процессом, чем со структурой, представляется, что
древовидная модель подходит лучше.
Таким образом, выбор модели БД сводится к
тщательному изучению данных, которые должны быть
смоделированы, и доступных ресурсов. Базы данных,
которые стабильны, хорошо определены и легко
описываются в терминах двумерных таблиц, а также
нуждаются в широкомасштабной поддержке,
наилучшим образом строятся с использованием
реляционной СУБД, такой как Oracle или Sybase.
Развивающиеся и сложные БД, со множеством связей
“многие-ко-многим” и разреженными данными, и
которые определяются, главным образом,
процедурно, лучше подходят к древовидной модели
М. [Прим. ред. перевода: Достоин упоминания и
гибридный вариант, реализуемый путем
“натягивания” реляционной структуры на
древовидную (например, с помощью MSM-SQL).
Относительно маленькие БД, которые в
значительной степени определяются описываемыми
ими объектами и действиями, которые эти объекты
могут выполнять, наверное, лучше реализуются при
помощи объектно-ориентированного подхода.
Произойдет ли ожидаемый революционный переход к
ООБД путем наслаивания ООП поверх реляционной
модели или М, или же на основе чисто
объектно-ориентированной платформы, пока, к
сожалению, не известно.
Применяя изложенные соображения, справедливые
по отношению к новым проектам баз данных, при
модернизации существующих БД не следует
пренебрегать такими важными факторами, как тип
существующей системы и имеющиеся человеческие
ресурсы. Все три модели, ставшие предметом
обсуждения, способны отобразить одни и те же
данные.
Сравнительные тесты различных систем
редки и часто противоречивы, но кажется
бесспорным, что проектировщик/разработчик,
знакомый с одной из этих технологий, может
создать более эффективную базу данных (с точки
зрения и времени, и пространства), используя те
средства, которые ему наиболее знакомы.
Сетевая модель базы данных
На разработку этого стандарта значительное влияние оказали ученые Европы. Основы сетевой модели данных были созданы в середине 1960-х годов, а эталонная версия была представлена на заседании рабочей группы по языкам баз данных (CODASel) в 1971 году.
Определение сетевой модели данных аналогично определению иерархической модели данных. Она включает множество записей, которые могут быть членами группы или владельцами. используя соотношение 1:N.
Запись в сетевой модели может принадлежать к нескольким группам. Каждое групповое отношение в этой модели имеет имя и различие между его типом и экземплярами.
Тип группового отношения определяется его именем и определяет свойства, общие для всех экземпляров этого типа. Экземпляр группового отношения представлен в виде владельца и набора (возможно, пустых) подчиненных записей. Существует ограничение: один экземпляр записи не может быть членом двух групповых отношений одного типа (например, сотрудник из примера в шаге 1), поскольку он работает во всех отделах одновременно.
Иерархическая структура
рис.
4.2 преобразовывается в сетевую модель, следующим образом (см.
рис.
4.3):
Индивидуальное групповое отношение отличается следующими характеристиками:
Способ упорядочения подчиненных записей
Запись может быть расположена по-разному, если она назначена подчиненной в нескольких группах.
Режим включения подчиненных записей
Режим исключения.
В групповых отношениях принято различать три класса принадлежности к подчиненным записям:
- Исправлено. Подчиненная запись связана с записью владельца и может быть исключена из групповых отношений только путем ее удаления. При удалении записи владельца автоматически удаляются и все подчиненные записи. В приведенном выше примере фиксированное членство подразумевает групповое отношение “CONTRACT” между записями “CONTRACT” и “CUSTOMER”, поскольку контракт не может существовать без заказчика.
- Обязательно. Допустимо переоформить подчиненную запись на другого владельца, но она не может существовать без владельца. Чтобы удалить запись о владельце, она не должна иметь подчиненных записей с обязательным членством. Это связь между записями COUNTRY и DIVISION. Если отдел ликвидируется, все его сотрудники должны быть переведены в другие отделы или уволены.
- Необязательно. Вы можете исключить запись из групповых отношений, но сохранить ее в базе данных, не присоединяя к другому владельцу. Когда запись-владелец удаляется, ее подчиненные записи – необязательные члены – сохраняются в базе данных и больше не участвуют в групповых отношениях данного типа. Примером такого группового отношения является ИСПОЛНЕНИЕ между “ПОДРЯДЧИКАМИ” и “ПОДРЯДЧИКОМ”, так как в организации могут быть сотрудники, деятельность которых не связана с выполнением договорных обязательств перед клиентами.
Системы управления базами данных с
древовидной структурой (например, m)
Теоретическая теория
Структура этих СУБД базируется на деревьях и на
ориентированных графах в большей степени, чем на
таблицах. В этих БД с древовидной структурой
данные представлены в виде набора узлов. Каждый
узел дерева может хранить данные и может иметь
некоторое количество (ориентированных) связей с
узлами-потомками.
Обычно не требуется, чтобы
узлы-потомки и/или узлы, имеющие один узел-предок
были одного типа. Обычно допускается, что узел
содержит открытый список связей с
многочисленными узлами того же типа, разрешая
прямое представление связей
“многие-ко-многим”.
В БД с сетевой структурой, требование
древовидности (каждый узел должен иметь точно
одного предка, кроме корня, который вообще не
имеет предков) смягчено. Связи могут быть
ограничены созданием ориентированного
нециклического графа (ОНГ) (никакая
последовательность связей, идущих от узла, не
может вернуться обратно к узлу), или может быть
разрешен любой ориентированный граф (набор узлов
и ориентированных связей между парами узлов без
каких-либо других ограничений).
В М воплощена концепция БД с древовидной
структурой (дочерние узлы являются компонентами
родительского узла) и разрешает внешние связи
(единичные или в массиве) с любыми другими узлами.
Пример, который мы использовали для реляционной
базы данных, может быть реализован на М при
помощи структуры, представленной на рис.6
(предполагаем, что каждый служащий – сотрудник
только одного отдела).
Эта структура, однако, не подходит, если
предположение, что служащий числится только в
одном отделе, неверно. Она также плохо работает,
если служащий меняет отдел, даже если он при этом
является членом хотя бы одного отдела. Это
происходит из-за того, что вместо простой
корректировки указателя (фактически одного
числа) целый набор данных (служащий) должен быть
перемещен из одного элемента данных (отдел) в
другой.
Более совершенная структура представлена на рис.3 и рис.7.
 | Она содержит два вида вершин верхнего уровня, Отдел и Служащий, оба – массивы (то есть может быть множество различных экземпляров каждого). Каждый Отдел имеет определенного Руководителя, который содержит указатель на экземпляр Служащий (Служащий, который является руководителем отдела). Каждый узел Отдел также имеет массив указателей на экземпляры объекта Служащий, представляющий всех служащих отдела, включая Руководителя (при этом назначение нового руководителя не выкидывает автоматически снятого руководителя из отдела). Аналогично, каждый Служащий имеет массив определенных узлов Отдел, каждый из которых состоит из указателя на узел Отдел и флаг для индикации, является ли данный служащий руководителем этого отдела. Служащие могут быть членами (и даже руководителями) многочисленных отделов, просто имея многочисленные экземпляры узла Отдел, определенные для Служащего. |
Рис.7 |
Эта модель данных содержит все те же связи, что
и реляционный пример, который был дан выше. Хотя
отдельные компоненты имеют более сложную
структуру, чем отдельные таблицы реляционной
модели, модель данных в целом в этом
представлении может быть более интуитивно
понятной.
Давайте теперь обратимся ко второму примеру –
упрощенная регистрация пациента. Используя БД с
древовидной структурой, мы можем создать
следующую модель данных для этой БД (см. рисунок
8).
Рис.8
Эта модель данных имеет всю ту же информацию о
структуре, что и реляционная модель,
рассмотренная нами ранее (включая ограничение,
что процедура может быть объявлена только
жалобой из списка жалоб пациента, что требовало
введения в реляционной модели правила
структурной целостности).
Практические вопросы
Структуры, определенные выше, базируются на
языке М, включающем элементы управления базой
данных. М – это имеющий ANSI стандарт язык
программирования, употребляемый уже более 20 лет,
который подвергся целому ряду существенных
преобразований (последний раз – в 1995 году.
Доля
рынка, занимаемая М, никогда не была большой и
относительно сокращалась (при абсолютном росте)
в течение нескольких лет. М используется в
основном в здравоохранении и банковском деле,
кроме того – в ряде вертикальных приложений,
таких как выпуск “желтых страниц”. М часто
объявляли мертвым, но тем не менее он продолжает
жить.
Слабое место большинства М приложений – это
пользовательский интерфейс, до недавнего
времени вынужденно отвечавший модели
“roll-and-scroll” семидесятых, созданную для тупых
или умеренно интеллектуальных терминалов. За
последние 2 года большинство крупных продавцов М
выпустили средства, открывшие возможность
реализации современных пользовательских
интерфейсов c помощью инструментов третьих фирм.
Относительно небольшое присутствие на рынке (а
значит, ограниченность средств) замедляет
развитие М-систем их разработчиками и делает
рынок непривлекательным для большинства крупных
третьих фирм. Роста популярности открытых
стандартов делают средства разработки сторонних
фирм все более доступными и для М.
Большинство сегодняшних М систем можно
свободно связывать с реляционными БД при помощи
SQL и ODBC. М может служить как внешним, так и
внутренним интерфейсом в этих “совместных
предприятиях”. Однако для того, чтобы
использовать этот мост, администратор БД должен
создать отображение структуры М данных в
реляционную модель, так как SQL и ODBC предполагают
именно эту модель.
В комитете развития М прикладываются
значительные усилия для расширения языка в таких
направлениях, как поддержка
объектно-ориентированного программирования,
создание объектно-ориентированных БД и
управление ими. Гибкость структур данных и
позднее связывание типов данных в М позволяет
воплотить “настоящий”
объектно-ориентированный подход (возможно,
исключая инкапсуляцию) в противовес методу
“наслаивания”, когда
объектно-ориентированные средства реализуются
как надстройка над реляционной БД.
Если М станет объектно-ориентированной СУБД и
продавцы снабдят его средствами разработки
интерфейса, то он может стать ведущим игроком в
индустрии баз данных. Без этого ему, возможно,
уготованы лишь вторые роли, за исключением тех
вертикальных “ниш”, где он имеет верных
приверженцев.
Системы управления реляционными
базами данных. (сурбд)
Теоретическая теория
Все реляционные базы данных используют в
качестве модели хранения данных двумерные
таблицы. Эта модель выбрана потому что она в
основном знакома всем пользователям и
рассматривается как “естественный” путь
представления данных. Любая система данных, не
имеет значения какой сложности, может быть
сведена к набору таблиц (или “отношений” в
терминологии СУРБД) с некоторой избыточностью.
- Каждое отношение (таблица) может быть
представлено в виде прямоугольного массива со
следующими свойствами: - Каждая ячейка в таблице представляет точно один
элемент данных; нет повторяющихся групп. - Каждая таблица имеет однородные столбцы; все
элементы в любом из столбцов одного и того же
вида. - Каждому столбцу назначено определенное имя.
- Все строки различны; дублировать строки не
разрешается. - И строки, и столбцы не зависят от
последовательности; просмотр в различной
последовательности не может изменить
информационное содержание отношения.
Каждая строка олицетворяет уникальный элемент
данных, который ею и описывается.
Столбцы представляют собой отдельные куски
информации (атрибуты данных), которые известны о
данном элементе. Строки обычно называют
записями, а столбцы – полями.
Кроме того, для обработки отношений разрешены
только следующие операции:
- Добавить и Удалить запись. (Редактирование
косвенно разрешено в виде конкатенации операций
“Добавить” и “Удалить”) - Соединение (при котором временное отношение
создается путем соединения информации двух
отношений, используя общие поля). - Выборка (в которой выбирается подмножество
записей в отношении, основываясь на определенных
значениях или ряде значений в выбранных полях).
Другие операции с данными обычно не
поддерживаются в базах с реляционной структурой.
Добавление произвольных данных, которые,
например, не соответствуют ни одному полю в
описании данных, запрещено. Добавление поля для
произвольных данных потребовало бы перестройки
(реструктурирования) базы данных. А этот,
зачастую очень длительный, процесс может
выполняться только когда базой данных никто не
пользуется.
Вообще, лишь немногие реальные базы данных
могут быть описаны при помощи единственной
таблицы. Большинство приложений используют
множество таблиц, которые содержат столбцы (поля)
с одинаковым именем. Эти общие данные позволяют
объединяя две (или несколько) таблицы, строить
осмысленные ассоциации.
Во многих случаях это объединение не такое
простое. Предположим, нам требуется найти способ
для определения, кто является Руководителем
для любого Служащего. Мы могли бы создать
следующую структуру данных:
Вместо нее более подходящей была бы структура,
представленная на рис.3.
Простой реальный пример может потребовать еще
более сложной труктуры.
Пусть Служащий является членом более чем
одного Отдела. Правила соединения в
реляционных базах данных не разрешают связей
“многие-ко-многим” (которые можно обозначить
при помощи стрелки с двойным указателем на
каждом конце).
Чтобы представить отношение с
такими связями (например, каждый Отдел имеет
многочисленных Служащих и каждый Служащий
может быть членом МногочисленныхОтделов),
нам надо создать отдельное отношение, которое
является гибридом двух столбцов:
“Естественный подход” с использованием
таблиц может оказаться еще более “притянутым
за уши”, когда данные – разреженные.
Разреженные данные означают, что не каждое поле в
каждой записи содержит данные. В некоторых
приложениях данные очень разреженные – только
несколько из большого числа столбцов,
определенных для данного отношения, могут
содержать данные в каком-либо заданном ряду.
Если
в реальном приложении типично, что данные
разреженные, то обычно пользователь не
рассматривает их как табличные. Например,
представим отношение, описывающее посещение
пациентом врача. Оно может иметь поля, которые
содержат результаты обследования: радиограмма,
ультразвук, температура, вес и т.д.
Большинство из
этих полей может быть пусто для какого-либо
пациента. Представить их в качестве полей
таблицы в лучшем случае противоестественно.
Более естественно представить эти данные в виде
списка элементов, чем в качестве полей таблицы.
Воплотить в жизнь эту точку зрения пользователя
в реляционной базе данных нелегко.
Реляционные базы данных были бы совсем
непригодны, если бы эти разреженные данные
действительно хранились внутри прямоугольного
массива, так как для этих пустых элементов данных
надо было бы выделять пространство. В
действительности, большинство современных СУРБД
используют таблицы как “логические”
структуры, но в качестве внутренних
“физических” структур используют структуры,
которые могут хранить редкие данные более
эффективным способом, таким как В-дерево. Выбор
физической структуры иногда предоставляется
разработчику БД как возможность оптимизации
производительности.
В качестве второго примера рассмотрим
упрощенный вариант компьютеризованной
регистрации пациента (КРП). В этой базе данных
хранится информация о пациентах и процедурах,
которым они подвергались (этими процедурами
могут быть осмотры, лабораторные тесты и т.д.).
рис.5
Рис.5 ясно показывает, как может расти сложность
модели данных, когда реляционные ограничения
применяются к данным, которые по своей природе не
являются табличными. Концептуальное описание БД
включает только пациентов, процедуры и
заболевания. Из-за большого количества связей
между этими объектами необходимо было ввести
отношения 2-го (Список заболеваний и Экземпляр
процедуры)
и 3-го уровня (Соответствие
заболевания и процедуры). Необходимо
также принять правило структурной целостности
для того, чтобы избежать появления бессмысленных
данных. (Назначение процедуры одному пациенту,
вызванной заболеванием другого пациента).
Для представления подобных данных могут
использоваться другие реляционные структуры, но
их можно упростить только либо за счет
ограничения гибкости БД (например, за счет
невозможности введения заболевания без
процедуры, связанной с данным заболеванием), либо
за счет нарушения принятых правил нормализации
реляционных БД (Третья Нормализованная Форма).
Практические вопросы
В настоящее время модель реляционной базы
данных – лидирующая в компьютерной индустрии и
занимает эту позицию уже приблизительно 20 лет. Но
по иронии судьбы эта позиция силы может
превратиться в позицию слабости. Несмотря на то,
что РБД стали доминирующими в индустрии баз
данных за последние 20 лет, многие эксперты
почувствовали, что РБД приближаются к концу
своей “карьеры” доминирующего игрока и
будут вытесняться более современными и гибкими
моделями, в первую очередь моделью
объектно-ориентированной базы данных.
Существуют некоторые сомнения относительно
того, смогут ли такие гиганты как Oracle, Informix, Sybase,
Gupta и т.д. произвести изменения своевременно, имея
так много клиентов. Требование поддерживать
обратную совместимость может резко
препятствовать их возможности идти в ногу с
прогрессом технологии БД.
С другой стороны,
прекрасное финансирование этим огромным
количеством клиентов упрощает разработки. Все
продавцы больших реляционных баз данных
добавляют объектно-ориентированные средства,
помещая их поверх нижележащей реляционной
структуры. Эти средства полезны при разработке
базы данных, но по-видимому бесполезны во время
выполнения, так как лежащая в основе реляционная
модель сохраняется.
Если вы ищете вполне
развитый, хорошо документированный, хорошо
изученный, хорошо поддерживаемый продукт на
сегодня, то СУРБД действительно лидеры. Если же
вы хотите, чтобы все эти свойства были и 10 лет
спустя, то они могут быть, а могут и не быть.
Многие эксперты ожидают серьезного изменения
основополагающих принципов технологии БД.
Конечно, легко предсказать, что кто-нибудь
станет следующим Oracle; предсказание же того, какая
именно фирма станет следующим Oracle достойно
оракула другого сорта…
Системы управления
объектно-ориентированными базами данных (суообд)
Теория в теории
Объектно-ориентированные БД – относительно
новая концепция и, как таковая, не имеет четкого
определения. Требования, которым должна отвечать
“объектно-ориентированная” БД, целиком и
полностью лежат на совести их авторов. Свойства,
представляющиеся общими для большинства
реализаций, таковы:
1. Абстракция: Каждая реальная
“вещь”, которая хранится в БД, является
членом какого-либо класса. Класс определяется
как совокупность свойств (properties), методов (methods),
общедоступных (public) и частных (private) структур
данных, а также программы, применимых к объектам
(экземплярам) данного класса.
Классы
представляют собой ни что иное, как абстрактные
типы данных. Методы – это процедуры, которые
вызывается для того, чтобы произвести какие-либо
действия с объектом (например, напечатать себя
или скопировать себя). Свойства – это значения
данных, связанные с каждым объектом класса,
характеризующие его тем или иным образом
(например, цвет, возраст).
2. Инкапсуляция: Внутреннее
представление данных и деталей реализации
общедоступных и частных методов (программ)
является частью определения класса и известно
только внутри этого класса. Доступ к объектам
класса разрешен только через свойства и методы
этого класса или его родителей (см. ниже
“наследование”), а не путем использования
знания подробностей внутренней реализации.
3. Наследование (одиночное или
множественное): Классы определены как часть
иерархии классов. Определение каждого класса
более низкого уровня наследует свойства и методы
его родителя, если они только они явно не
объявлены ненаследуемыми или изменены новым
определением.
При одиночном наследовании класс
может иметь только один родительский класс (т.е.
классовая иерархия имеет древовидную структуру).
При множественном наследовании класс может
происходить от многочисленных родителей (т.е.
иерархия классов имеет структуру
ориентированного нециклического графа, не
обязательно древовидную). Не все
объектно-ориентированные СУБД поддерживают
множественное наследование.
4. Полиморфизм: Несколько классов
могут иметь совпадающие имена методов и свойств,
даже если они считаются различными. Это
позволяет писать методы доступа, которые будут
правильно работать с объектами совершенно
различных классов, лишь бы соответствующие
методы и свойства были в этих классах определены.
5. Сообщения: Взаимодействие c
объектами осуществляется путем посылки
сообщений с возможностью получения ответов. Это
отличается от традиционного для других моделей
вызова процедур. Для того, чтобы применить метод
к объекту, надо послать ему сообщение типа
“примени к себе данный метод” (например,
“напечатай себя”).
Каждый объект, информация о котором хранится в
ООБД, считается принадлежащим какому-либо
классу, а связи между классами устанавливаются
при помощи свойств и методов классов. Чтобы
почувствовать, как это происходит, давайте вновь
обратимся к нашим простые примеры.
|
| |||||||||||||||||||||||
| Рис.9 | Рис.10 | |||||||||||||||||||||||
Объекты (экземпляры класса) могут быть созданы
путем применения метода “Создать
экземпляр”, который является общим для всех
классов. Объект класса “Служащий”, однажды
созданный, связывается с отделом при помощи
метода “Нанять” класса “Отдел” (со
ссылкой на объект “Служащий” в качестве
аргумента).
| ||||||||||||
| Рис.11 | ||||||||||||
Для того, чтобы сделать служащего
руководителем, надо применить метод
“Повысить” к служащему (аргумент – ссылка на
“Отдел”). Этот метод создает новый объект
класса “Руководитель” с дубликатами
наследуемых свойств, и затем уничтожает
существующий экземпляр “Служащего”
(используя метод “Уничтожить”, также общий
для всех классов).
Возвращается ссылка на новый
объект (дескриптор объекта). Отметим, что метод
также должен скорректировать свойство “Список
служащих” каждого отдела, входящего в
“Список отделов”, в которых работает
служащий. Это необходимо для сохранения
целостности БД.
Поскольку “Руководитель”
является подклассом “Служащего”, этот
“Список Служащих” не будет иметь никаких
конфликтов (ссылка на “Служащего”, на самом
деле, может быть ссылкой на Руководителя, так как
он является подклассом служащего – обратное
неверно).
Отметим также, что наследование метода
“Повысить” явно заблокировано в подклассе
Руководитель (это обычно достигается
определением на уровне класса Руководитель
метода “Повысить”, который ничего не делает).
Это годится лишь когда служащий может быть
руководителем только одного отдела.
Если же
отдельный служащий может руководить несколькими
отделами, метод “Повысить” должен быть
применим и к руководителям. В этом случае метод
“Повысить” обязан вносить коррективы в
свойство “Руководитель отдела” для
соответствующих отделов из “Список отделов”
объекта “Руководитель”.
|
| |||||||||||||||||
| Рис.12 | Рис.13 | |||||||||||||||||
Объектно-ориентированная реализация второго
примера (упрощенная регистрация пациента, рис.5)
может быть построена двумя различными способами
в зависимости от допустимости структурированных
значений свойств. В любом случае появятся классы
абстрактных заболеваний и абстрактных процедур
(рис. 12, 13).
Различия обнаружатся в конструкции
класса “Пациент” и дополнительных классов.
Если значение свойства может состоять из
нескольких отдельных частей, то списки
заболеваний и процедур, проведенных с пациентом,
возможно, лучше всего поместить в объект
“Пациент” в виде списков структурированных
значений, как это показано на рис. 14.
| ||||||||||
| Рис.14 | ||||||||||
Не во всех объектно-ориентированных БД
разрешены такие структурированные свойства. Это
не влияет на классы “Абстрактное
Заболевание” и “Абстрактная Процедура”,
однако свойство “Список Заболеваний” класса
“Пациент” (рис. 17) станет списком ссылок на
объекты нового класса “Экземпляр
Заболевания” (рис. 15), и, аналогично, свойство
“Список Процедур” – списком ссылок на
объекты еще одного нового класса “Экземпляр
Процедуры” (рис. 16). Эти новые классы не надо
путать с классами абстрактных объектов,
определенными выше.
|
| |||||||||||||||||
| Рис.15 | Рис.16 | |||||||||||||||||
В некоторых ООБД, особенно тех, которые
построены на вершине реляционной модели,
свойства не могут быть списками. В этом случае не
удивительно, что определения классов будут очень
похожи на реляционную структуру для этой
проблемы, описанную ранее.
| ||||||||||
| Рис.17 | ||||||||||
Успех объектно-ориентированного подхода лежит
в смещении акцента со структуры данных (в
особенности, от вида связей между данными) к
процессу, с помощью которого эти данные
создаются, изменяются и уничтожаются. Реальные
структуры данных – деталь реализации, лучше всего
относящаяся к внутренней работе каждого класса –
и разные классы для обеспечения наивысшей
эффективности могут быть реализованы совершенно
по-разному. Ведение базы данных выполняется как
раз за счет знания методов и свойств,
предоставляемых классами.
Практические проблемы
Модель ООБД находится на более высоком уровне
абстракции, чем реляционные или древовидные БД,
поэтому классы можно реализовать, опираясь либо
на одну из этих моделей, либо на какую-нибудь еще.
Поскольку в центре разработки оказываются не
структуры данных, а процедуры (методы), важно,
чтобы выбиралась базовая модель, которая
обеспечивает достаточную прочность, гибкость и
производительность обработки.
Реляционные БД с их строгим определением
структуры и ограниченным набором разрешенных
операций, бесспорно, не подходят в качестве
базовой платформы для ООБД. Система М-языка/БД с
ее более гибкой структурой данных и более
процедурным подходом к разработке
представляется особенно хорошо приспособленной
для использования в качестве базовой платформы
для СУООБД.
Существует целый ряд коммерческих предложений,
которые являются “чистыми”
объектно-ориентированными СУБД. Таковы Objectivity,
Poet, Versant. Вообще говоря, эти системы относительно
незрелые и нуждаются в средствах разработки и
обслуживания, которые необходимы для реализации
и сопровождения многомасштабных БД.
Более того,
эти объектно-ориентированные системы
оказываются достаточно медленными при доступе к
большим БД, проигрывая в эффективности
реляционным и древовидным БД. По сравнению с
сегодняшними весьма большими и сложными базами
данных, основанными на реляционных и
иерархических системах, базы данных,
сконструированные с использованием ООБД
относительно малы и просты. Это часть
рассматривается как признак незрелости
технологии, но не как ограничение ее потенциала.