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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификатор объекта (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 – группа управления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации 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.

06.04.2004 Сиха Багуи

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

Разработка систем объектно-ориентированных баз данных (так называемые технологии баз данных пятого поколения) началась в середине 80-х годов в связи с необходимостью удовлетворения требований приложений, отличных от тех приложений обработки данных, которые характерны для систем реляционных баз данных (технология баз данных четвертого поколения). Попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование (computer aided design, CAD); автоматизированное производство (computer aided manufacturing, CAM); технология программирования; системы, основанные на знаниях, и мультимедийные системы, обнажили ограничения систем реляционных баз данных (РБД) . В условиях, когда появилось новое поколение приложений баз данных, возникли потребности, которые лучшим образом удовлетворялись при применении объектно-ориентированных баз данных (ООБД).

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

В настоящее время на рынке представлено свыше 25 систем ООБД. Среди них - система GemStone компании Servio, ONTOS компании Ontos, ObjectStore компании Object Design и многие другие . Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора десятилетий разработки они все еще не вступили в пору зрелости; в этом - одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД. Среди современных ООБД почти нет полностью оперившихся систем, сопоставимых с современными системами реляционных баз данных. Обсудим основные достижения и проблемы, связанные с нынешним состоянием ООБД.

Модель ООБД

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

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

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

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

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

Достоинства модели ООБД

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

Определение пользовательских абстракций

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

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

Примером пакета ООБД, обладающего всеми упомянутыми возможностями, может служить ENCORE . Модель данных в ENCORE базируется главным образом на абстракции данных. ENCORE допускает подтипизацию (наследование), инкапсуляцию, сложные структуры, идентификацию объектов и отложенное связывание методов. Кроме того, ENCORE обеспечивает возможность связывания объектов с помощью свойств. В системе ENCORE свойство p связывает объект x с набором объектов S без какого-либо указания того, каким образом вычисляется эта связь. Ее можно вычислить путем прямого указания идентификатора набора S (или идентификаторов его членов) или с помощью установления соответствий значений других свойств, как в соединении.

Облегченное проектирование некоторых связей

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

Отсутствие потребности в определяемых пользователями ключах

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

Наличие предикатов сравнения

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

  1. Равенство объектов на основе их идентичности. Два объекта, S1 и S2 равны, если они являются одним и тем же объектом (т.е. имеют один и тот же идентификатор объекта).
  2. Равенство объектов на основе значений. Это можно определить в два захода - (a) два примитивных объекта равны, если имеют одно и то же значение; (b) два не примитивных объекта равны, если они имеют одинаковое число свойств, и для каждого свойства pi объекта S1 существует свойство pj объекта S2, равное ему по значению.
  3. Равенство свойств на основе значений.
  4. Равенство свойств на основе их идентичности.
Меньшая потребность в соединениях

Возможность навигации по структурам объектов и проистекающие из этого путевые выражения в терминах атрибутов объектов дают нам возможность по-новому взглянуть на проблему соединений в ООБД. Реляционное соединение - это механизм, сопоставляющий два отношения на основе значений соответствующих пар атрибутов в этих отношениях. Поскольку в ООБД два класса могут иметь соответствующие пары атрибутов, в этой модели все еще может сохраняться необходимость в реляционном соединении (или явном соединении). Например, допустим, у нас имеются классы Student и School, причем в каждом из этих классов имеются атрибуты Name и Age. Хотя домены атрибутов Name и Age класса School могут не совпадать с доменами атрибутов Name и Age класса Student, мы можем захотеть связать эти классы на основе значений этих атрибутов (скажем, найти всех учащихся, чей возраст меньше возраста школы, которую посещает данный учащийся ).

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

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

Выигрыш в производительности

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

  1. В ООБД значение атрибута объекта X, доменом которого является другой объект Y, - это идентификатор объекта Y. Следовательно, если приложение уже извлекло объект X и теперь хотело бы извлечь объект Y, то СУБД может извлечь объект Y, отыскав его идентификатор. Если этот идентификатор представляет собой физический адрес объекта, то данный объект может быть извлечен непосредственно; если же идентификатор является логическим адресом, то объект путем нахождения соответствующего элемента хэш-таблицы (в предположении, что в системе поддерживается хэш-таблица, отображающая идентификатор объекта в физический адрес). В РБД это могло бы не получиться так просто, поскольку в РБД не поддерживаются идентификаторы объектов.
  2. Вторая особенность ООБД, обеспечивающая выигрыш в производительности, состоит в том, что в большинстве ООБД при загрузке объекта в память хранимые в этом объекте идентификаторы объектов преобразуются в указатели по памяти. Поскольку в РБД не хранятся идентификаторы объектов, в них невозможно сохранять указатели по памяти на другие кортежи. Отсутствие возможности навигации по объектам, содержащимся в памяти, является принципиальным свойством РБД, и вытекающее из этого снижение производительности не может быть компенсировано простым увеличением объема буферной памяти. Так что при выполнении приложений, которые предполагают многократную навигацию по загруженным в память связанным объектам, ООБД могут существенно превзойти РБД по производительности .
  3. Кроме того, даже если ООБД не проиндексированы, может оказаться удобным выполнять произвольные запросы, соответствующие структуре объектов, путем последовательного сканирования, т.е. использовать ссылочные пути между объектами. Когда запрос формулируется в направлении, не поддерживаемом ссылками, этот запрос будет обрабатываться путем последовательного сканирования . Однако запросы, формулируемые на основании таких связей объектов, которые не моделируются напрямую с помощью ссылок, выполняются неэффективно.
Поддержка версий и длительных транзакций

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

Объектная алгебра

Объектная алгебра не столь подробно разработана и не является столь же зрелой, как реляционная алгебра. Но как бы то ни было, такая алгебра существует, и в ней определяются пять фундаментальных операций, сохраняющих объекты: union, difference, select, generate и map . На основе этих фундаментальных операций могут быть определены другие операции, например, intersection. Правила преобразований для логической оптимизации выражений объектной алгебры с сохранением эквивалентности выводятся в и . В то время как операции union, difference и map производят, главным образом, отображение «один к одному», операции select и generate производят отображение «один ко многим». Сохранение объектов означает, что алгебраические операции возвращают объекты, принадлежащие к ранее определенным классам базы данных, и не создают новых объектов. Оператор union возвращает объекты, содержащиеся во множестве P или во множестве Q, или в обоих множествах. Оператор difference возвращает набор объектов, принадлежащих множеству P, но не множеству Q. select возвращает подмножество введенного множества. generate генерирует объекты из тех, что принадлежат входному множеству. map возвращает множество объектов, образующихся в результате каждого применения последовательности методов .

Недостатки модели ООБД

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

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

Отсутствие интероперабельности между РБД и ООБД

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

  1. Превратить ООБД в полностью оперившиеся системы баз данных, обладающих достаточной совместимостью с РБД. Требуется некий путь миграции, чтобы обеспечить сосуществование существующих ныне и новых продуктов, а также плавный переход от первых ко вторым.
  2. Предложить средства разработки приложений и средства доступа к объектно-ориентированным базам данных.
  3. Унифицировать архитектуры РБД и ООБД.
  4. Унифицировать модели данных РБД и ООБД.
Недостаточность средств для оптимизации запросов

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

  1. Возможность определения пользователями новых типов и классов с помощью наследования и облегчает, и осложняет оптимизацию запросов. Примером, в котором эта возможность помогает оптимизации, может служить запрос, включающий пересечение множеств Employees («сотрудники») и Supervisors («инспекторы»). Если Employee является суперклассом класса Supervisor, то оптимизатор может исходить из того, что Supervisors является собственным подмножеством Employees и упростить процедуру пересечения множеств. Пример, в котором дополнительные типы данных ограничивают возможности оптимизации, может служить объединение множеств Students и Employees; суперклассом для обоих классов является класс Person. Если бы мы захотели найти всех инспекторов студентов и служащих, мы бы сначала произвели объединение, а применили бы supervisor() .
  2. Запросы могут базироваться на операциях над коллекциями, но виды оптимизации, затрагивающие множества (или мультимножества, или списки и т.п.), нужно сочетать с оптимизацией над типами объектов, содержащихся в этих множествах. Объектно-ориентированный оптимизатор запросов должен быть в состоянии применять процедуры оптимизации, характерные для данных типов, а также процедуры оптимизации, учитывающие связи между объектами разных типов .
  3. Сложность обработки запросов в ООБД усугубляется наличием сложных объектов, методов и инкапсуляции. Сложные объекты порождают путевые выражения, которые усложняют обработку запросов. Создание индексов для путевых выражений, особенно при наличии в выражениях произвольных методов, усложняет обработку запросов. Проблема еще более осложняется, если методы обладают побочными эффектами. Еще одна проблема, связанная с путевыми выражениями, состоит в том, что они навязывают порядок вызовов методов путевого выражения, и этот порядок может быть весьма неэффективным. Например, путевое выражение Orders.part.name лучше вычислять справа налево, если имеется много заказов (Orders) и мало деталей (Parts), но если деталей много, а заказов мало - выражение лучше вычислять слева направо. Кроме того, иногда путевые выражения более эффективно обрабатываются с использованием Join. Рассмотрим, например, запрос с путевым выражением s.comp.name, где s принадлежит множеству Students (студенты). Могло бы оказаться более эффективно (если число компаний, comp, невелико) сначала вычислить название (Name) для каждой компании (Company) и сохранить результат в кортеже. Тогда вычисление выражения от студента до названия компании включало бы соединение множества Students с множеством кортежей путем сопоставления свойства comp класса student со значением атрибута Company некоторого кортежа.
  4. В языках запросов к ООБД поддерживается использование вложенных структур, которые опять-таки могут существенно усложнить процесс оптимизации, поскольку превращают его из локальной проблемы в проблему глобальную, поскольку требуется глобальное знание всего выражения запроса.
  5. Когда объекты обладают идентифицируемостью, возникает вопрос, а что же понимается под равенством двух объектов . Этот вопрос переносится в язык, где операции сравнения по равенству используются в предикатах, и где необходимо принимать решение о создании новых объектов при выполнении запроса. Оптимизатор объектно-ориентированных моделей должен быть в состоянии решать проблемы, связанные с созданием новых объектов и с альтернативными определениями равенства.

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

Отсутствие стандартной алгебры запросов

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

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

Отсутствие средств обеспечения запросов

В большинстве ООБД не хватает средств обеспечения запросов . В тех же немногих системах, где имеются достаточные соответствующие средства, язык запросов не совместим с ANSI SQL. Среди этих средств обеспечения запросов нет вложенных подзапросов, запросов с множествами (union, intersection, difference), агрегатных функций и GROUP BY, соединения нескольких классов - возможностей, полностью поддерживаемых в РБД .

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

Отсутствие поддержки представлений

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

Проблемы с безопасностью

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

В некоторых системах ООБД пользователи должны явным образом устанавливать и снимать блокировки. Системы РБД автоматически устанавливают и снимают блокировки при обработке пользовательских запросов и операторов обновления.

Отсутствие поддержки динамических изменений определений классов

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

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

Ограниченная поддержка ограничений целостности

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

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

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

Недостаточная поддержка сложных объектов

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

Ограниченная интеграция с объектно-ориентированными системами программирования

Трудно переписывать объектно-ориентированные программы для управления стабильными данными. Здесь возникает ряд проблем: конфликты по именам; необходимость переделывать иерархии классов; склонность ООБД к перегрузке системных операций .

Ограниченный выигрыш в производительности

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

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

***

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

Литература

  1. S. Abiteboul, A. Bonner, «Objects and views». ACM SIGMOD Int. Conf. On Management of Data, 1991.
  2. M. Atkinson, et al., «Object-Oriented Database System Manifesto». Building an Object-Oriented Database System: The Story of O2. Morgan Kaufman, 1992.
  3. F. Bancilhon, «Object oriented database systems». 7th ACM SIGART/SIGMOD Conf., 1988.
  4. J. Banerjee, et al., «Data model issues for object oriented applications». ACM Trans. On Office Information Systems, Jan 1987.
  5. J. Banerjee, W. Kim, K.C. Kim, «Queries in object oriented databases». IEEE Data Engineering Conf., Feb. 1988.
  6. D. Beech, «Foundation for evolution and relational to object databases». Proc. Extended Data Base Technology, Mar. 1988.
  7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, «Object-Oriented Query Languages: Notion and Issues». IEEE Transactions on Knowledge and Data Engineering, Mar. 1992.
  8. A.W. Brown, Object-Oriented Databases, Applications in Software Engineering. New York: McGraw-Hill, 1991.
  9. R.G.G. Cattell, Object Data Management, Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1991.
  10. M. Cherniack, «Form(ers) over Function(s): KOLA Query Algebra». Technical Report, Brown University, Dec. 1995.
  11. S. Cluet, et al., «Reloop, Algebra based query language for an object-oriented database system». 1st Int. Conf. On Deductive and Object Oriented Databases, Dec. 1989.
  12. I.F. Cruz, DOODLE: Visual language for object-oriented databases. ACM SIGMOD Int. Conf. On Management of Data, 1992.
  13. U. Dayal, «Queries and views in object-oriented data model». 2nd Int. Work. On Database Programming Languages, June 1989.
  14. K.A. Dittrich, K.R. Dittrich, «Where Object-Oriented DBMSs Should Do Better: A Critique Based on Early Experiences». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
  15. U. Erlingsson, «Object-Qriented Query Optimization», unpublished manuscript.
  16. L. Fegaras, D. Maier, «Towards an Effective Calculus for Object Query Languages». ACM SIGMOD Int. Conf. on Management of Data, San Jose, California, May 1995.
  17. L. Fegaras, D. Maier, T. Sheard, «Specifying Rule-based Query Optimizers in a Reflective Framework». 3rd Int. Conf. on Deductive and Object-Oriented Databases, Phoenix, Arizona, Dec. 1993.
  18. S. Heiler, S. Zdonik, «Object Views: Extending the vision». 6th Int. Conf. On Data Engineering, 1990.
  19. J.G. Hughes, Object-Oriented Databases. New York: Prentice-Hall, 1991.
  20. S. Khoshafian, «Insight Into Object-Oriented Databases». Information and Software Technology, Apr. 1990.
  21. S. Khoshafian, Object-Oriented Databases, New York: John Wiley & Sons, 1993.
  22. S. Khoshafian, G. Copeland, «Object identity». 1st Int. Conf. On Object-Oriented Programming Systems, Languages, and Applications, Oct. 1986.
  23. W. Kim, «Foundation for object-oriented databases». MCC Tech. Rep., N. ACA-ST-248-88, Aug. 1988.
  24. W. Kim, Introduction to Object-Oriented Databases. MIT Press, 1991.
  25. W. Kim, «Object-Oriented Database Systems: Promises, Reality, and Future». Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
  26. T.W. Leung, et al, «Aqua Data Model and Algebra». Technical Report CS-93-09, Brown University, Mar. 1993.
  27. G. Mitchell, S.B. Zdonik, U. Dayal, «Object-Oriented Query Optimization - What?s the Problem?» Technical Report CS-91-41, Brown University, June 1991.
  28. E.A. Rudensteiner, «Multiview: Methodology for supporting multiple views in object-oriented databases». 18th Int. Conf. On Very Large Databases, 1992.
  29. M. Scholl, H. Schek, «Relational object model». 3rd Int. Conf. On Database Theory, LNCS, vol. 470, Springer Verlag, 1990.
  30. P.G. Selinger, et al, «Access path selection in a relational database management system». ACM SIGMOD Int. Conf. On Management of Data, 1979.
  31. M. Stefik, D.G. Bobrow, «Object-oriented programming: Themes and variations». The AI Mag., Jan. 1986.
  32. M. Stonebraker, et al, «Third-Generation Data Base System Manifesto». Committee for Advanced DBMS Function, University of California, Berkeley, 1990.
  33. D.D. Straube, M.T. Ozsu, «Queries and query processing in object-oriented database systems». ACM Transactions on Information Systems, Oct. 1990.
  34. D.D. Straube, M.T. Ozsu, «Execution Plan Generation for Object-Oriented Data Model». 2nd Int. Conf. on Deductive and Object-Oriented Databases, Munich, Germany, Dec. 1991.
  35. S.Y.W. Su, M. Guo, H. Lam, «Association Algebra: Mathematical Foundation for Object-Oriented Databases». IEEE Transactions on Knowledge and Data Engineering, Oct. 1993.
  36. S.B. Zdonik, D. Maier, eds., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
  37. S.B. Zdonik, P. Wegner, «Language and Methodology for Object-Oriented Database Environments». Hawaii Int. Conf. on System Sciences, Jan. 1986.

Сиха Багуи ([email protected]) - лектор факультета компьютерных наук университета Западной Флориды. Соавтор трех книг, посвященных базам данных: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) и Database Design Using Entity Relationship Diagrams (CRC Press).

Translated from «Achievements and Weaknesses of Object-Oriented Databases» by Sikha Bagui in Journal of Object Technology (JOT), vol. 2, no. 4, July-August 2003, pages 29-41. Translated into Russian for Otkrytye Systemy under special permission of the original publisher. Copyright JOT, 2003. Original article at http://www.jot.fm/issues/issue_2003_07/column2 .

От редактора перевода

ООБД - зрелость или упадок?

Сергей Кузнецов

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

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

Статья основывается на анализе 36 публикаций, посвященных объектно-ориентированным базам данных и изданных в период 1986-1995 годов. Поэтому часто используемая характеристика «современные» ООБД не совсем справедлива. Цитаты, иногда подаваемые в настоящем времени, порой выглядят довольно подозрительно.

Конечно же, в многочисленных источниках использовалась разная терминология, и в этом отношении их обзор обладает исключительной пестротой. Кроме того, многие из статей достаточно сложны с технической точки зрения, и их цитирование без обеспечения контекста только затрудняет понимание. Наиболее яркий пример - подраздел про разработку объектной алгебры. Первые три «фундаментальные» операции - union, difference, select - интуитивно понятны (хотя в действительности у авторов оригинальной статьи допускается не очень очевидный вариант выборки в форме полусоединения), но две последние - generate и map - являются сложно определяемыми и неочевидными операциями.

