Размещение и архитектура СУБД

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

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

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

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

 

Рис. 2. архитектура СУБД по технологии.

 

Функции СУБД

Выполняя свое назначение СУБД —предоставление пользователям БД средств доступа к данным – СУБД обладает приведенными ниже возможностями.

1 Позволяет определять базу данных, что обычно осуществляется с помощью языка определения данных (DDL — Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их струк­туры, а также средства задания ограничений для информации, хранимой в базе данных.

2 Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных, что обычно осуществляется с помощью языка управления данными (DML — Data Manipulation Language). Язык DML является общим инструментом управления данными и организации запросов (иногда его называют языком запросов - query language).

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

Существует две разновидности языков DML — процедурные (procedural) и непроцедурные (non-procedural) языки, — которые отличаются между собой способом извлечения данных.

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

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

Наиболее распространенным типом непроцедурного языка является язык структурированных запросов (Structured Query Language — SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых реляционных СУБД. (SQL произносится либо по буквам "S-Q-L", либо как мнемоническое имя "See-Quel".)

Для информационных систем с клиент-серверной архитектурой характерна максимальная разгрузка клиента от вычислительной работы, которая переносится на сервер, и существенное улучшение защищенности данных от несанкционированного доступа или ошибочных изменении. Для реализации клиент-серверной архитектуры применяются так называемые промышленные SQL-серверы, например, InterBase, Oracle, SQL Server, Informix, Sybase Adaptive Server, DB2.

Типичная СУБД, в том числе и реляционная СУБД, реализует ряд важных функций [10], рассматриваемых далее.

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

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

Пример. Ключевой особенностью архитектуры ANSI-SPARC [10] является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. Системный каталог (или словарь данных) является хранилищем информации, описывающей данные в базе данных (по сути, это «данные о данных, или метаданные). Обычно в системном каталоге хранятся следующие сведения:

· имена, типы и размеры элементов данных;

· имена связей;

· накладываемые на данные ограничения поддержки целостности;

· имена пользователей, которым предоставлено право
доступа к данным;

· внешняя, концептуальная и внутренняя схемы и отображения между ними;

· статистические данные, например частота транзакций
и счетчики обращений к объектам базы данных.

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

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

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

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

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

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

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

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

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

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

Однако в некоторых СУБД могут присутствовать как компиляторы, так и интерпретаторы, например, в dBASE и FoxPro, и всех современных СУБД реляционного типа.

Информационные системы с клиент-серверной архитектурой характеризуются наличием сервера – программным комплексом, устанавливаемым в компьютерной сети на специально выделенном компьютере—сервере, к которому имеют одновременный доступ компьютеры пользователей. При этом достигается максимальная разгрузка клиента от вычислительной работы, которая переносится на сервер. Если языком взаимодействия с СУБД является язык SQL, то речь идет о SQL-сервере, например, промышленные SQL-серверы: InterBase, Oracle, SQL Server, Informix, Sybase Adaptive Server, DB2. Использование SQL-сервера обеспечивает эффективное коллективное использование общей БД, также установленной на компьютере-сервере.

Контрольные вопросы

1. Каково назначение базы данных?
2. Какие возможности для развития АИС возникли в связи с появлением архитектуры клиент-сервер?
3. Какие функции СУБД независимы от архитектуры?

 

Тема 2. Модели БД

Ядром любой базы данных является модель данных. Модель данных — это совокупность структур данных и операций их обработки.

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

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

Иерархическая и сетевая модели хранения данных стали применяться в системах управления базами данных в начале 60-х годов прошлого столетия. В начале 70-х годов XX в. была предложена реляционная модель хранения данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

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

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: