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

Методы доступа внешней модели:

•доступ к отдельному файлу;

•доступ к нескольким несвязанным файлам;

•«многие ко многими при попарном связывании.

ЛИ Т Е Р А Т У Р А

1.С и г И с е КоЪег! М; Оа!а Вазе М ападетеп!—Ассезз М есЬатзтз апс! Эа1а 3!гис1иге

1пс., \Уе11ез1еу, МаззасЬизеДз 02181.

3. 0 11е ШПНат Т. ТЬе СоЛазу1 АрргоасЬ 1о Оа!а Вазе Мападешеп!. АУПеу-1п1егзс1епсе РиЪПсаЬоп, ЛоЬп УШеу апс! Зоп§, 1978. Русский перевод: О лле Т. В. Предложения КОДАСИЛ по управлению базами данных. М., Финансы и статистика, 1981.

4.1МЗ/УЗ Зуз!ет/АррПса!юп Без^п ОшЛе. 1ВМ СогрогаВоп, Ые>у Уогк.

5.АОАВАЗ ШгоЛисИоп Мапиа1, Мапиа1/Огс1ег ЫитЬег: АОА-410-000. ЗоЛдуаге АО о!

ЫогШ.Атепса, 1пс., Кез!оп 1п1егпаиопа1 Сеп1ег, У1гдт1а 22091’

6.В а с Ь т а п С. \У. ба{а 31гис!иге 01а&гат5. Па!а Вазе, Лоигпа! о! АСМ 5рес1а1 1п1егез1 Огоир ВгШ^Ь ба!а Ргосеззт^, уо1. 1, N0 2 (З и т тег 1969)

7.В а с Ь т а п С. XV. 1тр1етеп1а!юп ТесЬшциез 1ог Оа1а 31гис!иге Зе1з. Оа!а Вазе Мападетеп! 5уз!ет^: РгосееЛтдз о! 1Ье ЗНАКЕ \Уогктд СоЫегепсе оп Оа!а Вазе Мападетеп! Зуз1ет!з, Моп!геа1, СапаЛа, Ли1у 23—27, 1973, еЛйеЛ Ьу О. А, ЛагЛте,

Г л а в а 9

ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ (ФИЗИЧЕСКАЯ МОДЕЛЬ)

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

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

Прикладные программы, имеющие дело с базой данных, можно раз­ бить на группы по их значению для предметной области, а также по принципу применения. Для них можно проводить оценочное прогнозиро­ вание времени на основе метода «карандаша и бумаги». Желательно обнаружить все основные изъяны проекта физической базы данных и оце­ нить этот проект до начала его реализации. Оценка эксплуатационных характеристик на стадии проектирования должна быть одобрена админи­ страцией, поскольку после того, как база данных создана, перепроекти­ ровать ее чрезвычайно сложно, если. вообще возможно. Законченный проект подобен стреле, выпущенной из лука.

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

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

Необходимо, чтобы проектировщик физической модели базы данных хорошо представлял себе 1) функции СУБД;

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

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

Что касается функций СУБД, то проектировщик должен быть спе­ циалистом в этой области независимо от того, о каких системах идет речь: 1М5, ЮМ8, АЭАВАЗ, Ю З/И, ОВМ5-Ю/20 или ТОТАЬ. Он обязан знать, как СУБД выполняет свои специфические функции. Рассмотрим, например, функцию ОЕЬЕТЕ (УДАЛИТЬ), что означает «освободиться от чего-либо». Некоторые системы освобождаются от записи физически, т. е. память высвобождается и может повторно использоваться. В других системах записи лишь отмечаются как «удаленные» без фактического освобождения памяти на диске. Они удаляются только «логически», что может создавать различные проблемы, связанные с нехваткой па­ мяти на диске и увеличением времени извлечения искомой записи, так как наличие неиспользованной достаточно большой области между иско­ мыми записями увеличивает время, требуемое для извлечения следующей записи. Проектировщику физической модели необходимо представлять внутренние функции СУБД.

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

