LINEBURG


<< Пред. стр.

страница 15
(всего 19)

ОГЛАВЛЕНИЕ

След. стр. >>

1. Тематический заголовок необязателен в таблице, материал которой нужен только по ходу чтения документа.
2. Тематический заголовок не ставится над продолжением и окончанием таблицы.
3. Тематический заголовок горизонтально центрируется. Заголовки граф в головке таблицы. При их оформлении учитыва­ется следующее:
1. Заголовок должен быть над каждой графой, в том числе и над боко-виком, так как упрощает восприятие таблицы, позволяет сде­лать более лаконичным текст боковика.
2. Если заголовок графы состоит из нескольких элементов, то они разделяются запятыми (кроме словесного и буквенного обозна­чений) и располагаются в следующем порядке:
а) словесное обозначение данных графы;
б) буквенное обозначение данных графы;
в) обозначение единицы измерения;
г) указание на ограничение (от, до, не более, не менее).
3. Заголовок графы, как правило, формулируется в именительном падеже единственном числе; во множественном числе — только в слу­чаях, когда среди показателей графы некоторые стоят во множествен­ном числе, или когда заголовки графы — существительное, которое в данном значении в единственном числе не употребляется, или когда в графе дается количественная характеристика группы объектов.
4. Заголовок графы пишется без сокращений отдельных слов, за исключением общепринятых или принятых в тексте данного доку­мента.
5. Заголовок графы может включать в себя обозначения единиц измерения (кг, руб), а для некоторых терминов — обозначения в виде специальных символов (градусы — °С, проценты - %, доллары США -$ и т.п.).
6. Заголовок графы начинается с прописной буквы в верхнем ярусе, а в нижних ярусах только в случаях, когда заголовки грамма­тически не подчиняются объединяющему заголовку верхнего яруса; при грамматической связи с заголовком верхнего яруса заголовки нижних ярусов пишутся со строчной буквы.
7. Если строки таблицы выходят за границы страницы, то в каж­дой части таблицы повторяется ее головка (шапка).
8. Таблицы с большим количеством граф допускается делить на части и помещать одну часть под другой на одной странице.
Нумерация и литерация граф. Нумерация или литерация граф применяется только в случае, когда нужны ссылки на них в тексте документа или при использовании данных таблицы при решении практических задач. Оформление этих элементов таблицы должно производиться с учетом следующих требований:
Г. Нумерация или литерация граф не используется в продолже­ниях таблиц вместо заголовков граф.
2. В статистических таблицах принято графы боковика (если их несколько) обозначать прописными русскими буквами, а остальные графы — арабскими цифрами.
Графа «Номер по порядку». Оформляется с учетом следующих требований:
1. Данная графа обязательна только при необходимости ссылок в тексте документа на строки таблицы.
2. Графа рекомендуется для лучшего разграничения рубрик раз­ных ступеней в боковике.
3. Заголовок графы оформляется в виде: «№ п/п».
4. Допускается вместо указанной графы проставлять соответст­вующий номер с последующей точкой непосредственно перед наи­менованием показателя в боковике.
Единицы измерения. Их представление должно удовлетворять сле­дующим требованиям:
1. Включать в таблицу отдельную графу «Единицы измерения» не допускается.
2. Если все данные таблицы выражены в одной и той же единице измерения, то она указывается после тематического заголовка таб­лицы, будучи отделена от него запятой.
3. Если данные в таблице выражены преимущественно в одной единице измерения, но есть графы с данными, представленными в других единицах измерения, то преобладающая единица указывается после тематического заголовка, а остальные — после заголовков со­ответствующих граф.
4. Если данные в таблице выражены в различных единицах из­мерения, то они указываются после заголовков соответствующих граф.
5. Единицу измерения, общую для всех данных строки, указыва­ют после заголовка строки в боковике таблицы.
Заголовки «Итого», «Всего». Оформляются с учетом следующих требований:
1. Как в боковике, так и в головке заголовок «Итого» относится к частным, промежуточным итогам, заголовок «Всего» — к суммиру­ющим частные итоги.
2. В боковике принято заголовки «Итого» и «Всего» выравни­вать по левому краю.
Заголовки боковика. Оформляются с учетом следующих требова­ний:
1. Заголовки боковика располагаются:
а) при одной ступени:
от края боковика, если большинство умещается в 1 строку;
с абзацного отступа, если они в 2—3 строки.
б) при нескольких ступенях:
заголовки 1-й ступени — согласно п. а);
заголовки последующих ступеней — с отступом от начала заго­ловков предшествующей ступени или при выделении заголовков шрифтом, номерами, литерами без отступов;
в) заголовок «В том числе» рекомендуется ставить так же, как заголовки, к которым он относится.
2. Заголовки первой ступени пишутся с прописной буквы, также с прописной буквы пишутся заголовки последующих ступеней, если они грамматически не связаны с заголовками старшей ступени; со строчной буквы пишутся заголовки, грамматически связанные с за­головками старшей ступени.
3. Заголовки боковика завершаются отточием (рядом точек чис­лом не менее трех), если до строки прографки в боковике остается место (отточие помогает не соскользнуть на соседнюю строку про­графки); отточие не является обязательным; при отсутствии его ни­каких знаков препинания в конце заголовка не ставят или ставят двоеточие, если далее следуют подчиненные заголовки нижней сту­пени; отточие недопустимо, если строка прографки выравнивается по верхней строке заголовка боковика.
4. Если в боковике подряд идут одинаковые заголовки, то в нижних может быть заменено кавычками каждое слово (при одно­строчных заголовках) или сначала поставлены слова «То же» (при заголовках в две и более строк), а затем уже кавычки.
Указание на отсутствие сведений или явления в прографке. Оформ­ляется следующим образом:
1. При отсутствии сведений в соответствующей ячейке про­ставляется либо многоточие (...), либо слова «Нет свед.».
2. При отсутствии явления в соответствующей ячейке простав­ляется тире.
Обозначение ничтожно малых чисел. Оформляется следующим образом:
1. Если число значительно меньше одной десятой, то проставля­ется «0,0».
2. Если число значительно меньше одной сотой, то проставляет­ся «0,00», и т.д.
Деление чисел на цифровые группы. При представлении многораз­рядных чисел рекомендуется делить числа пробелами (запятыми в англоязычных документах) на группы по три цифры слева направо для целой части и слева направо — для дробной части.
Расположение чисел в графах. Представление числовых значений в ячейках должно удовлетворять следующим требованиям:
1. Числовые значения, относящиеся к одному и тому же показа­телю в одной графе, выравниваются по десятичной запятой (точке в англоязычных документах).
2. Числовые значения, относящиеся к различным показателям в одной графе, центрируются.
3. Числовые значения, определяющие пределы, записываются через многоточие (...) или тире и выравниваются по разделителю.
4. При указании в таблицах последовательных интервалов чи­сел, охватывающих все числа ряда, перед числами пишут (ОТ...ДО...БКЛЮЧ.).
5. В интервалах, охватывающих не все числа ряда, между числа­ми необходимо ставить тире.
6. Округление числовых значений до первого, второго, третьего и т.д. десятичного знака для одного типа данных должно быть оди­наковым.
Расположение строк прографки по отношению к заголовку бокови­ка. Определяется следующим образом:
1. Если строки прографки состоят из одного ряда числовых зна­чений, то они выравниваются по нижней строке соответствующего заголовка боковика.
2. Если среди строк прографки есть элементы в две и более стро­ки, то все строки прографки выравниваются по верхней строке соот­ветствующего заголовка боковика.
3. Если боковик начинается с графы «Номер по порядку», то рекомендуется выравнивать строки прографки по верхней строке соответствующего заголовка боковика.
4. Текстовые строки прографки рекомендуется выравнивать по верхней строке соответствующего заголовка боковика.
Текст в прографке. Оформление текста в ячейках таблицы долж­но удовлетворять следующим требованиям:
1. Текст в ячейке прографки должен начинаться с прописной буквы (если не служит образцом написания со строчной буквы).
2. Точка в конце текста в ячейке прографки не ставится.
3. При повторении текста в нижестоящих ячейках прографки он заменяется по тем же правилам, что и повторяющиеся заголовки боковика.
Линейки в прографке. Они предназначены для разделения граф и оформляются следующим образом:
1. Линейки в прографке не обязательны и могут быть заменены на пробелы.
2. В сдвоенных, строенных таблицах каждая повторяемая часть отделяется от другой обычно двойными линейками.
Примечания к таблице. Оформляются следующим образом:
1. Если примечания необходимы к подавляющей части строк таблицы и их объем невелик, то они оформляются в виде отдельной графы.
2. Если примечания относятся только к части строк или они велики по объему, то они размещаются под таблицей.
3. Примечания связываются с соответствующими местами табли­цы ссылками (цифрами или звездочками в виде верхних индексов).
4. Если примечания относятся к таблице в целом или к ее частям в целом, то они оформляются как внутритекстовые.

