Виды систем управления базами данных

Нижегородский филиал Курсовая работа По дисциплине: Базы данных Тема: Виды систем управления базами данных Студента Арафайлова Алексея Валентиновича

• Введение
• 1. Основная часть
• 1.1 Основные сведения о СУБД
• 1.1 Функциональные возможности СУБД
• 1.2 Уровневая архитектура СУБД
• 2. Основные классы СУБД
• 2.1 Характеристика реляционных СУБД
• 2.2 Характеристика объектных СУБД
• 2.3 Характеристика распределенных СУБД
• Заключение
• Глоссарий
• Список использованных источников
• Приложения

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

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

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

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

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

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

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

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

1) дать общую характеристику СУБД;

2) выделить функциональные возможности СУБД;

3) рассмотреть особенности архитектуры СУБД;

4) охарактеризовать основные классы СУБД и дать им оценку.

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

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

управление база реляционная распределенная

1. Основная часть

1.1 Основные сведения о СУБД

Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов XX века специальных программных комплексов, называемых «Системы управления базами данных» (СУБД).

СУБД называют программную систему, предназначенную для создания на ЭВМ общей базы данных, используемой для решения множества задач. Подобные системы служат для поддержания базы данных в актуальном состоянии и обеспечивают эффективный доступ пользователей к содержащимся в ней данным в рамках предоставленных пользователям полномочий Система управления базой данных [Электронный ресурс]. — Режим доступа: http: //www.ssti.ru/kpi/informatika/Content/biblio/b1/inform_man/gl₁₅_3. htm. — Загл. с экрана.

Термин база данных (БД) определяется по-разному. Мы выделим следующее определение: база данных — это совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данным, независимая от прикладных программ. Может рассматриваться как информационная модель предметной области Братчиков И. Л. Основы проектирования баз данных [Электронный ресурс]. — Режим доступа: http: //www.apmath. spbu.ru/ru/education/final/question41. pdf. — Загл. с экрана.

1.1 Функциональные возможности СУБД

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

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

1) Управление хранением данных.

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

2) Управление буферами оперативной памяти.

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

3) Управление словарем данных.

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

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

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

4) Журнализация.

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

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

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

Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (протокола Write Ahead Log — WAL). Этот способ заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя Руководство администратора баз данных Informix [Электронный ресурс]. — Режим доступа: http: //www.computerbooks.ru/книга/руководство%20администратора%20баз%20данных%20inrformix/4. — Загл. с экрана.

5) Управление транзакциями.

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

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

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

6) Управление безопасностью Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. — 5-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2004.С. 43.

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

7) Поддержка языков баз данных.

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language — язык структурированных запросов). Так как в состав SQL входят два основных компонента: язык определения данных (DDL) и язык манипулирования данными (DML), SQL позволяет определять схему реляционной БД и манипулировать данными Бураков П. В., Петров В. Ю.

Введение

в системы баз данных: Учебное пособ. — Изд-во: СПбГУ ИТМО, 2010.С. 17.

1.2 Уровневая архитектура СУБД

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

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

Концепции многоуровневой информационной архитектуры стали основой современной технологии баз данных. Эти идеи связывают с опубликованным в 1975 году отчетом рабочей группы по базам данных ANSI/X3/SPARC (Комитета по планированию стандартов Американского национального института стандартов). В данном отчете была предложена обобщенная трехуровневая модель информационной архитектуры системы базы данных, включающая концептуальный, внутренний и внешний уровни (см. Приложение А). Такая модель описывает архитектуру любой системы базы данных, но какие-либо ее компоненты или функции в конкретной СУБД могут иметь вырожденный характер.

Концептуальный уровень архитектуры ANSI/X3/SPARC служит для поддержки единого «взгляда» на базу данных, общего для всех ее приложений и в этом смысле независимого от них. Именно в среду концептуального уровня при проектировании базы данных отображается концептуальная модель предметной области. Представление базы данных на концептуальном уровне системы описывается концептуальной схемой базы данных.

Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления базы данных в среде хранения. Это единственный уровень информационной архитектуры, где база данных в действительности представлена полностью в «материализованном» виде. Описание представления базы данных на внутреннем уровне архитектуры называется внутренней схемой или схемой храненияМиндалев И. В. Информационные системы: Электронный учебно-методический комплекс [Электронный ресурс]. — Режим доступа: http: //www.kgau.ru/istiki/is/index.html. — Загл. с экрана. На внутреннем уровне хранится следующая информация: сведения о распределении дискового пространства для хранения данных и индексов; описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных); сведения о размещении записей; сведения о сжатии данных и выбранных методах их шифрования.

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

Необходимо отметить, что в предлагаемой архитектурной модели необходимо поддерживать соответствие между представлениями базы данных на смежных уровнях архитектуры системы базы данных. В модели ANSI/X3/SPARC для этой цели служат механизмы междууровневого отображения данных «внешний — концептуальный» и «концептуальный внутренний». Именно эти механизмы обеспечивают абстракцию данных в системе, определяют достижимую в системе степень независимости данных.

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

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

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

