Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Страничная организация данных в СУБД




Физическая организация данных

Проверка поддержки целостности данных

Проверка модели с помощью концепций последовательной нормализации

Созданный на предыдущем этапе предварительный набор отношений логической модели данных должен обязательно быть подвергнут анализу на корректность объединения атрибутов в каждом из отношений. Проверка корректности состава каждого из отношений должна проводиться посредством применения к ним процедуры последовательной нормализации. Целью применения этой процедуры является получение гарантий того, что каждое из отношений, полученных на основе концептуальной модели, находится, по крайней мере, в НФБК.

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

Следует обратить внимание на следующие вопросы:

§ возможность для атрибутов иметь пустые значения;

§ ограничения для доменов атрибутов;

§ категорная целостность;

§ ссылочная целостность;

§ бизнес-правила в данной предметной области.

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

Для функционирования СУБД во внешней памяти базы данных возникает необходимость хранить следующие разновидности объектов:

§ строки отношений — основная часть базы данных, большей частью непосредственно видимая пользователям;

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

§ журнальную информацию, поддерживаемую для удовлетворения потребности в надежном хранении данных;

§ служебную информацию, поддерживаемую для удовлетворения внутренних потребностей нижнего уровня системы.

Поиск и предоставление данных пользователю осуществляются с помощью нескольких программ доступа данных и включают в себя три основных этапа (рис. 7.1).

§ Определяется искомая запись, для извлечения которой запрашивается диспетчер файлов.

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

§ Диспетчер дисков определяет физическое положение искомой страницы на диске и посылает соответствующий вопрос на ввод-вывод данных.

Рис. 7.1. Схема доступа к базе данных

 

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

На одной странице хранятся однородные данные, например, только данные или только индексы. Все страницы данных имеют одинаковую структуру, представленную на рис. 7.2.

Заголовок страницы содержит информацию о физическом дисковом адресе страницы, которая логически следует за данной страницей (рис. 7.3 — правый верхний угол).

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

Рис. 7.2. Структура страницы данных

 

Рис. 7.3. Определение логической последовательности страниц

 

Слоты характеризуют размещение строк данных на странице.

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

Рис. 7.4. Структура идентификационного номера записи

 




Поделиться с друзьями:


Дата добавления: 2014-01-20; Просмотров: 1667; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.