Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ЭУМКД_БД_1.doc
Скачиваний:
15
Добавлен:
23.09.2019
Размер:
4.19 Mб
Скачать

2.4.2. Многоуровневая структура баз данных

В наших дальнейших рассуждениях о БД и её уровнях мы будем отталкиваться от следующей схемы.

Рисунок 2.4.2.1 – Схема уровней БД

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

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

Т.о. «метод доступа» можно рассматривать как некий аналог «драйвера».

Существование более сложных методов доступа (например, добавляющих собственные вторичные индексы) никак не противоречит последующему обсуждению.

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

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

  • структура соответствующих хранимых записей;

  • хранимые поля упорядочения (если таковые есть);

  • хранимые поля, которые могут использоваться как аргументы выборки при прямом доступе (если таковые есть).

Объектом, передаваемым через интерфейс хранимых записей, является один экземпляр хранимой записи.

СУБД неизвестно:

  • ничего о физических записях (блоках);

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

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

  • как выполняется прямой доступ (т.е. посредством индекса, последовательного просмотра или хэш-адресации).

Вся эта информация используется методом доступа, а не непосредственно СУБД.

Предположим, что структура хранения включает хранимый файл PART, где каждый экземпляр хранимой записи состоит из номера детали (Р#), наименования детали (PNAME), цвета (COLOR) и веса (WEIGHT).

Часть определения структуры хранения в этом случае может иметь следующий вид:

STORED FILE PART {Р#, PNAME, COLOR, WEIGHT)

SEQUENCED ASCENDING P#

Indexed р#

Это определение говорит о следующем:

  • существует хранимый файл PART;

  • хранимая запись имеет конкретную структуру;

  • экземпляры хранимой записи упорядочены в возрастающем порядке значений Р# (механизм упорядочения здесь НЕ задаётся);

  • поле Р# индексировано, так что прямой доступ может выполняться по некоторому значению, соответствующему этому полю.

Сделаем ещё одно допущение: когда экземпляр новой хранимой записи впервые создаётся – метод доступа должен присвоить ему уникальный адрес хранимой записи.

Адрес позволяет различить экземпляры хранимых записей в базе данных.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]