Обьектно–ориентированное проектирование

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 25.04.2011
Размер файла 20,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Уральский Государственный Экономический Университет

Кафедра Информационных Систем в Экономике

Обьектно-ориентированное проектирование

На примере СУБД

Руководитель : Рузакова О.В

Выполнил : Радукин П.П

Екатеринбург 2009

Содержание

Введение

1. Примеры использования объектно-ориентированных СУБД

2. Ограничения реляционно технологии, или почему ООБД

3. Технология объектно-ориентированных СУБД

4. СУБД РОЕТ - пример реализации объектно-ориентированной технологии

5. Проблемы и перспективы

Заключение

Введение

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

1. Примеры использования объектно-ориентированных СУБД

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

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки програмного обеспечения (CASE), системы управления составными документами - словом, в областях не вполне традиционных для баз данных. Особенно заметно присутствие объектноориентированных СУБД в сфере CAD/CAM [5].

Ряд американских компаний - Auto-trol Tecnology, STEP Tools, DEC и другие - используют объектно-ориентированные СУБД (например, ObjectStore производства компании Object Design) для работы со сложноконструированными данными, соответствующими стандарту STEP (Standart of Exchange of Product Model Data - Стандарт обмена данными моделей продуктов). Этот стандарт идет гораздо дальше своих предшественников, таких как IGES, поскольку, помимо информации о геометрии детали, он должен включать информацию о версиях, спецификациях материалов, допусках, о том, как отдельные детали соединяются в агрегаты.

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

Компания Enterprise Integration Tecnologies предлагает продукт MKS (Manufacturing Knowledge System - система знаний о производстве). В рамках этого продукта возможно интегрировать разработку технологических процессов, разработку оборудования, управление предприятием, проектирование производственных помещений, диагностику, мониторинг, моделирование и планирование. Основная применения продукта - заводы по производству микросхем, хотя он пригоден для управления производством во многих отраслях. В качестве СУБД системы, хранящей информацию о всех составляющих производственного процесса, используется Objectivity/DB. Вполне естественно задаться вопросом, почему приходится отказываться от зарекомендовавшей себя реляционной технологии и пробовать не вполне проверенные временем объектно-ориентированные подходы.

2. Ограничения реляционно технологии, или почему ООБД

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

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

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

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

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

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

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

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

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

5. Усложненный доступ к базе данных. Интерфейс между языком программирования и языком баз данных обычно усложнен, поскольку каждый язык имеет свой набор типов и свою модель вычислений. Организуя обращение к базе данных из прикладной программы, написанной, например, на C++, приходится подвергать данные структурной трансформации при передаче их из/в базу данных.

база модель интерфейс

3. Технология объектно-ориентированных СУБД

Создание базы данных, как правило, включает несколько этапов [3]. Среди них можно выделить:

1. Создание концептуальной модели данных. Как правило, на этом этапе происходит уточнение требований пользователей; модель не связывается с каким-либо конкретным способом реализации, какой-либо конкретной СУБД. Такие свойства технологии моделирования, как выразительность и гибкость, играют здесь первостепенное значение. Довольно часто на практике этап создания концептуальной модели пропускается, что чревато просчетами, которые трудно и дорого исправлять на последующих этапах.

2. Логическое конструирование. На этом этапе создается модель, пригодная для реализации средствами какой-либо определенной СУБД. Здесь уже приходится считаться с ограничениями по типам данных, набору операций, налагаемыми конкретной СУБД.

3. Физическое конструирование. На этом этапе прорабатываются вопросы, связанные с реализацией модели данных во внешней памяти, - кластеризации, разбиения (partitioning), индексирования.

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

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

2. Подклассы и суперклассы - экземпляры некоторого класса могут образовывать подмножество другого класса. Так, классы "студент" или "преподаватель" могут рассматриваться как подкласс класса "человек". Для "студента" и "преподавателя" "человек" является суперклассом.

3. Подклассы наследуют атрибуты и поведение своих суперклассов (например, "студент" и "преподаватель" наследуют у "человека" такие атрибуты, как "имя", "пол", "возраст" и т.д.).

