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

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

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

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

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

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

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

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

Принятое в архитектуре ANSI-SPARC двухэтапное  отображение может сказываться  на эффективности работы, но при  этом оно обеспечивает более высокую  независимость от данных.

 

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

 

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

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

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

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

 

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

 

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

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

Реляционный подход в построении СУБД имеет ряд достоинств:

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

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

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

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

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

Различные СУБД работают под управлением  разных ОС и аппаратной части. Наиболее известные среди таких ОС – UNIX, VAX, Solaris, Windows. В зависимости от объема хранения данных, количества пользователей, осуществляющих одновременный доступ к данным, сложности задач – используются различные СУБД на различных платформах. Например, СУБД Oracle на Unix, инсталлированная на многопроцессорный сервер позволяет решать задачи по обеспечению данными сотни тысяч пользователей.

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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