Ссылочная целостность

Второе  ограничение целостности касается внешних ключей.

Ссылочная целостность – если в отношении существует внешний ключ, то значение внешнего ключа должно либо соответствовать значению потенциального ключа некоторого кортежа в его базовом отношении, либо задаваться определителем NULL. (пример)

Корпоративные ограничения целостности

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

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

Билет 21. Безопасность. Защита данных.

Вопросы защиты данных часто рассматриваются вместе с вопросами поддержки целостности данных, хотя на самом деле это совершенно разные понятия. Термин защита относится к защищенности данных от несанкционированного доступа, изменения или умышленного разрушения, а целостность – к точности или достоверности данных. Эти термины можно определить и иначе:

• под ЗД подразумевается предотвращение доступа к ним со стороны несанкционированных пользователей.
• под поддержанием ЦД подразумевается предотвращение их разрушения при доступе со стороны санкционированных пользователей.

 Иначе  говоря, ЗД означает получение  гарантий, что пользователям разрешено  выполнять те действия, к-рые они  пытаются выполнить, поддержание  ЦД означает получение гарантий, что действия, к-рые пользователи  пытаются выполнить, будут корректны.

Среди многочисленных аспектов проблемы ЗД необходимо выделить следующие

1. правовые, общественные и этические аспекты
2. физические условия
3. организационные вопросы
4. вопросы управления
5. аппаратные средства защиты
6. возможности операционной системы
7. аспекты, имеющие отношение непосредственно к самой СУБД

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

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

Теперь  рассмотрим случай, когда нелегальный  пользователь пытается проникнуть в  БД, минуя систему, т.е. физически  перемещая часть базы данных или  подключаясь к коммуникационному каналу. Наиболее эффективным методом борьбы  с такими угрозами является шифрование данных, т.е. хранение или передача особо важных данных в зашифрованном виде. Исходные (незашифрованные) данные называются открытым текстом. Открытый текст шифруется с помощью специального алгоритма шифрования. В качестве входных данных для такого алгоритма выступают открытый текст и ключ шифрования, а в качестве выходных – зашифрованная форма открытого текста, к-рая называется шифрованным текстом. Детали алгоритма шифрования могут быть опубликованы или, по крайней мере, могут не утаиваться, но ключ шифрования обязательно хранится в секрете. Именно зашифрованный текст, непонятный всем, кто не обладает ключом шифрования, хранится в БД и передается по коммуникационным каналам. Одним из алгоритмов шифрования является Data Encryption Standard (DES), разработанный фирмой IBM и приятый в 1977 г. в качестве Федерального стандарта шифрования данных США.

В действующем  стандарте языка SQL предусматривается только поддержка избирательного метода управления доступом. Они строятся на основе двух более или менее независимых функций языка SQL. Первая из них может является механизмом представлений, к-рый может быть использован для сокрытия важных данных от несанкционированных пользователей. Вторая функция называется подсистемой полномочий и позволяет одним пользователям, обладающим определенными правами доступа, избирательно и динамично предоставлять эти полномочия другим пользователям, а также отменять предоставленные ими полномочия в случае необходимости.  Меры безопасности, к-рые поддерживаются в стандарте языка SQL – использование представлений для сокрытия информации и применение директив GRANT и REVOKE для управления набором привилегий, предоставленных конкретным пользователям в отношении различных объектов БД. 

Билет 22. Параллельные системы БД.

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

3 проблемы пар-зма:

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

• Проблема потери результатов обновления;
• Проблема незафиксированной зависимости;
• Проблема несовместимого анализа.

  Проблема потери  результатов обновления:

Рис.1 Потеря в момент времени t4 рез-та обновления, выполненного транзакцией А.

Рассмотрим  ситуацию, показанную на рис.1, в такой  интерпретации: транзакция А извлекает  некоторый кортеж р в момент времени  t1; транзакция В извлекает некоторый кортеж р в момент времени t2; транзакция А обновляет некоторый кортеж р в момент времени t3; транзакция В обновляет тот же кортеж р в момент времени t4. Однако рез-т операции обновления, выполненной транзакцией А, будет утерян, поскольку в момент времени t4 она будет учтена и потому будет «отменена» операцией обновл-я, выполн-ой транз-ей В.

Проблема  незафиксированной  зависимости

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

Рис2. Тран-ция А становится зависимой от невыполнен. Изменения в момент времени t2

В примере  тран-ция А в момент времени  t2 встречается с невыполн. обновлением. Затем это обновление отменяется в момент времени t3. Т.о., тран-ция А выпол-ся на основе фальшивого предполож-я, что кортеж р имеет некот. значение в момент времени t2, тогда как на самом деле он имеет некот. знач-е, существовавшее еще в момент времени t1. В итоге после выполнения транз-ции А будет получен неверный  рез-т. Кроме того, отмена выпол-я тран-ции В может произойти не по вине тран-ции В,а, например, в рез-те краха системы.

Проблема  несовместимого анализа

Рис.3. Тран-ция А выполнила несовмест.анализ

На рис.3 показаны транз-ции А и В, кот. Выполн-с для кортежей со счетами. При этом тран-ция А суммирует балансы, тран-я В производит перевод суммы 10 со счета 3 на счет 1. Полученный в итоге транз-и А рез-т 110, очевидно, неверен, и если он будет записан в БД, то в ней может возникнуть проблема несовместимости. В таком случае говорят, что транз-я А встретилась с несовмест.состоянием и на его основе был выполнен несовм. анализ.

Блокировка.

Описанные выше проблемы м.б. разрешены с помощью  методики управ-я пар-м выполнением процессов под названием блокировка. Ее основная идея: в случае, когда для выполнения некот. транз-ции необходимо, чтобы некот. объект не изменялся непредсказуемо и без ведома этой тран-ции, такой объект блокируется. Т.о., эффект блокировки состоит в том, чтобы «заблокир-ть доступ к этому объекту со стороны др. транз-ций», а значит, предотвратить непредсказуемое изменение этого объекта. След-но, первая тарнз-я в состоянии выполнить всю необх. обраб-ку с учетом того, что обрабатываемый объект остается в стабил. Состоянии настолько долго, насколько это нужно.

Перспективы развития пар-х систем БД:

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

Билет 23. Временные БД.

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

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