45923 (665229)

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

Текст из файла

Оъекгно-СУБД

Оглавление

1. 20 лет эволюции программного обеспечения.

2. Реляционные базы данных.

3. Объектно-реляционные методы.

4. Объектно-ориентированные базы данных.

4.1 Why ODBMS?

4.2 Спорные моменты технологии.

4.3 Стандарты объектных баз данных.

4.4 Поставщики ООСУБД.

5. Заключение.

6. Глоссарий

1.

2. 20 лет эволюциипрограммного обеспечения.

Рисунок 1

Управление информацией всегда было основной сферой применения компьютеров и,

надо думать, будет играть еще большую роль в будущем.Системы управления базами

данных[1] (СУБД, DBMS – Database Management System) на протяжении всего пути

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

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

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

стелекоммуникационными системами. Позволив себе рассуждения в стиле Билла

Гейтса, предположим, что результатом будет становление систем

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

История развития компьютерной техники – это история непрерывного движения от

языка и уровня коммуникации машины к уровнюпользователя. Если первые машины

требовали от пользователя оформления того, что ему нужно (то есть написания

программ), в машинных кодах, то языкипрограммирования четвертого уровня (4GLs)

позволяли конечным пользователям, не являющимсяпрофессиональными программистами,

получать доступ к информации без детального описания каждого шага, но только с

встроенными предопределенными типами данных– например, таблицами.

Последним шагом в этом направлении стала объектно-ориентированная

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

1990-х годах (Рисунок1). Объектно-ориентированный подход позволяет упаковывать

данные и код для их обработки вместе. Таким образом практически снимается

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

Эволюция систем управления информацией шла параллельно этому прогрессу, начиная

с низкоуровневых программ, которые, например, напрямуюпроизводили операции

чтения и записи со всей памятью без ограничения доступа, лентой, цилиндрами и

дорожками диска и более высокоуровневыми средствами –файловыми системами,

которые оперировали с такими понятиями, как массивы, записи и индексы для

повышения производительности. Базы данных в свою очередьначинали с модели

записей и индексов (ISAM и др.), приобретая со временем способность

восстановленияпосле сбоев, проверки целостности данных и возможности работы

нескольких пользователей одновременно. Эти ранние модели данных(CODASYL)

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

данных, пришедшие на смену в 1980‑х годах, приобрели механизм запросов,

позволяющий пользователю указать требуемое, предоставив СУБД самой оптимальным

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

Обьектно-ориентированные СУБД (ООСУБД) стали разрабатываться с середины 80‑х

годов восновном для поддержки приложений САПР. Сложные структуры данных систем

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

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

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

записи их в файлы послезавершения работы с чертежом, выполнения обратной

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

имеют связи глубиной в двауровня, то иерархическая информация чертежей САПР

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

для “сборки”результата. Объектные базы данных хорошо соответствовали подобным

задачам, и эволюция многих СУБД началась именно с рынка САПР.

Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители

ООСУБД обратили внимание на другие области применения, ужепрочно занятые

реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями

оперативной обработки транзакций (OLTP), утилитами администратора баз данных

(database administrator – DBA), средствами резервногокопирования/восстановления

и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно

сказать, что переход к коммерческим приложениям идетдостаточно успешно.

3. Реляционные базы данных.

В реляционных базах данных (Relational Database System, RDBS) все данные

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

иное,как набор таблиц. RDBS и ориентированные на записи системы организованы на

основе стандарта B-Tree илиметоде доступа, основанном на индексации – Indexed

Sequential Access Method (ISAM) и являются стандартными

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

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

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

B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO

(Digital Equipment), причем стандартом отрасли внастоящее время стал язык SQL,

поддерживаемый всеми производителями реляционных СУБД.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для

выполненияопераций над базами данных. Язык SQL был создан в начале 70‑х как

интерфейс для взаимодействия с базами данных, основанными на новой для того

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

генерирующих код на языке SQLи передающих их в СУБД в виде текста в формате

ASCII. Нужно отметить также, что практически все реальные реляционные (и не

только реляционные) системы помимореализации стандарта ANSI SQL, известного

сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя

дополнительныерасширения, например, поддержка архитектуры клиент-сервер или

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

Строки таблицы составлены из полей, заранее известных базе данных. В большинстве

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

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

вставкой новых строк.

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор

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

называются первичным ключом (primary key) таблицы и часто являются числами. Если

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

между элементами разных таблиц. Это поле называетсявнешним ключом (foreign key).