18.3. Основные понятия и технология работы с
табличными процессорами

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

18.3.1. Структура рабочего окна

Рабочее окно современного табличного процессора состоит из следующих элементов:
1. Строка заголовка.
Строка заголовка содержит имя программы, имя текущего фай­ла (книги или блокнота) и кнопки управления окном, состав и на­значение которых определяется операционной средой, в которой работает табличный процессор.
2. Строка меню.
В строке меню расположены имена основных групп команд и инструментальных средств табличного процессора, каждой из кото­рых соответствует собственное выпадающее меню, детализирующее возможности управления электронными таблицами.
3. Пиктографические меню.
Пиктограммы, объединенные в инструментальные панели, пред­назначены для вызова наиболее часто используемых команд. Количе­ство и состав пиктографических меню определяются пользователем.
4. Строка ввода (редактирования).
Строка ввода (редактирования) предназначена для ввода и изме­нения данных в ячейках электронной таблицы. Она содержит имя рабочего листа и адрес активной ячейки, в которой расположен ука­затель ячеек в виде рамки, окружающей ячейку. Указатель ячеек можно перемещать по рабочему листу с помощью мыши или клавиш управления курсором.
5. Рабочий лист.
Рабочий лист отображает собственно электронную таблицу и разбит на ячейки, которые образуют прямоугольный массив и коор­динаты которых определяются путем задания их позиции по верти­кали (в столбцах) и по горизонтали (в строках). Столбцы обознача­ются буквами латинского алфавита (А, В, С ... Z, АА, АВ, АС ... AZ, ВА, ВВ ...), а строки — числами натурального ряда. Так, D14 обозна­чает ячейку, находящуюся на пересечении столбца D и строки 14, а CD99 — ячейку, находящуюся на пересечении столбца CD и строки 99. Имена столбцов всегда отображаются в верхней строке рабочего листа, а номера строк — на его левой границе.
6. Линейки прокрутки.
На экране, как в окне, всегда виден лишь фрагмент активного рабочего листа. Это окно можно передвигать по рабочему листу с помощью линеек прокрутки, которые расположены в правой (верти­кальная линейка прокрутки) и нижней части листа справа (горизон­тальная линейка прокрутки). Еще одна маленькая линейка, располо­женная слева в нижней части рабочего листа, предназначена для перехода от одного рабочего листа к другому. Каждый рабочий лист имеет корешок с именем. Выбрав и активизировав конкретный ко­решок, можно продолжить работу на соответствующем этому кореш­ку рабочем листе документа.
7. Делители окна.
Они расположены в концах линеек прокрутки и с их помощью можно разделить активный рабочий лист по горизонтали или по вертикали. Это позволяет одновременно увидеть на экране несколь­ко рабочих листов и обработать их по фрагментам.
8. Строка сообщений.
В строке сообщений отображается информация о текущем со­стоянии таблицы и программы и о результатах выполняемых опера­ций. При выборе какой-либо команды в строке сообщений появля­ются краткие сведения о ее назначении.

18.3.2. Ввод и редактирование данных