Хочу отметить еще одну странную особенность статьи Багуи. До 2001 года существовал международный консорциум Object Data Management Group, который опубликовал три версии предложений по стандартизации объектно-ориентированной модели данных; последняя версия - ODMG 3.0 была опубликована в 2000 году . Это единственный документ, в котором предлагается сравнительно согласованная терминология и, в некоторой степени, объектно-ориентированная модель данных. Жаль, что Багуи не пользуется этим материалом.

Заметим, что в журнале «СУБД» публиковались статья, посвященная первому варианту стандарта, ODMG-93 . Краткий обзор стандарта ODMG 3.0 можно найти в . Также можно рекомендовать перевод Манифеста систем объектно-ориентированных баз данных и очень симпатичный обзор технологии ООБД .

Литература

  1. The Object Data Standard: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
  2. Л.А. Калиниченко, . // СУБД, № 1, 1996.
  3. С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests .
  4. М. Аткинсон и др., // СУБД, № 4, 1995.
  5. Арк Андреев, Дмитрий Березкин, Роман Самарев, . // Открытые системы, № 3, 2001.

Объектно-ориентированные базы данных: достижения и проблемы


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

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта 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. Организационно-систематическая работа при разработке БнД:

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки программного обеспечения (CASE), системы управления составными документами, т.е. в областях не традиционных для баз данных. Примерами объектно-ориентированных СУБД являются – POET, Jasmine, Versant, Iris , Orion.

