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

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

Автоматизированное проектирование;

Автоматизированное производство;

Автоматизированная разработка программного обеспечения;

Офисные информационные системы;

Мультимедиа системы;

Геоинформационные системы;

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

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

Построение ООМД исходит из предположения о том, что предметную область можно описать совокупностью объектов. Каждый объект представляет собой уникально идентифицируе­мую сущность, которая содержит атрибуты, описывающие состо­яние объектов «реального мира», и связанные с ними действия. Текущее состояние объекта описывается одним или несколькими атрибутами, которые могут быть простыми или сложными. Простой атрибут может иметь примитивный тип (например, целое число, строка и т. д.) и принимать литеральное значение. Состав­ной атрибут может содержать коллекции и/или ссылки. Ссылоч­ный атрибут представляет собой связь между объектами.

Ключевым свойством объекта является уникальность его Идентификации. Поэтому у каждого объекта в объектно-ориентированной системе должен быть свой идентификатор.

Идентификатор объекта (OID - Object Identifier) - это внутренний для базы данных способ пометки индивидуальных объектов. Пользователи, работающие с диалоговой программой заданий запросов или просмотра информации, как правило, не видят этих идентификаторов. Они назначаются и используются самой СУБД. Семантика идентификатора в каждой СУБД своя. Она может быть как случайным значением, так и содержать ин­формацию, необходимую для поиска объекта в файле базы дан­ных, например, номер страницы в файле и смещение объекта от ее начала. Именно идентификатор должен использоваться для организации ссылок на объект.

Все объекты являются инкапсулированными, т. е. пред­ставление или внутренняя структура объекта остаются скрыты­ми от пользователя. Вместо этого пользователю известно только, что данный объект может выполнять некоторые функции. Так, для объекта СКЛАД могут применяться такие методы как ПРИНЯТЬ_ТОВАР, ВЫДАТЬ_TOBAP и т. д. Преимущество инкап­суляции состоит в том, что она позволяет изменять внутреннее представление объектов, не переделывая приложений, в которых используются эти объекты. Иначе говоря, инкапсуляция подра­зумевает независимость данных.

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

Объекты, которые имеют один и тот же набор атрибутов и отвечают на одни и те же сообщения, могут быть сгруппированы в класс (в литературе термины «класс» и «тип» часто использу­ются как синонимы). У каждого такого класса имеется свой пред­ставитель - объект, который и является элементом данных. Объ­екты некоторого класса называются его экземплярами .

В некоторых объектно-ориентированных системах класс также является объектом и обладает собственными атрибутами и методами, которые называются атрибутами класса и метода­ми класса.

Важными понятиями ООП служат иерархия классов и ие­рархия контейнеров .

Иерархия классов подразумевает под собой возможность наличия у каждого класса, называемого в таком случае супер­классом, своего подкласса. В качестве примера можно привести следующую цепочку: все программисты какого-либо предприя­тия являются его сотрудниками, следовательно, каждый про­граммист, который в рамках ООМД является объектом класса ПРОГРАММИСТЫ, он является также и сотрудником, кото­рый, в свою очередь, является объектом класса СОТРУДНИКИ. Таким образом, ПРОГРАММИСТЫ будут подклассом, СО­ТРУДНИКИ - суперклассом. Но программисты могут также де­литься на системных и прикладных. Следовательно, ПРОГРАМ­МИСТЫ будут суперклассом к подклассам СИС_ПРОГРАМ-МИСТЫ и ПРИКЛ_ПРОГРАММИСТЫ. Продолжая эту цепочку далее, мы получим иерархию классов, при которой каж­дый объект подкласса наследует экземпляры переменных и мето­ды соответствующего суперкласса.

Существует несколько видов наследования - единичное, множественное и избирательное. Единичное наследование пред­ставляет собой случай, когда подклассы наследуют не более чем у одного суперкласса. Множественное наследование - наследова­ние более чем у одного суперкласса. Избирательное наследова­ние позволяет подклассу наследовать ограниченное количество свойств его суперкласса.

Наследование экземпляров переменных называется струк­турным наследованием , наследование методов - поведенческим наследованием , а способность использовать один и тот же метод для разных классов или, скорее, применять разные методы с од­ним и тем же именем для разных классов называется полимор­физмом .