Принятое в архитектуре ANSI-SPARC двухэтапное отображение может сказываться на эффективности работы, но при этом оно обеспечивает более высокую независимость от данных Среда базы данных [Электронный ресурс]. — Режим доступа: http: //do. bti. secna.ru/lib/book_it/sreda_bd.html. — Загл. с экрана.

2. Основные классы СУБД

В данной главе выделим и характеризируем основные классы СУБД.

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

Более ранние СУБД такие как иерархические и сетевые имеют древовидную структуру и построены по принципу «Предок — потомок». Но такие системы уже отжили своё и применяются все реже.

На смену иерархическим и сетевым пришли реляционные СУБД.

2.1 Характеристика реляционных СУБД

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

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

Реляционный подход в построении СУБД имеет ряд достоинств Байдак А. Я., Булгаков А. А. Современные СУБД и их применение в энергетике [Электронный ресурс]. — Режим доступа: http: //masters. donntu.edu.ua/2010/etf/baydak/library/article2. htm. — Загл. с экрана:

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

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

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

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

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

Основной принцип реляционной модели — устранять повторяющиеся поля и группы с помощью процесса, который называется нормализацией. Плоские нормализованные таблицы универсальны, просты в понимании и теоретически достаточны для представления данных любой предметной области. Они хорошо подходят для приложений, связанных с хранением и отображением данных в традиционных отраслях, таких как банковские или учетные системы, но их применение в системах, основанных на более сложных структурах данных, часто является затруднительным. В основном, это связано с примитивностью механизмов хранения данных, лежащих в основе реляционной модели Никитин М. Закончилась ли эпоха реляционных СУБД? [Электронный ресурс]. — Режим доступа: http: //www.cnews.ru/reviews/free/marketBD/articles/articles2. shtml. — Загл. с экрана.

На сегодняшний день известные фирмы производители реляционных СУБД следующие — ORACLE, Informix, IBM (DB2), Sybase, Microsoft (MS SQL Server), Progress и другие. В своих продуктах производители СУБД ориентируются на работу на различных типах компьютеров (от майнфреймов до портативных) и на различных операционных системах (ОС). Также производители СУБД не обошли вниманием продукты, работающие на настольных компьютерах, такие как dBase, FoxPro, Access и им подобные. Данные СУБД предназначены для работы на РС и решают локальные задачи на одном РС или небольшой группе РС. Часто данные СУБД используются, как зеркальное отображения небольшой части общей корпоративной СУБД, для минимизации требуемых аппаратных и ресурсных затрат для решения небольших задач.

Различные СУБД работают под управлением разных ОС и аппаратной части. Наиболее известные среди таких ОС — UNIX, VAX, Solaris, Windows. В зависимости от объема хранения данных, количества пользователей, осуществляющих одновременный доступ к данным, сложности задач — используются различные СУБД на различных платформах. Например, СУБД Oracle на Unix, инсталлированная на многопроцессорный сервер позволяет решать задачи по обеспечению данными сотни тысяч пользователей Пономарева И. С. Системы управления базами данных [Электронный ресурс]. — Режим доступа: http: //mathmod. aspu.ru/images/File/Ponomareva/TM10_About%20BD. pdf. — С. 2.

В настоящее время наибольший интерес представляют СУБД ориентированные на операционную систему Windows использующие платформу Intel.

2.2 Характеристика объектных СУБД

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

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

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

В объектной технологии свойства данных не сводятся к простым «компьютерным» типам данных. Объекты могут содержать внутри себя другие объекты или ссылки на них. Это облегчает построение точных и удобных моделей данных.

Объектные СУБД реализуют весь набор функций, присущих системам управления базами данных плюс возможности объектного программирования. Таким образом, мы получаем все преимущества СУБД наряду с мощным объектным языком программирования (среди них C++, Java, Smalltalk) объектов базы — см. Приложение В Андреев А. М. Березкин Д.В. Кантонистов Ю. А. Объектные СУБД на российских просторах [Электронный ресурс]. — «Компьютерная хроника», 1997 г., N11. — Режим доступа: http: //www.inteltec.ru/publish/articles/objtech/chronic. shtml. — Загл. с экрана.

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

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

Основными понятиями, с которыми оперирует эта модель, являются следующие Федоров В. А. Постреляционная эра: реляционная или объектная? [Электронный ресурс]. — Режим доступа: http: //www.ict.edu.ru/ft/3 850/PostrelationarEra. pdf. — Загл. с экрана:

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

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

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

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

Дополнительно существует еще две особенности объектного подхода — типизация и сохраняемость. Типизация защищает разработчика от некорректного использования в прикладных программах объектов одного класса вместо другого. Сохраняемость (или хранимость) позволяет объекту существовать в системе после завершения выполнения породившего его процесса. Принцип сохраняемости является чрезвычайно важным для концепции объектных СУБД Гришков В. И. Исследование возможностей объектного представления данных в прикладных системах // Труды СПИИРАН. Вып. 1, т. 3. — СПб: СПИИРАН, 2003.С. 78−79.

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

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

