|
6.2.6. Проверка модели с помощью концепций
последовательной нормализации
Созданный на предыдущем этапе предварительный набор
отношений логической модели данных должен обязательно быть
81
подвергнут анализу на корректность объединения атрибутов в каждом из
отношений. Проверка корректности состава каждого из отношений должна
проводиться посредством применения к ним процедуры последовательной
нормализации. Целью применения этой процедуры является получение
гарантий того, что каждое из отношений, полученных на основе
концептуальной модели, находится, по крайней мере, в НФБК.
Если в процессе анализа отношений модели будут найдены
отношения не отвечающие требованиям НФБК, то это будет означать, что
где-то на предыдущих этапах были допущены ошибки. Возможно, ошибки
появились при построении концептуальной модели, а возможно — в
процессе ее преобразования в логическую модель. Для обеспечения
корректности логической модели в такой ситуации придется вернуться на
ранние этапы проектирования и перестроить ошибочно созданные
фрагменты модели.
6.2.7. Проверка поддержки целостности данных
Следует обратить внимание на следующие вопросы:
возможность для атрибутов иметь пустые значения;
ограничения для доменов атрибутов;
категорная целостность;
ссылочная целостность;
бизнес-правила в данной предметной области.
Необходимо выполнить работу по проверке каждой составляющей
применительно к каждой сущности, к каждому атрибуту, к каждой связи
логической модели предметной области. В том случае, если и данная
проверка даст положительный результат, можно переходить к следующему
этапу проектирования базы данных — физическому проектированию.
7. Физическая организация данных
7.1. Страничная организация данных в СУБД
Для функционирования СУБД во внешней памяти базы данных
возникает необходимость хранить следующие разновидности объектов:
строки отношений — основная часть базы данных, большей частью
непосредственно видимая пользователям;
управляющие структуры — индексы, создаваемые по инициативе
пользователя (администратора) или верхнего уровня системы из
соображений повышения эффективности выполнения запросов и
обычно автоматически поддерживаемые нижним уровнем системы;
журнальную информацию, поддерживаемую для удовлетворения
потребности в надежном хранении данных;
служебную информацию, поддерживаемую для удовлетворения
внутренних потребностей нижнего уровня системы.
82
Поиск и предоставление данных пользователю осуществляются с
помощью нескольких программ доступа данных и включают в себя три
основных этапа (рис. 7.1).
Определяется
искомая
запись,
для
извлечения
которой
запрашивается диспетчер файлов.
Диспетчер файлов определяет страницу, на которой находится
искомая запись, и для извлечения этой страницы запрашивает
диспетчер дисков.
Диспетчер дисков определяет физическое положение искомой
страницы на диске и посылает соответствующий вопрос на ввод-
вывод данных.
Рис. 7.1. Схема доступа к базе данных
Основными единицами осуществления операций обмена являются
страницы данных, управляемые диспетчером дисков. Все данные хранятся
постранично. Таким образом, с точки зрения СУБД база данных выглядит
как набор записей, которые просматриваются с помощью диспетчера
файлов. С точки зрения диспетчера файлов база данных выглядит как
набор страниц, которые могут просматриваться с помощью диспетчера
дисков.
На одной странице хранятся однородные данные, например, только
данные или только индексы. Все страницы данных имеют одинаковую
структуру, представленную на рис. 7.2.
83
Заголовок страницы содержит информацию о физическом дисковом
адресе страницы, которая логически следует за данной страницей (рис. 7.3
— правый верхний угол).
Заголовки страниц и указатели на следующие страницы
обрабатываются только диспетчером дисков и скрыты от диспетчера
файлов. Для выполнения своих функций в распоряжении диспетчера
дисков имеется каталог (страница 0), содержащий информацию обо всех
имеющихся на данном диске наборах страниц вместе с указателями на
первые страницы этих наборов.
Рис. 7.2. Структура страницы данных
Рис. 7.3. Определение логической последовательности страниц
Слоты характеризуют размещение строк данных на странице.
Каждая запись обладает уникальным идентификатором, не
изменяемым во все время ее существования, он имеет определенную длину
и состоит из номера страницы, на которой данная запись находится, и
84
байта смещения слота от конца страницы, который в свою очередь
содержит байт смещения записи от начала страницы (рис. 7.4).
Рис. 7.4. Структура идентификационного номера записи
Do'stlaringiz bilan baham: |