Объектно-ориентированной архитектуре присущ также и другой тип иерархии - иерархия контейнеров . Он состоит в том, что некоторые объекты могут концептуально содержаться внут­ри других. Так, объект класса ОТДЕЛ должен содержать общедо­ступную переменную НАЧАЛЬНИК, являющуюся ссылкой на соответствующий начальнику отдела объект класса СОТРУД­НИКИ, а также должен содержать ссылку на совокупность ссы­лок на объекты, соответствующие работающим в данном отделе сотрудникам.

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

Пользователь и объект взаимодействуют посредством со­общений. В ответ на каждое сообщение система выполняет соот­ветствующий метод.

Все связи в объектной модели осуществляются с помощью ссылочных атрибутов, которые обычно реализуются как ОID-идентификаторы.

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

В ООМД могут быть реализованы не только традиционные связи, но и связи, обусловленные наследованием.

Связь типа один-к-одному (1: 1) между объектами А и В реализуется путем добавления ссылочного атрибута на объект В в объект А и (для поддержания ссылочной целостности) ссылоч­ного атрибута на объект А в объект В.

Связь типа один-ко-многим (1: М) между объектами А и В реализуется путем добавления в объект А ссылочного атрибута на объект В и атрибута, содержащего набор ссылок на объект А, в объект В (например, в объект А добавляется ссылочный атрибут В{ОID2, OID3...}, и в экземпляры объекта В с OID2, OID3,... до­бавляется ссылочный атрибут А: OID1.

Связь типа многие-ко-многим (М: N) между объектами А и В реализуется путем добавления в каждый объект атрибута, со­держащего набор ссылок.

В ООМД можно воспользоваться связью вида «целое-часть», описывающей, что объект одного класса содержит объекты других классов в качестве своих частей. В случае производствен­ной БД между классом ИЗДЕЛИЕ и классами ДЕТАЛЬ и СБОР­КА существовала бы связь «целое-часть». Данная связь - это ва­риант связи «многие-ко-многим», обладающий специальной се­мантикой. Связь «целое-часть» реализуется, как любая другая связь «многие-ко-многим», с помощью множества идентификато­ров связанных объектов. Однако она, в отличие от обычной связи «многие-ко-многим», имеет другое смысловое значение.

Поскольку объектно-ориентированная парадигма поддер­живает наследование, то в ООМД можно применять связь типа «является» и связь типа «расширяет». Связь «является», кото­рую еще называют отношением обобщения-специализации, по­рождает иерархию наследования, в которой подклассы оказыва­ются частными случаями суперклассов. Это позволяет не описы­вать повторно унаследованные признаки. При использовании связи «расширяет» подкласс развивает функциональность супер­класса, а не ограничивается его частным случаем.

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

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

Специфика ООМД диктуется и спецификой объекта. Она проявляется в необходимости группировки объектов в классы. Каждый объект входит в тот или иной класс в зависимости от за­дачи, причем один объект может принадлежать сразу нескольким классам (например, семейству ПРОГРАММИСТЫ и ВЫСОКОПЛАЧИВАЕМЫЕ). Другой спецификой объекта является то, что он может «перебегать» из одного класса (подкласса) в дру­гой. Так, СИСТЕМНЫЙ ПРОГРАММИСТ может стать со вре­менем ПРИКЛАДНЫМ. Таким образом, иерархия классов не является аналогом иерархической модели, как это могло пока­заться ранее, но требует от системы способности изменять распо­ложение каждого объекта внутри иерархии классов, например пе­ремещаться «вверх» или «вниз» внутри данной иерархии. Но воз­можен и более сложный процесс - система должна обеспечивать возможность объекта быть присоединенным (отсоединенным) к произвольной вершине иерархии в любой момент времени.

Важную роль в ООМД играют ограничения целостности связей. Чтобы связи в объектно-ориентированной МД могли рабо­тать, идентификаторы объектов по обе стороны связи должны соответствовать друг другу. Например, если имеется связь между СЛУЖАЩИМИ и их ДЕТЬМИ, то должна быть какая-то гаран­тия, что при вставке объекта, описывающего ребенка, в объект, ото­бражающий служащего, идентификатор последнего добавляется в соответствующий объект. Такой вид целостности связей, в чем-то аналогичный ссылочной целостности в реляционной модели дан­ных, устанавливается с помощью обратных связей. Чтобы гаранти­ровать целостность связей, проектировщику предоставляется спе­циальная синтаксическая конструкция, необходимая для задания места нахождения обратного идентификатора объекта. Обязан­ность задавать ограничения целостности связей (как и ссылочной целостности в реляционной БД) лежит на проектировщике.

В ООМД и описание данных, и манипулирование ими про­исходят с помощью одного и того же объектно-ориентированно­го процедурного языка.

Проблемами стандартизации технологии объектных БД за­нимается группа ODMG (Object Database Management Groop). Она разработала объектную модель (версия ODMG 2.0 была при­нята в сентябре 1997 г.), которая определяет стандартную модель для семантики объектов БД. Эта модель имеет большое значе­ние, поскольку определяет встроенную семантику, которую по­нимает и может реализовать объектно-ориентированная СУБД (ООСУБД). Структура библиотек и приложений, использую­щих эту семантику, должна быть переносимой среди различных ООСУБД, которые поддерживают данную объектную МД. Ос­новными компонентами архитектуры ODMG являются: объект­ная модель (ОМ), язык определения объектов (ODL), язык объ­ектных запросов (OQL), а также способность связывания с язы­ками C++, Java и Smalltalk.

Объектная модель данных в соответствии со стандартом ODMG 2.0 характеризуется следующими свойствами:

Базовыми конструктивными элементами являются объек­ты и литералы. Каждый объект имеет уникальный идентифика­тор. Литерал не имеет собственного идентификатора и не может существовать отдельно как объект. Литералы всегда встроены в объекты, и на них нельзя ссылаться индивидуально;

Объекты и литералы различаются по типу. Каждый тип имеет собственный домен, разделяемый всеми объектами и лите­ралами данного типа. Типы могут также обладать поведением. Если тип имеет некоторое поведение, то таким же поведением об­ладают все объекты этого типа. На практике тип может быть классом, из которого создается объект, интерфейсом или про­стым типом данных (например, целым числом). Объект можно представить как экземпляр типа;

Состояние объекта определяется набором текущих значе­ний, реализуемых множеством свойств. Этими свойствами могут быть атрибуты объекта или связи между объектом и одним или несколькими другими объектами;

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

Определение базы данных хранится в схеме, записанной на языке определения объектов Object Definition Language (ODL). База данных хранит объекты, позволяя их совместно использо­вать различным пользователям и приложениям.

СУБД, базирующиеся на ООМД, называют объектно-ори­ентированными СУБД (ООСУБД). Эти СУБД относят к СУБД третьего поколения* (* Историю развития моделей хранения данных часто разбивают на три этапа (поколения): первое поколение (конец 1960 - начало 70-х го­дов) - иерархическая и сетевая модели; второе поколение (приблизительно 1970-1980-е годы) - реляционная модель; третье поколение (1980-е годы - начало 2000-х годов) - объектно-ориентированные модели.) .

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

Приложение состоит из большого числа взаимодействую­щих частей. Каждая из них обладает своим поведением, которое зависит от поведения других;

Система должна обрабатывать большие объемы неструкту­рированных или имеющих сложную структуру данных;

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

Потребность в незапланированных запросах ограничена;

Структура хранимых данных имеет иерархическую или сходную природу.

В настоящий момент на рынке ПО присутствует множест­во объектно-ориентирован-ных СУБД. В табл. 10.6 представлены некоторые из коммерческих систем данного класса.

Таблица 10.6

Современные коммерческие ООСУБД,

их фирмы-производители и области применения

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

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

Немалое значение для ООСУБД имеет возможность пере­мещения объектов из одной базы в другую.

При создании различных приложений на базе ООСУБД немаловажной является встроенная структура классов той или иной СУБД. Библиотека классов поддерживает, как правило, не только все стандартные типы данных, но и расширенный набор мультимедийных и других сложных типов данных, таких как ви­део, звук, последовательность анимационных кадров. В некото­рых ООСУБД созданы библиотеки классов, дающие возмож­ность хранения и полнотекстового поиска документальной ин­формации (например, Jasmine, ODB-Jupiter). Пример базовой структуры классов приведен на рис. 10.17.

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

Как видно из рис. 10.17, в структуре существуют различные классы, ориентированные на обработку документальной инфор­мации - TOdbText, TOdbDocument, TODBTextDocument и др. Каждый документ представлен отдельным объектом. Таким об­разом обеспечивается естественность хранения документов. Од­ной из важнейших операций является поиск документов по за­просу. Для большинства классов реализована возможность поис­ка объектов по значению определенного ключа. Для класса TOdbText реализована возможность формирования поискового запроса по фразе, записанной на естественном языке.

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

На основе ODB-Jupiter разработчики ООСУБД создали полнофункциональную информационно-поисковую систему ODB-Text, обладающую универсальной структурой хранимых данных и мощным механизмом поиска. Система ODB-Text -средство коллективной обработки документов и ведения корпо­ративного архива. В числе возможных приложений назовем авто­матизацию учета документооборота современного офиса, постро­ение справочно-информационных систем (подобных известным Юридическим базам данных), ведение сетевых баз данных, учет кадров, библиографию и др.

41. Особенности проектирования прикладной ИС. Фазы развития ИС. (Тема 11, стр. 100-103).

11.1.3. Особенности системного проектирования прикладной ИС

При построении (выборе, адаптации) информационной системы можно использовать две основные концепции, два основных подхода (третья концепция - их комбинация):

1. ориентация на проблемы, которые необходимо решать с помощью этой информационной системы, т.е. проблемно-ориентированный подход (или индуктивный подход);

2. ориентация на технологию, которая доступна (актуализируема) в данной системе, среде, т.е. технологически-ориентированный подход (или дедуктивный подход).

Выбор концепции зависит от стратегических (тактических) и(или) долгосрочных (краткосрочных) критериев, проблем, ресурсов.

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

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

При этом обе концепции построения информационной системы зависят друг от друга: внедрение новых технологий изменяет решаемые проблемы, а изменение решаемых проблем - приводит к необходимости внедрения новых технологий; и то, и другое влияет на принимаемые решения.

Системное проектирование (разработка) и использование любой прикладной (корпоративной) информационной системы должно пройти следующий жизненный цикл информационной системы:

– предпроектный анализ (опыт создания других аналогичных систем, прототипов, отличия и особенности разрабатываемой системы и др.), анализ внешних проявлений системы;

– внутрисистемный анализ, внутренний анализ (анализ подсистем системы);

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

– определение критериев адекватности, эффективности и устойчивости (надежности);

– функциональное описание подсистем системы (описание моделей, алгоритмов функционирования подсистем);

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

– "сборка" и тестирование системы - реализация полноценных функциональных подсистем и критериев, оценка модели по сформулированным критериям;

– функционирование системы;

– определение целей дальнейшего развития системы и ее приложений;

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

Эти этапы - основные для информационного реинжиниринга систем.

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

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

Функциональные связи - каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;

Информационные связи - подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);

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

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

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

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

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

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

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

