Файл: Базы данных УП.pdf

101

го

доступа

к

БД

или

ее

модификации

,  

в

статистической

БД

существуют

проблемы

,  

связанные

с

тем

,  

что

допускаются

за

-

просы

в

виде

: «

Напечатать

средний

доход

всех

жителей

Том

-

ска

»,  

но

в

тоже

время

запрещается

доступ

к

данным

о

дохо

-

дах

,  

конкретного

человека

,  

например

Иванова

. 

Не

так

просто

запретить

запросы

,  

которые

требуют

ин

-

формации

,  

относящейся

к

единственной

записи

.  

Например

,  

Петров

может

запросить

средний

доход

для

множества

{

Петров

,  

Иванов

},  

из

которого

,  

зная

свой

собственный

до

-

ход

,  

он

может

вычислить

доход

Иванова

.  

Не

решает

про

-

блему

также

и

требование

,  

чтобы

информация

запрашива

-

лась

относительно

множества

,  

состоящего

из

  m  

человек

.  

Действительно

,  

в

этом

случае

Петров

мог

бы

взять

множе

-

ство

  S  

из

   m-1  

или

более

человек

,  

доходы

которых

ему

не

нужно

узнавать

,  

и

запросить

средний

доход

этих

людей

вместе

с

Ивановым

.  

Затем

он

получил

бы

средний

доход

для

множества

,  

включающего

его

самого

и

людей

из

мно

-

жества

    S.   

Зная

свой

собственный

доход

,  

он

смого

бы

те

-

перь

легко

определить

доход

Иванова

на

основе

двух

отве

-

тов

системы

.  

Поэтому

необходимо

ввести

огранечения

на

запросы

,  

сильно

пересекающиеся

друг

с

другом

и

таким

образом

можно

если

не

предотвратить

раскрытие

индивиду

-

альных

данных

,  

но

сделать

это

достаточно

трудным

делом

. 

Будем

считать

для

простоты

,  

что

статистическая

БД

со

-

держит

единственный

файл

записей

.  

Каждая

запись

состоит

из

нескольких

полей

.  

Пусть

  v = (v

1

,v

2

,…v

n

) – 

вектор

значе

-

ний

некоторого

неключевого

поля

этих

записей

.  

Тогда

ли

-

нейным

запросом

называется

линейная

сумма

∑

=

n

i

i

i

v

c

1

,  

где

i

c

-   

произвольные

действительные

числа

.   

Важным

случаем

линейных

запросов

является

сумма

по

множеству

  S,  

где

⎩

⎨

⎧

∉

=

∈

=

,

,

0

,

,

1

S

i

c

S

i

c

i

i

а

также

средние

,  

где

⎩

⎨

⎧

∉

=

∈

=

,

,

0

,

,

/

1

S

i

c

S

i

p

c

i

i

102

где

 p -  

число

записей

в

  S. 

Способность

компрометировать

БД

 (

т

.

е

.  

вычислять

значе

-

ния

отдельного

i

v

)  

будет

зависеть

от

допустимого

числа

ненулевых

i

c

,  

а

не

от

их

точных

значений

.  

Существует

теорема

:  

Пусть

допускаются

линейные

за

-

просы

,  

продуцирующие

по

меньшей

мере

  m  

элементов

  (

т

.

е

.  

обрабатывают

  m  

записей

), 

и

никакие

два

запроса

не

могут

иметь

более

    k   

общих

элементов

    (

т

.

е

.  k  

общих

записей

).  

Предположим

,  

что

    p   

элементов

уже

известны

    (

т

.

е

.  

для

    p  

записей

конкретные

значения

поля

известны

), 

тогда

для

вы

-

читания

некоторого

еще

неизвестного

элемента

  (

значения

поля

в

интересующей

нас

записи

)  

необходимо

сделать

не

менее

  1+ (m-1-p) 

/

k  

запросов

.  

Ограничения

на

структуру

запроса

. 

Пусть

ключ

записи

состоит

из

  x  

полей

и

предполагается

,  

что

в

запросе

можно

задать

не

более

  y  

полей

ключа

 (

т

.

е

.  

выполняется

поиск

по

частичному

соответствию

ключа

).  

То

-

гда

,  

если

  y < k,  

никакая

функция

,  

использующая

только

опе

-

рации

сложения

,  

вычитания

,  

умножения

и

деления

,  

не

по

-

зволит

определить

значение

данного

конкретной

записи

.   

103

4. 

Целостность

данных

4.1. 

Контроль

типов

Информация

,  

хранящаяся

в

БД

,  

должна

быть

в

меру

возможности

правильной

,  

точной

и

согласованной

.  

Необхо

-

димо

предусматривать

средства

,  

которые

бы

защищали

базу

от

потенциально

неверных

действий

,  

связанных

с

корректи

-

ровкой

данных

и

записью

новой

информации

. 

Одним

из

распространенных

способов

защиты

является

контроль

типов

.   

Простейший

вариант

    -   

проверка

принад

-

лежности

переменной

выделяемому

для

нее

диапазону

ве

-

личин

.  

Если

, 

например

,  

установлено

,  

чтобы

содержимое

ат

-

рибута

НОМЕР

_

КЛИЕНТА

находилось

в

пределах

от

  100000  

до

  999999,  

то

система

должна

предотвратить

попытку

поль

-

зователя

присвоить

этому

полю

значение

  403.  

Другой

при

-

мер

:  

торговые

зоны

,  

где

располагаются

фирмы

-

клиенты

,  

со

-

кращенно

