В объектно-ориентированной модели (ООМ) при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Стандартная ООМ описана в рекомендациях стандарта 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.
В основе технологий баз данных, базирующихся на описанных выше МД, лежит статическая концепция хранения информации, сконцентрированная на моделировании данных. Однако новые области применения технологии со сложными, взаимосвязанными объектами БД, такими как:
Автоматизированное проектирование;
Автоматизированное производство;
Автоматизированная разработка программного обеспечения;
Офисные информационные системы;
Мультимедиа системы;
Геоинформационные системы;
Издательские системы и другие, - продемонстрировали ограниченные возможности статической концепции с точки зрения моделирования объектов реального мира.
Для новых типов сложных специализированных приложений БД эффективна динамическая концепция хранения информации, позволяющая параллельно моделировать данные и процессы, действующие на эти данные. Это позволяет учитывать семантику предметной области и потому наиболее адекватно описывать эти приложения. Такая концепция основывается на объектно-ориентированном подходе, широко используемом при создании программного обеспечения. МД, реализующая данную концепцию и базирующаяся на объектно-ориентированной парадигме (ООП), получила название объектно-ориентированной модели данных (ООМД).
Построение ООМД исходит из предположения о том, что предметную область можно описать совокупностью объектов. Каждый объект представляет собой уникально идентифицируемую сущность, которая содержит атрибуты, описывающие состояние объектов «реального мира», и связанные с ними действия. Текущее состояние объекта описывается одним или несколькими атрибутами, которые могут быть простыми или сложными. Простой атрибут может иметь примитивный тип (например, целое число, строка и т. д.) и принимать литеральное значение. Составной атрибут может содержать коллекции и/или ссылки. Ссылочный атрибут представляет собой связь между объектами.
Ключевым свойством объекта является уникальность его Идентификации. Поэтому у каждого объекта в объектно-ориентированной системе должен быть свой идентификатор.
Идентификатор объекта (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).
При наличии большого количества экспериментальных проектов (и даже коммерческих систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле, имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
Объектно-ориентированная модель (рис. 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 (Американский Национальный Институт Стандартов) языков реляционной базы данных. Сегодня данная база рассматривается в качестве стандарта для современных информационных систем.
Таким образом, таблица является основным типом структуры данных реляционной модели. Структура таблицы определяется совокупностью столбцов. В каждой строке таблицы содержатся по одному значению в соответствующем столбце. В таблице не может быть двух одинаковых строк, общее число строк не ограничено. Столбец – это элемент данных, каждый столбец имеет имя. Один или несколько атрибутов, значения которых однозначно идентифицируют строку таблицы, являются ключом таблицы.
Достоинствами реляционной модели являются:
Простота и доступность понимания конечным пользователем - единственной информационной конструкцией является таблица;
При проектировании реляционной БД применяются строгие правила, базирующие на математическом аппарате;
Полная независимость данных. При изменении структуры изменения, которые требуют произвести в прикладных программах, минимальны;
Для построения запросов и написания, прикладных программ нет необходимости знания конкретной организации БД во внешней памяти.
Недостатками реляционной модели являются:
Относительно низкая скорость доступа и большой объем внешней памяти;
Трудность понимания структуры данных из-за появления большого количества таблиц в результате логического проектирования;
Далеко не всегда предметную область можно представить в виде совокупности таблиц.
Реляционные базы данных в настоящее время получили наибольшее распространение. Сетевые и иерархические модели считаются устаревшими, объектно-ориентированные модели пока не стандартизированы и не получили широкого распространения.
Объектно-ориентированная база данных (ООБД) - база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.
Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.
В манифесте ООБД предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой базу данных.
Обязательные характеристики
1. Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.
2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
3. Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
4. Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)
5. Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
6. Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.
7. Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
8. Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.
ОО СУБД
Объектно-ориентированные базы данных – базы данных, в которых информация представлена в виде объектов, как в объектно-ориентированных языках программирования.
Применять или не применять объектно-ориентированные системы управления базами данных (ООСУБД) в реальных проектах сегодня? В каких случаях их применять, а в каких нет?
Вот преимущества использования ООСУБД:
· Отсутствует проблема несоответствия модели данных в приложении и БД (impedance mismatch). Все данные сохраняются в БД в том же виде, что и в модели приложения.
· Не требуется отдельно поддерживать модель данных на стороне СУБД.
· Все объекты на уровне источника данных строго типизированы. Больше никаких строковых имен колонок! Рефакторинг объектно-ориентированной базы данных и работающего с ней кода теперь автоматизированный, а не однообразный и скучный процесс.
Стандарт ODMG
Первый манифест формально являлся всего лишь статьей, представленной на Конференцию по объектно-ориентированным и дедуктивным базам данных группой частных лиц. Как вы могли видеть в предыдущем подразделе, требования Манифеста были скорее эмоциональными, чем явно специфицированными. В 1991 г. был образован консорциум ODMG (тогда эта аббревиатура раскрывалась как Object Database Management Group , но впоследствии приобрела более широкую трактовку – Object Data Management Group ). Консорциум ODMG тесно связан с гораздо более многочисленным консорциумом OMG (Object Management Group ), который был образован двумя годами раньше. Основной исходной целью ODMG была выработка промышленного стандарта объектно-ориентированных баз данных (общей модели). За основу была принята базовая объектная модель OMG COM (Core Object Model ). В течение более чем десятилетнего существования ODMG опубликовала три базовых версии стандарта, последняя из которых называется ODMG 3.0 . 16
Забавно, что хотя ODMG (по мнению автора) вышла из OMG , в последние годы некоторые стандарты OMG опираются на объектную модель ODMG . В частности, на модель ODMG опирается спецификация языка OCL (Object Constraint Language ), являющаяся частью общей спецификации языка UML 1.4 (и UML 2.0) . В этой статье мы не ставим цель провести детальное сопоставление подходов OMG и ODMG и отсылаем заинтересованных читателей к Энциклопедии Когаловского и материалам сайтов этих консорциумов . Мы ограничимся кратким изложением основных идей, содержащихся в стандарте ODMG -3.
Архитектура ODMG
Предлагаемая ODMG архитектура показана на рис. 2.1. В этой архитектуре определяются способ хранения данных и разные виды пользовательского доступа к этому “хранилищу данных” 17 . Единое хранилище данных доступно из языка определения данных, языка запросов и ряда языков манипулирования данными. 18 На рис. 2.1 ODL означает Object Definition Language (язык определения объектов) , OQL – Object Query Language (язык объектных запросов) и OML – Object Manipulation Language (язык манипулирования объектами) .
Рис. 2.1. Архитектура ODMG
Центральной в архитектуре является модель данных , представляющая организационную структуру, в которой сохраняются все данные, управляемые ООСУБД. Язык определения объектов, язык запросов и языки манипулирования разработаны таким образом, что все их возможности опираются на модель данных. Архитектура допускает существование разнообразных реализационных структур для хранения моделируемых данных, но важным требованием является то, что все программные библиотеки и все поддерживающие инструментальные средства обеспечиваются в объектно-ориентированных рамках и должны сохраняться в согласовании с данными.
Основными компонентами архитектуры являются следующие.
- Объектная модель данных. Все данные, сохраняемые ООСУБД, структуризуются в терминах конструкций модели данных. В модели данных определяется точная семантика всех понятий (более подробно см. ниже).
- Язык определения данных (ODL). Схемы баз данных описываются в терминах языка ODL , в котором конструкции модели данных конкретизируются в форме языка определения. ODL позволяет описывать схему в виде набора интерфейсов объектных типов, что включает описание свойств типов и взаимосвязей между ними, а также имен операций и их параметров. ODL не является полным языком программирования; реализация типов должна быть выполнена на одном из языков категории OML . Кроме того, ODL является виртуальным языком в том смысле, что в стандарте ODMG не требуется его реализация в программных продуктах ООСУБД, которые считаются соответствующими стандарту. Допускается поддержка этими продуктами эквивалентных языков определения, включающих все возможности ODL , но адаптированных под особенности конкретной системы. Тем не менее, наличие спецификации языка ODL в стандарте ODMG является важным, поскольку в языке конкретизируются свойства модели данных.
- Язык объектных запросов (ODL). Язык имеет синтаксис, похожий на синтаксис языка SQL, но опирается на семантику объектной модели ODMG . В стандарте допускается прямое использование OQL и его встраивание в один из языков категории OML .
Реляционная модель данных
Почти все современные системы основаны на реляционной (relational) модели управления базами данных. Название реляционная связано с тем, что каждая запись в такой базе данных содержит информацию, относящуюся только к одному конкретному объекту.
В реляционной СУБД все обрабатываемые данные представляются в виде плоских таблиц. Информация об объектах определенного вида представляется в табличном виде: в столбцах таблицы сосредоточены различные атрибуты объектов, а строки предназначены для сведения описаний всех атрибутов к отдельным экземплярам объектов.
Модель, созданная на этапе инфологического моделирования, в наибольшей степени удовлетворяет принципам реляционности. Однако для приведения этой модели к реляционной необходимо выполнить процедуру, называемую нормализацией .
Теория нормализации оперирует с пятью нормальными формами . Эти формы предназначены для уменьшения избыточности информации, поэтому каждая последующая нормальная форма должна удовлетворять требованиям предыдущей и некоторым дополнительным условиям. При практическом проектировании баз данных четвертая и пятая формы, как правило, не используются. Мы ограничились рассмотрением первых четырех нормальных форм.
Введем понятия, необходимые для понимания процесса приведения модели к реляционной схеме.
Отношение - абстракция описываемого объекта как совокупность его свойств. Проводя инфологический этап проектирования, мы говорили об абстракции объектов и приписывали им некоторые свойства. Теперь же, проводя концептуальное проектирование, мы переходим к следующему уровню абстракции. На данном этапе объектов, как таковых, уже не существует. Мы оперируем совокупностью свойств, которые и определяют объект.
Экземпляр отношения - совокупность значений свойств конкретного объекта.
Первичный ключ - идентифицирующая совокупность атрибутов, т.е. значение этих атрибутов уникально в данном отношении. Не существует двух экземпляров отношения содержащих одинаковые значения в первичном ключе.
Простой атрибут - атрибут, значения которого неделимы.
Сложный атрибут - атрибут, значением которого является совокупность значений нескольких различных свойств объекта или несколько значений одного свойства.
Понятия сущности..
Домен
Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена.
Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).
Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.
Постреляционная модель
Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц. Постреляционная модель представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных. Модель допускает многозначные поля – поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу.
На рис. 2.6 на примере информации о накладных и товарах для сравнения приведено представление одних и тех же данных с помощью реляционной (а) и постреляционной (б) моделей. Из рисунка видно, что по сравнению с реляционной моделью в постреляционной модели данные хранятся более эффективно, а при обработке не потребуется выполнять операцию соединения данных из двух таблиц.
Накладные Накладные-товары
|
N накладной |
Покупатель |
N накладной |
Количество |
||
Накладные
|
N накладной |
Покупатель |
Количество |
|
Рис. 2.6. Структуры данных реляционной и постреляционной моделей
Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД соответствующих механизмов.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.
Рассмотренная постреляционная модель данных поддерживается СУБД uniVers . К числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb .
Многомерная модель
Многомерный подход к представлению данных появился практически одновременно с реляционным, но интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов. Толчком послужила в 1993 году статья Э. Кодда. В ней были сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing – оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных.
В развитии концепций информационных систем можно выделить следующие два направления:
Системы оперативной (транзакционной) обработки;
Системы аналитической обработки (системы поддержки принятия решений).
Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД.
Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации. Основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость.
Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь, управляющий, руководитель.
Историчность данных предполагает обеспечение высокого уровня статичности собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени.
Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными.
По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 2.7 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей.
Основные понятия многомерных моделей данных: измерение и ячейка.
Измерение – это множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.
Ячейка – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).
Рис. 2.7. Реляционное и многомерное представление данных
В примере на рис. 2.7 б каждое значение ячейки Объем продаж однозначно определяется комбинацией временного измерения Месяц продаж и модели автомобиля. На практике зачастую требуется большее количество измерений. Пример трехмерной модели данных приведен на рис. 2.8.
Рис. 2.8. Пример трехмерной модели
В существующих многомерных СУБД используются две основных схемы организации данных: гиперкубическая и поликубическая.
В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server .
В случае гиперкубической схемы предполагается, что все ячейки определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов в БД, все они имеют одинаковую размерность и совпадающие измерения.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем.
Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации.
Примерами систем, поддерживающими многомерные модели данных, является Essbase , Media Multi - matrix , Oracle Express Server , Cache . Существуют программные продукты, например Media / MR , позволяющие одновременно работать с многомерными и с реляционными БД.
Объектно-ориентированная модель
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы данных. Между записями и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG -93 (Object Database Management Group – группа управления объектно-ориентированными базами данных).
Рассмотрим упрощенную модель объектно-ориентированной БД. Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связн ую ие рархию объектов. Пример логической структуры объектно-ориентированной БД библиотечного дела приведен на рис. 2.9. Здесь объект типа Библиотека является родительским для объектов-экземпляров классов Абонент , Каталог и Выдача . Различные объекты типа Книг а могут иметь одного или разных родителей. Объекты типа Книга , имеющие одного и того же родителя, должны различаться, по крайней мере, инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isb n , удк , названи е и автор .
Логическая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД. Основное различие между ними состоит в методах манипулирования данными.
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Каталог добавить свойство, задающее телефон автора книги и имеющее название телефон , то мы получим одноименные свойства у объектов Абонент и Каталог . Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование , наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Книга , являющимся потомками объекта типа Каталог , можно приписать свойства объекта-родителя: isbn , удк , название и автор . Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs . Так, определение абстрактных свойств билет и номер в объекте Библиотека приводит к наследованию этих свой ств вс еми дочерними объектами Абонент , Книга и Выдач а. Не случайно, поэтому значения свойства билет классов Абонент и Выдача , показанных на рис. 2.9, являются одинаковыми – 00015.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к рассматриваемому примеру полиморфизм означает, что объекты класса Книга , имеющие разных родителей из класса Каталог , могут иметь разный набор свойств. Следовательно, программы работы с объектами класса Книга могут содержать полиморфный код.
Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД.
Рис. 2.9. Логическая структура БД библиотечного дела
Основным достоинством объектно-ориентированной модели данных в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
К объектно-ориентированным СУБД относятся POET , Jasmine , Versant , O 2, ODB - Jupiter , Iris , Orion , Postgres .