— встроенные процедуры, работающие с отношениями.

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

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

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

Со времен СССР давно и активно развивались объектные СУБД. В этой области известны такие разработки как: GoodBase, ODB-Jupiter, Dss. Данные разработки совершенно различны, выполнялись в разное время и применялись для различных задач (GoodBase — для решения задач в металлургии, ODB-Jupiter — для создания систем хранения и поиска документов, Dss — для создания систем контроля и управления технологическими процессами) Снова о объектных СУБД [Электронный ресурс] // Открытые системы, № 04, 1999. — Режим доступа: http: //www.publish.ru/os/1 072 579/text/179 797/_p3.html. — Загл. с экрана.

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

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

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

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

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

2.3 Характеристика распределенных СУБД

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

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

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

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

— отражают структуру организации;

— обладают разделяемостью и локальной автономностью;

— обеспечивают высокую доступность данных;

— обладают высокой надежностью и повышенной производительностью.

Не лишены РаСУБД и недостатков Зеневич А. М. Системы обработки многопользовательских баз данных: Курс лекций [Электронный ресурс]. — Режим доступа: http: //www.bseu. by/ffbd/tohod/lekcii8₅. htm. — Загл. с экрана:

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

— Увеличение сложности означает и увеличение затрат на приобретение и сопровождение РаСУБД.

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

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

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

— Еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем.

— РаСУБД сложны в управлении, что обусловливает потенциальную опасность потери целостности данных.

Наиболее полно функции распределенной СУБД реализованы в системах: 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-е годы).

Заключение

Подводя итоги нашей работы, выделим следующие моменты.

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

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

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

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

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

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

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

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

Глоссарий

Список использованных источников

1. Бураков П. В., Петров В. Ю.

Введение

в системы баз данных: Учебное пособ. — Изд-во: СПбГУ ИТМО, 2010. — 129 с.

2. Гришков В. И. Исследование возможностей объектного представления данных в прикладных системах // Труды СПИИРАН. Вып.1, т.3. — СПб: СПИИРАН, 2003.

3. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. — 5-е изд., перераб. и доп. — СПб.: БХВ-Петербург, 2004. — 1040 с.

4. Андреев А. М. Березкин Д.В. Кантонистов Ю. А. Объектные СУБД на российских просторах [Электронный ресурс]. — «Компьютерная хроника», 1997 г., N11. — Режим доступа: http://www.inteltec.ru/publish/articles/objtech/chronic. shtml. — Загл. с экрана

5. Байдак А. Я., Булгаков А. А. Современные СУБД и их применение в энергетике [Электронный ресурс]. — Режим доступа: http://masters. donntu.edu.ua/2010/etf/baydak/library/article2. htm. — Загл. с экрана

6. Братчиков И. Л. Основы проектирования баз данных [Электронный ресурс]. — Режим доступа: http://www.apmath. spbu.ru/ru/education/final/question41. pdf. — Загл. с экрана

7. Зеневич А. М. Системы обработки многопользовательских баз данных: Курс лекций [Электронный ресурс]. — Режим доступа: http://www.bseu. by/ffbd/tohod/lekcii8₅. htm. — Загл. с экрана

8. Миндалев И. В. Информационные системы: Электронный учебно-методический комплекс [Электронный ресурс]. — Режим доступа: http://www.kgau.ru/istiki/is/index.html. — Загл. с экрана

9. Никитин М. Закончилась ли эпоха реляционных СУБД? [Электронный ресурс]. — Режим доступа: http://www.cnews.ru/reviews/free/marketBD/articles/articles2. shtml. — Загл. с экрана

10. Пономарева И. С. Системы управления базами данных [Электронный ресурс]. — Режим доступа: http://mathmod. aspu.ru/images/File/Ponomareva/TM10_About%20BD. pdf — C.2

11. Руководство администратора баз данных Informix [Электронный ресурс]. — Режим доступа: http://www.computerbooks.ru/книга/руководство%20администратора%20баз%20данных%20inrformix/4. — Загл. с экрана

12. Система управления базой данных [Электронный ресурс]. — Режим доступа: http://www.ssti.ru/kpi/informatika/Content/biblio/b1/inform_man/gl₁₅_3. htm. — Загл. с экрана

13. Снова о объектных СУБД [Электронный ресурс] // Открытые системы, № 04, 1999. — Режим доступа: http://www.publish.ru/os/1 072 579/text/179 797/_p3.html. — Загл. с экрана

14. Среда базы данных [Электронный ресурс]. — Режим доступа: http://do. bti. secna.ru/lib/book_it/sreda_bd.html. — Загл. с экрана

15. Федоров В. А. Постреляционная эра: реляционная или объектная? [Электронный ресурс]. — Режим доступа: http://www.ict.edu.ru/ft/3 850/PostrelationarEra. pdf. — Загл. с экрана

Приложения

Приложение А

Трехуровневая архитектура ANSI-SPARC

Приложение Б

Реализация независимости от данных в трехуровневой архитектуре ANSI-SPARC

Приложение В

Объединение возможностей СУБД и объектного программирования