Можно выделить следующие основные отличительные признаки проекта как объекта управления:

Изменчивость - целенаправленный перевод системы из существующего в некоторое

желаемое состояние, описываемое в терминах целей проекта;

Ограниченность конечной цели;

Ограниченность продолжительности;

Ограниченность бюджета;

Ограниченность требуемых ресурсов;

Новизна для предприятия, для которого реализуется проект;

Комплексность - наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;

Правовое и организационное обеспечение - создание специфической организационной структуры на время реализации проекта.

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

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

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

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).

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

Можно выделить следующие фазы развития информационной системы:

Формирование концепции;

Разработка технического задания;

Проектирование;

Изготовление;

Ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно. Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.

Концептуальная фаза

Формирование идеи, постановку целей;

Формирование ключевой команды проекта;

Изучение мотивации и требований заказчика и других участников;

Сбор исходных данных и анализ существующего состояния;

Определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

Сравнительную оценку альтернатив;

Представление предложений, их экспертизу и утверждение.

Разработка технического предложения

Разработка основного содержания проекта, базовой структуры проекта;

Разработка и утверждение технического задания;

Планирование, декомпозиция базовой структурной модели проекта;

Составление сметы и бюджета проекта, определение потребности в ресурсах;

Разработка календарных планов и укрупненных графиков работ;

