АРХИТЕКТУРА СИСТЕМ БАЗ ДАННЫХ Внутренний

АРХИТЕКТУРА СИСТЕМ БАЗ ДАННЫХ

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

• Внешний уровень - самый верхний уровень, где каждое представление имеет свое «видение» данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.

В представленной на рис. 9 трехуровневой архитектуре выделяются два вида отображений (проекций, представлений объекта в определенных условиях): • отображение концептуального уровня данных на внутренний; • отображение внешнего уровня данных на концептуальный.

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

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

• Отображение концептуальный-внешний определяет соответствие между внешним представлением и концептуальным представлением данных. • Структуры данных (таблицы, поля, записи) внешнего уровня связываются со структурами данных концептуального уровня. При изменении структур данных на концептуальном уровне необходимо будет изменить только отображение (т. е. процедуру установления соответствия) концептуальныйвнешний.

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

• Трехуровневая архитектура баз данных позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. • Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. • Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных.

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

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

• Рассмотрим функции СУБД немного подробнее. 1. Определения данных. СУБД должна допускать определения данных (внешние схемы, концептуальную схему, внутреннюю схему, а также все связанные отображения) в исходной форме и преобразовывать эти определения в форму соответствующих объектов. Иначе говоря, СУБД должна включать в себя компонент языкового процессора для различных языков определений данных. СУБД должна также "понимать" синтаксис языка определений данных. 2. Обработка данных. СУБД должна уметь обрабатывать запросы пользователя на выборку, изменение или удаление существующих данных в базе данных или на добавление новых данных в базу данных. Другими словами, СУБД должна включать в себя компонент процессора языка обработки данных. 3. Безопасность и целостность данных. СУБД должна контролировать пользовательские запросы и пресекать попытки нарушения правил безопасности и целостности, определенные администратором базы данных (АБД)

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

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

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

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

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