Ю. А. Григорьев, Г. И. Ревунков - Банки данных

3. Проектирование баз данных

локальных представлениях при описании исходных объектов ПО. Целью введения подобных абстракций является:

•объединение в композиционно единое представление фрагментар­ ных представлений о различных свойствах одного и того же объекта;

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

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

•образование классов и подклассов подобных объектов и введение соответствующих абстрактных понятий (например, в АСУ предприятия целесообразно введение понятия «изделия предприятия» как класса, а типы производимых на этом предприятии изделий могут выступать в качестве подклассов), классификация объектов по некоторым условиям (например,

покупные детали и детали собственного производства и т.п.);

• образование производных типов объектов, соответствующих объе­ динению, пересечению или разности исходных объектов и т.д.

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

Например, имеется п моделей. Можно попытаться выполнить объеди­ нение за один шаг, вовлекая в него все п представлений. Это возможно, если п невелико — 2, 3, 4 представления. При увеличении п задача резко усложня­ ется, растут временнь'ю затраты, возрастает вероятность ошибок и упуще­ ний. Поэтому число шагов объединения увеличивают, уменьшая число мо­ делей, подлежащих объединению на отдельном шаге. Обычно используется бинарное объединение (рис. 3.11). При бинарном (попарном) объединении результат объединения Л^1 объектов одного представления с Л^ объектами другого представления даст в результирующем объединении N1 + Ш - X объектов, где X соответствует количеству совпадающих объектов в объеди­ няемых представлениях, что минимизирует число сравниваемых объектов при объединении представлений на последующих шагах процесса.

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

При объединении представлений используют три основополагающие концепции: идентичность, агрегация и обобщение.

Идентичность. Два (или более) элемента модели являются идентич­ ными, если они имеют одинаковое семантическое (смысловое) значение.

100

3.2. Объединение моделей локальных представлений

Модель

результирующего

(объединенного)

представления

Рис. 3.11. Бинарное объединение моделей

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

Например, связь между сущностями Студент, Дисциплина, Препода­ ватель, Оценка имеет смысловое описание «студент по фамилии

ным элементом: сущностью Экзамен с атрибутами Фамилия студента, На­ звание дисциплины. Фамилия преподавателя. Код оценки.

При объединении представлений агрегация может встретиться в сле­ дующих формах.

1. В одном представлении агрегатный объект определен как единое целое, а в другом — рассматриваются его составные части.

Например, в одном представлении определен только один объект А (некоторое изделие), а в другом — только объекты 51, 52, ВЪ (некоторые детали), являющиеся составными частями объекта А, но объект А во втором представлении не определен. Если выполнить простое объединение, т.е. рассматривать четыре самостоятельных объекта А, В\, 52, 53 (как само­ стоятельные компоновочные элементы), то это будет означать, что в объе-

101

3. Проектирование баз данных

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

2.Агрегатный объект как единое целое не определен ни в одном из представлений, но в обоих представлениях рассматриваются его различные составные части.

Например, в одном представлении определены объекты 51, 52, а в другом — объекты 53, 54, 55, являющиеся составными частями объекта^, который не назван ни в одном представлении, но о существовании которого знает проектировщик.

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

3.Один и тот же агрегатный объект рассматривается в обоих пред­ ставлениях, но составляющие различаются.

Например, в одном представлении рассматривается одна часть агрега­ та, а в другом представлении другая часть. При объединении этих представ­ лений вводится единый агрегат.

Пример. Объединению подлежат два представления, изображенные на рис. 3.12, а, б.

С использованием агрегации может быть выполнено следующее объединение этих представлений (рис. 3.12, в).

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

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

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

102

3.2. Объединение моделей локальных представлений

Рис. 3.12. Пример объединения представлений

103

3. Проектирование баз данных

Рис. 3.13. Окончательный вид итогового объединения

понятию наименование Компонент и введем его в модель представления, использовав конструктивный элемент сущность, т.е. введем в рассмотрение сущность Компонент.

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

Стол, Стул, Шкаф, Полка.

Таким образом, окончательный вид объединенного представления в рассматриваемом примере изображен на рис. 3.13.

Пример. В объединяемых исходных представлениях присутствуют следую­ щие сущности:

Детали собственного производства; Детали покупные; Сборочные единицы покупные;

Сборочные единицы собственного производства.

В объединенном представлении могут быть использованы обобщения, пред­ ставленные на рис. 3.14.

104

3.2. Объединение моделей локальных представлений

Элементы

изделий

предприятия

Рис. 3.14. Пример обобщений

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

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

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

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

105

3. Проектирование баз данных

Позиция в ифе

Игрок

Рис. 3.15. Пример несогласованных связей и возможный вариант их согласования

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

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

106

4. МЕТОДЫ СПЕЦИАЛЬНОЙ ОБРАБОТКИ

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

4.1.Обеспечение защиты данных в базе

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

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

При решении вопросов защиты данных в обязанности АБД входит следующее:

1)классификация данных в соответствии с их использованием;

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

3)организация системы контроля доступа к данным;

4)тестирование всех вновь создаваемых средств защиты данных;

5)периодическое проведение проверок правильности функциониро­ вания системы защиты данных;

6)исследование случаев нарушения защиты данных и проведение по­ литики их предотвращения;

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

Администратор БД или сотрудники его группы, ответственные за обеспечение защиты данных, должны хорошо знать состав, структуру и все

108

4. L Обеспечение защиты данных в базе

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

Рассмотрим уровни доступа к БД, каждый из которых может оказаться целесообразным для предоставления определенной категории пользователей:

1)неограниченный доступ ко всем отношениям в БД и их поколениям;

2)неограниченный доступ к группе отношений и их поколениям;

3)ограниченный доступ к группе отношений и их поколениям.

На уровне отношений различают следующие уровни доступа:

1)неограниченный доступ ко всему отношению для всех типов операций;

2)запрет на доступ к любым частям отношения для всех типов операций;

3)доступ к любой части отношения без права изменения ее содер­

жимого;

4)доступ к любой части отношения, но с правом изменения значений только для атрибутов А\, ^2?-? ^г- Неограниченный доступ только к одному кортежу отношения для всех типов операций;

5)доступ только к одному кортежу отношения без права изменения содержимого этого кортежа;

6)неограниченный доступ к атрибутам Аи ^2? •••? ^г отношения для всех типов операций и запрет доступа к остальным атрибутам отношения;

7)доступ только к атрибутам А\, А2, ..., А,, отношения без права изме­ нения их значений и запрет доступа к остальным атрибутам отношения;

8)доступ только к атрибутам А\, Ai, .... А^ отношения с правом изме­ нения значений только для атрибутов Ai, ..., Ар (где {А/, ..., Ар} с ({^ь А2, ...,

Аг}) и запрет доступа к остальным атрибутам отношения; 9) доступ в соответствии с п. 1, 3—8, но с ограничением по интервалу

времени (с t] по /2);

10) доступ в соответствии с п. 1, 3—9, но с разрешением изменения значений только в случае выполнения условий соответственно F, на значе­ ния атрибутов (например, если значение атрибута не превышает некоторой величины N);

И) разрешение права применения вычислительных операторов (сум­ мирование, вычитание и т.п.) к атрибутам А], А2, ..., Аг без права доступа к этим атрибутам или изменения их значений.

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

Рассмотрим основные методы и приемы защиты данных.

109