Так как все поля одной таблицы должны содержать постоянное число полей заранее

определенных типов, приходится создавать дополнительныетаблицы, учитывающие

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

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

Желающим убедится, что это действительно так и не пожалевшим на это

определенный отрезоквремени, компания POET Software любезно предоставляет

возможность ознакомиться с примером в своей “белой книге” “POET Technical

Reference”. База данных рядового предприятия общепита (клиенты – Джордж Буш и

Эдди Мэрфи) состоит изчетырех таблиц.

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

манипулирования информацией и изменения связей.

4. Объектно-реляционные методы.

Несмотря на рассмотренные в п. 3 недостатки реляционных баз данных, они обладают

рядом достоинств:

разделение таблиц разными программами;

развернутый “код возврата” при ошибках;

высокая скорость обработки запросов (команда SELECTязыка SQL; результатом

выборки является таблица, которая содержит поля, удовлетворяющие заданному

критерию);

Рисунок 2 Возможные подходы к объединению объектных и реляционных БД.

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

серьезного и длительного обучения;

относительно высокая скорость при работе с большимиобъемами данных.

Кроме того, во всем мире значительные средства уже инвестированы в реляционные

СУБД. Многие организации не уверены, что затраты, связанные с переходом на

объектные базы данных, окупятся.

Поэтому многие пользователи заинтересованы в комбинированном подходе, который бы

им позволил воспользоваться достоинствами объектных базданных, не отказываясь

полностью от своих реляционных БД. Такие решения действительно существуют. Если

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

последней в качестве расширения и дополнения реляционных СУБД часто является

более экономичной альтернативой.Компромиссные решения позволяют соблюсти баланс

между объектами и реляционными таблицами (Рисунок2).

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

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

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

Объектно-ориентированныеприложение работает как рядовой пользователь СУБД.

Несмотря на некоторое снижение производительности, такой вариант позволяет

программистам целикомсконцентрироваться на объектно-ориентированной разработке.

Кроме того, все имеющиеся на предприятии приложения по-прежнему могут обращаться

к данным,хранящимся в реляционной форме.

Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут

сами выполнятьроль мощного объектно-реляционного адаптера, позволяя

объектно-ориентированным приложениям обращаться к реляционным БД.

Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для

СУБД Oracle, можно с успехом использовать вомногих областях, например в качестве

связующего ПО, объединяющего объектно-ориентированные приложения с реляционными

СУБД.

Объектно-реляционные шлюзы. При использовании такого метода пользователь

взаимодействует с БДпри помощи языка ООСУБД, а шлюз заменяет все

объектно-ориентированные элементы этого языка на их реляционные компоненты. За

это опять приходитьсярасплачиваться производительностью. Например, шлюз должен

преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы

(original identifier – OID) объектов и передать этов реляционную БД. Затем шлюз

должен каждый раз, когда используется интерфейс реляционной СУБД,

преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный

вРСУБД.

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

реляционной базе данных. Каждая РСУБД состоит из двухуровней: уровня управления

данными (data manager layer) и уровня управления носителем (storage manager

layer). Первый из нихобрабатывает операторы на языке SQL, а второй отображает

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

есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя

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

ниже (например, система OpenODBфирмы Hewlett-Packard, которая может выполнять

роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД. Еще одним решением может стать создание гибридных

объектно-реляционных СУБД,которые могут хранить и традиционные табличные данные,

и объекты. Многие аналитики считают, что будущее за такими гибридными БД.

Ведущие поставщикиреляционных СУБД начинают (или планируют) добавлять к своим

продуктам объектно-ориентированные средства. В частности, Sybase и Informix

собираются в следующих версияхСУБД ввести поддержку объектов. Подобные

разработки намерены вести и независимые фирмы. Например, компания Shores

готовится оснастить объектно-ориентированными средствамиСУБД Oracle8, выпуск

которой намечен на конец 1996 г.

С другой стороны, производители объектных СУБД, такие как компания Object

Design,сознают, что объектно-ориентированные базы данных в обозримом будущем не

заменят реляционные СУБД. Это вынуждает их создавать шлюзы для

поддержкиреляционных и иерархических баз данных иди различного рода интерфейсы,

характерным примером которых является объектно-реляционный интерфейс Ontos

Integration Server фирмы Ontos, применяемый всочетании с ее ООБД Ontos/DB.

5. Объектно-ориентированные базы данных.

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов реферата