Подписание контракта с заказчиком;

Ввод в действие средств коммуникации участников проекта и контроля за хо дом работ.

Проектирование

На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:

Выполнение базовых проектных работ;

Разработка частных технических заданий;

Выполнение концептуального проектирования;

Составление технических спецификаций и инструкций;

Представление проектной разработки, экспертиза и утверждение.

Разработка

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

Выполнение работ по разработке программного обеспечения;

Выполнение подготовки к внедрению системы;

Контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ:

Комплексные испытания;

42. Концепция жизненного цикла ИС. (Тема 11, стр. 103-105).

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

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных).

Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент, Каталог и Выдача. Различные объекты типа Книга могут иметь одного или разных родителей. Объекты типа Книга, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.

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

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов Абонент и Каталог. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга, являющимся потомками объекта типа Каталог, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свойств всеми дочерними объектами Абонент, Книга и Выдача. Не случайно поэтому значения свойства билет классов Абонент и Выдача, показанных на рис. 2.9, являются одинаковыми - 00015.

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

Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.

Рис. 2.9 Логическая структура БД библиотечного дела

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

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

К объектно-ориентированным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Банки данных, как целое, обычно классифицируют по экономико-правовым признакам.

По условиям предоставления услуг различают бесплатные и платные банки, которые, в свою очередь, делятся на коммерческие и бесприбыльные (научные, библиотечные или социально-значимые).

По форме собственности БнД делятся на государственные и негосударственные. По степени доступности различают общедоступные и с ограниченным кругом пользователей.

Другие виды классификации связаны с отдельными компонентами БнД.

1. Разработка банков данных состоит из 4-х этапов:

1этап. Формирование и анализ требований к системе:

Составляется спецификация системы, включающая список задач, которые должен решать БнД;

Перечень конечных пользователей и их функций;

Перечень требований к БД;

Составляется схема документооборота в организации.

2 этап. Концептуальное проектирование: создается информационная модель системы без привязки к типу ЭВМ и типу системных программных средств; строится инфологическая модель базы данных, которая наиболее полно описывает предметную область в терминах пользователя.

3 этап. Проектирование реализации: выбирается вычислительная система, системные программные средства и СУБД; проектируется структура данных и строится даталогическая модель БД (схема БД), которая представляет собой описание логической структуры БД на языке конкретной выбранной СУБД.

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

2. Основные задачи, решаемые персоналом банка данных

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

Перечислим основные функции и задачи, решаемые персоналом при разработке и эксплуатации базы данных:

1) анализ предметной области (определение потребностей конечных пользователей, построение информационной модели предметной области, выявление ограничений целостности);

2) проектирование структуры базы данных (определение состава и структуры файлов БД, описание ее схемы на языке описания данных);

3) задание ограничений целостности БД;

4) загрузка и ведение БД (к ведению БД относится изменение, удаление и добавление записей); разработка технологии загрузки и ведения; разработка форм ввода данных; ввод и контроль данных;

5) защита данных (разграничение пользователей, выбор и проверка средств защиты, фиксация попыток несанкционированного доступа);

6) обеспечение восстановления БД;

7) анализ эффективности БнД и развитие системы;

8) работа с пользователями (сбор откликов, обучение);

9) сопровождение системного программного обеспечения (приобретение, установка и развитие);

10) организационно-методическая работа (выбор методов проектирования и модернизации, планирование развития БнД, разработка документации).

3. Пользователи банков данных

Как любой программно-организационно-техничеcкий комплекс, банк данных существует во времени и в пространстве. У этого есть определенные этапы разработки:

Проектирование,

Реализация,

Поддержка,

Обновление и разработка,

Полная реорганизация.

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

Конечные пользователи

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

Администраторы банка данных

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

Разработчики и администраторы приложений

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

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

Рассмотрим их более детально.

Часть группы администратора БнД должна быть:

Системные комментаторы;

Разработчики структур данных и внешнего вида относительно банка данных информационной поддержки;

Разработчики технологических процессов обработки данных;

Системные и прикладные программисты;

Действующие компании и эксперты в ремонтной службе.

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

Основные функции группы администраторов БД

1. Исследование области данных: описание области данных, укладка текста ограничений целостности, определение состояния (доступность, конфиденциальность) информация, определение потребностей потребителей, определение соответствия "потребители данных", определение височных объемом характеристик обработки данных.

2. Разработка строения БД: определение сочинения и строение файлов БД и связи промежуточный, выбор методов оптимизации данных и методов доступа для информации, описания БД на языке описания данных (ЯОД).

3. Задание ограничений целостности в описании структуры БД и процедурах обработки БД:

Задание декларативных ограничений целостности, свойственной от области данных;

Определение динамичных ограничений целостности, свойственной от области данных в ходе изменения информации, хранившей в БД;

Определение ограничений целостности вызывается строением БД;

Разработка процедур поддержки целостности БД при вводе и корректировке данных;

Определение ограничений целостности параллельной работой потребителей в многопользовательском режиме.

4. Инициирование загрузки и руководство БД

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

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

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

5. Предохранение данных

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

Разработка принципов предохранения определенных данных и объектов разработки; разработка специализированных методов кодирования информации при ее циркуляции в локальных и глобальных информационных сетях;

Разработка средств фиксации доступа к данным и попыткам нарушения системы защиты;

Тестирование системы защиты;

Исследование случаев нарушения системы защиты и разработки динамичных методов предохранения информации в БД.

6. Поддержка восстановления БД

Разработка организационных означает архивирования и принципы восстановления БД;

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

7. Исследование вызовов потребителей БД: набор статистики на символе запросов, времени включения их производительности, в соответствии с требуемыми выходными документами

8. Исследование эффективности функционирования БнД:

Исследование индексов функционирования БнД

Планирующая перестройка структуры (структурное изменение) БД и реорганизация БнД.

9. Работа с конечными пользователями:

Сбор информации об изменении области данных;

Сбор информации об оценке работ БнД;

Тренировка потребителей, консультация потребителей;

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

10. Приготовление и поддержка системных средств:

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

Разработка требуемых организационных и технических программой движений для разработки БнД;

Проверка работоспособности искупленного матобеспечения перед их соединением с БнД;

Контроль соединения нового матобеспечения к БнД.

11. Организационно-систематическая работа при разработке БнД:

Выбор или создание метода разработки БД;

Определение целей и направление разработки системы в целом;

Планирование стадий развития БнД;

Разработка справочников генеральных словарей проекта БнД и концептуальной модели;

Монтаж внешних моделей разработанных приложений;

Контроль соединения нового приложения к работе БнД;

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

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

Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group – группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура ОО БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связанную иерархию объектов.

Пример логической структуры ОО БД библиотечного дела приведен на рис. 3.14. Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА, имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор .

Рис.3.14. Логическая структурабазы данныхбиблиотечного дела

Логическая структура ОО БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными. Для выполнения действий над данными в ООМ БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД).

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к ООМ БД.

Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в котором оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся потомками объекта типа КАТАЛОГ, можно приписать свойства объекта-родителя: isbn, удк, название и автор. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойства билет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми – 00015.

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

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

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

Недостатком ООМ являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.

Рис.3.15. Фрагмент базы данных с объектом-целью

Вновь обратимся к задаче Заказы, представленной в виде реляционной модели данных на рис. 3.8, и рассмотрим ее в терминах объектно-ориентированной базы данных. Всего в примере три класса: «Клиенты », «Заказы » и «Товары ». Объектами класса «Клиенты » являются конкретные клиенты; свойства класса - № клиента, Имя клиента Город, Статус и т.п. Методы класса – «Создать заказ », «Оплатить счет » и т.п. Метод – это некоторая операция, которую можно применить к объекту; метод – это то, что должен делать объект. Класс, соответствующий таблице «Сведения о заказе », не требуется. Данные таблицы могут быть частью класса «Заказы ». Наличие в классе «Клиенты » метода «Создать заказ » приводит к взаимодействию с объектами классов «Заказы » и «Товары ». При этом пользователю не надо знать об этом взаимодействии объектов. Пользователь лишь обращается к объекту «Заказы » и использует метод «Создать заказ ». Факт воздействия на другие базы данных может быть скрыт от пользователя. Если метод «Создать заказ », в свою очередь, обращается к методу «Проверить кредитоспособность клиента », то этот факт также может быть скрыт от пользователя. В реляционных базах данных для выполнения тех же функций требуется писать процедуры на языке Visual Basic for Application (VBA).

В 90-е годы существовали экспериментальные прототипы ОО систем управления базами данных. В настоящее время такие систем получили широкое распространение. В частности, к ним относятся следующие СУБД: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (научно-производственный центр «Интелтек Плюс»), а также Iris, Orion и Postgres.

Основные понятия

Определение 1

Объектно-ориентированная модель представления данных дает возможность идентификации отдельных записей базы.

Записи базы данных и функции их обработки связаны механизмами, подобными соответствующим средствам, которые реализуются в объектно-ориентированных языках программирования.

Определение 2

Графическим представлением структуры объектно-ориентированной базы данных является дерево, узлы которого представляют объекты.

Стандартный тип (например, строковый – string ) или тип, созданный пользователем (class ), описывает свойства объектов .

На рисунке 1 объект БИБЛИОТЕКА является родителем для объектов-экземпляров классов КАТАЛОГ , АБОНЕНТ и ВЫДАЧА. У разных объектов типа КНИГА может быть один или разные родители. У объектов типа КНИГА, которые имеют одного и того же родителя, должны быть по крайней мере разные инвентарные номера (уникальные для каждого экземпляра книги), но одинаковые значения свойств автор , название , удк и isbn .

Логические структуры объектно-ориентированной и иерархической базы данных внешне похожи. Отличаются они в основном методами манипулирования данными.

При выполнении действий над данными в объектно-ориентированной модели используются логические операции, которые усилены инкапсуляцией, наследованием и полиморфизмом. С некоторым ограничением можно применять операции, которые подобны командам SQL (например, при создании БД).

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

Определение 3

Цель инкапсуляции – ограничение области видимости имени свойства границами того объекта, в котором оно определено.

Например, если в объект КАТАЛОГ добавлено свойство, которое задает телефон автора и имеет название телефон , то одноименные свойства получатся у объектов КАТАЛОГ и АБОНЕНТ. Смысл свойства определяется тем объектом, в который оно инкапсулировано.

Определение 4

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

Например, всем объектам КНИГА, которые являются потомками объекта КАТАЛОГ, могут быть приписаны свойства объекта-родителя: автор , название , удк и isbn .

При необходимости расширения действия механизма наследования на объекты, которые не являются непосредственными родственниками (например, на два потомка одного родителя) в их общем предке определяют абстрактное свойство типа abs .

Таким образом, свойства номер и билет в объекте БИБЛИОТЕКА наследуются всеми дочерними объектами ВЫДАЧА, КНИГА и АБОНЕНТ. Именно поэтому значения этого свойства классов АБОНЕНТ и ВЫДАЧА одинаковые – 00015 (рисунок 1).

Определение 5

Полиморфизм позволяет одному и тому же программному коду работать с разнотипными данными.

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

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

Преимущества и недостатки объектно-ориентированной модели

Основное преимущество объектно-ориентированной модели данных в отличие от реляционной модели состоит в возможности отображения информации о сложных взаимосвязях объектов. Рассматриваемая модель данных позволяет определять отдельную запись БД и функции ее обработки.

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

На сегодняшний день такие системы достаточно широко распространены. К ним относятся СУБД:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Objectivity /DB,
• ObjectStore,
• Statice,
• GemStone
• G-Base.

Введение

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

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

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

Рассмотрим один из подходов к построению БД - использование объектно-ориентированной модели данных (ООМД). Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).

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

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;

расширение существующего языка работы с базами данных объектно-ориентированными функциями;

создание объектно-ориентированных библиотек функций для работы с БД;

создание нового языка и новой объектно-ориентированной модели данных.

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID - object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

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

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

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

Стандартная ООМ описана в рекомендациях стандарта ODMG-93 (Object Database Management Group - группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура ОО БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связанную иерархию объектов.