книги / Структурный подход к организации баз данных

обычно состоит из двух типов записей: долговременных, остающихся в базе данных длительное время, и кратковременных с коротким жизнен­ ным циклом. Записи базы данных о ЗАКАЗЧИКАХ, СТУДЕНТАХ и СЧЕТАХ обычно относятся к типу долговременных, в то время как записи о НАКЛАДНЫХ и ОРДЕРАХ — к типу кратковременных. Кратковременными, как правило, являются часто обновляемые записи. Если указатели размещаются в кратковременных записях, то при удалении записей указатели пропадают в отличие от указателей в долговременных записях (рис. 9.7).

Рис. 9.7. Указатели, размещаемые в записях с кратковременным хранением, сопровож­ дать значительно труднее, чем указатели долговременного типа записей

предпочтительнее оперативной. Обработка в автономном режиме вполне подходит для архивных и инвентаризационных данных. Для определенного ряда проблем сортировка в пакетном режиме — отнюдь не самое плохое решение.

9.2.3. СУБД, использующие инвертированные файлы

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

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

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

Перечислим основные вопросы, на которые необходимо ответить при проектировании физической модели для СУБД, основанной на ин­ вертированных файлах. При этом воспользуемся терминологий АОАВА5, рассмотренной в гл. 8.

1. Что можно сказать относительно дублирования данных и их избыточнос­ ти? Главный вопрос, на который требуется ответить, состоит в том, когда и как дублировать данные и когда и как избегать их избыточности. Технические средства АОАВА5, имеющие отношение к вопросу о дубли­ ровании данных, предусматривают использование:

•многозначных полей;

•периодических групп;

•нескольких типов записей в файле;

•нескольких файлов для хранения данных.

М н о г о з н а ч н ы е поля. Применяя многозначные поля, можно избежать дублирования. Пусть множество элементов данных «Детали заказчику» для ЗАКАЗЧИКА повторяется для одного элемента «Номер счета». При размещении пары ЗАКАЗЧИК-СЧЕТ в отдельной записи имеет место значительное дублирование данных:

Если для номера счета используемся многозначное поле, эти записи для одного и того же заказчика сживаются в одну запись:

П е р и о д и ч е с к и е г руппы. Если бы у нас имелся набор элементов данных «Счет за детали», то для счета мы могли бы использовать периодическую группу. Три записи:

оказались бы сжатыми в одну:

Номер заказчика Счет за детали Счет за детали Счет за детали

Определяя степень сокращения дублирования данных в первую очередь нужно рассматривать области, имеющие высокий приоритет обработки. Цель заключается в том, чтобы все поля, запрашиваемые такой областью обработки, размещались в одной записи. Следует избегать дублирования часто обновляемых полей. В качестве общего правила, однако,, рекомендуется не исключать дублирования коротких полей, к кото­ рым ч<асто происходит обращение, но которые редко обновляются. Фактически иногда даже полезно вводить этот тип дублирования данных для повышения производительности.

Н е с к о л ь к о т и п о в з а п и с е й в файле . Иногда полезно уста­ навливать структуру записи, используя один файл для нескольких типов записей. Пусть три записи до разбиения имели вид:

Возникает вопрос: из какого числа файлов должна состоять база данных? Как указывалось в предыдущих главах, концептуальная и логи­ ческая модели для СУБД с инвертированием файлов состоят из ряда отно­ шений или плоских файлов. Плоские файлы физической модели могут ^ыть идентичны плоским файлам логической модели. Большое число плос­ ких файлов влечет за собой уменьшение длины записи, но в то же время переключение файлов может сопровождаться значительными накладны­ ми расходами. Это также приводит к значительным затратам на про­ граммирование.

Аргументы в пользу увеличения числа файлов:

•наличие более коротких записей с меньшим числом полей сокращает число необходимых операций ввода-вывода и затрачиваемое время, так как блоки данных содержат большее число записей;

•увеличение числа файлов может привести к большей независимости данных и гибкости расширения структур данных.

Аргументы против увеличения числа файлов таковы:

•может возникнуть необходимость в поиске данных, находящихся в раз­ ных файлах. Это менее эффективно в отношении числа операций ввода-вывода, времени работы центрального процессора и времени разработки программ;

•может возникнуть необходимость в попарном связывании файлов для использования критериев поиска по нескольким файлам. Попар­ ное связывание требует выделения дополнительной памяти на диске

и дополнительных накладных расходов при выполнении подпрограмм* обновления.

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

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

может влиять на время, необходимое центральному процессору на обработку.

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

•Определяйте поля в той последовательности, в которой они запра­ шиваются областью основной обработки.

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

5.Какой объем свободной памяти необходимо отвести во время загрузки файла? Чему следует уделить внимание собственно при загрузке файла?

Свободная память, отводимая во время загрузки, влияет не только на

объем запрашиваемой памяти на магнитном диске, но и на процессорное время, поскольку с размерами этого поля связано число записей в блоке.

синвертированными списками может сама по себе представлять проблему.

Вэтой ситуации следует использовать многоуровневый индекс. В боль­ шинстве случаев и для конкретной СУБД возможности проектировщика при выборе организации индекса весьма ограничены, посколько организа­ цией и ведением инвертированного списка управляет СУБД.