После запуска табличного процессора и появления рабочего окна обычно устанавливается режим ввода данных в ячейки таблицы (рабочего листа). Как уже указывалось, одна из ячеек является текущей или активной (она отображается указателем в виде утолщенной рам­ки или прямоугольника с иным цветом фона) и именно в нее будет вводиться информация с клавиатуры.
При необходимости редактирования данных в процессе ввода следует использовать клавиши Del и Backspace. Если же возникает необходимость изменения данных, уже имеющихся в ячейке, необ­ходимо перейти в режим редактирования. Это может быть осуществ­лено двумя способами: либо нажатием соответствующей функцио­нальной клавиши, либо установкой и активизацией указателя мыши на строке ввода.
Помимо редактирования данных на уровне ячейки в электрон­ной таблице реализуется редактирование на уровне объектов табли­цы. К объектам таблицы помимо уже упомянутых столбцов, строк и ячеек относятся диапазоны столбцов и строк, блоки ячеек, таблица в целом.
Диапазоном столбцов (строк) называется последовательность нескольких подряд идущих столбцов (строк) таблицы. Обычно диа­пазон обозначается именами (номерами) первого и последнего эле­ментов с двоеточием между ними (например, C:R для диапазона столбцов и 5:12 для диапазона строк).
Блок клеток представляет собой прямоугольный фрагмент таб­лицы, образованный пересечением нескольких подряд идущих столб­цов с несколькими подряд идущими строками. Обозначается блок клеток адресами ячеек, стоящих в верхнем левом и правом нижнем углах прямоугольного фрагмента, с двоеточием .между ними (напри­мер, G7:L14).
Для указанных объектов определены следующие операции ре­дактирования: удаление, очистка, вставка, копирование. Перед вы­полнением конкретной операции редактирования необходимо опре­делить объект, над которым выполняется действие. По умолчанию таким объектом является текущая ячейка. Остальные объекты долж­ны быть выбраны (выделены). Это обычно выполняется с помощью мыши или клавиатуры.

18.3.3. Форматирование элементов таблицы

Для правильного оформления таблицы в соответствии с опреде­ленными требованиями для отдельных элементов (объектов) табли­цы могут быть установлены различные параметры формата.
Формат ячейки (группы ячеек) представляет собой совокупность значений следующих параметров:
формат представления числовых значений (общий, числовой, денежный, финансовый, календарный, временной, процентный, дробный, экспоненциальный, текстовый, задаваемый пользовате­лем);
выравнивание значений внутри клетки (горизонтальное — по левому краю, по правому краю, по обоим краям, по центру; верти­кальное — по верхнему краю, по нижнему краю, по обоим краям, по центру; ориентация — горизонтальная, вертикальная с горизонталь­ным представлением символов в столбик, вертикальная с представ­лением символов с поворотом на 90° влево, вертикальная с пред­ставлением символов с поворотом на 90° вправо);
вид, начертание, размер, цвет шрифта;
вид и толщина линий, образующих обрамление (рамку) ячейки, рисунок и цвет затенения (фона) ячейки.
Формат столбца (столбцов) предполагает задание его ширины, а формат строки (строк) — задание ее высоты.
Все указанные параметры форматирования устанавливаются либо с помощью операций из соответствующего меню, либо с помо­щью соответствующих кнопок-пиктограмм с предшествующим вы­делением объекта форматирования.

18.3.4. Вычисления в таблицах

Каждая ячейка электронной таблицы характеризуется следую­щими параметрами:
адрес ячейки;
содержание ячейки;
значение ячейки;
формат ячейки.
Адрес и формат ячейки уже были рассмотрены выше.
В качестве содержания ячейки выступают числовые и текстовые константы, а также выражения (формулы).
В качестве значения ячейки рассматриваются выводимые на экран представления числовых и текстовых констант, а также ре­зультатов вычисления выражений (формул).
Под выражением понимается совокупность операндов, соеди-. ненных знаками операций. В качестве операндов используются чис­ловые и текстовые константы, адреса ячеек и встроенные функции. При этом числовые и текстовые константы используются непосред­ственно, вместо адресов ячеек используются значения соответствую­щих клеток таблицы, а вместо встроенных функций — возвращаемые ими значения.
Адреса ячеек в роли операндов и аргументов встроенных функций выступают в двух формах: относительной и абсолютной. Относительный адрес указывает на положение адресуемой ячейки относительно той ячейки, в содержании которой он используется и записывается как обычно (имя столбца и номер строки, напри­мер F7). Абсолютный адрес указывает на точное положение адре­суемой ячейки в таблице и записывается со знаком $ перед име­нем столбца и номером строки (например, $F$7). При редактиро­вании объектов электронной таблицы относительные адреса соот­ветствующим образом корректируются, а абсолютные адреса не изменяются.
Встроенные функции имеют тот же смысл, что и в языках про­граммирования высокого уровня, но в табличных процессорах их набор существенно больше. Существуют следующие группы встро­енных функций:
функции для работы с базами данных и списками;
функции для работы с датами и временными значениями;
функции для инженерных расчетов;
функции проверки свойств и значений;
логические функции;
функции для работы со ссылками и массивами;
математические функции;
функции для статистических расчетов;
текстовые функции;
финансовые функции.

Литература к главе 18

1. Денисов В.М. Lotus Тройка. — СПб., BHV-Санкт-Петербург, 1994. - 336 с.
2. Кении К. и др. Использование Microsoft Office : Специальное издание. - Киев, Диалектика, 1995. — 480 с.
3. Кох О. Excel 5.0: английская и русская версии. — СПб., BHV-Санкт-Петербург, 1995. — 272 с.
4. Нелсон С.Л. Путеводитель по Microsoft Excel 5 для Windows. — М., Издат. отдел «Русская редакция», 1994. - 240 с.
5. Николь П., Альбрехт Р. Электронные таблицы Excel 5.0: Прак­тическое пособие. — М., ЭКОМ, 1995. - 352 с.
6. Николь Н., Альбрехт Р. Электронные таблицы Excel 5.0 для квалифицированных пользователей: Практическое пособие. — М., ЭКОМ, 1995. - 304 с.462
7. Новиков Ф., Яценко A. Microsoft Office в целом. - СПб., BHV-Санкт-Петербург, 1995. - 336 с.
8. Харвей Г. Excel 5.0 для «чайников». - Киев, Диалектика, 1996. -288 с.
9. Шмидт Майнхард. Quattro Pro for Windows... для пользовате­ля. - Киев, Торгово-издательское бюро BHV, 1994. - 368с.










































Глава 19 СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

19.1. Определение и классификация современных
систем управления базами данных