обозначаются

Ю

,  

ЮЗ

,  

З

,  

СЗ

, 

С

, 

СВ

,  

В

,  

ЮВ

.  

Недо

-

пустимо

,  

чтобы

система

позволила

записать

в

атрибут

ТОР

-

ГОВАЯ

_

ЗОНА

значение

  «

МОСКВА

». 

4.2.  

Контроль

изменений

Если

на

фирме

  «

Хелми

»  

операции

ведутся

таким

обра

-

зом

, 

что

количество

не

распределенного

со

склада

товара

,  

указанного

в

таблице

СОДЕРЖИМОЕ

_

НАРЯДОВ

_

НА

_

ПРО

-

ДАЖУ

,  

не

может

увеличиваться

,  

всякий

прирост

этого

пока

-

зателя

должен

фиксироваться

,  

расцениваясь

как

возможная

ошибка

.  

СУБД

оснащаются

средствами

,  

которые

позволяют

объявлять

ограничения

,  

накладываемые

на

характер

изме

-

нения

переменных

. 

Еще

один

пример

ограничений

такого

типа

.  

В

    «

Хелми

»  

считается

недопустимым

,  

чтобы

содержимое

атрибута

КО

-

ЛИЧЕСТВО

_

НА

_

СКЛАДЕ

в

таблице

ТОВАРНЫЕ

_

ЗАПАСЫ

возрастало

после

единичной

корректировки

на

величину

, 

пре

-

вышающую

ЗАКАЗЫВАЕМОЕ

КОЛИЧЕСТВО

.  

Если

это

прави

-

ло

нарушается

,  

СУБД

должно

известить

пользователя

об

ошибке

. 

104

4.3. 

Целостность

на

уровне

ссылок

При

построении

реляционных

таблиц

для

связывания

строк

одной

таблицы

со

строками

другой

таблицы

исполь

-

зуются

внешние

ключи

.  

Например

,  

ТИП

_

СПЕЦИАЛЬНОСТИ

используется

в

таблице

РАБОТНИК

для

того

,  

чтобы

сооб

-

щить

нам

основную

специальность

каждого

работника

,  

чтобы

можно

было

подсчитать

размер

премиальных

.  

Таким

обра

-

зом

,  

важно

,  

чтобы

значение

атрибута

ТИП

_

СПЕЦИ

-

АЛЬНОСТИ

каждой

строки

,  

обозначающей

служащего

,  

соот

-

ветствовал

некоторому

значению

атрибута

ТИП

_

СПЕЦИ

-

АЛЬНОСТИ

в

таблице

СПЕЦИАЛЬНОСТЬ

.  

В

противном

слу

-

чае

ТИП

_

СПЕЦИАЛЬНОСТИ

служащего

ни

на

что

не

будет

указывать

.  

БД

,  

в

которой

все

непустые

внешние

ключи

ссы

-

лаются

на

текущие

значения

ключей

другой

реляционной

таблицы

,  

обладает

целостностью

на

уровне

ссылок

. 

105

5.  

Параллельная

работа

с

БД

5.1. 

Обработка

транзакций

Транзакция

  -  

это

блок

программы

,  

выполнение

которого

сохраняет

непротиворечивость

БД

.  

Неделимая

транзакция

 – 

транзакция

, 

в

которой

либо

все

связанные

с

ней

действия

вы

-

полняются

до

конца

, 

либо

ни

одно

из

них

не

выполняется

. 

Если

БД

непротиворечива

до

выполнения

транзакции

,  

то

она

должна

оставаться

непротиворечивой

и

после

ее

вы

-

полнения

.  

Для

того

чтобы

обеспечить

выполнение

этих

ус

-

ловий

,  

транзакции

должны

быть

неделимыми

,  

что

означает

,  

что

либо

все

действия

,  

связанные

с

транзакцией

,  

выполня

-

ются

до

конца

,  

либо

ни

одно

из

них

не

выполняется

.  

На

-

пример

,  

транзакция

записи

взноса

клиента

на

сумму

  500 $  

включает

следующие

действия

: 

1. 

Изменение

записи

клиента

: 

уменьшение

суммы

счета

на

500 $. 

2. 

Изменение

кассовой

записи

:  

увеличение

суммы

на

  500 $.      

Предположим

,  

что

второй

шаг

не

выполняется

.  

Тогда

ба

-

ланс

счетов

не

будет

сходиться

.  

На

рис

.5.1  

показано

,  

что

происходит

,  

когда

эти

действия

выполняются

как

последова

-

тельность

независимых

шагов

  (

а

)  

и

когда

они

выполняются

как

единая

неделимая

транзакция

  (

б

). 

Для

обработки

транзакций

требуется

,  

чтобы

СУБД

под

-

держивала

запись

транзакции

для

каждого

изменения

,  

вно

-

симого

в

БД

.  

Один

из

способов

 – 

применение

протокола

.  

Когда

клиент

платит

  500 $  

по

счету

,  

транзакция

включает

  1) 

уменьшение

счета

клиента

и

  2) 

увеличение

кассового

счета

.  

Во

время

выполнения

транзакции

все

записанные

операции

задерживаются

до

тех

пор

,  

пока

не

будет

выполнено

по

-

следнее

действие

транзакции

.  

Результаты

обновления

запи

-

сываются

в

протокол

транзакций

.  

Когда

все

действия

вы

-

полнены

,  

информация

об

обновлении

из

протокола

исполь

-

зуется

для

переноса

обновленной

информации

в

соответст

-

вующие

записи

данных

.