Общее представление о базах данных и СУБД

Виды СУБД

Выделяют следующие виды СУБД:

• полнофункциональные СУБД;
• серверы БД;
• средства разработки программ работы с БД.

Полнофункциональные СУБД представляют собой традиционные СУБД. К ним относятся dBaseIV, Microsoft Access, Microsoft FoxPro и др.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД обеспечивают обработку запросов клиентских программ обычно с помощью операторов SQL. Примерами серверов БД являются: Microsoft SQL Server, InterBase и др.

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

Средства разработки программ работы с БД могут использоваться для создания следующих программ:

• клиентских программ;
• серверов БД и их отдельных компонентов;
• пользовательских приложений.

 

 

 По характеру использования СУБД делят на: 

• многопользовательские (промышленные)
• локальные (персональные).

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

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

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

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

Модели организации данных

По используемой модели данных СУБД разделяют на:

• Иерархические
• Сетевые
• Реляционные
• Объектно-ориентированные
• Объектно-реляционные

Некоторые СУБД могут одновременно поддерживать несколько моделей данных.

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

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

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

 

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

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

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

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

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

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

Системы на основе сетевой модели не получили широкого распространения на практике.

 

Реляционные СУБД – эта модель данных предложена сотрудником фирмы IВМ Эдгаром Коддом и основывается на понятии отношения (relation).

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение.

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

Таким образом, любая СУБД должна обеспечивать следующее:

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

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

 

 

 

 

 

 

 

 

Используемая литература:

1. Голицына, О.Л. Базы данных: учеб. пособие / О.Л. Голицына, Н.В. Максимов. - М.: Инфра-М, 2009.
2. Илюшечкин В.М., Основы использования и проектирования баз данных: учеб. пособие: Высшее образование, 2010.
3. Пирогов В.Ю., Информационные системы и базы данных: организация и проектирование: БХВ-Петербург, 2009.
4. http://www.kgau.ru/istiki/umk/ituman/textbox/bdrelatl.htm
5. http://intuit4.intuit.ru/studies/courses/508/364/print_lecture/4766
6. http://www.websoft.ru/db/wb/C9C5AD9B644BD153C3256F31003896B8/doc.html