При разработке физической модели необходимо позаботиться и о физических параметрах базы данных: о распределении записей на диске, размере блока, размере буфера, характеристиках ввода-вывода и др. Если их не принимать во внимание, проект базы данных может «прова­ литься» из-за плохих эксплуатационных характеристик.

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

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

9.2. ПРОЕКТИРОВАНИЕ ФИЗИЧЕСКОЙ МОДЕЛИ

Предлагаемые здесь рекомендации «универсальны», т. е. они не за­ висят от используемой СУБД. Однако условимся иметь в виду следующие три СУБД:

1) систему управления информацией (1М5), поставляемую фирмой 1ВМ. 1М5 поддерживает иерархическую модель данных с некоторыми свойствами сетевой модели и возможностями инвертирования файлов;

2)систему управления базами данных-10/20 (ОВМ5-10/20), поставляе­ мую фирмой ОЕС для систем ОЕС5У5ТЕМ-Ю/20. ОВМ5-10/20 использу­ ет сетевую модель данных, соответствующую спецификациям КОДАСИЛ;

3)адаптируемую систему баз данных (АОАВАЗ), поставляемую (в США

и Канаде) фирмой ЗоПшаге АО оГ 1Чог1Н Атепса, которая основана на инвертированных файлах.

9.2.1. Иерархические СУБД

Рассмотрим рекомендации по созданию физических моделей для СУБД, основанной на иерархической модели данных, например для по­ ставляемой фирмой МК1 системы 5У5ТЕМ 2000, право использования которой принадлежит фирме ЩТЕБ, и системы МАКК IV, поставляемой фирмой 1пГогтаБс, 1пс. Главное внимание мы уделим 1М5, в частности воспользуемся ее терминологией. Более подробно 1М5 рассматривается в гл. 8.

Основные рекомендации:

1. Упрощайте по возможности иерархическую структуру. Упорядоченность иерархии определена сверху вниз и слева направо. Корневой сегмент — доминирующий тип сегмента. Если индексирование не применяется, доступ к любой записи базы данных предполагает доступ к корневому сегменту. Сегменты, расположенные в иерархии снизу и справа, удалены от корня. Поэтому следует добиваться простоты структуры, снижения числа уровней и уменьшения протяженности слева направо. Решающую роль играет не число типов сегментов, а число экземпляров сегментов. Сложные структуры обычно включают множество сегментов, что создает чрезмерное число вызовов языка ОБ/1 и обращений к сегментам, а также увеличивает время реорганизации. Необходим анализ целесообразности введения вторичного индексирования и логических взаимосвязей. Вто­ ричное индексирование позволяет осуществлять поиск по многим ключам что, однако, связано с обновлением вторичных наборов данных. Введение логических взаимосвязей позволяет получить некоторые свойства сетевой модели данных, что, однако, влечет за собой обновление логических указа­ телей и, по всей вероятности, обращение к нескольким физическим базам данных. Ключевой момент проектирования физической модели — рассмотрение альтернативных решений.

2. Не жертвуйте безопасностью и независимостью данных ради умень­ шения числа сегментов. Если уменьшить число сегментов, в которых хранятся данные, то количество данных на сегмент будет относительно большим. В результате обращения к сегменту прикладной программист может получить данные, которые не требуются прикладной программе. Уменьшение числа сегментов при том же количестве данных снижает их безопасность и независимость. Необходимо найти оптимальное число сегментов.

3. Располагайте сегменты, частота обращений к которым высока, ближе

квершине иерархии. Поскольку доступ к записям базы данных обычно начинается с корневого сегмента, доступ к хранимым в нем данным осу­

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

да при обращении к сегменту от корневого,— увеличение расстояния между корневым и данным сегментом.

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

Врекомендациях должны также содержаться ответы на вопросы:

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

