Лекционный комплекс модуль Базы данных и субд глоссарий бд база данных, поименованная совокупность структурированных данных субд icon

Лекционный комплекс модуль Базы данных и субд глоссарий бд база данных, поименованная совокупность структурированных данных субд


Смотрите также:
Опираются на единый устоявшийся комплекс основных понятий. Рассмотрим эти понятия...
Программа дисциплины «Базы данных»...
Тема «Основные термины и понятия»...
Системы управления базами данных (субд). Функции субд базы данных (БД)...
Методика выполнения работы Введение в базы данных и Microsoft Access База данных (БД)...
Реферат на тему: Access. Базы данных...
Учебная программа по дисциплине базы данных и субд дорохина Т. В., Скуратовская О. Г...
Управление транзакциями в системах баз данных Понятие транзакции...
Гис-технологии в экологии...
Вопросы к государственному меж...
Вопросы к государственному междисциплинарному...
Лекция №1: Стандарты языка sql...



Загрузка...
страницы: 1   2   3   4   5   6
вернуться в начало
скачать
^

Объектно-ориентированные базы данных.

  • Объектно-реляционные методы

  • Реляционные базы данных.


  • Реляционная технология

  • Объектная модель данных

  • Связь базы данных с объектным программированием

  • Реляционный доступ

  • Основные концепции объектной технологии


    4-лекция. Постреляционная или объектно-реляционная СУБД Cache

    Цель декции: рассмотреть основные понятия СУБД Cache. Преимущества комбинированного доступа к данным

    1. Поняте Cache СУБД

    2. Архитектура постреляционной СУБД Cache

    3. Преимущества комбинированного доступа к данным.

    4. Открытые средства разработки.


    Cache использует многомерные структуры данных, в которых разнородные объектные данные сохраняются естественным образом. Поэтому и доступ к данным становится быстрее, и разработка идет динамичнее.

    Принципиально иной подход реализован в СУБД Cache’ компании InterSystems Corp., которая поддерживает и объектный, и реляционный доступ к данным. При этом объектная модель данных ориентируется на стандарт ODMG 2.0, а реляционная – на стандарт SQL-92. Применение этих двух достаточно устоявшихся стандартов, которые популярны, с одной стороны, при создании чисто объектных систем, а с другой – реляционных, позволяет извлечь преимущества обоих подходов. Обе модели данных опираются непосредственно на оригинальную внутреннюю многомерную структуру данных и максимально синхронизированы друг с другом.

    Если коротко, то уникальность технологии Cache’ заключается в том, что система автоматически обеспечивает полный доступ к данным через SQL, как только определяется класс объекта базы данных. Таким образом, без каких-либо дополнительных затрат можно немедленно подключить для работы с данными, хранящимися в Cache’, инструменты на основе SQL, при этом производительность их работы даже увеличится за счет оригинальной многомерной структуры хранения данных.

    Возможен также и обратный вариант. При импорте описания реляционной базы данных Cache’ автоматически генерирует интегрированное реляционное/объектное описание данных и немедленно предоставляет доступ к ним, как к объектам, или через SQL.
    Единая архитектура данных Cache’, базирующаяся на словарь данных, синхронизирует оба типа доступа и бесконфликтно объединяет два подхода: реляционный и объектный.

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

    Реляционный доступ к данным осуществляется точно так же, как и в реляционных СУБД.

    Объектный доступ открывает принципиально новые возможности. При объектном доступе данные представляются в виде классов объектов. Объекты несут в себе данные (свойства) и коды (методы), одни объекты могут включать в себя другие объекты и совокупности объектов (свойство может содержать как многочисленные значения, так и множество включенных объектов) Cache’ в отличие от “объектно-реляционных” СУБД поддерживает весь спектр современных концепций объектного программирования, включая инкапсуляцию, встроенные объекты, множественное наследование, полиморфизм и коллекции.

    InterSystems Corp., компания-изготовитель относит свою СУБД Cache’ к постреляционным. Термин “постреляционная СУБД” обозначает в данном случае принадлежность Cache’ к новому поколению СУБД. Имеется в виду не столько аспект времени (Cache’ появилась позже традиционных реляционных систем), сколько ряд технологических аспектов: полный охват Cache’ объектно-ориентированных технологий и единая архитектура данных.

    ^ Архитектура постреляционной СУБД Cache.

    Основные элементы архитектуры СУБД Cache’: платформы, на которых она работает, сервер многомерных данных, три способа доступа к данным, язык описания бизнес-логики Cache’ ObjectScript, интерфейсы к средствам проектирования и разработки приложений и Web-технология Cache’ Server Pages. Далее мы подробно остановимся на всех основных элементах архитектуры.

    ^ Единая архитектура данных. Сервер многомерных данных.

    Cache’ – кроссплатформенная система. Она работает в операционных системах семейства Windows, Linux, основных реализациях Unix и Open VMS. Большое внимание уделяется новой платформе Itanium.

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

    В отличие от ранних многомерных СУБД, которые были созданы и оптимизированы для аналитических систем, Cache’ ориентирована на системы обработки транзакций (Online Transaction Processing). Сервер многомерных данных Cache’ предназначен для обработки транзакций в системах с большими и сверхбольшими БД (сотни гигабайт, терабайты) и большим количеством одновременно работающих пользователей. Сервер многомерных данных Cache’ позволяет получать очень высокую производительность, т.к. Cache’ не хранит избыточные данные и таблицы. Реляционная модель не всегда подходит для описания сложных предметных областей. Модель данных Cache’ позволяет оптимизировать данные на уровне хранения, поддерживать объектную модель и сложные типы данных. Все эти возможности значительно упрощают создание сложных систем.

    В Cache’ реализована концепция Единой архитектуры данных. К одним и тем же данным, хранящимся под управлением сервера многомерных данных Cache’ есть три способа доступа: прямой, объектный и реляционный:

    1. Cache’ Direct Access – прямой доступ к данным, обеспечивающий максимальную производительность критических приложений и алгоритмов и полный контроль со стороны программиста. Появляется возможность работать напрямую со структурами хранения. Использование этого способа доступа предъявляет определенные требования к квалификации разработчиков, но понимание структуры хранения данных в Cache’ позволяет оптимизировать хранение данных приложения и создавать сверхбыстрые алгоритмы обработки данных. 2. Cache’ SQL – реляционный доступ, обеспечивающий максимальную производительность реляционных приложений с использованием встроенного SQL стандарта SQL-92. Кроме него, разработчик может использовать разные типы триггеров и хранимых процедур. Все это позволяет использовать Cache’ и как реляционную СУБД. Даже без использования прямого и объектного доступа приложения на Cache’ работают быстрее традиционных РСУБД за счет высокой производительности сервера многомерных данных.
    3. Cache’ Objects – объектный доступ, обеспечивающий максимальную продуктивность разработки при использовании Java, Visual C++, VB и других ActiveX-совместимых средств разработки, таких как PowerBuilder и Delphi. Как уже отмечалось, объектная модель Cache’ соответствует рекомендациям ODMG. В Cache’ полностью поддерживаются наследование (в том числе и множественное), инкапсуляция и полиморфизм. При создании информационной системы можно использовать объектно-ориентированный подход к разработке, моделируя предметную область в виде совокупности классов объектов, в которых хранятся данные (свойства классов) и поведение классов (методы классов). Cache’, поддерживая объектную модель данных, позволяет естественным образом использовать объектно-ориентированный подход как при проектировании (в Rational Rose, например) предметной области, так и при реализации приложений в ОО-средствах разработки (Java, C++, Delphi, VB). Постреляционная СУБД Cache’ , значительно превосходит “чисто” объектные СУБД по таким показателям как надежность, производительность и удобство разработки.

    Все три способа доступа к одним и тем же данным могут использоваться одновременно в одном и том же приложении, программе. Как только определяется класс объектов, Cache’ автоматически генерирует реляционное описание этих данных так, что к ним можно обращаться, используя SQL. Подобным же образом, при импорте в словарь данных описания реляционной базы данных (DDL-описания), Cache’ автоматически генерирует и объектное описание данных, открывая тем самым доступ к данным как к объектам. При этом все описания данных ведутся согласованно, все операции по редактированию проводятся только над одним экземпляром данных. Кроме того, к тем же данным можно обратиться с помощью прямого доступа.

    ^ Преимущества комбинированного доступа к данным.

    Cache’ позволяет комбинировать три способа доступа к данным, оставляя выбор за разработчиком. При разработке промышленных информационных систем объектный доступ может использоваться при описании бизнес-логики приложения и создания пользовательского интерфейса с помощью объектно-ориентированных средств разработки (VB, Delphi, C++), реляционный доступ – для совместимости с другими системами и интеграции с инструментами построения отчетов и аналитической обработки данных (Seagate Info, Cognos, Busines Objects). Прямой доступ обеспечивает максимальную производительность и может быть использован для реализации таких операций, в которых применение обычных хранимых процедур, основанных на SQL, не может обеспечить необходимую производительность. Использование прямого доступа для реализации подобных операций позволяет увеличить производительность на 1-2 порядка.

    Известны случаи перевода в Cache’ сложных приложений, которые ранее работали под управлением реляционных СУБД. Обычно переход осуществляется следующим образом: сначала существующее приложение с минимальными изменениями переводится под управление Cache’. Приложение на этом этапе работает с Cache’ как с реляционной СУБД, т.е. используется реляционный доступ Cache’-SQL. В результате, даже в этом случае, система начинает работать быстрее. Далее ряд операций может быть переписан, с использованием прямого способа доступа к БД. На этом этапе обычно удается увеличить производительность критических операцийв десятки и сотни раз.

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

    ^ Открытые средства разработки.

    Для реализации бизнес-логики в СУБД Cache’ используется Cache’ Object Script (COS). COS – полнофункциональный язык, который имеет все необходимые механизмы для работы с данными с помощью любого способа доступа. С помощью COS создаются методы классов, триггеры, хранимые процедуры, различные служебные программы.

    СУБД Cache’ – открытый продукт, который имеет набор интерфейсов, позволяющих разработчику использовать вместе с Cache’ любые современные технологии. Во-первых, стоит отметить интерфейсы со средствами проектирования и разработки приложений. Специальные компоненты Cache’ позволяют проектировать приложения в Rational Rose при объектном подходе, и в ErWin – при реляционном.

    Поддерживаются также следующие интерфейсы: Native C++, Java, EJB, ActiveX, XML, интерфейсы CallIn и CallOut .

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

    В Cache’ реализована полноценная поддержка XML. Cache’ не хранит XML-документы в текстовых файлах, Memo-полях или реляционных таблицах. Полная поддержка Cache’ объектной модели позволяет автоматически трансформировать сложные XML-документы в классы объектов Cache’. Из описания классов объектов Cache’ можно получить описания документов, а сами объекты Cache’ проецируются в XML-документы. С помощью Cache’ Server Pages (CSP), Web-технологии Cache’, можно генерировать не только HTML страницы, но и страницы с XML-содержанием.
    Таким образом, появляется возможность использовать XML с Cache’ как для обмена информацией между различными информационными системами, так и для реализаций приложений электронной и мобильной коммерции (WAP).

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

    База данных — это структурированная совокупность данных различных типов. Понятие базы данных очень обширное — к нему можно отнести даже совокупность обычных текстовых файлов, информация в которых хранится в определенном формате. В качестве простого примера базы данных можно также привести список сотрудников, состоящий из трех столбцов — фамилии, имени и отчества, хранимый в виде электронной таблицы (например, в формате Microsoft Excel). Тем не менее,

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

    • Локальные базы данных. Размещаются на локальном диске компьютера или в локальной сети. При совместном обращении к ним нескольких пользователей, для организации механизма блокировки доступа, используется файловая система. К таким базам данных относятся Paradox, dBase и FoxPro. Приложения, взаимодействующие с локальными базами данных, называются одноуровневыми, потому что они находятся в одной файловой системе с базой данных.

    • Серверы баз данных. Такие базы данных могут размещаться на отдельном компьютере (иногда они даже распределены между несколькими серверами). Серверы баз данных отличаются друг от друга способом хранения информации, однако все они для организации взаимодействия с пользователями используют один обобщенный язык, называемый SQL (Structured Query Language — язык структурированных запросов). По этой причине серверы баз данных также называют SQL-серверами. Приложения, подключающиеся к SQL-серверам, называются многоуровневыми, потому что такие приложения и базы данных могут функционировать в различных системах (на различных уровнях). Кроме основного набора команд SQL, большинство серверов баз данных используют дополнительные команды. В результате каждому серверу соответствует собственный "диалект" языка SQL

    ПРИМЕЧАНИЕ .

    Язык SQL применяется также и при работе с локальными базами данных, однако при этом SQL-команды выполняются гораздо медленнее, чем в случае с SQL-серверами (особенно при обработке больших объемов данных}. Это объясняется тем, что серверы баз данных выполняют анализ SQL-команд и определяют оптимальный способ обработки или выбора данных, а в случае с локальными базами данных подобный анализ SQL-команд не выполняется. По этой причине при разработке приложений, ориентированных на работу с базами данных Paradox, dBase и FoxPro, язык SQL используется только в тех случаях, когда другие способы реализации поставленной программной задачи менее эффективны, чем использование SQL. В отличие от локальных баз данных, работа с SQL-серверами полностью основана на использовании команд языка SQL. К SQL-серверам относятся, например, такие серверы: InterBase, Oracle, Sybase, Informix, Microsoft SQL Server и DB2.

    Выбор типа базы данных.

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

    Прежде, чем двигаться дальше, дадим определение таким основополагающим терминам, как таблица, строка и столбец.

    Таблица (table) — это набор строк в базе данных, объединенных по некоторому критерию. Например, одна таблица может использоваться для хранения информации о заказах, а вторая — о клиентах.

    Строка (row) — это одна запись таблицы. Например, в одной строке таблицы заказов может храниться информация об одном заказе.

    Столбец (column) — это поле (или атрибут), которое содержится s строке таблицы. Например, в таблице заказов может быть столбец с номерами заказов и столбец с фамилиями клиентов. Таким образом, можно сказать, что строка такой таблицы содержит поле номера и поле фамилии.

    При выборе типа базы данных следует учитывать такие факторы.

    • Количество пользователей, одновременно подключенных к базе данных.

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

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

    • Необходимость использования средств администрирования. Для поддержки локальных баз данных требуется меньше ресурсов, чем для администрирования SQL-серверов. Кроме того, их проще сопровождать.

    • Потребность в надежной системе безопасности. Базы данных часто содержат конфиденциальную информацию, которая требует применения средств защиты. Локальные базы данных, подобные Paradox и dBASE, обеспечивают защиту только на уровне таблицы или поля. В отличие от них, большинство SQL-серверов применяют защиту на уровне всей базы данных. В этом случае права доступа к таблицам определяются при обращении пользователя к базе данных по его имени и паролю.

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

    . Таблицы базы данных не будут содержать десятки тысяч строк информации.

    • К базе данных будет подключаться небольшое количество пользователей.

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

    Работа с локальными базами данных.

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

    Приложения, созданные с помощью Delphi, обращаются к локальным базам данных через систему Borland Database Engine (BDE). Система BDE устанавливается вместе с Delphi. Через BDE можно организовать доступ и к SQL-серверам, но в Delphi 7 для этого лучше использовать новые специализированные средства В тех приложениях, которые ориентированы на работу с локальными таблицами, используются компоненты с вкладки BDE.

    Понятие "запрос". Его определение вытекает из его названия. Запрос (query) — это команда на языке SQL, которая передается в базу данных с целью извлечения специфической информации или внесения изменений. По той причине, что запросы основаны на использовании языка SQL, они часто называются SQL-запросами. Запросы могут возвращать наборы строк, которые еще называют наборами данных (dataset). Такие запросы формируются при помощи команды SQL select. Существуют также запросы, которые используются для создания различных элементов базы данных (команды SQL, которые начинаются со слова create), для изменения данных (команда SQL update), для вставки строк в таблицы (команда SQL insert), для удаления записей (команда SQL delete) и т.д. Такие запросы не возвращают наборов данных.

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

    Обратите внимание на элемент под названием "Псевдоним BDE". Псевдоним (от английского слова alias) — это набор параметров, определяющих метод подключения средств BDE к определенной базе данных. Для создания псевдонима необходимо воспользоваться отдельным приложением BDE Administrator или средством Delphi — SQL Explorer. Для того чтобы понять смысл псевдонимов, рассмотрим следующий пример. Предположим, в каталоге c:\Mybase расположена база данных Paradox, состоящая из нескольких таблиц. В базах данных Paradox таблицы хранятся в виде отдельных файлов с расширением .db. Предположим, что в данном случае база данных состоит из двух таблиц: Tablel.db и ТаЫе2 .db. У компонента Table, который используется в приложениях Delphi для доступа к таблицам, есть свойство DatabaseName. Это свойство указывает расположение базы данных, к которой принадлежит таблица, а имя самой таблицы указывается в свойстве TableName. Если свойству DatabaseName присвоить значение C:\MyBase, а свойству TableName — значение Tablel.db, то приложение будет работать нормально до тех пор, пока вся база данных или файл Tablel.db не будут перенесены в другой каталог. После этого придется перекомпилировать приложение с новым значением свойства Table.DatabaseName. Псевдонимы позволяют избежать подобных проблем. При помощи средств BDE Administrator или SQL Explorer можно создать псевдоним (например, МуВазе) типа Paradox, для которого параметр Path (путь) будет иметь значение С:\MyBase. После этого в приложении для свойства Table. DatabaseName можно указать значение МуВазе, и теперь при смене места расположения базы данных отпадает необходимость в изменении и перекомпиляции приложения — новый путь указывается в качестве значения параметра Path в программах BDE Administrator или SQL Explorer, Таким образом, можно назвать эти две программы средствами администрирования локальных баз данных.



    ^ Рис. З.1. Доступ к локальным базам данных в Delphi 7


    В качестве примера рассмотрим базу данных “Avto”, в котором имеются поля: марка автомобиля, цвет, год выпуска, страна, цена. Нужно организовать автоматизированное место работы бизнесмена по продаже автомобилей и вести всевозможные переговоры и договора по продаже авто предусматривающее особенность каждого клиента. Для этого понадобится создать нужную базу данных, запросы клиентов на различные авто, передача информации клиентам и заключить с ними договора. При передачи информации об автомобиле, которой заинтересовался клиент иногда возникают затруднения: клиенты могут жить в цивилизованном городе или в провинции, могут иметь компьютер с нужными для принятия информации программы или не иметь. Иногда клиентам легко передавать данные по факсу или по сети, где требуется импортирование и экспортирование данных. Существуют несколько видов импортирования и экспортирования данных: это - импортирование, экспортирование и связывание внешних файлов в Access, импорт файлов FoxPro, экспорт в электронную таблицу или в файлы dBASE, Paradox, FoxPro, экспорт данных в файл HTML, экспорт базы данных среды Delphi в текстовый редактор.

    Вопросы для самопроверки:

          1. Как ведется обработка данных в СУБД Cache?

          2. Преимущества и недостатки СУБД Cache?

          3. Локальные СУБД?

          4. Серверные СУБД?

          5. Получение доступа к данным в СУБД разных архитектур?

          6. Понятие запроса?

          7. Понятие импортирования и экспортирования данных?


    Лекция – 5. Информационная безопасность систем управления базами данных

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


            1. Идея защиты баз данных

            2. Аспекты аутентификации и управления доступом в СУБД

            3. Управление доступом

            4. Привилегии безопасности, доступа

            5. Ограничения и правила

            6. Угрозы, специфичные для СУБД. Получение информации путем логических выводов


    Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в "Критериях оценки надежных компьютерных систем".

    Основы стандартов в области безопасности информационных систем были заложены "^ Критериями оценки надежных компьютерных систем". Этот документ, изданный в США в 1983 году национальным центром компьютерной безопасности (NCSC - National Computer Security Center), часто называют Оранжевой Книгой.

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

    Иерархия уровней безопасности, приведенная в Оранжевой Книге, помечает низший уровень безопасности как D, а высший - как А.

    • В класс D попадают системы, оценка которых выявила их несоответствие требованиям всех других классов.

    • Основными свойствами, характерными для С-систем, являются: наличие подсистемы учета событий, связанных с безопасностью, и избирательный контроль доступа. Уровень С делится на 2 подуровня: уровень С1, обеспечивающий защиту данных от ошибок пользователей, но не от действий злоумышленников, и более строгий уровень С2. На уровне С2 должны присутствовать средства секретного входа, обеспечивающие идентификацию пользователей путем ввода уникального имени и пароля перед тем, как им будет разрешен доступ к системе. Избирательный контроль доступа, требуемый на этом уровне позволяет владельцу ресурса определить, кто имеет доступ к ресурсу и что он может с ним делать. Владелец делает это путем предоставляемых прав доступа пользователю или группе пользователей. Средства учета и наблюдения (auditing) - обеспечивают возможность обнаружить и зафиксировать важные события, связанные с безопасностью, или любые попытки создать, получить доступ или удалить системные ресурсы. Защита памяти - заключается в том, что память инициализируется перед тем, как повторно используется. На этом уровне система не защищена от ошибок пользователя, но поведение его может быть проконтролировано по записям в журнале, оставленным средствами наблюдения и аудитинга.

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

    • Уровень А является самым высоким уровнем безопасности, он требует в дополнение ко всем требованиям уровня В выполнения формального, математически обоснованного доказательства соответствия системы требованиям безопасности. Этот уровень используется в системах управления ядерными устройствами. А-уровень безопасности занимает своими управляющими механизмами до 90% процессорного времени.

    ^ Аспекты аутентификации и управления доступом в СУБД

     

    Пользователей СУБД можно разбить на три категории:

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

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

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

    Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Например, в случае СУБД Oracle оператор CONNECT имеет следующий вид:

    CONNECT пользователь[/пароль] [@база_данных];

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

     

    ^ Управление доступом

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

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

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

    Привилегии в СУБД можно подразделить на две категории: привилегии безопасности и привилегии доступа.

    ^ Привилегии безопасности.

    Привилегии безопасности позволяют выполнять административные действия и всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания или изменения характеристик. Таких привилегий пять:

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

    • createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.

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

    • maintain_locations - право на управление расположением баз данных и операционной системы.

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

    ^ Привилегии доступа

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

    Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся:

    • таблицы и представления

    • процедуры

    • базы данных

    • сервер баз данных

    • события

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

    SELECT

    право на выборку данных

    INSERT

    право на добавление данных

    DELETE

    право на удаление данных

    UPDATE

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

    REFERENCES

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

    Средства управления доступом СУБД позволяют реализовать следующие виды ограничения доступа:

    • операционные ограничения

    • ограничения по значениям (за счет механизма представлений);

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

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

    На иерархию привилегий можно посмотреть и с другой точки зрения. Каждый пользователь, помимо, собственных, имеет привилегии PUBLIC. Кроме этого, он может входить в различные группы и запускать приложения с определенными ролями. Иерархия авторизации выглядит для СУБД следующим образом:

    • роль (высший приоритет);

    • пользователь;

    • группа;

    • PUBLIC (низший приоритет).

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

    Ограничения

    Средства управления доступом СУБД позволяют реализовать следующие виды ограничения доступа:

    • операционные ограничения

    • ограничения по значениям (за счет механизма представлений);

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

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

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

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

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

    Правила

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

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

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

     

    ^ Угрозы, специфичные для СУБД

     

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

    ^ Получение информации путем логических выводов

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

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

    Рассмотрим базу данных, состоящую из одной таблицы с двумя столбцами: имя пациента и диагноз. Предполагается, что имя является первичным ключом. Каждая из строк таблицы относится к одному из двух уровней секретности - высокому (HIGH) и низкому (LOW). Соответственно, и пользователи подразделяются на два уровня благонадежности - высокий и низкий. К высокому уровню секретности относятся сведения о пациентах, находящихся под надзором правоохранительных органов или страдающих специфическими заболеваниями. На низком уровне располагаются данные о прочих пациентах, а также информация о некоторых "секретных" пациентах с "маскировочным" диагнозом.

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

    Дезинформирующих строк о секретных пациентах они видеть не должны:

    Имя

    Диагноз

    Иванов

    СПИД

    Ивлев

    Рак легких

    Иванов

    Пневмония

    Петров

    Сифилис

    Сидоров

    Стреляная рана

    Ярцев

    Ожог второй степени

    Суворов

    Микроинфаркт

     

    ^ Агрегирование данных

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

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

    ^ Средства поддержания высокой готовности

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

     

    Вопросы для самопроверки

     1.      Иерархия уровней безопасности документа «Критерии оценки надежных компьютерных систем»

    2.      Категории пользователей СУБД

    3.      Способы идентификации пользователей СУБД

    4.      Носители привилегий

    5.      Категории привилегий

    6.      Назначение привилегий безопасности

    7.      Назначение привилегий доступа

    8.      Иерархия привилегий

    9.      Назначение метки безопасности и ее компоненты

    10. Условия получения доступа к данным в случае использования механизма метки безопасности

    11. Назначение ограничений и виды ограничений

    12. Правила

    13. Угрозы, специфичные для СУБД

    14. Агрегирование информации

     


    Лекция – 6. Основы работы с базами данных в среде Delphi7

    Цель лекции: Рассмотреть основные подходы создания и обработки баз данных в среде Delphi7

    ^ Основные функции СУБД 5

    Требования к базам данных 31

    Основные концепции реляционных баз данных 32

    Алиасы 39

    Системная информация утилиты настройки BDE (BDECFG) 42

    Установка драйверов ODBC и других драйверов 45

    Сразу оговоримся, что мы будем рассматривать только реляционные базы данных: во-первых, реляционные базы получили наибольшее распространение в мире; во-вторых, они наиболее “продвинуты” в научном плане; а в-третьих, ядро баз данных Borland Database Engine, на основе которого работают все последние продукты компании Borland, предназначено именно для работы с реляционными базами данных.

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

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




    оставить комментарий
    страница4/6
    Дата31.03.2012
    Размер0,86 Mb.
    ТипДокументы, Образовательные материалы
  • Добавить документ в свой блог или на сайт

    страницы: 1   2   3   4   5   6
    отлично
      1
    Ваша оценка:
    Разместите кнопку на своём сайте или блоге:
    rudocs.exdat.com

    Загрузка...
    База данных защищена авторским правом ©exdat 2000-2017
    При копировании материала укажите ссылку
    обратиться к администрации
    Анализ
    Справочники
    Сценарии
    Рефераты
    Курсовые работы
    Авторефераты
    Программы
    Методички
    Документы
    Понятия

    опубликовать
    Загрузка...
    Документы

    наверх