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

Объектно-ориентированная модель данных является расширением положений объектно-ориентированного программирования (в то время как реляционная модель возникла на основе теории множеств, именно как модель данных). Группой управления Объектно-ориентированных БД разработан стандарт ODMG-93 (Object DataBase Management Group). Этот стандарт полностью еще не реализован.

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

В качестве примера рассмотрим БД «БИБЛИОТЕКА» (рис.4.4). Для каждого объекта определены свойства, их типы и значения. В БД:

«БИБЛИОТЕКА» – родитель (предок) для «АБОНЕМЕНТ», «КАТАЛОГ», «ВЫДАЧА»;

«КАТАЛОГ» – родитель для «КНИГА».

«КНИГА» – различные объекты могут иметь одного или разных родителей. Если один и тот же родитель (один автор), то инвентарные номера разные, но isbn, УДК, название и автор – одинаковы.

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

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

Наследование ,наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа «КНИГА», являющимся потомками «КАТАЛОГ», можно приписать свойства родителя isbn, УДК, название и автор.

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

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

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

В 90-е годы были созданы прототипы действующих объектно-ориентированных БД. Это POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Тема 5

Реляционный подход при построении информационно-логической модели: основные понятия

Реляционная модель данных. Основные понятия

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

Основные теоретические идеи реляционной модели были изложены в работах по теории отношений американского логика Чарльза Содерса Пирса (1839-1914) и немецкого логика Эрнста Шредера (1841-1902), а также американского математика Эдгара Кодда.

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

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

Основные понятия реляционной модели даны в табл. 3.1.

Объектами реляционной модели в основном являются таблицы (отношения). Целостность данных обеспечивается внешними и первичными ключами (см. п. «Реляционная целостность данных»).

Операторы в реляционной модели – это набор инструкций, которые обеспечивают выборку и манипуляцию над данными.

Таблица 5.1. Элементы реляционной модели

Термин реляционной модели	Описание
База данных (БД)	Набор таблиц и других объектов, необходимых для абстрактного представления выбранной предметной области
Схема БД	Набор заголовков таблиц, взаимосвязанных друг с другом
Отношение	Таблица – совокупность объектов реального мира, которые характеризуются общими свойствами и характеристиками (поля таблицы)
Заголовок отношения	Заголовок таблицы – названия полей (столбцов) таблицы
Тело отношения	Тело таблицы – совокупность значений для всех объектов реального мира, которая представима в виде записей таблицы (строки таблицы)
Схема отношения	Строка заголовков столбцов таблицы («шапка» таблицы)
Атрибут отношения	Наименование столбца таблицы (поле таблицы)
Кортеж отношения	Строка таблицы (запись) – однозначное представление объекта реального мира, созданное с использованием значений полей таблицы
Домен	Множество допустимых значений атрибута
Значение атрибута	Значение поля в записи (кортеже)
Первичный ключ	Один или несколько (в случае составного ключа) атрибутов, которые единственным образом определяют значение кортежа (значение строки таблицы)
Внешний ключ	Атрибут таблицы, значения которого соответствуют значениям первичного ключа в другой связанной (родительской, первичной) таблице. Внешний ключ может состоять как из одного, так и из нескольких атрибутов (составной внешний ключ). Если число атрибутов внешнего ключа меньше, чем количество атрибутов соответствующего первичного ключа, то он называется усеченным (частичным) внешним ключом
Степень (арность) отношения	Количество столбцов таблицы
Мощность отношения	Количество строк (кортежей) таблицы
Экземпляр отношения	Множество записей (кортежей) для данной таблицы (отношения). С течением времени экземпляр может изменяться. Поскольку обычная БД в текущий момент времени работает только с одной версией отношения, то такой экземпляр отношения называется текущим
Тип данных	Тип значений элементов таблицы
Базовое отношение	Отношение, содержащие один или несколько столбцов, характеризующих свойства объекта, а также первичный ключ
Производное отношение	Не является базовым отношением, т.е. не характеризует свойства объекта и используется для обеспечения связей между другими таблицами, может не содержать первичного ключа. Если первичный ключ задан, то он состоит из внешних ключей, связанных с первичными ключами базового отношения
Связь	Устанавливает взаимосвязь между совпадающими значениями в ключевых полях – первичным ключом одной таблицы и внешним ключом другой
Связь «один-к-одному» (1:1)	При использовании этого вида связи запись в одной таблице может иметь не более одной связанной с нею записи в другой таблице. В обеих таблицах ключевые поля должны быть первичными. Используется для разделения таблиц с многочисленными полями или по требованию защиты данных
Связь «один-ко-многим» (1:M)	При использовании этого вида связи каждой записи одной таблицы может соответствовать несколько записей второй, но каждой записи второй таблицы соответствует лишь одна запись первой таблицы. В первой таблицы обязательно должен быть задан первичный ключ, во второй – внешний
Связь «многие-ко-многим» (N:M)	При данном типе связи одной записи в первой таблице может соответствовать несколько записей второй таблицы, но и одной записи второй таблицы может соответствовать несколько записей первой. Уникальность ключей для таких таблиц не требуется. В процессе проектирования схемы БД такие связи преобразуют. Для этого необходимо ввести вспомогательное отношение, позволяющее заменить связь «многие-ко-многим» на две связи типа «один-ко-многим»

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

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