6.Что можно сказать о типе сегмента, у которого длина префикса пре­ вышает длину данных? Префикс любого сегмента состоит из указателей как физических, так и логических. Если его длина превышает длину данных сегмента, желательно слить этот сегмент с исходным. В том случае, когда из соображений безопасности сегмент не может быть включен в исходный и не имеет ключа, можно попытаться сократить число его экземпляров до одного. Если сегмент, у которого длина пре­ фикса превышает длину данных, является корневым, нужно слить его с несколькими сегментами второго уровня и сформировать новый корневой сегмент.

7.Когда следует использовать сегменты переменной длины? Если весьма вероятно, что порожденный сегмент появится один раз или не появится вовсе, то он — первый кандидат на объединение с исходным. Исходный сегмент должен иметь переменную длину.

Если после начального включения размер сегмента увеличится, то он будет включен в базу данных в виде двух частей. Это может потребовать выполнения двух операций ввода-вывода для его поиска. Сегмент, размер которого может увеличиваться после начального включения, нежелательно использовать в качестве сегмента переменной длины.

8.Что делать при различной частоте изменения сегментов? Как разде­ лять сегменты, размеры и применение которых различны? Проблемы такого рода можно разрешить с помощью групп наборов данных базы данных. Часть базы данных может храниться как одна группа наборов, а часть — как другая группа наборов. Для групп наборов данных могут быть определены различные размеры блоков и свободных областей. Сегменты, обращение к которым происходит часто и одновременно, могут храниться в одной группе наборов данных. Сегменты, обращение к которым производится в оперативном режиме, могут быть отделены от сегментов, обращение к которым производится в пакетном режиме. Группы наборов данных позволяют также сократить длину пути к некото­ рым сегментам за счет других.

