Организация Web-доступа к базам данных с использованием SQL-запросов

Информация - Компьютеры, программирование

Другие материалы по предмету Компьютеры, программирование

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

До сих пор в качестве примера распространенного вида ошибок фигурировал случай, когда неправильно обновлялось индивидуальное поле некоторой записи. Однако часто возникают ситуации, когда совокупные данные записи становятся неверными по той причине, что значения нескольких полей должны изменяться согласованно. Расширим немного пример базы данных марок автомобилей. Пусть каждая запись содержит еще одно поле класс автомобиля. Например, пусть при весе до 3,5 тонн автомобиль относится к классу B, а при большем весе к классу С. Конечно, это ограничение целостности, и его можно сформулировать, например, на языке SQL. Конечно, можно определить триггер, который будет автоматически изменять значение класса автомобиля в зависимости от устанавливаемого значения его веса. Но все это ужасно громоздко.

На мой взгляд, более изящное решение подобных проблем обеспечивают системы объектно-ориентированных баз данных (ООБД). В таких системах хранятся не записи данных, а объекты. Каждый объект обладает внутренним состоянием (по-простому, хранит внутри себя запись данных), а также набором методов, т.е. процедур, с помощью которых (и только таким образом) можно обратиться к данным, составляющим внутреннее состояние объекта, и/или изменить их.

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

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

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

 

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

механизм представлений, рассмотреный в предыдущей главе и используемый для скрытия засекреченных данных от пользователей, не обладающих правом доступа;

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

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

Привилегии предоставляются с помощью предложения GRANT (предоставить), общий формат которого имеет вид

GRANT привилегии ON объект TO пользователи;

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

К таблицам (представлениям) относятся привилегии SELECT, DELETE, INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать (выполнять любые операции, в которых используе