Введение в системы БД (542480), страница 153
Текст из файла (страница 153)
Обратите внимание на то, что формальные определения даются с помощью матрицы совместимости типов блокировок (см. рис. 15.11). В этой главе были рассмотрены три проблемы параллельности, а именно: проблемы потери результатов обновления, зависимости от незафиксированных результатов и несоазасованной обработки данных. ° Потеря резулыпатов обновления.
Согласно стандарту языка БОБ требуется, чтобы при любых обстоятельствах проблема потери результатов обновления никогда не возникала. ° Зависимость от незафиксированных результатов. Это всего лишь иное название проблемы некорректного чтения. ° Несолласованная обработка данных. Этим термином обозначаются как проблема неповторяемости чтения, так и проблема чтения фантомов. 598 Часть 1У. Управление транзакг4илми Рис. 15.14.
Граф ожидания для унр. 15.4 15.10.Приведенное ниже краткое описание взято из [20.!51. Прежде всего в системе должны выполняться следующие условия. !. Для каждого объекта данных необходимо поддерживать стек зафиксированных версий !каждый элемент стека дает значение объекта и идентификатор транзакции, ко~прая создала это значение, т.е.
каждый элемент стека содержит указатель на соответствующий элемент журнала регистрации). Стек организован в обратном хронологическом порядке, при котором последний элемент находится сверху. 2. Необходимо поддерживать список идентификаторов транзакций для всех зафиксированных транзакций (список фиксации). В момент начала выполнения транзакции система предоставляет ей закрытую копию списка фиксации.
Операции чтения объекта направляются к последней версии объекта, полученной с помощью транзакции из этого закрытого списка. А операции обновления выполняются с фактическим текущим состоянием объекта данных !вот почему все еще необходимо выполнять проверку конфликта "обновление/обновление"). После фиксации транзакции система обновляет список фиксации и стеки версий объектов данных.
Глава 15. Параллельность 599 Часть У Дополнительные аспекты В части 11 этой книги было сказано, что реляционная модель является основой современной технологии баз данных, и это действительно так. Но это только основа, и, помимо описанной в части 11 реляционной модели, в технологии баз данных есть много других компонентов. Как студентам, так и профессионалам необходимо освоить множество дополнительных концепций и технологий, чтобы полностью овладеть этой областью знаний (последнее вполне очевидно из обсуждений в частях !11 и !Ч данной книги).
Теперь нам предстоит сосредоточить внимание на ряде важных тем, которые будут рассматриваться в такой последовательности. ° Защита данных (глава 16) ° Оптимизация (глава 17) ° Отсутствующая информация (глава 18) ° Наследование типов (глава 19) ° Распределенные базы данных (глава 20) ° Поддержка принятия решений (глава 21) ° Хронологические базы данных (глава 22) ° Логические системы управления базами данных (глава 23) Выбранная последовательность глав носит несколько произвольный характер, однако при их написании предполагалось, что эти главы (может быть, не все) будут изучаться именно в таком порядке.
Глава 16 Защита данных 16.1. Введение Вопросы защиты данных часто рассматриваются вместе с вопросами поддержки целостности данных (по крайней мере, в неформальном контексте), хотя на самом деле это совершенно разные понятия. Термин защита (зесцг(зу) относится к защищенности данных от несанкционированного доступа, изменения или умышленного разрушения, а целостность — к точности или достоверности данных. Эти термины можно определить и несколько иначе. ° Под защитой данных подразумевается предотвращение доступа к ним со стороны несанкционированных пользователей.
° Под поддержанием целостности данных подразумевается предотвращение их разрушения при доступе со стороны санкционированных пользователей. Иначе говоря, зашита данных означает получение гарантий, что пользователям разрешено выполнять те действия, которые они пытаются выполнить, а поддержание целостности означает получение гарантий, что действия, которые пользователи пытаются выполнить, будут корректны. Между этими понятиями есть, конечно, некоторое сходство, поскольку как при обеспечении защиты данных, так и при обеспечении поддержки их целостности система вынуждена проверять, не нарушаются ли при выполняемых пользователем действиях некоторые установленные ограничения. Эти ограничения формулируются (обычно алминистратором базы данных) на некотором подходящем языке и сохраняются в системном каталоге.
Причем в обоих случаях СУБД должна каким-то образом отслеживать все выполняемые пользователем действия и проверять их соответствие установленным ограничениям. В данной главе речь пойдет о защите данных, а вопросы целостности уже рассматривалась в главах 8 и др. Замечание. Основная причина, по которой эти две темы обсуждаются раздельно, состоит в том, что целостность данных является фундаментальным понятием, тогда как защита данных — понятием вторичным.
Общие соображения Срели многочисленных аспектов проблемы защиты данных необходимо выделить следующие. ° Правовые, общественные и этические аспекты (например, имеет лн некоторое лицо юридическое право запрашивать, скажем, информацию о выделенном клиенту кредите). 602 Часть К Дополнительные аспекты ° Физические условия (например, запирается ли помещение с компьютерами или терминалами либо же оно охраняется другим способом). ° Организационные вопросы (например, каким образом на предприятии, являющемся владельцем системы, принимается решение о том, кому разрешено иметь доступ к тем или иным данным). ° Вопросы управления (например, как в случае организации зашиты системы от несанкционированного доступа по схеме паролей обеспечивается секретность используемых паролей и как часто они меняются).
° Аппаратные средства защиты (например, имеет ли используемое вычислительное оборудование встроенные функции зашиты, подобные ключам защиты хранимой информации или привилегированному режиму управления). ° Возможности операционной системы (напрнмер, стирает ли используемая операционная система содержимое оперативной памяти и дисковых файлов после прекращения работы с ними).
° Аспекты, имеющие отношение непосредственно к самой СУБД (например, поддерживает ли используемая СУБД концепцию владельца данных). По очевидным причинам обсуждение этой обширной темы в данной главе будет ограничено, в основном, вопросами, относящимися к последнему пункту приведенного выше списка. В современных СУБД обычно поддерживается один из двух (иногда оба) широко распространенных подходов к организации зашиты данных, а именно — иэбираглельвый (йзсгейопагу) или.мандатный (шапйаюгу) подход.
В обоих случаях единица данных или "объект данных", для которых организуется система защиты, может выбираться нз широкого диапазона от всей базы данных до конкретных компонентов отдельных кортежей. Различия между двумя указанными подходами состоят в следующем. ° В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями или полномочиями) к разным объектам.
Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю В1 может быть разрешен доступ к объекту а, но запрещен доступ к объекту В, тогда как пользователю 02 может быть разрешен доступ к объекту В, но запрещен доступ к объекту а.) Поэтому избирательные схемы характеризуются значительной гибкостью. ° В случае мандатного контроля, наоборот, каждому объекту данных назначается некоторый классификационный уровень, а каждому пользователю присваивается некоторый уровень допуска. В результате право доступа к объекту данных получают только те пользователи, которые имеют соответствующий уровень допуска.
Мандатные схемы обычно имеют иерархическую структуру и поэтому являются более жесткими. (Если пользователь В1 имеет доступ к объекту л, но не имеет доступа к объекту В, то в схеме зашиты объект В должен будет располагаться на более высоком уровне, чем объект й, а значит, не может существовать никакого пользователя В2, который будет иметь доступ к объекту В, но не будет иметь доступа к объекту й.) б03 Глава 1б. Защита данньп Избирательные схемы подробно обсужлаются ниже, в разделе 16.2, а мандатные схемы — разделе 16.3. Независимо от того, какая схема используется (избирательная или мандатная), все решения относительно предоставления пользователям прав на выполнение тех или иных операций с теми или иными объектами должны приниматься исключительно управленческим персоналом.
Поэтому все эти вопросы выходят за пределы компетенции самой СУБД, и все, что она способна сделать в данной ситуации, — привести в действие решения, которые будут приняты на другом уровне. Исходя из этих соображений, можно отметить следующее. 1. Принятые организационные решения должны быть доведены до сведения системы (т.е. представлены как выражения некоторого подходящего случаю языка описания требований) и быть ей постоянно доступны (посредством их сохранения в системном каталоге). 2. Очевидно, что в системе должны существовать определенные средства проверки поступающих запросов на получение доступа по отношению к установленным правилам зашиты.
(Здесь под понятием "запрос на получение лоступа" подразумевается конкретная комбинация запрашиваемой операции, запрашиваемого объекта и запраиеивающего пользователя.) Обычно такая проверка выполняется подсистемой зашиты СУБД, которая иногда также называется подсистемой авторизации. 3. Для принятия решения о том, какие именно установленные ограничения защиты применимы к данному запросу на получение доступа, система должна быть способна установить исто~пик этого запроса, т.е. суметь опознать запрашивающего пользователя.
Поэтому при подключении к системе от пользователя обычно требуется ввести не только свой идентификатор (чтобы указать, кто он такой), но и пароль (чтобы подтвердить, что он именно тот, за кого себя выдает). Предполагается, что пароль известен только системе и тем лицам, которые имеют право применять данный идентификатор пользователя'. Кстати, в отношении последнего пункта следует заметить, что один и тот же идентификатор может совместно применяться произвольным количеством разных пользователей, входящих в состав некоторой группы. Таким образом, система может поддерживать группы пользователей, обеспечивая одинаковые права доступа для всех ее членов, например для всех работников расчетного отдела. Кроме того, операции добавления новых пользователей в группу или их удаления из нее можно выполнять независимо от операций задания привилегий доступа лля этой группы, Обратите внимание, однако, что местом хранения информации о принадлежности пользователей к группам также является системный каталог (или, возможно, сама база данных).
В этой связи следует обратить Проверка того, что пользователь действительно явллется тем, за кого себя выдает, называется аутентификацией. Попутно ояшетим, что в настоящее врел(я, помимо простой проверки пароля, существуют более сложные методы аутентификации пол~ловителей с применениеи различныл биометрическил устройств (считывателей отпечатков пальцев, сканеров сетчатки глаз, измерителеи геометрических параметров рук, устройств проверки голоса, распознавания подписи и т.д). Они могут быть зффективно использованы для проверки тел "личныл зароктеристик, которые нельзя подделать или украсть" Пб.З).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
