Этапы доступа к бд

Рисунок 2.7 Схема доступа к БД

Опишем последовательность действий при доступе к БД:

1. Сначала в СУБД определяется искомая запись, а затем для ее извлечения запрашивается диспетчер файлов (ДФ).

2. Диспетчер файлов одним из рассмотренных способов адресации определяет страницу, на которой находится искомая запись, а затем для ее извлечения запрашивается диспетчер дисков (ДД).

Возврат хранимых записей возврат хранимых записей возврат хранимых страниц

3. Диспетчер дисков определяет физическое положение искомой страницы на диске и посылает запрос на ввод – вывод данных (страница уже может находиться в ОЗУ).

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

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

Страница внутри набора обладает уникальным идентификационным номером страницы.

Соответствие физических адресов на диске и номера станиц достигается с помощью ДД.

Преимущества страничной организации - все компоненты высокого уровня не зависят от конкретного диска.

Диск – это набор хранимых файлов. Файл – хранимый набор однотипных записей. В общем случае хранимый файл может храниться в памяти различными способами:

· на одном томе памяти (диске);

· на нескольких томах;

· физически упорядоченным в соответствии со значением некоторого хранимого поля;

· упорядоченным с помощью одного или нескольких индексов;

· упорядоченным с помощью цепочек указателей;

· к нему может быть обеспечен доступ методом хэш-адресации;

· хранимые записи могут быть объединены в блоки (несколько логических записей в одной физической записи).

Набор страниц может содержать несколько хранимых файлов. Каждый хранимый файл имеет имя или идентификационный номер (file ID), уникальный в данном наборе страниц. А каждая хранимая (логическая) запись обладает идентификационным номером (record ID).

ДФ выполняет следующие операции с файлами:

1. извлечь хранимую запись r из хранимого файла f;

2. заменить хранимую запись r в хранимом файле f;

3. удалить хранимую запись r из хранимого файла f;

4. добавить новую хранимую запись r в хранимый файл f;

5. создать новый хранимый файл f;

6. удалить хранимый файл f.

Компоненты модели данных

Сущность - это что-то такое, о чем нужно хранить информацию в базе данных.

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

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

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

Атрибуты сущностей в базах данных, определение атрибута, выбор набора атрибутов

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

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

Домены (domains) в реляционных моделях данных, определение домена, домены и типы данных, доменная целостность данных

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

Понятие "домен" не следует путать с понятием "тип данных". Тип данных - это физическое понятие (которое реализовано средствами конкретной СУБД), а домен - логическое понятие. Например, для пола обычно используется текстовое поле длиной 1 символ или 3 символа (на уровне типа данных), в то же время на уровне домена - это только два возможных значения.

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