Всю историю вычислительной техники можно представить как развитие двух основных направлений ее использования: для реше­ния сложных математических расчетов, выполнение которых невоз­можно вручную, и, собственно, интересующее нас - использование вычислительной техники в автоматизированных информационных системах. Под информационной системой следует понимать программ­но-аппаратный комплекс, функции которого состоят в надежном хранении информации, предоставлении пользователю удобного ин­терфейса и, что особенно важно, выполнении специфических опе­раций по преобразованию и поиску необходимой информации.
Важнейшие требования к информационным системам — хране­ние и обработка данных — не были реализованы возможностями си­стем управления файлами, существовавшими в 60-х гг.; отсутствова­ли, поддержание логически связанных файлов, средства восстановле­ния данных в системе после сбоев и параллельная работа нескольких пользователей; не был реализован язык манипулирования данными.
В начале 70-х гг. разработан новый вид программного обеспече­ния — системы управления базами данных (Data Base Management System — DBMS), позволивший структурировать, систематизировать и организовать данные для их компьютерного хранения и обработки. Системой управления базами данных (СУБД) называют программную систему, предназначенную для создания на ЭВМ общей базы данных для множества приложений; поддержания ее в актуальном состоя­нии и обеспечения эффективного доступа пользователей к содержа­щимся в ней данным в рамках предоставленных им полномочий. СУБД предназначена, таким образом, для централизованного управления базой данных как социальным ресурсом в интересах всей совокупности пользователей.
В настоящее время практически невозможно представить информационную поддержку современного учреждения без применения профессиональных СУБД. Однако существующий сегодня уровень возможностей программных продуктов данного направления был достигнут не сразу: эволюция СУБД прошла путь от систем, опиравшихся на иерархическую и сетевую модель данных, до систем так называемого третьего поколения, для которых характерны идеи объектно-ориентированного подхода.
СУБД первого поколения имели ряд существенных недостатков: отсутствие стандарта внешних интерфейсов и обеспечиваемости переносимости прикладных программ. Однако эти СУБД оказались весьма долговечны: разработанное на их основе программное обеспечение используется и сегодня и большие ЭВМ (mainframe) содержат огромные массивы актуальной информации.
Разработка Е. Коддом реляционной теории подтолкнула к со­зданию следующего класса СУБД. Особенностями второго поколе­ния являются применение реляционной модели данных и развитый ! язык запросов SQL. Простота и гибкость модели данных позволили , ей стать доминирующей и занять лидирующие позиции на соответ­ствующем секторе рынка.
Многие разработчики сегодня выделяют ряд негативных момен-j , тов в реляционной модели, среди которых невозможность представ­ления и манипулирования данными сложной структуры (тексты, пространственные данные). Это заставляет вести работы по совер­шенствованию систем второго поколения или создания новой моде­ли данных. Для СУБД третьего поколения характерны использова­ние предложений, касающихся управления объектами и правилами, управления распределенными данными, языков программирования ' четвертого поколения (4GL), технологии тиражирования данных и других достижений в области обработки данных. Сегодня СУБД это­го поколения применяются в деловой сфере достаточно активно не только как незаконченные технические решения, но и как готовые ; продукты, дающие возможности разработчикам активно использо­вать мощные средства управления данными.
Системы управления базами данных можно классифицировать, используя различные признаки: по используемому языку общения:
замкнутые — имеют собственные самостоятельные языки обще­ния пользователей с БД; они обеспечивают непосредственное обще­ние с системой в режиме диалога, позволяют работать без програм­мистов;
открытые — для общения с БД используется язык программиро­вания, «расширенный» операторами языка манипулирования данны-<„ ми (ЯМД); в этом случае необходимо присутствие квалифицирован­ного программиста;
по числу поддерживаемых СУБД уровней моделей данных:
одно-, двух-, трехуровневые системы. Теоретически обоснован выбор трехуровневой архитектуры данных; однако на практике СУБД для ПК часто объединяют концептуальный и внутренний уровни представления;
по выполняемым функциям:
операционные — иные виды обработки по получению информа­ции, не хранящейся в явном виде в БД;
информационные — позволяют организовать хранение данных, поиск и выдачу нужных данных из БД и поддерживать их целесооб­разность и актуальность;
по сфере применения:
универсальные — настраиваются на любую предметную область путем создания соответствующей БД и прикладных программ;
проблемно-ориентированные — ориентация на определенные процедуры обработки данных, присущих конкретной области при­менения;
по допустимым режимам работы:
пакетный;
телеобработка.

19.2. Основные функции систем управления
базами данных