9.Когда следует разбивать физическую базу данных на несколько физических баз данных? В основе каждой физической базы данных 1М5 лежит иерархическая модель, т. е. на одну физическую базу данных приходится один корневой сегмент. Если физическая база данных стано­ вится слишком большой и это создает неудобство (в большинстве

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

Здесь также необходимо находить оптимальное решение. С ростом числа физических баз данных усложняются копирование и восстанов­ ление баз данных. Открытие и закрытие баз данных требуют опреде­ ленных затрат времени, а по мере увеличения числа физических баз данных растет и число операций открытия и закрытия.

10. Как обеспечить наличие различных путей доступа, помимо строго иерархических? Хотя 1М5 и обеспечивает прикладного программиста «иерархическими представлениями», она предлагает средство, называемое вторичным индексированием, которое позволяет осуществить непосредст­ венное обращение к сегменту, не проходя строго по иерархии от корне­ вого сегмента к подчиненным. Кроме того, 1М8 открывает некоторые возможности использования сетевой модели данных, называемые логи­ ческими взаимосвязями. И вторичное индексирование, и логические

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

10.1. В т о р и ч н о е и н д е к с и р о в а н и е . При вторичном индекси­ ровании к записям базы данных 1М8 можно обращаться по элементам данных, отличным от первичных ключей.

Элемент данных, служащий точкой входа, называется исходным сегментом. Вторичное индексирование дает возможность проектировщику базы данных инвертировать файл. Однако не следует применять вторич­ ное индексирование при последовательной обработке и частом измене­ нии исходного сегмента. Инвертирование записей базы данных практику­ ется в системе 8У8ТЕМ 2000, поставляемой фирмой МК1 и принадлежа­

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

9.2.2. Сетевые СУБД

Рассмотрим рекомендации для СУБД, использующих в качестве ба­ зовой структуры сетевую модель данных. Все изложенное ниже в первую очередь касается СУБД, основанных на спецификациях РГБД КОДАСИЛ, например ЭВМ8-10/20 для системы ОЕС8У8ТЕМ-10/20 фирмы 01^Иа1 Е^и^ртеп^ СогрогаБоп. Приводятся основные этапы разработки физической базы данных, которые могут выполняться итеративно.

Основные рекомендации:

1. Составляйте диаграмму структуры базы данных. Как отмечалось в предыдущих главах, аппарат наглядного представления сетевых мо­ делей данных был введен Ч. Бахманом. Прямоугольники обозначают типы записей, а стрелка между двумя прямоугольниками указывает на наличие взаимосвязи «владелец — член» и задает тип набора. Стрелка непосредственно представляет логическую взаимосвязь. Запись-член мо­ жет размещаться или не размещаться рядом с записью-владельцем. Для владельца и члена определяется ряд правил хранения и поиска, которые могут совпадать или не совпадать. Стрелка не подразумевает направления. Если конкретная реализация предоставляет возможность обращения записи-члена к записи-владельцу, то сначала может выпол­ няться поиск записи-члена. Типы наборов, поддерживаемые специфи­ кациями РГБД КОДАСИЛ, были подробно рассмотрены в гл. 4.

2. При проектировании физической модели учитывайте принятые воз­ можности СУБД в логической модели.

к отдельным записям? Должны ли они быть «вычисляемыми», т. е. необ­ ходимо ли обеспечить доступ к записям по значениям каких-либо особых ключей? Определите, к каким типам записей пути должны быть кратчайши­ ми. Проанализируйте, для каких типов записей выбрать способ раз­ мещения САЬС, а для каких — У1А ЗЕТ.

2.2. П р а в и л а в ы б о р а н а б о р а . Это относится к правильному вы­ бору владельца при включении записей в набор. Каковы наилучшие критерии определения владельца? Должна ли система определять и вы­ бирать запись, или в прикладной программе должна содержаться команда, определяющая, какую запись выбрать? Необходимо ли задание функции «автоматическая» или «ручная»?

2.3. У п о р я д о ч е н и е н а б о р о в . Здесь речь идет о включении записей в набор. Должны ли они рключаться в последовательности, упорядоченной по определенному ключу, в начало набора или в его конец?

2.4. О б р а б о т к а н а б о р о в . Если СУБД поддерживает дополнитель­ ные указатели, разработчику должно быть известно, как будет обраба­ тываться набор. Эта проблема менее важна в системе, автоматически поддерживающей указатели. Разработчик должен определить комбинацию указателей типов ЫЕХТ, РКЮК, 0\Ш ЕК и т. д.

В ы ч и с л е н и е о б ъ е мо в . Оцените число записей в наборе и число странйц в базе данных. Для способа размещения У1А ЗЕТ определите, какой тип кластеризации следует использовать, и вычислите размер страницы.

3.Окончательно определите содержимое записи. Решите, в каких записях какие элементы данных содержатся. Список правил структуризации дан­ ных, приводимый ниже, может быть полезен при окончательном опреде­ лении содержимого записей.

4.Следуйте правилам структуризации:

4.1. С т р у к т у р и з у й т е п е р е м е н н ы е д а н н ы е . Проанализируйте взаимосвязи «владелец—член» в логической модели. При большом числе экземпляров записей-членов для данной записи-владельца введение типа набора достаточно обосновано. Но если для данного владельца имеется только один экземпляр записи-члена, целесообразность введения типа

набора сомнительна. Запись-член можно включить в состав записи-вла­ дельца.

4.2. Н а й д и т е р а ц и о н а л ь н о е ре ше ние . Вполне возможно, что конкретная среда требует поиска некоторых данных в различных кон­ текстах, например поиск записи СЛУЖАЩИЙ на рис. 9.1 может проис-

Рис. 9Л. Рациональный выбор между поиском по нескольким ключам и временем запоминания записи

ходить либо по ОСНОВНОЙ СПЕЦИАЛЬНОСТИ, либо по РАЗМЕЩЕ­ НИЮ, либо по КОДУ ПРОФЕССИИ. Здесь проектировщик обеспечивает разнообразные возможности поиска за счет хранения данных о служа­

очень длинного набора не существует. Проектировщик должен сам установить ограничение такого рода. Считать ли очень длинным набор, содержащий 50, или набор, содержащий 500 членов? Ответ зависит и от того, сгруппированы члены или распределены. Очень длинный на­ бор может делиться на несколько групп. Также желательно разбиение множества ключей на диапазоны (рис. 9.2).

а)