4. Наследование атрибутов и поведения позволяет построить иерархию классов: суперкласс, обладающий общими для ряда классов атрибутами, порождает ряд подклассов, которые, наследуя атрибуты своего класса-родителя, добавляют к ним ряд атрибутов, определяющих их собственные свойства. Так, класс "студент", наследуя у "человека" "имя", "возраст", "пол", может добавить к ним "курс", "кафедру" и пр. Этот механизм практически реализует концепции обобщения/конкретизации.

5. Агрегирование - по зволяет создать сложные объекты из объектов-компонентов, определять отношения типа "часть-целое".

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

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

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

4. СУБД РОЕТ - пример реализации объектно-ориентированной технологии

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

В настоящее время СУБД РОЕТ доступна не только в нескольких вариантах для UNIX платформ, но и для систем Windows 3.1, NT, OS/2, Мас System 7 и NextStep.

По сути, объектно-ориентированная СУБД РОЕТ представляет собой библиотеку классов на языке С++ и препроцессор, выполняющий обработку объектно-ориентированной структуры данных и генерацию баз данных.

Использование СУБД РОЕТ позволяет разработчикам баз данных:

1. свести к минимуму барьеры между стадиями разработки информационной системы;

2. работать с данными практически любых типов;

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

Структура служебных классов СУБД РОЕТ схематически изображена на Рисунке 1. Эта упрощенная схема (на самом деле, взаимосвязи между классами намного сложнее) позволяет оценить основные возможности системы. Центральное место системы занимает класс PtObject, который является базовым для всех классов базы данных (например, класс "клиент", "заказ" и т.п.). Подклассы, образованные от класса PtObject, для работы со строками, датами, временем могут использовать классы PtString PtDate, PtTime. Для агрегирования объектов используется класс PtSet - своеобразный контейнер классов PtObject. Например, человек может иметь несколько имен, и, таким образом, подкласс "человек" класса PtObject содержит в себе класс PtSet - набор классов "имя", образованных от класса PtObject, которые, в свою очередь, для хранения имен, отчеств и фамилий содержат строковые объекты, образованные от класса PtString.

Отношения один-ко-многим получаются использованием класса PtOnDemand. Вся база данных (на логическом уровне) - это объект класса PtAllSet, а часть базы данных может быть представлена как объект класса PtSet. Объект класса PtQuery генерирует запрос к объекту класса PtAllSet, и результат обычно записывается в объект класса PtSet. Объекты классов PtAllSet и PtObject связаны с объектом класса PtBase, представляющим собой базу данных в целом на уровне файловой системы. Создавая приложение, разработчику программисту необходимо выполнить следующие шаги:

1. Описать все типы и структуры данных, используя POET/C++ нотацию. В результате получается *.hcd файл описания структуры базы данных.

2. Написать интерфейс для работы с базой данных (ввод, просмотр, поиск объектов и т.п.), используя, например, язык С++.

3. Откомпилировать составные части разрабатываемой системы.

На рисунке 3 схематически представлена структура объектов, описывающая данные о работниках, которые трудятся над проектами, и рядом представлен фрагмент соответствующего .hcd файла. Каждый работник связан с одним проектом. Над проектом может трудиться несколько человек. Работник (класс Person) может быть программистом (класс Programmer). Программист отличается от обычного работника знанием языков программирования, и, следовательно, класс Programmer содержит не только дополнительные данные (language), но и разные методы ввода и вывода.

5. Проблемы и перспективы

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

Неясным пока остается положение со стандартами объектно-ориентированной технологии. Борьба идет между стандартами OLE 2.1 (Object Linking and Embedding, фирма Microsoft) и CORBA 2 (Common Object Request Broker Architecture, группа OMG - Object Management Group, объединяющая компании IBM, HP, Sun, Novell, ВЕС и др.). За спиной Microsoft стоят тысячи независимых разработчиков программного обеспечения для ПК, которые, как предполагается, с появлением системы Cairo перейдут на технологию Distributed OLE. Группа OMG отстаивает стандарт, ориентированный на все платформы и предназначенный для всех производителей, включая и Microsoft. Ясно, что отсутствие компромисса и война стандартов на модели объектов и способы обслуживания объектов всего лишь заставит производителей программного обеспечения на неопределенное время занять выжидательную позицию.

