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

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

В гл. 9 мы рассмотрели несколько альтернатив создания физической структуры данных. Можно также разбить базу данных на несколько баз данных или частей. Следует ли интенсивно меняющуюся часть базы данных отделять от редко меняющейся? Следует ли также при перво­ начальной загрузке или реорганизации базы данных резервировать свободную память, и если да, то какого объема и как она должна распределяться? Выделение свободной памяти может снизить эксплуата­ ционные характеристики сегодня, но обеспечить их должный уровень через шесть месяцев. Каковы размеры блока (контрольного интервала для УЗАМ) и логической записи? С увеличением размера блока возрастает вероятность размещения в нем двух сегментов или записей. Но может быть, прикладной программе не требуется, чтобы эти два сегмента находились в одном блоке? В этом случае возрастет время канала на передачу блока без достижения каких-либо преимуществ.

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

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

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

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

1) хранить часто используемые данные на быстродействующих устрой­ ствах;

2)располагать данные таким образом, чтобы свести к минимуму число «длинных» перемещений головок диска;

3)выбирать адрес и поисковую схему, при которой минимизируется число обращений к диску (в идеальном случае до одного);

4)распараллеливать операции.

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

10Л.2. Конвертирование и интеграция

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

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

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

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

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

Но проводимые в этой области исследования все-таки дали опреде-

ленные результаты. Примером может служить система ЕХРКЕ55 (система выделения, обработки и реструктуризации: данных;) [1]. С помощью этой системы за один «проход» можно обратиться к нескольким.файлам, рес­ труктуризовать содержащиеся 'в них данные и создать несколько новых файлов;

В большинстве случаев для работы с базой данных может оказаться целесообразным доработать / существующие прикладные ; программы. Иногда есть смысл разработать полностью новые прикладные программы. Однако выполнение конвертирования и интеграции должно затрагивать лишь небольшую часть функций 'предприятия.. :Как и в любом проекте, здесь необходимо ввести этап* изучения проблемы. Для успешной реали­ зации проекта конвертирования нужны жесткие стандарты, которые одно­ временно должны быть просты в использовании и соответствовать требова­ ниям разработки.

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

10.2. ЭКСПЛУАТАЦИЯ

10.2.1. Дублирование и восстановление

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

ееразрушения рекомендуется принять следующие меры:

1.Выявить ошибку, которая привела к разрушению базы данных; выяснить, когда она возникла, какая часть базы данных разрушена,

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

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

3.Восстановить базу данных до состояния, свободного от ошибок,

ивыполнить действия, определенные в п. 2.

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

Для возвращения базы данных в состояние, свободное от ошибок,

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

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

Хранимая на ленте информация привязана к транзакциям и включает следующие основные компоненты:

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

2.Состояние базы данных до изменения. До выполнения изменения

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

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

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

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

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

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

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

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

Контрольные точки могут выполняться в разное время по следующим причинам:

1.Оператору приходится выдавать команду контрольной точки.

2.Система автоматически выполняет контрольную точку по истечении определенного временного интервала, который в течение дня может изме­ няться. При «пиковой» нагрузке он может уменьшаться и возрастать, когда нагрузка уменьшается.

3.Контрольная точка выполняется системой после определенного числа изменений базы данных.

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

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

Лента журнала позволяет при восстановлении возвратить базу дан­ ных в свободное от ошибок состояние. Процесс восстановления начинается с исследования ошибки. Выявление ошибки (что нарушено?) и определе­ ние ее источника (кто ее допустил?) может потребовать значительных временных затрат и вмешательства человека.

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

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

10.2.2. Реорганизация

Как правило, базу данных время от времени приходится приводить

впорядок. После первоначальной загрузки или перезагрузки базы данных

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

влогической последовательности, что может приводить к образованию

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

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

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

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

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

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

Основная причина реорганизации с точки зрения пользователя— «простои» или недоступность базы данных. Перед АБД в этом случае встает дилемма: либо регулярно проводить реорганизацию базы данных,

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

10.2.3, Реструктуризация

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

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

Определим различия между реструктуризационными изменениями трех типов: процедурными, на физическом уровне (во внутренней модели)

ина логическом уровне.

1.Процедурные изменения.

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

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

2. Изменения на физическом уровне.

Изменения конфигурации оборудования и размещения базы данных.

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

задаются на уровне описания физической базы данных; для систем, реализующих предложения КОДАСИЛ, на этом же уровне задаются ука­ затели 1ЧЕХТ, РКЮК и др.) Если на основе анализа статистики эксплуата­ ционных характеристик изменяется структура указателей, осуществляется их добавление или удаление, то об этом необходимо сообщить СУБД. Большинство СУБД предоставляет утилиты реконфигурации указателей. Изменяется описание физической базы данных, а затем текущая физичес­ кая база данных разгружается и перезагружается с набором новых ука­ зателей. Если особенности указателей в прикладной программе специально не используются, то такие изменения ее не затрагивают.

Изменения размеров блоков и буферных пулов, основных областей, областей переполнения. Большинство этих изменений можно рассматри­ вать как реорганизационные.

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

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

3. Изменения на логическом уровне.

Изменения на логическом уровне могут оказывать влияние на существую­ щие прикладные программы. Все эти изменения можно разбить на следую­ щие категории:

•добавление или удаление элемента данных в существующем сегменте или записи;

•объединение нескольких записей или сегментов либо разбиение записи или сегмента;

•изменение взаимосвязей между записями, наборами или сегментами,

например, владелец — член, исходный — порожденный;

• изменение роли элементов данных: ключевой или неключевой.

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

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

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

10.2.4. Учет и управление производительностью

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

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

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

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

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