Реферат: Объектно-ориентированные СУБД

БойкоИ.

Объектно-ориентированныеСУБД.

Оглавление

TOC o «1-2» 1. 20 летэволюции программного обеспечения. GOTOBUTTON _Toc375501920 PAGEREF _Toc375501920 3

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

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

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

4.1 Why ODBMS? GOTOBUTTON _Toc375501924 PAGEREF _Toc375501924 8

4.2 Спорные моменты технологии. GOTOBUTTON _Toc375501925 PAGEREF _Toc375501925 10

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

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

5. Заключение. GOTOBUTTON _Toc375501928 PAGEREF _Toc375501928 19

6. Глоссарий GOTOBUTTON _Toc375501929 PAGEREF _Toc375501929 21

1.

Рисунок SEQ Рисунок * ARABIC 1

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

(СУБД, DBMS – Database Management System)на протяжениивсего пути развития компьютерной техники совершенствовались,поддерживая все более сложные уровни абстрактных данных, заданныхпользователем, и обеспечивая взаимодействие компонентов, распределенных вглобальных сетях и постепенно интегрирующихся с телекоммуникационнымисистемами. Позволив себе рассуждения в стиле Билла Гейтса, предположим, чторезультатом будет становление систем управления информацией одной из частейповседневной жизни каждого.

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

Последним шагом в этом направлении стала объектно-ориентированная технология,радикально изменившая сферу разработки программного обеспечения уже в 1990-хгодах (Рисунок1

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

Эволюция систем управления информацией шла параллельно этомупрогрессу, начиная с низкоуровневых программ, которые, например, напрямуюпроизводили операции чтения и записи со всей памятью без ограничения доступа,лентой, цилиндрами и дорожками диска и более высокоуровневыми средствами –файловыми системами, которые оперировали с такими понятиями, как массивы,записи и индексы для повышения производительности. Базы данных в свою очередьначинали с модели записей и индексов (ISAM и др.), приобретая со временем способность восстановленияпосле сбоев, проверки целостности данных и возможности работы несколькихпользователей одновременно. Эти ранние модели данных (CODASYL)относились скорее к уровню машинной ориентации. В дальнейшем реляционные базы данных, пришедшие насмену в 1980‑х годах, приобрели механизм запросов, позволяющий пользователю указать требуемое, предоставивСУБД самой оптимальным образом найти результат, используя динамическуюиндексацию.

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

Между тем рынок САПР был быстро насыщен, и в начале 90‑хгодов производители ООСУБД обратили внимание на другие области применения, ужепрочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБДфункциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator – DBA),средствами резервного копирования/восстановления и т. д. Работы в данномнаправлении продолжаются и сегодня, но уже можно сказать, что переход ккоммерческим приложениям идет достаточно успешно.

2.

В реляционных базахданных (Relational DatabaseSystem, RDBS) все данные отображаются в двумерных таблицах. База данных,таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системыорганизованы на основе стандарта B-Tree или методе доступа, основанном наиндексации – IndexedSequential 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).

Так как все поля одной таблицы должны содержать постоянноечисло полей заранее определенных типов, приходится создавать дополнительныетаблицы, учитывающие индивидуальные особенности элементов, при помощи внешнихключей. Такой подход сильно усложняет создание сколько нибудь сложныхвзаимосвязей в базе данных. Желающим убедится, что это действительно так и не пожалевшим на это определенный отрезоквремени, компания POETSoftware любезно предоставляет возможность ознакомиться с примером всвоей “белой книге” “POET Technical Reference”.База данных рядового предприятия общепита (клиенты – Джордж Буш и Эдди Мэрфи)состоит из четырех таблиц.

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

3.

Несмотря на рассмотренные в п. REF _Ref371952349

·

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

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

·

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

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

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

Некоторые объектные СУБД, например GemStone компании GemStoneSystems, могут сами выполнятьроль мощного объектно-реляционного адаптера, позволяя объектно-ориентированнымприложениям обращаться к реляционным БД.

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

Объектно-реляционныешлюзы. При использовании такого метода пользователь взаимодействует с БДпри помощи языка ООСУБД, а шлюз заменяет все объектно-ориентированные элементыэтого языка на их реляционные компоненты. За это опять приходитьсярасплачиваться производительностью. Например, шлюз должен преобразовать объектыв набор связей, сгенерировать оригинальные идентификаторы (original identifier – OID)объектов ипередать это в реляционную БД. Затем шлюз должен каждый раз,когда используется интерфейс реляционной СУБД, преобразовывать OID, найденный в базе, всоответствующий объект, сохраненный в РСУБД.

Производительность в рассмотренных двух подходах зависит отспособа доступа к реляционной базе данных. Каждая РСУБД состоит из двухуровней: уровня управления данными (datamanager layer)иуровня управленияносителем (storage manager layer). Первый из них обрабатываетоператоры на языке SQL,а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать какс уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовамипроцедур низкого уровня). Производительность в первом случае намного ниже(например, система OpenODB фирмыHewlett-Packard,которая может выполнять роль шлюза, поддерживает только на высоком уровне).

Гибридные СУБД.Еще одним решением может стать создание гибридных объектно-реляционных СУБД,которые могут хранить и традиционные табличные данные, и объекты. Многиеаналитики считают, что будущее за такими гибридными БД. Ведущие поставщикиреляционных СУБД начинают (или планируют) добавлять к своим продуктамобъектно-ориентированные средства. В частности, Sybase и Informix собираются в следующих версияхСУБД ввести поддержку объектов. Подобные разработки намерены вести инезависимые фирмы. Например, компания Shores готовится оснастить объектно-ориентированными средствамиСУБД Oracle8, выпусккоторой намечен на конец 1996 г.

С другой стороны, производители объектных СУБД, такие каккомпания Object Design,сознают, что объектно-ориентированные базы данных в обозримом будущем незаменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержкиреляционных и иерархических баз данных иди различного рода интерфейсы,характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмыOntos, применяемый всочетании с ее ООБД Ontos/DB.

4. 4.1 Why ODBMS?

“Белымикнигами” с названием,вынесеннымв заголовок, с избыткомснабдит любая компания, занимающаяся объектными базами данных. Кое-что опреимуществах и недостаткахобъектно-ориентированных СУБД уже упоминалось выше, подведем в таком случаеитог.

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

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

В РСУБД связи управляются пользователем, создающим внешниеключи. Затем для обнаружения связей динамически во время выполнения системапросматривает две (или больше) таблицы, сравнивая внешние ключи до достижениясоответствия. Этот процесс, называемый объединением (join), является слабой сторонойреляционной технологии. Более двух или трех уровней объединений – сигнал, чтобыискать лучшее решение. В ООСУБД пользователь просто объявляет связь, и СУБДавтоматически генерирует методы управления, динамически создавая, удаляя ипересекая связи. Ссылки при этом прямые, нет необходимости в просмотре исравнении или даже поиске индекса, который может сильно сказаться напроизводительности. Таким образом, применение объектной модели предпочтительнеедля баз данных с большим количеством сложных связей: перекрестных ссылок,ссылок, связывающих несколько объектов с несколькими (many-to-many relationships) двунаправленнымиссылками.

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

И, наконец, ООСУБД подходят (опять же без трансляций междуобъектной и реляционной моделями) для организации распределенных вычислений.Традиционные базы данных (в том числе и реляционные и некоторые объектные)построены вокруг центрального сервера, выполняющего все операции над базой. Посуществу, эта модель мало отличается от мэйнфреймовой организации 60‑хгодов с центральной ЭВМ – мэйнфреймом (mainframe), выполняющейвсе вычисления, и пассивных терминалов. Такая архитектура имеет ряднедостатков, главным из которых является вопрос масштабируемости. В настоящеевремя рабочие станции (клиенты) имеют вычислительную мощность порядка 30 ‑50 % мощности серверабазы данных, то есть большая часть вычислительных ресурсов распределена средиклиентов. Поэтому все больше приложений, и в первую очередь базы данных исредства принятия решений, работают в распределенных средах, в которых объекты(объектные программные компоненты) распределены по многим рабочим станциям исерверам и где любой пользователь может получить доступ к любому объекту.Благодаря стандартам межкомпонентного взаимодействия (об этом позже) все этифрагменты кода комбинируются друг с другом независимо от аппаратного,программного обеспечения, операционных систем, сетей, компиляторов, языковпрограммирования, различных средств организации запросов и формирования отчетови динамически изменяются при манипулировании объектами без потериработоспособности.

4.2 технологии.

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

·

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

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

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

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

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

Это необходимо для реализации уже второго необходимогосвойства баз данных – масштабируемости. Опять следует упомянуть организациюраспределенных компонентов. Классическая схема клиент-сервер, где основнаянагрузка приходится на клиента (такая архитектура называется еще “толстыйклиент-тонкий сервер”), лучше справляется с этой задачей, чем мэйнфреймоваяструктура, однако ее все равно нельзя масштабировать до уровня предприятия.Благодаря многозвенной архитектуреклиент-сервер (N-Tier architecture) происходитравномерное распределение вычислительной нагрузки между сервером и конечнымпользователем. Нагрузка распределяется по трем и более звеньям, обеспечивающимдополнительную вычислительную мощность. К чему же еще ведет такая практика?“Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой,постепенно превратилась в исключительно сложную среду. Почему? Благодаряускоренному переходу к использованию систем клиент-сервер нескольких звеньев” (PC Magazine).Разработчикам приходится расплачиваться дополнительными сложностями, большимизатратами времени и множеством проблем, связанных с интеграцией. Оставимочередное упоминание распределенных компонентов на этой не лишенной оптимизманоте.

Рисунок SEQ Рисунок * ARABIC 3Прямая и косвенная адресации.

Третье необходимое качествобазы данных – это отказоустойчивость. Именно это свойство отличает программныйпродукт от “прилады”. Существуют несколько способов обеспеченияотказоустойчивости:

·

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

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

·

third-party transaction monitor),благодаря которому транзакция выполняется не в два, а в три этапа – сначалапосылается запрос о готовности к транзакции.

Что произойдет, если один из компонентов выйдет из строя?Система, созданная в соответствии только с вышеизложенными доводами,приостановит работу всех пользователей и прервет все транзакции. Поэтому важнотакое свойство СУБД, как независимость компонентов.

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

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

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

4.3

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

В области объектных СУБД в настоящее время выработаныстандарты для:

·

Object Query Language– OQL);

·

Smalltalk);

·

Хотя у Microsoftи свое мнение на этот счет, организацией, выработавшей наиболееиспользуемые на сегодня и устоявшиеся стандарты, является консорциум поставщиковООСУБД ODMG (ООСУБД), которого поддерживаютпрактически все действующие лица отрасли. В сотрудничестве с OMG, ANSI,ISO и другими организациями был создан стандарт ODMG-93. Этот стандарт включает в себясредства для построения законченного приложения, которое будет работать (послеперекомпиляции) в любой совместимой с этой спецификацией ООСУБД.В книгу ODMG-93 входят следующие разделы:

·

Object Definition Language – ODL);

·

Рисунок SEQ Рисунок * ARABIC 4Схема использования ODL для построения приложения.

·

C++;

·

Smalltalk.

ODL. В качестве языка определенияобъектов (ODL) ODMG былвыбран существующий язык IDL(Interface Definition Language – язык описания интерфейсов), который был дополнентакими необходимыми для объектных БД свойствами, как определение коллекций,двунаправленных связей типа “многие-ко-многим”, ключей и др. В сочетании сосредствами языка IDL определенияатрибутов и операций, это позволяетопределять практически любые объекты. Все дополнения реализованы в видедоопределения методов, что обеспечивает совместимость со стандартами OMG, например стандартом CORBA.

Рисунок4

показывает работоспособную схемудля построения приложения на стандартных языках программирования, в процессекоторой автоматически генерируются метаданные,заголовочные файлы и методы. Приведем также пример на языке ODL из “белой книги” компании Objectivity, которыйиллюстрирует связи типа “один-ко-многим”, объявленные между преподавателем истудентами:

interfaceprofessor: employee {
attribute string <32> name;
unique attribute lang unsigned ssn;
relationship dept works_in inversefaculty; relationship setteaches inverse taught_by; ... operations...
{
interface section: class {
... taught_by: professor... ;
.. .
}

OQL.За основу языка OQL была взята команда SELECT

языка SQL2 (илиSQL-92) и добавленывозможность направлять запрос к объекту или коллекции объектов и возможностьвызывать методы в рамках одного запроса. Данные, полученные в результатезапроса, могут быть скалярными (включая кортежи), объектами или коллекциямиобъектов.Некоторые примеры наязыке OQL (тот же источник):

•

Select x from x in facultywhere x.salary >
 x.dept.chair.salary
•sort s in (select struct (name: x.name, s:x.ssn) from
 x in facultywhere for all y in
 x.advisees:y.age<25)by s.name
•Chair.salary
•Students except TAs
•list (1,2) + list (count (jse.advisees), 1+2)
•exists x in faculty [1:n]: x.spouse.age<25

C++. Спецификация ODMG-93 позволяетпрограммистам легко использовать объекты в то время как ООСУБД прозрачнымобразом управляет ими.Приопределении стандарта члены ODMG руководствовались следующими принципами:

·

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

·

Определениевременных экземпляров (Transient Instance) иэкземпляров, создаваемых на длительный срок (Transient Instance)припомощи оператора new(). При перегрузке оператора new()оба типа экземпляров могут создаваться от одного класса, которыйможет существовать продолжительное время.

·

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

·

Использованиеспециального механизма указателей (Smart Pointers). Связимежду объектами объявляются при помощи шаблона <span Courier New";mso-bidi-font-fa

еще рефераты

Еще работы по программированию, базе данных

Реферат по программированию, базе данных

Защита программ от компьютерных вирусов

29 Августа 2013

Реферат по программированию, базе данных

Цифровая обработка графики

29 Августа 2013

Реферат по программированию, базе данных

Программа и План - сопоставительный анализ

29 Августа 2013

Реферат по программированию, базе данных

Редактор

29 Августа 2013