Тем не менее, современное системное программное обеспечение (операционные системы и средства разработки) становится всерьез объектно-ориентированным, и возможно, что к концу 1995 года объекты будут повсюду. Это обещают три конкурирующих проекта [4]: объектно-ориентированная среда OpenStep (компании Sun, HP, NeXT обещают создать ее к началу 1995 года), объектно-ориентированная среда и файловая система Cairo - объектно-ориентированная версия Windows-NT вместе с новой системой хранения файлов Object File System (фирма Microsoft планирует выпустить рабочую версию к лету 1995 года) и объектно-ориентированная операционная система Taligent (компании IBM, Apple, HP планируют завершить создание системы в 1995-96 годах).

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

Следует обратить серьезное внимание на попытки интеграции реляционного и объектно-ориентированного подхода [7]. Эти попытки заметны как со стороны известных поставщиков реляционных СУБД, так и со стороны компаний-производителей объектно-ориентированных СУБД. Можно ожидать, что такие компании-поставщики реляционных СУБД, как Oracle, Informix, SyBase, ASK Group (СУБД Ingres), IBM (СУБД DB2) в течение 1994-1996 годов в той или иной мере начнут поддерживать объектно-ориентированные технологии в своих продуктах. Большие надежды при этом возлагаются на язык запросов SQL-3, находящийся пока в стадии рассмотрения, который должен включать объектные расширения. Со своей стороны, производители объектно-ориентированных баз данных пытаются интегрировать в свои продукты элементы реляционной технологии. Так, фирма Objectivity Inc. включила в третью версию своего продукта поддержку ANSI-стандарта языка SQL. Ряд продуктов, так или иначе интегрирующих реляционный и объектно-ориентированный подходы, включают OpenODB (производитель - компания Hewlett-Packard), семейство продуктов UniSQL, производимых одноименной компанией, Montage, производства компании Montage Software, Inc. Остается, однако, вопросом, насколько глубоко и естественно можно интегрировать реляционную и объектно-ориентированную технологии. На данном этапе журнал "Datamation" считает целесообразным исследовать применимость объектно-ориентированных СУБД для данной предметной области путем реализации локальных проектов.

Заключение

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

Размещено на Allbest.ru


Подобные документы

  • Характеристики и свойства языков программирования. Исследование эволюции объектно-ориентированных языков программирования. Построение эволюционной карты механизмов ООП. Разработка концептуальной модели функционирования пользовательского интерфейса.

    курсовая работа [2,6 M], добавлен 17.11.2014

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

    реферат [128,4 K], добавлен 16.02.2012

  • Сущность и характеристика типов моделей данных: иерархическая, сетевая и реляционная. Базовые понятия реляционной модели данных. Атрибуты, схема отношения базы данных. Условия целостности данных. Связи между таблицами. Общие представления о модели данных.

    курсовая работа [36,1 K], добавлен 29.01.2011

  • Приемы и правила объектно-ориентированного программирования с использованием языка С++. Общие принципы разработки объектно-ориентированных программ. Основные конструкции языка С++. Разработка различных программ для Windows с использованием WIN32 API.

    учебное пособие [1,6 M], добавлен 28.12.2013

  • Использование скриптового языка программирования для разработки web-приложений (сценариев). Изучение основ объектно-ориентированного программирования в языке PHP. Ознакомление со специальными методами для работы с классами. Назначение интерфейсов.

    контрольная работа [25,1 K], добавлен 14.03.2015

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

    дипломная работа [66,7 K], добавлен 06.01.2014

  • Компоненты и классификация банков данных. Модели данных: иерархическая, сетевая, реляционная, постреляционная, многомерная, объектно-ориентированная. Настольные системы управления базами данных: VisualdBase, Рarаdох, Microsoft FoxРrо и Visual FoxРrо.

    курсовая работа [849,8 K], добавлен 25.04.2015

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

    презентация [1,4 M], добавлен 14.10.2013

  • Объектно-ориентированное программирование как методология программирования, опирающаяся на инкапсуляции, полиморфизме и наследовании. Общая форма класса. Наследование как процесс, посредством которого один объект получает свойства другого объекта.

    презентация [214,9 K], добавлен 26.10.2013

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

    реферат [115,8 K], добавлен 19.12.2011

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.