Словарь данных.

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

Производительность.

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

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

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

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

Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

- управление данными во внешней памяти;

- управление буферами оперативной памяти (рабочими областями, в которые осуществляется подкачка данных из базы для повышения скорости работы);

- управление транзакциями.

1. Непосредственное управление данными во внешней памяти.

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

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

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

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

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

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

4. Архитектура СУБД.

Три уровня архитектуры.

Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

- Внешний уровень наиболее близок к пользователям, т.е. он связан со способами представления данных для отдельных пользователей.

- Концептуальный уровень-это «промежуточный» уровень между двумя первыми.

Внешний уровень (индивидуальные представления пользователей).

Концептуальный уровень (обобщенное представление пользователей).

Внутренний уровень (представление в

памяти).

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

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

У каждого пользователя есть свой язык общения.

- Для прикладного программиста это либо один из распространенных языков программирования, такой как C, COBOL или PL/1, либо специальный язык рассматриваемой системы. Такие оригинальные языки называют (неформально!) языками четвертого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками трех первых «поколений», а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

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

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