Множество взаимосвязанных друг с другом таблиц образуют схему БД .

Итак, отношение R представляет собой двумерную таблицу, содержащую некоторые данные.

Математически N -арное отношение R – это множество декартова произведения D 1 ×D 2 ×…×D n множеств (доменов) D 1 , D 2 ,…,D n (n ≥1), необязательно различных:

R D 1 ×D 2 ×…×D n ,

где D 1 ×D 2 ×…×D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется из своего домена.

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

Свойства домена :

Домен имеет уникальное имя (в пределах БД),

Определен на некотором простом типе данных или на другом домене,

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

Несет определенную смысловую нагрузку.

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

Атрибут отношения представляет собой пару вида

<Имя_атрибута: Имя_домена> (либо <A:D >).

Имена атрибутов в пределах отношения уникальны. Часто имена атрибутов совпадают с именами соответствующих доменов.

Отношение R, определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – фиксированное кол-во атрибутов отношения, описывающее декартово произведение доменов, на котором задано отношение:

(<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >).

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

Тело отношения содержит множество кортежей отношения.

Каждый кортеж представляет собой множество пар вида:

<Имя_атрибута: Значение атрибута>:

R (<A 1:Val 1 >, <A 2:Val 2 >, …, <A n: Val n >).

Таких, что значение Val i атрибута A i принадлежит домену D i .

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

Отношение обычно записывается в виде:

R (<A 1: D 1 >, <A 2: D 2 >, …, <A n: D n >),

либо сокращенно: R (A 1 , A 2 , …, A n ) или R .

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

S R = (A 1 , A 2 , …, A n ), A i D i , i = 1,..., n .

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

Например, если домен содержит числовые данные, то для него допустимы все операции сравнения: θ == {=, <>,>=,<=,<,>}. Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он также имеет полное множество операций сравнения.

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

Таким образом, для эквивалентных отношений выполняются следующие условия:

Наличие одинакового количества атрибутов;

Наличие атрибутов с одинаковыми наименованиями;

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

Отношения такого рода есть различные изображения одно­го и того же отношения.

Свойства отношений непосредственно следуют из приведен­ного ранее определения отношения. В этих свойствах в ос­новном и состоят различия между отношениями реляционной модели данных и простыми таблицами:

Уникальность имени отношения. Имя одного отношения должно отличаться от имен других отношений.

Уникальность кортежей. В отношении нет одинаковых кор­тежей. Действительно, тело отношения есть множество кор­тежей и, как всякое множество, не может содержать нераз­личимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Каждая ячейка отношения содержит только атомарное (неделимое) значение.

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

Неупорядоченность атрибутов. Атрибуты не упорядочены (слева направо).

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

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

Замечание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандартная ООМ описана в рекомендациях стандарта 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.

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

Объектно-ориентированная модель (рис. 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 (Американский Национальный Институт Стандартов) языков реляционной базы данных. Сегодня данная база рассматривается в качестве стандарта для современных информационных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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