Классификация СУБД

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

 

    

     4. 2. Классификация по модели данных

По модели данных классифицировать СУБД можно следующим образом:

- иерархические

- сетевые

- реляционные

- объектно-ориентированные

- объектно-реляционные

Рассмотрим эти модели более  подробно.

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

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

Отсюда следует необходимость  правильно упорядочивать записи, чтобы время их поиска было минимальным. Это трудно, так как не все отношения, существующие в реальном мире, можно выразить в иерархической базе данных. Отношения «один ко многим» являются естественными, но практически невозможно описать отношения «многие ко многим» или ситуации, когда запись имеет несколько предков. До тех пор пока в приложениях будут кодироваться сведения о физической структуре данных, любые изменения этой структуры будут грозить перекомпиляцией [12].

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

Следуя спецификации CODASYL, сетевая  модель поддерживает DDL (Data Definition Language – язык определения данных) и DML (Data Manipulation Language – язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие программист по-прежнему должен знать структуру базы данных.

В сетевой модели допускаются отношения «многие ко многим», а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

     4. 3. Классификация по степени распределенности

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

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

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

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

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

 

     4. 4. Классификация по способу доступа к базам данных

По способу доступа  к базам данных системы управления ими подразделяются на три типа:

- Файл-серверные

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

На данный момент файл-серверные СУБД считаются устаревшими. Они могут применяться для обучения работе с базами данных или для хранения информации в небольших информационных системах. Например, Microsoft Access, Paradox, dBase.

- Клиент-серверные

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

Клиент-серверные СУБД представляют больше возможностей для профессиональной работы с данными, поэтому они чаще всего используются в крупных предприятиях и организациях. Они больше всего подходят к крупным информационным системам с одним или несколькими серверами, обладающими большой производительностью. Даже в случае большого количества пользователей, работающих с ними, они не очень сильно загружают сеть. Например: Oracle, Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, PostgreSQL, MySQL, ЛИНТЕР.

Встраиваемые

Встраиваемая СУБД –  библиотека, которая позволяет унифицированным  образом хранить большие объемы данных на локальной машине. Доступ к данным может происходить через SQL, либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объемами данных (например, геоинформационные системы). Например, OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

Таким образом, для использования  в крупных организациях, в том  числе на промышленных предприятиях, больше подходят клиент-серверные СУБД [8].

 

     4. 5. Профессиональные, или промышленные и персональные (настольные) СУБД

Профессиональные, или  промышленные СУБД предназначены для ведения больших БД. Они в состоянии одновременно обеспечить доступ к ним со стороны большого числа пользователей. Наиболее известными промышленными СУБД являются Oracle, MS SQL Server, Sybase, Informix, DB2, InterBase, Progress.