2.2.4.Реляционная модель данных

В 1970 году американский математик Кодд Е.Ф. опубликовал революционную по своему содержанию статью, предложив использовать для обработки данных теорию множеств. Он утверждал, что данные нужно связывать в соответствии с их логическими взаимоотношениями (например, объединение, пересечение), а не физическими указателями. Он предложил простую модель данных, в которой все данные сведены в таблицы, состоящие из строк и столбцов, имеющих уникальные имена. Эти таблицы получили название реляций (relatio - отношение), а модель – реляционной моделью данных, построенной на понятии математических отношений и ее иногда называют также моделью Кодда. Предложения Кодда были настолько эффективны для систем баз данных, что за эту модель он был удостоен престижной премии Тьюринга в области теоретических основ вычислительной техники.

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

Рис.4. Таблица реляционной БД.

У каждого столбца есть свое имя. Например, в таблице «Товар на складе» (рис. 5.) имена полей такие: Идентификатор , Товар , Название группы , Группа , Единица измерения , Цена закупочная , Цена реализации , Наличие на складе .

Рис. 5. Таблица «Товар на Складе»

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

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

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

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

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

Рис.6. Пример использование внешнего ключа

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

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

Для работы с реляционными базами данных в настоящее время обычно используется язык структурированных запросов (Structured Query Language - SQL). Это язык, применяемый для создания, модификации и управления данными. Язык SQL не является алгоритмическим языком программирования. Это информационно-логический язык, он основывается на реляционной алгебре и подразделяется на три части:

· операторы определения данных;

· операторы манипуляции данными (Insert, Select, Update, Delete);

· операторы определения доступа к данным.

В 1986 году язык SQL был принят в качестве стандарта ANSI (Американский Национальный Институт Стандартов) языков реляционной базы данных. Сегодня данная база рассматривается в качестве стандарта для современных информационных систем.

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

Достоинствами реляционной модели являются:

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

При проектировании реляционной БД применяются строгие правила, базирующие на математическом аппарате;

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

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

Недостатками реляционной модели являются:

Относительно низкая скорость доступа и большой объем внешней памяти;

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

Далеко не всегда предметную область можно представить в виде совокупности таблиц.

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

Популярное
Категории

© 2024
maccase.ru - Android. Бренды. Железо. Новости