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

Автор работы: Пользователь скрыл имя, 31 Января 2013 в 12:01, курсовая работа

Описание

Цель нашей работы заключается в рассмотрении классов и характеристик систем управления базами данных в конкретном классе. Достижение цели достигается путем решения ряда задач:
1) дать общую характеристику СУБД;
2) выделить функциональные возможности СУБД;
3) рассмотреть особенности архитектуры СУБД;
4) охарактеризовать основные классы СУБД и дать им оценку.

Содержание

ВВЕДЕНИЕ ……………………………………………………………….......
3
ГЛАВА 1. ТЕОРЕТИЧЕСКАЯ ОСНОВА СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (СУБД) …………………………………………….....

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

6
1.2 Уровневая архитектура систем управления базами данных ……….......
10
ГЛАВА 2. ОСНОВНЫЕ КЛАССЫ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (СУБД) ………...………...………...…………………

14
2.1. Характеристика основных классов систем управления базами данных
14
2.2. Обзор современных систем управления базами данных……………….
23
ЗАКЛЮЧЕНИЕ……………………………………………………………….
28
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ……………………...
30
ПРИЛОЖЕНИЯ………………………………………………………………
32

Работа состоит из  1 файл

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

— 504.00 Кб (Скачать документ)

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

Основными понятиями, с которыми оперирует эта модель, являются следующие:

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

Множественное наследование подразумевает, что подкласс может иметь более одного "родителя".

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

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

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

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

  • реляционная таблица с конечным набором операций, которые допустимы для отношений (имеются в виду операции над множествами);
  • встроенные процедуры, работающие с отношениями.

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

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

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

В этой области  известны такие разработки как: GoodBase, ODB-Jupiter, Dss. Данные разработки совершенно различны, выполнялись в разное время и применялись для различных задач (GoodBase - для решения задач в металлургии, ODB-Jupiter - для создания систем хранения и поиска документов, Dss - для создания систем контроля и управления технологическими процессами) .

Среди современных  программных продуктов-лидеров направления  объектных СУБД можно выделить: VERSANT (Versant, Inc), ObjectStore (ObjectDesign, Inc), POET (POET Software, Inc), Jasmine (Computer Associates, Inc).

Наиболее привлекательной  для создания корпоративных информационных систем и различных прикладных программ является объектная мультимедийная СУБД Jasmine (компания Computer Associates Internatonal Inc. совместно с Fujitsu).

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

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

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

2) Распределенные системы управления базами данных (РаСУБД).

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

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

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

РаСУБД обладают безусловными преимуществами перед  централизованными, а именно:

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

Не лишены РаСУБД и недостатков:

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

Наиболее полно  функции распределенной СУБД реализованы в системах: INGRES/STAR, разработанная отделением Ingres Division фирмы The ASK Group Inc.; ORACLE фирмы ORACLE Corp.; модуле распределенной системы DB2 фирмы IBM. Наиболее близко подошли к реализации функций распределенных СУБД такие как: Informix On-line фирмы Informix Software; Sybase System 10 фирмы Sybase Inc.

К РаСУБД, наиболее изученным относятся: система SDD-1, созданная  в конце 70-х-начале 80-х годов; система R* фирмы IBM; система Distributed INGRES. которая  является распределенной версией системы INGRES (80-е годы).

 

2.2. Обзор современных систем управления базами данных (СУБД)

Первым поколением СУБД принято считать иерархические  и сетевые системы. Данные системы  получили широкое распространение  в 70-х годах прошлого века, а первой коммерческой системой данного типа была система IMS компании IBM. В 80-х годах эти системы были вытеснены системами второго поколения – повсеместно используемыми и по сей день реляционными СУБД. В этих системах использовались непроцедурные языки управления данными (SQL) и предусматривалась значительная степень независимости данных.

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

В 1991 г. был образован  консорциум ODMG (Object Database Management Group ), основной целью которого стала выработка промышленного стандарта объектно-ориентированных баз данных. Последняя версия стандарта имеет индекс 3.0. К концу 90-х существовало около десяти компаний, производящих коммерческие продукты, позиционируемые на рынке как ООСУБД. Наиболее известными системами данного класса стали Objectivity, Versant производства одноименных компаний, а также СУБД Jasmine, выпущенная компанией CA. Несмотря на преимущества, позволяющие более эффективно решать определенный ряд задач, объектно-ориентированные системы так и не смогли завоевать значимую долю рынка СУБД, оставшись «нишевым» продуктом.

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

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

  1. Помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечить поддержку более развитых структур объектов и правил. Более развитая структура объектов характеризует средства, необходимые для хранения и манипулирования нетрадиционными элементами данных (тексты, пространственные данные, мультимедиа).
  2. СУБД третьего поколения должны включить в себя СУБД второго поколения. Системы второго поколения внесли решающий вклад в двух областях – непроцедурный доступ с помощью языка запросов SQL и независимость данных. Эти достижения обязательно должны учитываться в системах третьего поколения.
  3. СУБД третьего поколения должны быть открыты для других подсистем. Это включает оснащениеразнообразными инструментами поддержки принятия решений, доступом из многих языков программирования, интерфейсами к существующим популярным системам и бизнес-приложениям, возможностью запуска приложений из базы данных на другой машине и распределенной СУБД. Весь набор инструментов и СУБД должен эффективно функционировать на разнообразных аппаратных платформах с различными операционными системами. Кроме того, СУБД, рассчитывающая на широкую сферу применения, должна быть оснащена языком четвертого поколения (4GL).

 

В середине девяностых годов  прошлого века имелось лишь несколько  исследовательских прототипов СУБД, сочетавших лучшие черты реляционных  и объектно-ориентированных СУБД. Первым коммерческим продуктом, которому были присущи объектно-реляционные черты, стал Universal Server компании Informix (впоследствии была поглощена IBM). В настоящее время большинство этих идей уже воплощено в реальных коммерческих решениях, в том числе и в продуктах основных поставщиков СУБД (Oracle Database и IBM DB2).

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

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

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