5. Быстрота работы. В нашем случае быстрота работы зависит не от конфигурации компьютера, а от качества связи с сервером, на котором установлена система.

Система регистрации ресурсов.

Устройство системы не предполагает немедленное внесение информации в основную базу данных после ее регистрации. По сути, таблица «Ресурсы» делится на две подтаблицы: основная и временная. После регистрации ресурс попадает во временную таблицу. Цензор просматривает временную таблицу каждые 24 часа. Ресурс может быть перемещен в основную таблицу, удален или оставлен во временной таблице для дальнейшего рассмотрения.

5. Вопросы безопасности и санкционирования доступа к базам данных.

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

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

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

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

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

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

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

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

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

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