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

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

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

5.Обработка в системе других задач. На производительность базы данных значительное влияние могут оказывать другие обрабатываемые

всистеме задачи (например, пакетные задания, операции, выполняемые

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

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

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

Ниже приводятся компоненты, определяющие время отклика, и функ­ циональные компоненты.

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

| К о м п о н е н т ы , о п р е д е л я ю щ и е в р е м я о т к л и к а Ф у н к ц и о н а л ь н ы е к о м п о н е н т ы

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

1. Информацию об использовании процессора, каналов и устройств. Эта информация позволяет определить, существуют ли компоненты, которые с точки зрения производительности создают «узкое место». Такую статис­ тику обычно предоставляет операционная система. Необходимо провести подробный анализ во время пиковых нагрузок.

2.Данные об использовании памяти. Хорошим индикатором достаточ­ ности реальной памяти является интенсивность смены страниц и свопин­ га (в случае применения виртуальной системы). Можно расширить буфер­ ный пул памяти и тем самым уменьшить число физических вводов-выво­ дов. Для определения степени использования памяти необходимо периоди­ чески фиксировать текущее состояние.

3.Статистику о транзакциях. Основной источник информации — лента журнала. Анализируя ленты журнала с помощью поставленных фирмой или написанных пользователем программ, можно получить следующие данные:

•интенсивность потока транзакций и ее распределение;

•значение времени отклика транзакций;

•приоритеты и классы транзакций;

•число вызовов базы данных на транзакцию;

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

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

шению эффективности базы данных может способствовать статистика по занимаемой указателями памяти, соотношению ее с памятью, зани­

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

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

6.Информацию об использовании модулей прикладных программ и проце-

дур СУБД. Поскольку основное время выполнения программы связано

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

7. Информацию об использовании базы данных пользователем. Пользова­ тель в основном и определяет, насколько эффективно применяется система

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

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

•статистику буферного пула;

•данные об использовании раздела;

• значения времени выполнения и ожидания ввода-вывода;

•время загрузки программы;

•выданные программой вызовы базы данных;

• частоту обращений к базе данных;

•число и частоту поступлений транзакций;

•время планирования транзакции;

•число операций ввода-вывода на один вызов базы данных;

10.2.5. Защита базы данных

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

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

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

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

Пользователи. Эта группа определяет требования к прикладным программам, на основе которых осуществляется проектирование базы данных и ее загрузка. Группа АБД совместно с пользователями определяет источник каждого элемента данных/ Отправитель данных выясняет их доступность и возможные типы доступа к ним. Чтобы обеспечить непро­ тиворечивость данных, за точность представления их отдельных элементов должен нести ответственность только один отдел. После того как отправи­ тель данных установит, санкционировано ли их использование, группа АБД может осуществить контроль доступа к ним. Доступ к базе данных выполняется как комбинация следующих действий":

•Частичный поиск. Санкционированный пользователь может видеть только определенную часть данных и не может ее изменить.

•Поиск записей всех типов. Санкционированный пользователь может видеть всю базу данных, но не может ее изменить.

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

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

•Удаление записей определенного типа. Пользователь может видеть

записи определенного типа, которые он также может и удалить.

•Удаление записей всех типов.

•Обновление записей определенного типа.

•Обновление записей всех типов.

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

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

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

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

Программисты. Большой процент разоблачений, нарушений и разру­ шений связан с ошибками программистов. Различают три категории программистов:

1)прикладные программисты;

2)системные программисты;

3)операторы.

Все они имеют свои функциональные обязанности:

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

2.Системный программист может изменять только системные программы. Он не может разрабатывать или выполнять прикладные программы.

3.Оператор может выполнять, но не разрабатывать прикладные програм­ мы. Он также не может изменять системные программы.

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

•фиксирует изменения в прикладных программах, которые могут осуществляться только прикладными программистами;

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

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

•запрашивает у оператора удаление или загрузку любой программы. Эксплуатационная группа. Часто случайное разрушение данных

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

Во избежание возникновения проблем, связанных с ошибками эксплуатации, необходимо:

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

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

•запретить оператору доступ к листингам исходных модулей приклад­

ных программ.

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

•оператор не должен разрабатывать прикладные программы;

•сотруднику группы АБД надлежит ежедневно проверять по консоль­ ным распечаткам все виды работ с базой данных;

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

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

•важные формы, такие, как чеки, должны выводиться за пределами поля зрения оператора.

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

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

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

2.Работает ли программа должным образом в граничной ситуации, такой, как обработка единственной транзакции? Что случится, если в первой или последней транзакции имеется ошибка? Полезна следующая аналогия:

большинство аварий самолетов происходит при взлете или посадке.

3.Фиксирует ли программа в журнале число записей, карт, транзакций и т. д.? Необоснованно большое или малое число записей, карт и транзак­ ций может означать ошибку.

4.Тестировал ли кто-нибудь программу, кроме программиста? Доволь­ но часто разработчик программы — не лучший претендент на нахождение

вней технических дефектов.

5.Проста ли программа для чтения, документирована ли она таким об­ разом, чтобы в ней можно было разобраться? (Отметим, что обычно программист и тот, кто в дальнейшем будет поддерживать программу,— разные лица. Хорошо документированная программа предоставляет средства для восстановления потерянных данных.)

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

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

Физическая защита. Еще недавно вычислительные средства считались престижными для компании. Теперь же наметилась обратная тенденция. Наличие многих установок ЭВМ понизило внимание к ним. Одна

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

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

3. Огнетушители должны быть хорошо заметны и размещаться в обще­ доступных местах.

4. Аварийный выключатель энергии должен быть хорошо заметен и легко доступен.

5.Нельзя закрывать запасной выход для персонала.

6.Время от времени необходимо проводить учебную пожарную тревогу.

7.Важные сведения должны храниться в несгораемых шкафах.

8.Системы противопожарной безопасности должны немедленно выявлять комнату с ЭВМ и дистанционно определять местонахождение каждого дефекта.

9.Обновленные копии исходных программ рекомендуется хранить вне комнаты с ЭВМ, предпочтительно в другом здании.

10.Так же вне комнаты с ЭВМ должны храниться данные, требуемые

для восстановления базы данных.

Подробную информацию о защитных мерах против наводнения, актов вандализма и саботажа мржно найти в списке литературы

вконце главы.

10.2.6.Соблюдение секретности при использовании базы данных

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

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

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

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

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

или просто знать о наличии такой записи?

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

При решении пробдемы секретности Информации приходится сталки­ ваться со следующими ситуациями (или их комбинацией):

•наличие ошибочной или вводящей в заблуждение информации;

•случайное раскрытие или изменение информации;

•намеренное тайное проникновение в информационную систему;

•потеря данных.

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

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

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

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

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