Классификация баз данных

Многообразие характеристик и видов баз данных порождает многообразие классификации. Рассмотрим основные виды классификации.

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

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

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

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

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

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

На данный момент файл — серверные СУБД считаются устаревшими.

Примеры: Microsoft Access, Borland Paradox.

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

Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, MySQL,

PostgreSQL.²

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

Модель данных — совокупность структур данных и операций их обработки.

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

иерархические;

сетевые;

реляционные.

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

К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь.

Узел — это совокупность атрибутов данных, описывающих некоторый объект. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне.

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

Уровни Корневой узел

Узлы

Рис. 2. Структура учебной дисциплины (иерархическая база данных)

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

Сетевая (полносвязная) база данных. В сетевой структуре базы данных при тех же основных понятиях иерархической базы данных: узел, уровень, связь — каждый элемент может быть связан с любым другим элементом. Недостатком такой модели данных является высокая сложность и жесткость схемы БД, построенной на ее основе.

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

Каждая реляционная таблица обладает следующими свойствами:

каждый элемент таблицы — один элемент данных;

все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковые характеристики и свойства;

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

порядок следования строк и столбцов может быть произвольным.

Понятие реляционный (relation — отношение) связано с разработками известного американского специалиста в области баз данных Э. Кодда. В основу реляционной базы данных положено понятие алгебры отношения и реляционного исчисления.

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

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

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

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

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

Ключи

Связи между таблицами

Рис. 3. Структура библиотеки (реляционная база данных)

Реляционная база данных является объединением нескольких двумерных таблиц, между которыми установлены связи.

Между записями двух таблиц могут быть установлены следующие основные виды связей:

один к одному — эта связь предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот; например, начальник курса — курс;

один к многим — эта связь предполагает, что одному экземпляру информационного объекта А соответствует 0, 1, 2 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А, например, начальник курса — курсант;

многие к многим — эта связь предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1, 2 или более экземпляров объекта В и наоборот, например, учебная дисциплина — курсант.

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

При этом должен выполняться принцип нормализации:

в одной и той же таблице не может находиться повторяющихся полей;

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

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

изменение значения любого не ключевого поля не должно влиять на информацию в других полях.

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

Общие положения

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

1. под безопасностью подразумевается, что пользователям разрешается выполнять некоторые действия;

2. под целостностью подразумевается, что эти действия выполняются корректно.

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

Среди многочисленных аспектов проблемы безопасности необходимо отметить следующие:

1. Правовые, общественные и этические аспекты (имеет ли право некоторое лицо получить запрашиваемую информацию, например об оценках студента).

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

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

4. Вопросы реализации управления (например, если используется метод доступа по паролю, то, как организована реализация управления и как часто меняются пароли).

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

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

7. И, наконец, некоторые вопросы, касающиеся непосредственно самой системы управления базами данных (например, существует ли для базы данных некоторая концепция предоставления прав владения данными).

Методы обеспечения безопасности

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

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

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

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

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

Во — вторых. Очевидно, должны быть некоторые средства регулирования запросов доступа по отношению к соответствующим правилам безопасности. (Здесь под «запросом, доступа» подразумевается комбинация запрашиваемой операции, запрашиваемого, объекта и запрашивающего пользователя.) Такая проверка выполняется подсистемой безопасности СУБД, которая также называется подсистемой полномочий.

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

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

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