Еще раз отметим, что для оценки и приведения во взаимное соот­ ветствие эксплуатационных характеристик базы данных проектировщик должен хорошо представлять себе следующее:

1)функции СУБД;

2)характеристики устройств прямого доступа;

3)прикладные программы.

9.3. ОЦЕНКА ФИЗИЧЕСКОЙ МОДЕЛИ

Оценка физической модели до реализации базы данных и разра­ ботки прикладных программ представляется необходимым условием проектирования. В §9.2 были рассмотрены некоторые возможности выбора при переходе от логической модели к физической. Поскольку существуют возможности выбора, возможно и существование альтернативных физических моделей, подлежащих оценке. Основные оцениваемые пара­ метры — память и время. В данном случае упор делается на «проверку за столом».

Часто облегчают сравнение альтернатив вычисления, проводимые

сцелью получения ответа на два вопроса:

1.Сколько существует экземпляров каждого типа сегмента или типа записи?

2.Киков средний размер записи базы данных и как велика база данных?

Поскольку одним из факторов, влияющих на время, является число операций физического ввода-вывода, необходимых для выполнения оператора САББ, проектировщик должен знать, какова вероятность того, что два сегмента находятся в различных блоках или управляющих интервалах. На основе этой вероятности и образцов операторов САББ прикладных программ проектировщику надлежит провести грубую оценку времени. Мы не рассматриваем базу данных, которая уже была когда-то загружена. Такая база данных в зависимости от ее изменчивости может состоять из нескольких фрагментированных областей памяти, некоторые удаленные из нее части записей могут по-прежнему занимать физическую память и т. д. Нас интересует вновь загруженная или реорганизованная база данных. Указанные выше основные сведения о базе данных также обеспечивают обычные дополнительные преимущества программирован­ ного подхода — согласованный ввод, согласованный вывод и хорошую документацию.

9.3.1. Оценка памяти

Оценка физической модели может проводиться только после подроб­ ного ознакомления с конкретной СУБД. Допустим, что предложено исполь­ зовать 1М5. Однако метод оценки памяти, так же как и метод оценки вре­ мени, может применяться и для большинства других СУБД. На этом этапе проектирования не обязательно точно знать объем всей необходимой памя­ ти с прямым доступом. Как правило, достаточно рассмотреть только хранение сегментов. Поэтому мы не будем подсчитывать объем памяти, требуемой для хранения индексов, которые необходимы методам доступа.

При анализе проекта базы данных с помощью описанного ниже метода «карандаша и бумаги» принимаются следующие допущения: 1) все базы данных таковы, какими они были в момент начальной загруз­ ки или сразу после реорганизации;

2)размеры сегментов малы по сравнению с размерами блоков;

3)частоты появления экземпляров порожденных сегментов относительно

исходного в базе данных есть независимые случайные величины;

4)сегменты имеют фиксированную длину;

5)если противное не оговорено особо, частотное распределение порож­ денных сегментов под исходным постоянно;

6)записи базы данных с явно различающимися экземплярами сегментов не обрабатываются; в модели они должны быть представлены отдельно;

7)оценки числа операций ввода-вывода помогают проектировщику преобразовывать обращения к сегментам в операции ввода-вывода.

модели (называемой в случае 1М5 физической базой данных).

Анализ проекта базы данных включает оценку памяти и изучение характеристик ввода-вывода (рис. 9.8). Зная характеристики ввода-вы- да, образцы вызовов и длину пути к устройству (т. е. число команд,

Рис. 9.8. Эксплуатационные характеристики языка ЭЬ/1. Язык ЭЬ/1 состоит из компонента управления базой данных и языка манипулирования данными 1М5. В 1М5 внешняя мо­ дель называется логической базой данных

которые необходимо выполнить для выполнения САЫД, можно получить количественные оценки эксплуатационных характеристик языка ОЬ/1 (язык данных/1 состоит из компонента управления базой данных и языка манипулирования данными 1М5).

Для оценки памяти необходимо прежде всего ответить на вопросы: 1. Какова иерархия? (В СУБД КОДАСИЛ необходимо знать, как по­ строены наборы.)

2. Какова длина каждого типа сегмента? Здесь имеется в виду не только длина собственно данных, но и длина области, занимаемой указателями. Допускается использование физических и логических указателей, напри­ мер физически порожденный первый, физически порожденный последний, физически подобный прямой, логически порожденный первый, логически порожденный последний и логически исходный. (В СУБД КОДАСИЛ возможные указатели ЫЕХТ (СЛЕДУЮЩИЙ), РЩОК (ПРЕДЫДУ­ ЩИЙ), ОАУЫЕК (ВЛАДЕЛЕЦ) и т. д.)

3. Какова ожидаемая относительная частота появления экземпляра каж­ дого типа сегмента относительно его исходного? Длина записи зависит не только от типов сегментов в базе данных, но и (в первую очередь) от числа экземпляров сегментов. По той же причине расстояние между двумя любыми экземплярами сегментов зависит от числа экземпляров сегментов между ними.

Зная эти факторы, проектировщик может определить

•средний размер физической записи базы данных в байтах;

•размер базы данных.