Рис. 9.2. а) Две альтернативы разбиения очень длинных наборов с использованием диапа­ зонов; б) Очень длинный набор, диапазоны не используются

4.4. Р а с с м о т р и т е в о з м о ж н о с т ь в в е д е н и я м а с с и в о в у к а ­ з а т е л е й . Размещение указателей требует выделения памяти. Поло­ жим, что существуют запись-владелец и некоторое число связанных с ним переменных. Будем считать, что имеется 500 000 записей-владельцев и четыре различных набора. Объем подструктуры очень мал, т. е. из 500 000 записей только 5% записей-владельцев требуют введения под­

структуры. В подобных случаях следует рассмотреть возможность ис­ пользования массива указателей, являющегося членом набора (рис. 9.3). При положительном решении указатели помещаются в массив указа­ телей, а не в запись-владелец. В 500 000 экземплярах записей-владельцев указатели отсутствуют. Они будут участвовать только в 25 000 записях массива указателей. В большинстве поставляемых систем массивы ука­ зателей не поддерживаются.

Член

Рис. 9.3. Массив указателей формируется только при наличии членов из наборов 1—4. При отсутствии массива указателей потребность в памяти возрастает, поскольку в каждой из 500 000 записей-владельцев необходимо отвести поле для указателя

проблема выбора распределения данных. Для сетевых систем чем равно­ мернее распределение, тем лучше эксплуатационные характеристики ба­

КЛИЕНТОВ — равномерным. Желательно учитывать влияние группиро­ вания на распределение данных.

Рис. 9.4. Для получения лучших эксплуатационных характеристик равномерное распределение данных предпочтительнее асимметричного. Контурная стрелка обо­ значает группирование (кластеризацию):

а) счет группируется с клиентом; б) счет группируется'с типом счета

4.6. И с п о л ь з у й т е у к а з а т е л и ОАУМЕК и РЩОК.

а) Члены не группируются рядом с владельцами. Если члены не груп­ пируются рядом с владельцами, и в СУБД имеется дополнительная воз­ можность введения указателей ОШЫЕК (ВЛАДЕЛЕЦ), целесообразно использовать эти указатели. Даже если во время проектирования не были выявлены требования ни одного пользователя относительно обращений к записи-владельцу от записи-члена, скорее всего, через три — шесть месяцев после реализации базы данньЬс, некоторые пользователи захотят обращаться к владельцу непосредственно от члена.

б) Большое число членов в наборе. Если набор содержит несколько сотен членов, при группировании они могут не уместиться на одной странице. При их рассеивании на пяти или шести страницах памяти представляется желательным наличие указателей ОАУЫЕК (ВЛАДЕ­ ЛЕЦ). В качестве альтернативного решения проектировщик может уве­ личить размер страницы, чтобы на ней уместились все записи, либо выделить прикладной программе больший объем памяти под буфер, чтобы все пять или шесть страниц одновременно заносились в память.

в) Условия обработки. При различных условиях обработки жела­ тельно наличие указателей РКЮК (ПРЕДЫДУЩИЙ). В одном случае нас интересует самая последняя хранимая накладная, в другом случае нам требуется рассчитаться по старым накладным во избежание уплаты высоких процентов. Если накладные являются членами набора, то удобно использовать этот указатель.

г) Удаление записей. Указатель РЩОК также может быть полезен и в процессе удаления записей. При его отсутствии наилучший способ добраться до предыдущей записи-члена, скорее всего, заключается в по­ иске записи-владельца с помощью указателя ЫЕХТ (СЛЕДУЮЩИЙ).

размещения указателей. База данных

Рис. 9.5. Если число записей-членов значи­ тельно меньше числа записей-владельцев, то один и тот же ключ накладной используется для обращения и к накладной, и к возвратному ордеру.