Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Фаза 2 - сервер распределенной БД направляет команду "зафиксировать" всем узлам, затронутым транзакцией, и гарантирует, что транзакции на них будут зафиксированы. Если связь с локальной базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД принимает решение о фиксации транзакции и моментом, когда сервер локальной БД подчиняется его команде, то сервер распределенной БД продолжает попытки завершить транзакцию, пока связь не будет восстановлена.

1.6 Средства защиты данных в СУБД

Существенным аспектом современных СУБД является защита данных. В самом общем виде требования к безопасности реляционных СУБД формулируются так:

• данные в любой таблице должны быть доступны не всем пользователям, а лишь некоторым из них

• некоторым пользователям должно быть разрешено обновлять данные в таблицах, в то время как для других допускается лишь выбор данных из этих же таблиц

• для некоторых таблиц необходимо обеспечить выборочный доступ к ее столбцам

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

Схема доступа к данным во всех реляционных СУБД выглядит примерно одинаково и базируется на трех принципах:

• Пользователи СУБД рассматриваются как основные действующие лица, желающие получить доступ к данным. СУБД от имени конкретного пользователя выполняет операции над базой данных, то есть добавляет строки в таблицы (INSERT), удаляет строки (DELETE), обновляет данные в строках таблицы (UPDATE). Она делает это в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом базы данных.

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

• Привилегии (priveleges) - это операции, которые разрешено выполнять пользователю над конкретными объектами.

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

Привилегии устанавливаются и отменяются специальными операторами языка SQL - GRANT (ПЕРЕДАТЬ) и REVOKE (ОТОБРАТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице.

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

Некоторые СУБД (Oracle, Sybase, InterBase) используют собственную систему паролей, в других (Ingres, Informix, MS SQL Server) применяется идентификатор пользователя и его пароль из операционной системы.

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

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

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

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

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

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

В СУБД Ingres и Oracle это решение обеспечивается механизмом ролей (role). Роль представляет собой именованный объект, хранящийся в базе данных. Роль связывается с конкретной прикладной программой для придания последней привилегий доступа к базам данных, таблицам, представлениям и процедурам базы данных. Роль создается и удаляется администратором базы данных, ей может быть придан определенный пароль. Как только роль создана, ей можно предоставить привилегии доступа к объектам базы данных.

Современные информационные системы обеспечивают также другую схему безопасности - обязательный или принудительный контроль доступа (mandatory access control). Он основан на отказе от понятия владельца данных и опирается на так называемые метки безопасности (security labels), которые присваиваются данным при их создании. Каждая из меток соответствует некоторому уровню безопасности. Метки служат для классификации данных по уровням.

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

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

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

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

1.7 Применение CASE-средств для информационного моделирования в системах обработки данных .

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

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

Computer Aided Software Engineering (CASE) - это технология автоматизированного проектирования информационных систем, позволяющая значительно ускорить процесс их разработки, сократить затраты труда, а также повысить качество проектирования.

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

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

Стандартный подход выделяет в жизненном цикле программной разработки несколько этапов:

• анализ;

• проектирование;

• программирование;

• тестирование;

• сопровождение.

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

Такое возможно только с использованием CASE-средств.

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

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

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

2. Реализация распределенной базы данных с удаленным доступом

В качестве примера реализации распределенной базы данных рассмотрим информационную систему для автоматизации расчетов с абонентами АО «Связьинформ» РМ.

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

Основные требования к системе таковы:

• система автоматизации расчетов с абонентами должна обрабатывать данные по имеющимся клиентам;

• система должна учитывать начисления по оказанным услугам;

• система должна учитывать оплату, поступившую с клиента за оказанные услуги;

• система должна иметь механизм регистрации изменений и возможность отката к одному из предыдущих состояний;

• система должна обеспечивать возможность оперативного доступа к информации;

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

2.1 Анализ существующей системы

Для определения потребностей в построении системы расчета с абонентами и определения её структуры проведем анализ уже существующей схемы обмена данными.

Характеристики

Список файлов реферата