ЧАСТЬ 2 епщштьа. систем баз данных

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

систему, и их можно применять без всяких ограничений.

Процесс разработки системы нелинейный. Изменение таблиц на этапе разработки может привести к серьезным проблемам, которые в

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

Защита данных

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

Требования, связанные с администрированием системы - это

некие общие требования или метатребования, поскольку они относятся ко всей системе в целом, а не к предметной области, которую

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

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

Реализовать политику зашиты данных зачастую весьма непросто. Вам поможет техническая документация ess, механизму баз данных Micrisoft Jet и SQL Server, где эти вопросы подробно освещены. Кроме того, разработка баз данных и реализация системы - это разные процессы, и при проектировании базы данных вам нужно всего лишь разработать логическую схему защиты данных. А на логическом уровне эти вопросы совсем не сложны.

ГЛАВ Скема базы

данных

Уровни защиты данных

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

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

всего реализовать, и такую систему легко администрировать.

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

Следующий уровень защиты данных - общего доступа к данным (share-level security). На этом уровне зашиты данных для всей базы назначается единый пароль, и все, кто его знают, получают полный доступ к системе. Этот уровень также легко реализовать, и администрирование такой системы не будет слишком сложным делом: все, что требуется от - регулярно изменять пароль. Во мно-

гих случаях защита на уровне общего доступа к данным вполне приемлема.

Защита на уровне пользователя (User-leve mrity), хотя и гораздо более сложна с точки зрения реализации и администрирования, позволяет дифференцировать права доступа пользователей к базе данных. Этот уровень защиты позволяет администратору системы задавать права доступа для каждого объекта в отдельности. Право доступа к определенному объекту может быть предоставлено только нескольким причем каждый из них вправе совершать с объектом только те действия, на которые он получит от администратора соответствующие права. Например: пользователь Joe может добавлять и изменять данные для сущности Customers, однако к данным сущности Orders он имеет доступ только для Пользователь Магу (Мери) может добавлять и изменять данные для сущностей Customers и Orders. Однако ни Joe, ни Магу не имеют права удалять

записи ни для одной из сущностей.

ЧАСТЬ 2 баз

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

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

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

Часто нужно предоставить отдельным группам пользователям доступ только к некоторым фрагментам записей, хранимых в таблицах, а не ко всей записи целиком. Например, право просмотра данных, хранящихся в нолях Name (Фамилия) и Extension (Внутренний номер телефона) таблицы Employees (Сотрудники) нужно предоставить всем пользователям системы, но право просматривать информацию, хранящуюся в ноле Salary (Заработная плата) - только менеджерам. Или требуется ограничить права доступа торговых агентов к данным о заказах, относящимся к деятельности всей компании в целом, предоставив каждому торговому агенту право просматривать информацию только о тех заказах, которые сделаны его клиентами, но не клиентами его коллег. Чтобы реализовать все эти требования, вы можете предоставить пользователям права на выполнение запросов, но запретить доступ к нижележащим таблицам.