1. Управление данными во внешней памяти.
Функция управления данными во внешней памяти включает в себя обеспечение необходимых структур внешней памяти как для непосредственного хранения данных, так и для служебных целей, например для ускоренного доступа к данным в некоторых случаях (обычно используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых сис­тем. Однако пользователи не должны знать, использует ли СУБД файловую структуру или нет. Существует множество способов орга­низации внешней памяти баз данных. Как и все решения, принима­емые при создании баз данных, конкретные методы организации внешней памяти необходимо выбирать вместе со всеми остальными решениями.
2. Управление буферами оперативной памяти.
СУБД обычно работают с базами данных значительных разме­ров; по крайней мере, этот размер превышает доступный объем опе­ративной памяти. Понятно, что если при обращении к любому эле­менту данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью внешней памяти. Единствен­ным способом реального увеличения этой скорости является буфе­ризация данных в оперативной памяти. И даже если операционная система производит общесистемную буферизацию, этого недостаточ­но для целей СУБД, которая располагает гораздо большей информа­цией о полезности буферизации той или иной части базы данных. В развитых СУБД поддерживается свой набор буферов оперативной памяти с собственной дисциплиной замены буферов. При управле­нии буферами необходимо разрабатывать и применять согласован­ные алгоритмы буферизации, журнализации и синхронизации. За­метим, что существует собственное направление СУБД, ориентиро­ванное на постоянное присутствие всей БД в оперативной памяти (ОП). Это направление основывается на предположении, что в пред­видимом будущем объем оперативной памяти может быть настолько велик, что позволит не беспокоиться о буферизации.
3. Управление транзакциями.
Транзакция — это последовательность операций над БД, рассма­триваемых СУБД как единое целое. Либо транзакция успешно вы­полняется и СУБД фиксирует изменения БД, произведенные ею, во внешней памяти, либо ни одно из этих изменений никак не отража­ется в состоянии БД. Понятие транзакции необходимо для поддер­жания логической целостности БД (например, необходимость объе­динения элементарных операций над файлами). Поддержание меха­низма транзакций — необходимое условие даже однопользователь­ских СУБД. Но понятие транзакции гораздо важнее в многопользо­вательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование по­нятия транзакции как единицы активности пользователя по отноше­нию к БД. При соответствующем механизме управления транзакци­ями пользователь может почувствовать себя единственным пользо­вателем СУБД.
4. Журнализация и восстановление БД после сбоев.
Одно из основных требований к СУБД — надежное хранение данных во внешней памяти. Под надежностью хранения понимает­ся: СУБД должна быть в состоянии восстановить последнее согласо­ванное состояние БД после аппаратного или программного сбоя. Поддержание надежного хранения данных в БД требует избыточно­сти хранения данных, причем та их часть, которая используется для восстановления должна храниться особо надежно. Наиболее распро­страненный метод поддержания такой избыточности — это ведение журнала изменений базы данных. Во всех случаях придерживаются «упреждающей» записи в журнал (так называемый протокол Write Ahead Log). Эта стратегия заключается в том, что запись об измене­нии любого объекта БД должна попасть во внешнюю память журна­ла раньше, чем она попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
5. Поддержание языков БД.
Для работы с БД используются специальные языки, в целом называемые языками БД. В ранних СУБД поддерживалось несколь­ко специализированных по своим функциям языков. В современных СУБД обычно поддерживается единый интегрированный язык, со­держащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с БД.

19.3. Типовая организация современной СУБД

Организация типичной СУБД и состав ее компонентов соответ­ствует набору функций. Логически в современной СУБД можно выделить внутреннюю часть — ядро СУБД (Data Base Engine), ком­пилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит.
Ядро СУБД отвечает за управление данными во внешней памя­ти, управление буферами оперативной памяти, управление транзак­циями и журнализацию. Соответственно, можно выделить и такие компоненты ядра (по крайней мере, логически, хотя во многих СУБД они существуют явно), как менеджер данных, менеджер буферов, менеджер транзакций, менеджер журнала.
Все функции взаимосвязаны, поэтому компоненты должны вза­имодействовать по продуманным и спланированным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным поль­зователю напрямую и используемым в программах, производимых компилятором SQL, и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «кли­ент-сервер» ядро является основным составляющим элементом сер­верной части системы.
Основная функция компилятора языка БД — компиляция опе­раторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является наличие непроцедурного языка, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не процедура, она лишь опи­сывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен сначала решить, каким образом вы­полнить оператор языка, прежде чем произвести программу. Резуль­татом компиляции является выполнимая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполня­емом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением под­системы поддержки времени выполнения, представляющей собой, по сути, интерпретатор этого внутреннего кода.
В отдельные утилиты обычно выделяют такие процедуры, кото­рые слишком накладно выполнять с использованием языка БД, на­пример загрузка БД, сбор статистики, глобальная проверка целост­ности. Утилиты программируются с использованием ядра СУБД, а иногда с проникновением внутрь ядра.

19.4. Языковые средства систем управления
базами данных

Функциональные возможности моделей данных становятся до­ступными пользователям СУБД благодаря ее языковым средствам. В данном случае речь идет о пользователях СУБД, к числу которых можно отнести: персонал администрирования данными, разработ­чиков прикладных программ на основе СУБД и конечных пользова­телей системы. Пользователи каждой их этих категорий могут иметь специально предназначенные для них интерфейсы на том или ином уровне архитектуры системы.
Реализация языковых средств интерфейсов может быть осуще­ствлена различными способами:
для высококвалифицированных пользователей языковые сред­ства представляются в их явной синтаксической форме;
в других случаях функции языков могут быть доступны косвен­ным образом, когда они реализуются в форме различного рода меню, диалоговых сценариев или заполняемых пользователем таблиц. По таким входным данным интерфейсные средства формируют адекват­ные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый код языка приложе­ния. Интерфейсы с неявным использованием языка широко исполь­зуются в СУБД для персональных ЭВМ. В этом случае используется (для реляционных СУБД), например, табличный язык Query-By-Example (QBE), разработанный М.Злуфом.
Языковые средства используются для выполнения двух основ­ных функций:
для описания представления базы данных на управляемых уров­нях архитектуры системы;
для инициирования выполнения операций манипулирования данными.
Первая из этих функций обеспечивается языком описания данных (ЯОД, Shema Definision Language), Его часто называют языком опре­деления данных. Описание данных средствами ЯОД называют схе­мой базы данных. Оно включает описание логической структуры данных и налагаемых на нее ограничений целостности в рамках тех правил, которые регламентированы моделью данных используемой СУБД. Помимо указанных функций, ЯОД некоторых СУБД обеспе­чивает возможности задания ограничения доступа к данным или пол­номочий пользователей.
Кроме того, многие системы не имеют своих самостоятельных языков для спецификации многоуровневых отображений данных. В таких случаях определение способов отображения также описывает­ся средствами ЯОД одного из смежных архитектурных уровней. Они при этом включаются в схему базы данных.
Стоит заметить, что при проектировании архитектуры системы часто не уделяют внимания обеспечению естественного разделения функций архитектурных уровней. В результате в значительной мере утрачивается возможность достижения той степени независимости данных, которая потенциально способна обеспечить «чисто» реали­зованная многоуровневая архитектура. Наиболее часто встречающи­йся дефекты архитектуры заключаются в том, что спецификации некоторых характеристик организации хранимых данных, законное место которых в схеме внутреннего представления, попадают в схему концептуального уровня.
ЯОД не всегда синтаксически оформляется в виде самостоятель­ного языка. Он может быть составной частью языка данных, сочета­ющего возможности определения данных и манипулирования ими.
Язык манипулирования данными (ЯМД, Shema Manipulation Language) позволяет запрашивать предусмотренные в системе опера­ции над данными из базы данных, т.е. содержит набор операторов манипулирования данными, позволяющий заносить данные, удалять, модифицировать или выбирать их. Аналогично ЯОД, ЯМД не обяза­тельно выступает в качестве синтаксически самостоятельного языка СУБД.
В настоящее время имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипули­рования данными в единых синтаксических рамках. Более того, в современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с ба­зой данных, начиная от'ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Наиболее популяр­ным и стандартным для реляционных СУБД является язык SQL (Structured Query Language), разработанный фирмой IBM и реализо­ванный в реляционной СУБД System R, а впоследствии и в коммер­ческой системе DB2. Другим примером языков этого класса могут служить: язык Quel системы Ingres, созданный Калифорнийским университетом, языковые средства большинства СУБД для персо­нальных ЭВМ, например язык dBase семейства СУБД фирмы Asthon-Tate и многочисленных совместимых с ним систем, язык СУБД: R:Base фирмы Microrim.
Некоторые СУБД располагают такими языками, которые не только реализуют функции определения и манипулирования данны­ми, но и обладают управляющими структурами и другими средства­ми, свойственными традиционным языкам программирования. Бла­годаря этому они могут использоваться как функционально полное средство для создания прикладных программ и для .формулировки запросов пользователей к БД. Такие языки называют автономными (язык запросов). В качестве примера приведем ранее упоминавшийся язык dBase, построенный в стиле структурного программирования.
Хотя автономные языки современных СУБД и обладают разви­тыми функциональными возможностями, существует много прило­жений, для реализации которых этих возможностей оказывается недостаточно. Наиболее распространены случаи, когда поддержива­емая модель данных оказывается слишком бедна средствами моде­лирования семантики ПО.
Как уже отмечалось, конечные пользователи информационной системы разделяются на две категории — прямые и косвенные. Те, кто относится к группе прямых пользователей, в отличие от косвен­ных, самостоятельно без посредников общается с ЭВМ. Они способ­ны разрабатывать новые приложения.
В настоящее время акцент разработки приложений все более пере­носится с профессиональных программистов на конечных пользовате­лей. Эта тенденция имеет очевидные достоинства: приложения разра­батываются быстрее; реализуются именно те алгоритмы, которые не­обходимы пользователю в момент разработки приложений; снижается себестоимость программной реализации системы и упрощается весь процесс ее разработки. Все это становится возможным, если в состав СУБД входят языки конечных пользователей, которые относят к классу автономных непроцедурных языков высокого уровня. Сегодня почти для всех промышленных систем такие языковые средства разработаны.
Языки конечных пользователей позволяют осуществлять выбор­ку данных, формировать отчеты, разрабатывать новые приложения и запрашивать выполнение уже разработанных. В некоторых языках такого типа обеспечены также возможности обновления БД и реали­зация достаточно сложных обработок данных.
Изучение простейших возможностей языков конечных пользо­вателей не требует больших затрат времени. Такой уровень подготов­ки (обычно 1—3 дня) позволит пользователю разрабатывать неслож­ные приложения.
Использование всего арсенала языков, необходимого для созда­ния сложных процедур обработки данных, требует профессиональ­ной подготовки.
Процедурный язык, при помощи которого осуществляется уп­равление базой данных, называют языком управления данными.

Язык QBE
Это язык, относящийся к классу высокоуровневых языков уп­равления базами данных и представляющий пользователю удобный и унифицированный интерфейс для осуществления операций по ведению базы данных.
Для пользователя решение основных задач производится через таблицу-шаблон, связанную с реальной БД.
Важно, что для выполнения действий над базой пользователю достаточно обладать элементарным запасом языковых средств, что­бы понимать и использовать возможности всего языка. Синтаксис языка прост, тем не менее охватывает широкий спектр сложных опе­раций. Это достигается за счет использования одинаковых операций для извлечения, манипулирования, определения и контроля данных. Операции языка «подражают» ручному манипулированию таблица­ми, сохраняя при этом все требования реляционной модели. Форми­рование операций должно следовать процессу рассуждений пользо­вателя, предоставляя тем самым свободу при их построении. Архи­тектура языка QBE направлена на удовлетворение сформулирован­ных требований.

Язык SQL
Сами по себе данные в компьютерной форме не представляют интерес для пользователя, если отсутствуют средства доступа к ним. Доступ осуществляется в виде запросов, которые формулируются на стандартном языке запросов. Сегодня для большинства СУБД таким языком является SQL.
Его появление и развитие как средства описания доступа к БД связано с созданием теории реляционных БД. Прообраз языка воз­ник в 1970 г. в лаборатории Санта-Тереза фирмы IBM в рамках научно-исследовательского проекта System/R. Сегодня - это фактичес­кий стандарт интерфейса с современными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (напри­мер, ADABAS), снабжают свои системы SQL-интерфейсом.
Язык SQL имеет официальный стандарт - ANSI/ISO. Большин­ство разработчиков придерживаются этого стандарта, однако часто расширяют его для реализации новых возможностей обработки дан­ных.
SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Поэтому это язык декларативный. Это означает, что с его помощью можно сформулировать, что необходимо получить, однако нельзя указать, как это следует сделать. В частности, в отличие от процедурных языков программирования (Си, Паскаль), в языке SQL отсутствуют такие операторы, как if/then/else.
Запрос в языке SQL состоит из одного или нескольких операто­ров, следующих один за другим и разделенных точкой с запятой. Наиболее важные выделены в стандарте ANSI/ISO SQL.
Для пользователя представляют интерес не сами операторы язы­ка, а их последовательность, оформленная как единое целое и име­ющая смысл с его точки зрения. Каждая такая последовательность операторов языка SQL реализует определенное действие над БД. Оно осуществляется за несколько шагов, на каждом из которых над таб­лицами выполняются определенные действия.
Повторяем, что SQL — это язык запросов, поэтому на нем невоз­можно написать достаточно сложные прикладные программы, кото­рые работают с базой данных. Для этой цели в современных СУБД используют язык четвертого поколения (FGL — Forth Generation Language), обладающий основными возможностями процедурных языков третьего поколения (Си, Паскаль), возможностью встроить текст программы оператора SQL, и средствами управления интер­фейсом пользователя (формами, меню, вводом пользователя и т.д.). Сегодня - FGL - это один из фактических стандартов разработки приложений, работающих с БД.
Первый стандарт этого языка появился в 1989 г. — SQL-89 — и поддерживался практически всеми коммерческими реляционными СУБД. Он имел весьма общий характер и допускал широкое толко­вание. Достоинствами SQL-89 можно считать стандартизацию син­таксиса и семантики операторов выборки и манипулирования дан­ными, а также фиксацию средств ограничения целостности базы данных. Однако в нем отсутствовали такие важные разделы, как ма­нипулирование схемой БД и динамический SQL.
Неполнота стандарта SQL-89 привела к появлению в 1992 г. сле­дующей версии языка SQL. SQL-92 охватывает практически все не­обходимые проблемы: манипулирование схемой базы данных, управ­ление транзакциями и сессиями, динамический SQL. В стандарте существуют три уровня: базовый, промежуточный и полный. Только в. последнее' время СУБД ведущих производителей обеспечивается совместимость с полным вариантом языка.
Появление новых требований пользователей к СУБД и обраба­тываемым данным привели к тому, что в настоящее время ведется работа по разработке SQL 3. Эта версия языка, видимо, будет иметь в своем составе механизм триггеров, определение произвольного типа данных, серьезные объекты расширения. Пока же крупнейшие производители СУБД затягивают разработку этого стандарта, совер­шенствуя и расширяя собственные версии языка SQL.

19.5. Основы информационной безопасности
систем управления базами данных

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

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

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

Протоколирование и аудит
Такая мера, как протоколирование и аудит, состоит в следую­щем:
обнаружение необычных и подозрительных действий пользова­телей и идентификация лиц, совершивших эти действия;
оценка возможных последствий состоявшегося нарушения;
оказание помощи;
организация пассивной защиты информации от нелегальных
действий пользователя.
Рекомендуется при выполнении организации протоколирования фиксировать факты передачи привилегий и подключения к той или иной базе данных.
Следующим вопросом в рассмотрении проблемы обеспечения информационной безопасности является анализ средств поддержания высокой готовности. Если речь идет о СУБД, то необходимо в архитектуре аппаратно-программного комплекса иметь средства, обеспечивающие нейтрализацию аппаратных отказов и восстановле­ние после ошибок обслуживающего персонала или прикладных программ.
Сохранение информации БД на дисках, помещаемых затем в бе­зопасное место, уже длительное время активно применяется для ин­формационных систем. При архивировании сохраняются простран­ства базы данных и многочисленная сопутствующая информация, необходимая для последующего восстановления. Надо помнить, что архив отражает состояние базы данных на время начала архивирова­ния. Резервные копирования логических журналов транзакций со­храняют файлы журналов; интерпретация последних позволяет вос­становить базу данных до состояния, более позднего, чем момент последнего архивирования. На основании полученной информации из архива и/или резервной копии может быть осуществлено восста­новление не только архивной информации (физическое восстанов­ление), но и более свежей версии базы данных (логическое восста­новление). Можно перечислить возможности службы восстановле­ния на примере СУБД Informix: архивирование в горячем режиме, т.е. без прерывания работы сервера; резервное копирование журна­лов транзакций; сохранение на удаленных устройствах; сохранение по заранее определенному расписанию без участия оператора; сжа­тие и шифрование информации.
Рассмотренные выше средства сохранения могут обеспечить восстановление с минимальными потерями пользовательской ин­формации, однако работа сервера базы данных будет на некоторое время прервана. Некоторые коммерческие приложения требуют под­держания постоянной работоспособности системы и, чтобы это тре­бование было удовлетворено, прибегают к кластерной организации сервера баз данных. Особенность этого подхода состоит в том, что создается некоторая архитектура, состоящая из нескольких компью­теров (узлов), выполняющих общее приложение. Обычно кластер содержит также несколько дисковых подсистем, используемых все­ми узлами, и избыточные связи между компонентами. Подобная аппаратная архитектура обеспечивает устойчивость к отказам ( оди­ночный отказ не способен вызвать остановки кластера в целом) и эффективное использование избыточных компонентов в процессе обычной работы.
Следующий механизм, обеспечивающий высокий уровень отка­зоустойчивости, - технология тиражирования данных. Тиражирова­ние данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распре­деленной системы. В конфигурации серверов базы данных выделяют один основной и ряд вторичных. В обычном режиме работы основ­ной сервер выполняет чтение и обновление данных, обеспечивает перенос зафиксированных изменений на вторичные серверы. В слу­чае отказа основного сервера его функции автоматически (вручную) переводятся на вторичный сервер в режим работы «чтение + запись». После восстановления функций основного сервера ему может быть присвоен статус вторичного, а вторичному делегированы все полно­мочия основного (при этом обеспечивается непрерывная доступность данных). Процедура тиражирования осуществляется либо в синхрон­ном, либо в асинхронном режиме. Благодаря первому осуществляет­ся гарантированность полной согласованности данных, т.е. на вто­ричном сервере будут зафиксированы все транзакции, выполненные на основном. Асинхронный режим улучшает рабочие характеристи­ки системы, не всегда обеспечивая полную согласованность (стоит заметить, что далеко не во всех задачах требуется синхронизация фиксации; достаточно поддерживать тождественность данных лишь в критические моменты времени).
Специалисты выделяют побочный положительный эффект ти­ражирования - более оптимальное распределение нагрузки на сер­веры: ресурсоемкие приложения выносятся на вторичный сервер, в то время как на основном выполняются приложения оперативной обработки транзакций.

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

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

19.6. Системы распределенной обработки данных

Потребность в данных коллективного пользования в последнее время все более возрастает. Это послужило причиной все усиливаю­щегося внимания к различным системам распределенной обработки данных.
Существует несколько понятий в этой области, которые необхо­димо определить более точно. Вначале выделим эти понятия:
распределенная обработка данных;
базы данных с сетевым доступом;
архитектура «клиент-сервер»;
распределенные базы данных.
Под распределенной обработкой данных понимают обработку приложений несколькими территориально распределенными маши­нами. При этом в приложениях, связанных с обработкой базы дан­ных, собственно управление базой данных может выполняться цен­трализованно.
Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как фактически имеют дело лишь с распределенным (сетевым) доступом к централизованной базе данных. Такие системы создаются на основе оборудования и программного обеспечения различных ло­кальных вычислительных сетей; большинство СУБД работает в сетях IBM PC Network (IBM Corp.), Novell Network (Novell Inc.).
Архитектура систем баз данных с сетевым доступом предполага­ет выделение одной из машин сети в качестве центральной. Эта машина обеспечивает функционирование той части сетевой версии СУБД, которая осуществляет управление данными в терминах базы данных и называется сервером файлов (File Server). Предполагается, что центральная машина обладает жестким диском достаточно боль­шой емкости, на котором хранится совместно используемая центра­лизованная база данных. Все другие машины сети выполняют функ­ции рабочих станций (Workstation), с помощью которых поддержива­ется доступ пользователей системы к централизованной базе дан­ных. В соответствии с пользовательскими запросами файлы базы данных передаются на рабочие станции, где в основном и произво­дится их обработка. Рабочая станция должна иметь достаточно ре­сурсов для обеспечения приемлемого уровня реактивности при об­работке пользовательских запросов.
Поскольку СУБД с сетевым доступом построены из расчета, что вся обработка данных ведется на рабочей станции, то рассматрива­емый вариант архитектуры системы баз данных характеризуется боль­шим сетевым трафиком, что отрицательно сказывается на произво­дительности и надежности системы.
Сетевые версии отличаются от локальных версий тем, что они рассчитаны на мультипользовательскую обстановку. Это предполага­ет обладание некоторыми специальными механизмами, позволяю­щими многим пользователям совместно обращаться к общим ресур­сам данных из централизованной базы данных. К числу таких меха­низмов относятся механизмы синхронизации транзакций, основанные на технике блокирования ресурсов и позволяющие производить об­новление данных при параллельной работе различных пользовате­лей, а также механизмы управления доступом, обеспечивающие кон­кретным пользователям операции над базой данных'в рамках тех полномочий, которые им предоставлены.
В сетевых версиях СУБД используются разнообразные протоко­лы блокирования ресурсов. Некоторые системы обеспечивают в опре­деленных ситуациях автоматическое блокирование ресурсов, осво­бождая разработчика от необходимости заботиться об этом. В других системах имеются только средства явного блокирования.
Протокол, принятый, например, в СУБД R:BASE for DOS, допу­скает возможность блокирования ресурсов данных вплоть до уровня поля. Благодаря этому два пользователя могут одновременно обнов­лять одну и ту же строку таблицы, но разные ее поля. Выбор разра­ботчиками такой мелкой единицы блокирования позволяет мини­мизировать интегральное время ожидания доступа к блокированно­му ресурсу при исполнении приложения. Представляют интерес «тонкие» средства блокирования ресурсов, при котором один поль­зователь блокирует строку для обновления, а другой — может тем не менее в это же время читать ее. СУБД позволяет пользователям иметь информацию о том, кто в данный момент блокирует запрашиваемые ими данные.
Сложные проблемы связаны в мультипользовательском режиме работы с базами данных с тупиковыми ситуациями (Deadlock). В тех­нологии баз данных предусматривается специальная техника профи­лактики возникновения тупиковых ситуаций и отката (Roll-Back) транзакций при их возникновении.
В некоторых СУБД обеспечивается возможность для приложе­ний направлять специальные сообщения о намерениях, связанных с блокированием ресурсов, в поддерживаемый для этих целей систе­мой «почтовый ящик», а также получать информацию из такого «поч­тового ящика», об установленных в данный момент блокировках. Подобная информация позволяет каждому пользователю соблюдать «джентльменскую линию поведения» для того, чтобы исключить возможность возникновения тупиковых ситуаций.
В последнее время происходит существенная трансформация подходов к использованию баз данных в обстановке локальных се­тей, направленная на повышение роли центральной машины сети, ранее используемой лишь для реализации сервера файлов. Это озна­чает, что сервер файлов центральной машины обеспечивает обработ­ку параллельных запросов на файлы, поступающие с рабочих стан­ций, используя необходимую дисциплину блокирования ресурсов; рабочие станции должны при этом копировать с центральной маши­ны нужные им файлы базы данных и выполнять их обработку.

19.6.1. Архитектура «клиент-сервер»

Новая модель взаимодействия компьютеров в сети получила название «клиент-сервер». Каждый из составляющих эту архитекту­ру элементов играет свою роль: сервер владеет и распоряжается ин­формационными ресурсами системы, клиент - имеет возможность воспользоваться ими.
Сервер базы данных представляет собой мультипользователь-скую версию СУБД, параллельно обрабатывающую запросы, по­ступившие со всех рабочих станций. В его задачу входит реализа­ция логики обработки транзакций с применением необходимой техники синхронизации - с поддержкой протоколов блокирова­ния ресурсов, с обеспечением предотвращения и (или) устране­ния тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Про­граммное обеспечение рабочей станции при такой архитектуре игра­ет роль только внешнего интерфейса (Front—end) централизованной системы управления данными. Это позволяет существенно умень­шить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить ра­бочие станции и при достаточно мощной центральной машине ис­пользовать для них более дешевое оборудование.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фак­тически стандартом.
Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», прикладные программы, реа­лизованные в ее рамках, будут иметь распределенный характер. Это означает, что часть функций приложений будет реализована в программе-клиенте, другая — в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:
функции ввода и отображения данных;
прикладные функции, характерные для предметной области;
фундаментальные функции хранения и управления ресурсами (базами данных);
служебные функции.
Исходя из этого деления любое приложение может состоять из следующих компонентов:
компонент представления (функции первой группы);
прикладной компонент (функции второй группы);
компонент доступа к информационным ресурсам (функции тре­тьей группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
какие виды программного обеспечения в логических компонен­тах;
какие механизмы программного обеспечения используются для реализации функций трех групп;
как логические компоненты распределяются компьютерами в сети;
какие механизмы используются для связи компонент между собой.
Исходя из этих допущений рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
1. FS-моделъ — базовая для локальных сетей персональных ком­пьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.
Основные требования:
выделяется файл-сервер для реализации услуг по обработке фай­лов других узлов сети; работает под управлением сетевых ОС;
играет роль компонент доступа к информационным ресурсам;
в остальных узлах функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент;
протокол обмена — набор низкоуровневых вызовов;
Технология: запрос направляется на файловый сервер, кото­рый передает СУБД, размещенной на компьютере-клиенте, требу­емый блок данных. Вся обработка осуществляется на компьюте­ре-клиенте.
Недостатки:
высокий сетевой трафик;
небольшое число операций манипулирования;
недостаточные требования к безопасности.
2. RDA-модель.

<< Пред. стр.

страница 15
(всего 19)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign