2.6.3. Физические модели данных
Физические модели описывают то, как данные хранятся в компьютере: структура записей, их упорядоченность, пути доступа и т.п. Физических моделей не так много как логических Самыми популярными из них являются:
обобщающая модель
модель памяти кадров
2.6.4. Концептуальное моделирование – это процесс определения архитектуры базы данных, не зависящей от таких подробностей ее реализации как целевая СУБД, набор прикладных программ, используемые языки программирования или другие аспекты физической реализации БД. Качество разработанной концептуальной схемы весьма важно для общего успеха создания системы, поэтому имеет смысл затратить усилия для подготовки максимально продуманного концептуального проекта системы.
2.7. Функции и службы субд
Типичная СУБД должна обеспечивать следующий набор функций и служб:
Хранение, извлечение и обновление данных независимо от физической организации БД
Наличие системного каталога, описывающего данные в базе (обеспечивает независимость программ от данных)
Механизм транзакций должен гарантировать выполнение либо всех операций обновления данной транзакции, либо ни одной из них (защита данных от сбоев при выполнении транзакций)
Корректное обновление базы данных при параллельном выполнении операций обновления многими пользователями (исключение конфликтов целостности БД).
Таблица 2.1. Пример возникновения проблемы «потерянного обновления».
Предоставлять средства восстановления БД в случае какого-либо ее повреждения или разрушения (возврат к последнему непротиворечимому состоянию)
Гарантия доступа к информации в базе только санкционированных пользователей (безопасность и конфиденциальность)
Способность к интеграции с коммуникационным программным обеспечением (интеграция с диспетчерами обмена данными, работа в локальной сети и т.п.)
Поддержка целостности данных (контроль ограничений или правил сохранения непротиворечивости данных в базе)
2.8. Компоненты субд
Процессор запросов. Преобразует запросы на языке DML в последовательность низкоуровневых команд для диспетчера базы данных
Диспетчер базы данных. Взаимодействует с запущенными пользовательскими программами и запросами. Диспетчер БД принимает запросы и проверяет внешние и концептуальные схемы для определения записей, которые необходимы для выполнения запроса. Затем диспетчер БД вызывает диспетчер файлов для выполнения запроса.
Диспетчер файлов. Манипулирует файлами, предназначенными для хранения данных, отвечает за распределение доступного дискового пространства. Создает и поддерживает список структур, определенных во внутренней схеме. Однако диспетчер файлов не управляет физическим вводом и выводом данных, а передает запросы соответствующим методам доступа ОС.
Препроцессор языка DML. Преобразует внедренные в прикладные программы операторы DML-языка в вызовы стандартных функций базового языка
Компилятор языка DDL. Преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация – в заголовках файлов с данными.
Диспетчер словаря. Управляет доступом к системному каталогу и обеспечивает работу с ним
Перечислим основные программные компоненты, входящие в состав диспетчера БД (рис.2.5)
Модуль авторизации. Проверяет наличие у данного пользователя полномочий для выполнения затребованной операции.
Процессор команд. Выполнение затребованной операции
Контроль целостности. В случае операций, изменяющих содержимое базы, выполняется проверка ограничений целостности данных
Оптимизация запросов. Определяет оптимальную стратегию выполнения запроса.
Диспетчер транзакций. Осуществляет требуемые операции в процессе выполнения транзакции
Планировщик. Отвечает за бесконфликтное выполнение параллельных операций с БД. Для этого он управляет относительным порядком выполнения операций в отдельных транзакциях.
Диспетчер восстановления. Гарантирует восстановление БД до последнего непротиворечивого состояния при возникновении сбоев
Диспетчер буферов. Отвечает за перенос данных между оперативной памятью и вторичным запоминающим устройством, например, жестким диском.
