Базы данных. Лекции - База данных, лекционный курс. Базы данных лекционный курс
 Скачать 1.23 Mb.
|
|
7.1. Обязательное управление доступом Методы обязательного управления доступом применяются к базам данных, в которых данные имеют достаточно статичную и жесткую структуру, свойственную, например, правительственным или военным организациям. Правила безопасности формулируются следующим образом: Пользователь i имеет доступ к объекту j, только если его уровень допуска больше или равен уровню классификации объекта j. Пользователь i может модифицировать объект j, только если его уровень допуска равен уровню классификации объекта j. Правило 1 достаточно очевидно, а правило 2 можно сформулировать так: любая информация, записанная пользователем i, автоматически приобретает уровень, равный уровню классификации i. Требования к обязательному управлению изложены в двух важных публикациях министерства обороны США, которые неформально называются «оранжевой книгой» и «розовой книгой». В «оранжевой книге» перечислен набор требований к безопасности для некой «надежной вычислительной базы», а в «розовой книге» дается интерпретация этих требований для систем управления базами данных. В этих документах определяется четыре класса безопасности – D, C, B и A. Говорят, что класс D обеспечивает минимальную защиту (данный класс предназначен для систем, признанных неудовлетворительными), класс С – избирательную защиту, класс В – обязательную, а класс А – проверенную защиту. Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных. Согласно требованиям класса С1, необходимо разделение данных и пользователя, т.е., наряду с поддержкой концепции взаимного доступа к данным, здесь возможно также организовать раздельное использование данных пользователями. Согласно требованиям класса С2, необходимо дополнительно организовать учет на основе процедур входа в систему, аудита и изоляции ресурсов. Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом). Согласно требованиям класса В1, необходимо обеспечить «отмеченную защиту» (это значит, что каждый объект данных должен содержать отметку о его уровне классификации, например: секретно, для служебного пользования и т.д.), а также неформальное сообщение о действующей стратегии безопасности. Согласно требованиям класса В2, необходимо дополнительно обеспечить формальное утверждение о действующей стратегии безопасности, а также обнаружить и исключить плохо защищенные каналы передачи информации. Согласно требованиям класса В3, необходимо дополнительно обеспечить поддержку аудита и восстановления данных, а также назначение администратора режима безопасности. Проверенная защита. Класс А является наиболее безопасным и, согласно его требованиям, необходимо математическое доказательство того, что данный метод обеспечения безопасности совместим и адекватен заданной стратегии безопасности. Коммерческие СУБД обычно обеспечивают избирательное управление на уровне класса С2. СУБД, в которых поддерживаются методы обязательной защиты, называют системами с многоуровневой защитой. 7.2. Защита баз данных в среде Access 2000 Под защитой базы данных понимают обеспечение защищенности базы данных против любых предумышленных или непредумышленных угроз с помощью различных компьютерных и некомпьютерных средств. В Access реализованы следующие способы защиты: парольная защита, защита на уровне пользователя, шифрование. 7.2.1. Парольная защита базы данных Парольная защита является простым и часто достаточным средством обеспечения защиты БД от открытия несанкционированными пользователями. Используемый при этом пароль называют паролем базы данных. Зная пароль БД, любой пользователь сможет ее открыть и использовать, а также выполнить все необходимые операции с ней. Парольная защита может использоваться в дополнение к защите на уровне пользователя. В этом случае устанавливать парольную защиту может пользователь, обладающий правами администратора БД. Установка пароля не влияет на систему защиты на уровне пользователя. Парольную защиту БД нельзя использовать в случае, если предполагается выполнять репликацию БД. Система Access не позволяет создавать копии (реплики) БД, защищенных паролем. Метод парольной защиты достаточно надежен, так как пароль система Access шифрует, и к нему нет прямого доступа. Он хранится вместе с защищаемой БД, а потому открыть БД не удастся и на другом компьютере с установленной там системой. Для установки парольной защиты следует выполнить следующие действия: Закрыть базу данных. Сделать резервную копию базы данных и сохранить ее в надежном месте. В меню Файл выбрать команду Открыть. Выделить файл базы данных, щелкнуть по стрелке справа от кнопки Открыть и выбрать вариант Монопольно. В меню Сервис выбрать команду Защита и подкоманду Задать пароль базы данных. Ввести пароль в поле Пароль (пароль вводится с учетом регистра). Подтвердить пароль, введя его еще раз в поле Подтверждение, OK. Пароль будет установлен. При следующем открытии базы данных Вами или любым другим пользователем будет выводиться диалоговое окно, в которое следует ввести пароль. Удалить пароль еще проще, главное – знать его при открытии БД. Для удаления пароля БД следует выполнить следующие действия: Открыть базу данных в режиме монопольного доступа. В меню Сервис выбрать команду Защита и команду Удалить пароль базы данных. В диалоговом окне Удаление пароля базы данных ввести текущий пароль, OK. При очередном открытии базы данных система Access запрашивать пароль не будет. Средств изменения пароля БД в Access нет, поэтому для изменения пароля следует сначала удалить пароль, а затем определить новый. Если Вы потеряете или забудете пароль, восстановить его будет невозможно, и Вы не сможете открыть базу данных. 7.2.2. Защита на уровне пользователя Защита на уровне пользователя применяется в случаях, когда с одной БД работают несколько пользователей или групп пользователей, имеющих разные права доступа к объектам БД. Использовать защиту на уровне пользователя можно на отдельном компьютере и при коллективной работе в составе локальной сети. Для организации защиты на уровне пользователя в системе Access создаются рабочие группы (РГ). Каждая рабочая группа определяет единую технологию работы совокупности пользователей. Система Access в произвольный момент времени может работать с одной РГ. Информация о каждой РГ хранится в соответствующем файле РГ. При установке системы автоматически создается рабочая группа, которая описывается в файле system.mdw. В последующем можно изменять описание РГ (содержимое соответствующего файла РГ), а также создавать новые РГ. Для этой цели в системе имеется программа администратора РГ (АРГ). Файл РГ описывает группы пользователей и отдельных пользователей, входящих в эту РГ. Он содержит учетные записи групп пользователей и отдельных пользователей. По каждой учетной записи система Access хранит права доступа к объектам базы данных. По умолчанию в каждую рабочую группу входит две группы пользователей: администраторы (Admins) и обычные пользователи (Users). Причем, в группу Admins первоначально включен один администратор под именем Admin. При создании группы указывается имя (идентификатор) группы и код, представляющий собой последовательность от 4 до 20 символов. При регистрации пользователей в системе защиты им присваивается имя, код и необязательный пароль. Имена групп и пользователей, их коды, а также пароли пользователей (если они заданы) Access скрывает от пользователя. Поэтому если пользователь их забудет, найти их в файле РГ и восстановить практически невозможно. Коды группы и пользователя используются для шифрования системой учетных записей в файле РГ. Каждому из пользователей, независимо от принадлежности к группе, можно присвоить пароль. Этот пароль называется паролем учетной записи и хранится в файле РГ. Первоначально все включаемые в РГ пользователи, в том числе и пользователь Admin, не имеют пароля. Каждой из групп приписываются определенные права на объекты БД. Члены группы Admins имеют максимальные права. Наличие двух функциональных групп пользователей в рабочей группе, как правило, достаточно для организации нормальной работы коллектива пользователей. При необходимости можно создать дополнительные группы пользователей. Один пользователь может входить в несколько групп. При подключении пользователя, зарегистрированного в нескольких группах, действуют минимальные из установленных в разных группах ограничения на объекты БД. Основные ограничения, действующие при создании рабочих групп и регистрации пользователей: Группы Admins и Users удалить невозможно. В группе Admins должен быть хотя бы один пользователь. Первоначально таким пользователем является пользователь Admin. Удалить пользователя Admin из этой группы можно после включения в нее еще одного пользователя. Все регистрируемые пользователи автоматически становятся членами групп Users. Удалить их из этой группы нельзя. Удалить пользователя Admin из рабочей группы нельзя (из группы Admins его можно удалить, а из группы Users – нет). Создаваемые группы не могут быть вложены в другие группы, другими словами, нельзя создавать иерархию групп пользователей. В системе защиты могут быть пустые группы, но не может быть пользователей, не входящих ни в одну группу (они обязательно войдут в группу Users). Рабочая группа имеет структуру, показанную на рис. 7.1. Символами A, B и F обозначены созданные группы пользователей, а символами P1, P2, P3, P4 и Pn – пользователи. Все пользователи являются членами группы Users. Группа F пока пуста.  Рис. 7.1. Структура рабочей группы Основное назначение системы защиты на уровне пользователя состоит в контроле прав доступа к объектам базы данных. Типы прав доступа, существующие в Access, приведены в табл. 7.1. Права подключающегося пользователя делятся на явные и неявные. Явные права имеются в случае, если они определены для учетной записи пользователя. Неявные права – это права той группы, в которую входит пользователь. Изменить права доступа других пользователей на объекты некоторой БД могут следующие пользователи: члены группы Admins, определенной в файле РГ, использовавшемся при создании базы данных; владелец объекта; пользователь, получивший на объект права администратора. Изменить свои собственные права в сторону их расширения могут пользователи, являющиеся членами группы Admins и владельцы объекта. Владельцем объекта считается пользователь, создавший объект. Владельца объекта можно изменить путем передачи права владельца другому. Установка защиты на уровне пользователя сложнее парольной защиты. Она предполагает создание файла РГ, учетных записей пользователей и групп, включение пользователей в группы, назначение прав доступа к объектам базы данных пользователям и группам. Далее кратко рассматриваются эти операции. Как отмечалось, манипуляции с файлами РГ выполняются с помощью программы АРГ. Программа АРГ имеет три функции: создание файла РГ, связь с произвольным файлом РГ и выход из программы. Исполняемый файл администратора имеет имя wrkgadm.exe. Таблица 7.1 Типы прав доступа
Замечания: Для того чтобы обойти требование ввода пароля при входе в Access, достаточно задать другой файл рабочей группы, в котором оно не установлено. В простейшем случае – это создаваемый при установке системы файл system.mdw. Чтобы система использовала его, а не текущий файл, достаточно запустить программу администратора рабочих групп и с его помощью связать Access с «подставным» файлом. Файл рабочей группы не обязательно должен быть «родным». Несовпадение имени и названия организации не мешает нормальному запуску системы с другим файлом рабочей группы, который может находиться в любой папке. Чтобы обезопасить себя от порчи файла рабочей группы или утери пароля администратора из группы Admins, следует сохранить исходный файл рабочей группы в надежном месте. В критический момент следует подключиться к нужному файлу. При организации работы нескольких групп пользователей на одном компьютере целесообразно для каждой из групп создать свой файл рабочей группы. Перед началом работы следует подключиться к нужному файлу. Чтобы случайно не подключиться к чужому файлу и не дать возможности несанкционированному пользователю войти в систему Access, файл лучше хранить отдельно от системы. Учетные записи отдельных пользователей и групп пользователей создаются с помощью команды Сервис | Защита | Пользователи и группы. Определение прав пользователей и групп выполняется с помощью команды Сервис | Защита | Разрешения. Окно Разрешения имеет две вкладки: Разрешения и Смена владельца. Установка прав может выполняться по отношению к группам и отдельным пользователям. Выбор определяется с помощью переключателей в группе Список. Возможности манипуляций зависят от полномочий текущего пользователя, указываемого в нижней части окна. Вкладка Смена владельца служит для смены владельца некоторого объекта БД. Новым владельцем может стать отдельный пользователь и группа. Если права владельца передаются учетной записи группы, то права владельца автоматически получают все пользователи этой группы. Возможности операций по смене владельца зависят от полномочий текущего пользователя. Установку защиты базы данных на уровне пользователя можно выполнить с помощью Мастера защиты. Результат защиты – создание новой защищенной БД. Для вызова Мастера защиты следует открыть БД и выполнить команду Сервис | Защита | Мастер. Исходная БД при этом остается без изменения и, если не нужна, ее можно удалить. Процедура снятия защиты на уровне пользователей включает два этапа: 1) предоставление группе Users полных прав на доступ к объектам базы данных; 2) изменение владельца базы данных – предоставление права владения пользователю Admin. Чтобы снять защиту необходимо выполнить следующие действия: 1) Запустить Microsoft Access, открыть защищенную базу данных и подключиться к системе в качестве администратора (члена группы Admins). 2) Предоставить группе Users полные права на доступ ко всем объектам базы данных. 3) Закрыть базу данных и Access. 4) Запустить Microsoft Access. 5) Создать новую базу данных и зарегистрироваться под именем Admin. 6) Импортировать в новую базу данных все объекты из защищенной базы данных с помощью команды Файл | Внешние данные | Импорт. 7) Удалить пароль пользователя Admin, если текущий файл рабочей группы будет использоваться в дальнейшем. Если в дальнейшем будет использоваться стандартный файл рабочей групп system.mdw, то в этом нет необходимости. Замечания: Система защиты Access позволяет создавать произвольное число групп пользователей, но создавать большое число групп не стоит. Права доступа пользователей лучше назначать на уровне групп. Это упрощает использование системы защиты для администратора и пользователей. 7.2.3. Шифрование баз данных Средства шифрования в Access позволяют кодировать файл БД таким образом, что она становится недоступной для чтения из других программ, в которых известен формат БД Access. Шифровать незащищенную паролем базу данных большого смысла нет, так как дешифровать БД может любой пользователь на этой или другой ПЭВМ, где установлена система Access. Более того, пользователь может открыть и использовать зашифрованную БД как обычную незашифрованную. Для шифрования/дешифрования базы данных требуется выполнить следующие действия: Запустить Microsoft Access без открытия базы данных. Важно! Нельзя зашифровать или дешифровать открытую базу данных. При работе с сетевой (общей) базой данных операции шифрования и дешифрования не срабатывают, если база данных открыта каким-либо пользователем. В меню Сервис выбрать команду Защита и подкоманду Шифровать/дешифровать. Указать имя базы данных, которую требуется зашифровать или дешифровать, OK. Указать имя, диск и папку для конечной базы данных (рекомендуется шифруемой БД задавать имя, отличное от исходного), OK. Для обычной работы с зашифрованной БД ее не обязательно специально расшифровывать. Система «понимает» и зашифрованную информацию. Следует иметь в виду, что с зашифрованной базой данных Access работает несколько медленнее, поскольку операции шифрования/дешифрования выполняются в реальном масштабе времени. Тесты для самоконтроля  1. Понятия безопасности и целостности базы данных: а) тождественны; б) представляют собой совершенно разные понятия. 2. Под безопасностью БД подразумевается, а) что некий пользователь обладает различными полномочиями при работе с объектами; б) что действия, выполняемые пользователем корректны; в) что пользователям разрешается выполнять некоторые действия. 3. При обязательном подходе доступом к определенному объекту данных обла-дают: а) только пользователи, уровни допуска которых не больше уровня классификации данного объекта; б) любые пользователи; в) только пользователи с соответствующим уровнем допуска. 4. Классы безопасности в порядке повышения безопасности: а) D, C, B, A; б) A, B, C, D; в) все классы безопасности содержат одинаковые требования к безопасности. 5. Под защитой базы данных понимают обеспечение: а) защищенности базы данных против любых угроз с помощью различных средств; б) целостности базы данных; в) доступа разных пользователей к объектам базы данных. 6. Одно из правил безопасности при обязательном управлении доступом гласит: а) пользователь i может модифицировать объект j, если только его уровень допуска больше уровня классификации объекта j; б) пользователь i может модифицировать объект j, если только его уровень допуска равен уровню классификации объекта j; в) пользователь i может модифицировать объект j, если только его уровень допуска не меньше уровня классификации объекта j. 8. ОБЕСПЕЧЕНИЕ ЦЕЛОСТНОСТИ БАЗЫ ДАННЫХ Целостность данных обеспечивается набором специальных предложений, называемых ограничениями целостности. Ограничения целостности представляют собой утверждения о допустимых значениях отдельных информационных единиц и связях между ними. В большинстве случаев ограничения целостности определяются особенностями предметной области (хотя могут отражать и чисто информационные характеристики). Ограничения целостности могут относиться к разным информационным объектам: атрибутам, кортежам, отношениям, связям между ними и тому подобное. Для полей (атрибутов) используются следующие виды ограничений: Тип и формат поля (автоматически допускают ввод только данных определенного типа). Задание диапазона значений. Данное ограничение используется обычно для числовых полей. Различают открытые и закрытые диапазоны: первые фиксируют значение только одной из границ, вторые – обеих границ. Недопустимость пустого поля. Ограничение позволяет избежать появления в БД «ничейных» записей, в которых пропущены какие-либо обязательные данные, например: поле «ФИО» должно обязательно иметь значение, а у поля «ученая степень» значение может отсутствовать. Задание домена. Ограничение позволяет избежать излишнего разнообразия данных, если его можно ограничить, например, значением поля «должность» для преподавателей может быть одно из следующих значений: ассистент, старший преподаватель, доцент, профессор. Проверка на уникальность значения какого-либо поля. Ограничение позволяет избежать записей-дубликатов. Данное ограничение возникает при отображении в базе данных каких-либо объектов, когда уникальное поле является идентификатором объекта; поэтому данное ограничение часто называют ограничением целостности объекта. Приведенная классификация видов ограничений является довольно условной, так задание диапазона также можно считать способом задания домена. Перечисленные выше ограничения определяют проверку значения поля вне зависимости от того, вводится ли это ограничение впервые или корректируется имеющееся в БД значение. Ограничения, используемые только при проверке допустимости корректировки, называют ограничениями перехода. Например, если в БД имеется поле «возраст сотрудника», то при корректировке значение этого поля может только увеличиваться; если в БД имеется поле «год рождения», то на корректировку этого поля должен быть наложен запрет. В случае попытки произвести некорректное исправление должно выдаваться диагностирующее сообщение. Что касается ограничения целостности, относящегося к кортежам, то здесь имеется в виду либо ограничение на значение всей строки, рассматриваемой как единое целое (естественным ограничением является требование уникальности каждой строки таблицы), либо ограничения на соотношения значений отдельных полей в пределах одной строки (например, значение поля «стаж» не должно превышать «возраст»). Существуют ограничения, проверяющие соотношения между записями одной таблицы, например, «год рождения матери» должен быть меньше, чем «год рождения ребенка»; нельзя быть родителем и ребенком одного и того же человека. В качестве примера ограничений, относящихся ко всей таблице, можно привести следующий. Предположим, что фонд заработной платы формируется исходя из величины средней заработной платы одного сотрудника, которая составляет 10 000 р. Тогда в качестве ограничения целостности таблицы может быть задано выражение, указывающее, что среднее значение поля «оклад» должно быть не больше 10 000. Если СУБД не позволяет контролировать какие-либо ограничения целостности, то следует создавать процедуры (программы), позволяющие это делать. Все ограничения, которые были рассмотрены выше, затрагивают информационные единицы в пределах одной таблицы. Кроме такого рода ограничений имеются ограничения, относящиеся к нескольким взаимосвязанным таблицам, например, ограничение целостности связи, которое выражается в том, что значение атрибута, отражающего связь между объектами и являющегося внешним ключом отношения, обязательно должно совпадать с одним из значений атрибута, являющегося ключом отношения, описывающего соответствующий объект. Например, в БД имеются три таблицы: «Преподаватели», «Дисциплины» и таблица, отражающая связь между преподавателями и дисциплинами: код преподавателя в последней из трех таблиц должен соответствовать одному их кодов в таблице «Преподаватели», а код дисциплины – значению соответствующего поля в таблице «Дисциплины». Своеобразным видом ограничения является запрет на обновление. Он может относиться и к отдельному полю, и ко всей записи, и к целой таблице. Например, не могут меняться значения таких полей, как «Дата рождения», «Место рождения»; или пусть имеется таблица «Поощрения» с полями: «Табельный номер сотрудника», «Вид поощрения», «Дата», - в такую таблицу записи могут только добавляться, а изменяться не могут. В рассматриваемом примере наблюдается также ограничение по существованию между таблицей «Поощрения» и таблицей «Сотрудники»: табельный номер в таблице «Поощрения» должен обязательно присутствовать в таблице «Сотрудники»; при удалении записи в таблице «Сотрудники» все связанные с ней записи в таблице «Поощрения» также должны быть удалены. Ограничения целостности разделяют по моменту контроля за соблюдением ограничения – на одномоментные и отложенные. Отложенные ограничения целостности могут не соблюдаться в процессе выполнения какой-либо группы операций, но обязаны быть соблюдены по завершении выполнения этой группы операций. С понятием отложенного ограничения тесно связано понятие транзакции. В системе Microsoft Access транзакция определяется как набор операций, результат которых подтверждается (сохраняется) в том и только том случае, если все операции набора прошли успешно. Если какая-либо из операций транзакции не выполнена, то все выполненные ранее операции отменяются, и данные возвращаются к тому состоянию, которое они имели до начала выполнения транзакции. Примером может служить перевод денег с одного банковского счета на другой, состоящий из двух операций: удаление денег с одного счета и добавление такой же суммы денег на другой счет. Ограничения целостности разделяют по способу задания – на явные и неявные. Неявные ограничения определяются спецификой модели данных и проверяются СУБД автоматически. Неявные ограничения обычно относятся к классу синтаксических ограничений в отличие от семантических ограничений целостности, обусловленных спецификой предметной области. Рассмотренные примеры ограничений целостности относятся к данным пользователя. Понятие же целостности может относиться и к служебной информации. Наряду с понятием целостности БД, может быть введено понятие информационной целостности БнД, заключающееся в обеспечении правильности взаимосвязи всех его информационных компонентов. Резюме. Задание ограничений целостности и их проверка являются важной частью проектирования и функционирования БнД. При проектировании БнД необходимо изучить, какие возможности по контролю целостности предоставляет используемая СУБД. Если СУБД автоматически не поддерживает нужное ограничение, то обеспечение его соблюдения становится заботой проектировщика. Тесты для самоконтроля 1. Утверждения о допустимых значениях отдельных информационных единиц и связях между ними называют: а) ограничениями перехода; б) ограничениями целостности связи; в) ограничениями целостности. 2. Ограничения целостности: а) определяются в основном особенностями предметной области; б) предназначены для отражения чисто информационных характеристик; в) подразумевают, что пользователям разрешается выполнять некоторые действия. 3. Могут не соблюдаться в процессе выполнения какой-либо группы операций, но обязаны быть соблюдены по завершении этой группы операций: а) отложенные ограничения; б) ограничения перехода; в) явные ограничения. 4. К классу синтаксических ограничений относятся: а) ограничения целостности связи; б) неявные ограничения; в) ограничения перехода. 5. Понятие транзакции связано с понятием: а) отложенного ограничения; б) одномоментного ограничения; в) явного ограничения. 6. По способу задания ограничения разделяют: а) на одномоментные и отложенные; б) на синтаксические и семантические; в) на явные и неявные. 7. Обеспечение соблюдения ограничений целостности: а) является заботой пользователя; б) является заботой проектировщика; в) является функцией СУБД. 8. Ограничения целостности являются важной компонентой: а) даталогической модели; б) базы данных; в) инфологической модели. 9. НАСТОЛЬНЫЕ СУБД На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, считаются dBase, Раrаdох, FoxPro и Access. Отмечают также СУБД Microsoft Data Engine – по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server, но предназначенную для использования главным образом в настольных системах и небольших рабочих группах. Сведения о производителях перечисленных выше СУБД представлены в табл. 9.1. Таблица 9.1
Далее каждая из этих СУБД рассматривается в отдельности. 9.1. DBase и Visual dBase Первая промышленная версия СУБД dBase – dBase II появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя, этот продукт приобрел немалую популярность, а с выходом следующих его версий – dBase III и dBase III Рlus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений. Хранение данных в dBase основано на принципе «одна таблица – один файл» (эти файлы обычно имеют расширение *.dbf). МЕМО – поля и ВLОВ – поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase-подобных СУБД, частично совместимых с dBase по форматам данных. Помимо популярного формата данных dBase является родоначальником и некогда популярного семейства языков программирования, получившего название хВаsе. Однако для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами хВаsе. Доступ к этим данным возможен с помощью ОDВС АРI (и соответствующих драйверов) и некоторых других механизмов доступа к данным. После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании, и для имевшейся у нее другой настольной СУБД – Раrаdох. Среди этих возможностей можно отметить специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования ВDЕ АРI и SQL Links. В настоящее время Visual dBase принадлежит компании dBase, Inс. Его версия – Visual dBase 7.5 имеет следующие возможности: средства манипуляции данными dBase и FoxPro всех версий; средства создания форм, отчетов и приложений; средства публикации данных в Internet и создания Web-клиентов; ядро доступа к данным Аdvantage Database Server фирмы Extended Systems и ОDВС - драйвер для доступа к данным этой СУБД; средства публикации отчетов в Web; средства визуального построения запросов; средства генерации исполняемых файлов и дистрибутивов. В настоящее время к Visual dBase в качестве дополнения может быть приобретен компонент dСоnnections, позволяющий осуществить доступ к данным Оracle, Sybase, Informix, МS SQL Server, DB2, InterBase из Visual dBase 7.5 и приложений, созданных с его помощью. Компания DBase, Inс объявила также о проекте dBASE Open Source, целью которого является разработка сообществом пользователей dBase новых компонентов и классов с целью включения их в последующую версию dBase (получившую название dBase 2000). Иными словами, имеется тенденция превращения dBase (или его частей) в некоммерческий продукт с доступными исходными текстами. 9.2. Рarаdох Раrаdох был разработан компанией Аnsa Software, и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Воrland. С июля 1996 года он принадлежит компании Соrеl и является составной частью Соrеl 0ffice Professional. В конце 80-х - начале 90-х годов Раrаdох, принадлежавший тогда компании Воrland International, был весьма популярной СУБД, в том числе и в нашей стране. Принцип хранения данных в Раrаdох сходен с принципами хранения данных в dВаsе – каждая таблица хранится в своем файле (расширение *.db), МЕМО- и ВLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.рх). Однако, в отличие от dBase, формат данных Раrаdох не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Отсутствие «открытости» формата данных имеет свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании «открытых» форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах – все эти сервисы предоставляются Раrаdох, начиная с первых версий этой СУБД. По сравнению с аналогичными версиями dВаsе ранние версии Раrаdох обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QВЕ – Query by Ехаmрlе, средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования РАL (Paradox Аррlication Language). Windows-версии СУБД Раrаdох, помимо перечисленных выше сервисов, позволяют также манипулировать данными других форматов, в частности dВаsе и данными, хранящимися в серверных СУБД. Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Раrаdох как средство разработки приложений и манипуляции данными. Версия данной СУБД – Раrаdох 9, поставляется в двух вариантах – Раrаdох 9 StandaloneEdition и Раrаdох 9 Developer’sEdition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Соrеl Оffice Professional, второй – в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат: средства манипуляции данными Раrаdох и dBase; средства создания форм, отчетов и приложений; средства визуального построения запросов; средства публикации данных и отчетов в Internet и создания Web-клиентов; Cоrеl Web – сервер; ОDВС – драйвер для доступа к данным формата Раrаdох из Windows-приложений; средства для доступа к данным формата Раrаdох из Java-приложений. Помимо этого, Раrаdох 9 Developer’s Edition содержит: Run – time - версию Раrаdох для поставки вместе с приложениями; средства создания дистрибутивов; драйверы SQL Links для доступа к данным серверных СУБД. В последнее время популярность этого продукта как средства разработки несколько снизилась, хотя в мире эксплуатируется еще немало информационных систем, созданных с его помощью. 9.3. Microsoft FoxРrо и Visual FoxРrо FохРrо ведет свое происхождение от настольной СУБД FохВаsе фирмы Fох Software. Впоследствии этот продукт был приобретен компанией Microsoft. Его последние версии (начиная с версии 3.0, выпущенной в 1995 году) получили название Visual FoxPro. С каждой новой версией этот продукт оказывался все более и более интегрирован с другими продуктами Microsoft, в частности с Microsoft SQL Server, - в состав Visual FoxPro в течение нескольких последних лет входят средства переноса данных FoxPro в SQL Server и средства доступа к данным этого сервера из Visual FoxPro и созданных с его помощью приложений. Хотя формат данных FoxPro также модифицировался с каждой новой версией, приобретая такие возможности, как хранение правил ссылочной целостности и некоторых бизнес–правил в самой базе данных, миграции приложений Visual FoxPro на серверные платформы уделялось значительно большее внимание. Версия этого продукта –- Visual FoxPro 6.0 – доступна и отдельно, и как составная часть Microsoft Visual Studio 6.0. Отличительной особенностью этой настольной СУБД от двух рассмотренных выше является интеграция этого продукта с технологиями Microsoft, в частности поддержка СОМ (Component Object Mоdel – компонентная объектная модель, являющаяся основой функционирования 32-разрядных версий Windows и организации распределенных вычислений в этой операционной системе), интеграция с Microsoft SQL Server, возможности создания распределенных приложений, основанных на концепции Windows DNA (Distributed interNet Applications). VisualFoxPro 6.0 предоставляет следующие возможности: средства публикации данных в Internet и создания Web-клиентов; средства создания ASP - компонентов и Web – приложений; средства создания СОМ-объектов и объектов для Microsoft Transaction Server, позволяющих создавать масштабируемые многозвенные приложения для обработки данных; средства доступа к данным серверных СУБД, базирующиеся на использовании OLE DB (набор СОМ - интерфейсов, позволяющий осуществить унифицированный доступ к данным из разнообразных источников, в том числе из нереляционных баз данных и иных источников, например Microsoft Exchange); средства доступа к данным Microsoft SQL Server и Оracle, включая возможность создания и редактирования таблиц, триггеров, хранимых процедур; средства отладки хранимых процедур Microsoft SQL Server; средство визуального моделирования компонентов и объектов, являющиеся составными частями приложения – Visual Modeller; средство для управления компонентами приложений, позволяющее осуществлять их повторное использование. Тенденции развития этого продукта очевидны: из настольной СУБД Visual FoxPro постепенно превращается в средство разработки приложений в архитектуре «клиент/сервер» и распределенных приложений в архитектуре Windows DNA. 9.4. Microsoft Ассеss Первая версия СУБД Ассеss появилась в начале 90-х годов. Это была первая настольная реляционная СУБД для 16-разрядной версии Windows. Популярность Ассеss значительно возросла после включения этой СУБД в состав Microsoft Оffice. В отличие от Visual FoxPro, фактически превратившегося в средство разработки приложений, Ассеss ориентирован в первую очередь на пользователей Microsoft Оffice, в том числе и не знакомых с программированием. Это, в частности, проявилось в том, что вся информация, относящаяся к конкретной базе данных, а именно таблицы, индексы (естественно, поддерживаемые), правила ссылочной целостности, бизнес–правила, список пользователей, а также формы и отчеты хранятся в одном файле, что в целом удобно для начинающих пользователей. Версия этой СУБД – Ассеss 2000 входит в состав Microsoft Office 2000 Рrofessional и Premium, а также доступна как самостоятельный продукт. В состав Ассеss 2000 входят: средства манипуляции данными Ассеss и данными, доступными через ОDВС (последние могут быть «присоединены» к базе данных Ассеss); средства создания форм, отчетов и приложений; при этом отчеты могут быть экспортированы в формат Microsoft Word или Microsoft Excel, а для создания приложений используется Visual Basic for Applications, общий для всех составных частей Microsoft Office; средства публикации отчетов в Internet; средства создания интерактивных Web-приложений для работы с данными (Data Access Pages); средства доступа к данным серверных СУБД через OLE DВ; средства создания клиентских приложений для Microsoft SQL Server; средства администрирования Microsoft SQL Server. Поддержка СОМ в Ассеss выражается в возможности использовать элементы управления АсtiveX в формах и Web-страницах, созданных с помощью Ассеss. В отличие от Visual FoxPro создание СОМ-серверов с помощью Ассеss не предполагается. Иными словами, Microsoft Ассеss может быть использован, с одной стороны, в качестве настольной СУБД и составной части офисного пакета, а с другой стороны, в качестве клиента Microsoft SQL Server, позволяющего осуществлять его администрирование, манипуляцию его данными и создание приложений для этого сервера. Помимо манипуляции данными Microsoft SQL Server, Ассеss 2000 позволяет также в качестве хранилища данных использовать Microsoft Data Engine (MSDE), представляющий собой по существу настольный сервер баз данных, совместимый с Microsoft SQL Server. 9.5. Microsoft Data Engine МSDE представляет собой СУБД, базирующуюся на технологиях Microsoft SQL Server, но предназначенную для использования в настольных системах или в сетевых приложениях с объемом данных до 2 Гбайт и небольшим количеством пользователей. По существу МSDE является облегченной версией Microsoft SQL Server, не содержа-щей средств администрирования, и к настольным СУБД может быть отнесена весьма условно. Базы данных МSDE полностью совместимы с базами данных Microsoft SQL Server и могут при необходимости управляться этим сервером. Как большинство серверных СУБД, эти базы данных поддерживают транзакции, позволяют создавать триггеры и хранимые процедуры (недоступные в базах данных Ассеss), использовать механизмы защиты данных, предоставляемые операционной системой. Помимо этого при большом числе пользователей и большом объеме данных приложения, использующие МSDЕ, отличаются более высокой производительностью, так как обработка запросов происходит внутри процесса, управляющего базой данных, а не внутри клиентского приложения, что позволяет снизить сетевой трафик, связанный с передачей данных от сервера к клиенту. |