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

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

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

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

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

Преимущества протоколов удаленного вызова процедур

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

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

Типичные распределения функций между клиентами и серверами

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

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

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

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

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

Распределенные базы данных

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

1) простота использования системы;

2) возможности автономного функционирования, при нарушении связанности сети;

Разновидности распределенных систем

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

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

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

1) легкость использования системы;

2) возможность автономного функционирования при нарушении связности сети;

3) высокая степень эффективности.

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

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

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

Распределенная компиляция запросов

Запросы на языке SQL до своего реального выполнения могут подвергаться компиляции. Компиляция запросов может производиться на стадии предкомпиляции прикладной программы, написанной на обычном традиционном языке программирования с включением предложений SQL, или в процессе выполнения транзакций с использованием инструкции языка SQL. С точки зрения пользователя процесс компиляции приводит к следующим результатам: для каждого предложения на SQL образуется программа в машинных кодах, вызовы которой помещаются в текст исходной прикладной программы, однако в действительности процесс компиляции запроса намного более сложен из-за наличия сложных сетевых взаимодействий, которые требуются при реальном выполнении транзакции. Будем называть главным узлом сети тот узел, в котором инициирован процесс компиляции предложений SQL, и дополнительными узлами (те узлы, которые вовлекаются в этот процесс в ходе его выполнения). На самом грубом уровне процесс компиляции можно разбить на следующие стадии:

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

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

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

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

1.1. Основные понятия серверов и их классификация. 2

1.2. Аппаратное обеспечение. 9

2. Базы данных. 12

2.1. Понятие базы данных (БД) 12

2.2. Понятие системы управления базами данных (СУБД) 14

2.3. Классификация СУБД.. 17

1.1 Основные понятия серверов и их классификация

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

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

2. Сервер (программное обеспечение) - программное обеспечение принимающее запросы от клиентов (в архитектуре клиент-сервер).

3. Сервер (аппаратное обеспечение) - компьютер (или специальное компьютерное оборудование) выделенный и/или специализированный для выполнения определенных сервисных функций.

3.Сервер в информационных технологиях - программный компонент вычислительной системы, выполняющий сервисные функции по запросу клиента , предоставляя ему доступ к определённым ресурсам.

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

Понятия сервер и клиент и закрепленные за ними роли образуют программную концепцию «клиент-сервер ».

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

Формат запросов клиента и ответов сервера определяется протоколом. Спецификации открытых протоколов описываются открытыми стандартами, например протоколы Интернета определяются в документах RFC.

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

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

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

· inetd от англ. i nternet super- server d aemon демон сервисов IP - стандартное средство UNIX-систем - программа, позволяющая писать серверы TCP/IP (и сетевых протоколов других семейств), работающие с клиентом через перенаправленные inetd потоки стандартного ввода и вывода (stdin и stdout).

· RPC от англ. R emote P rocedure C all удаленный вызов процедур - система интеграции серверов в виде процедур доступных для вызова удаленным пользователем через унифицированный интерфейс. Интерфейс изобретенный Sun Microsystems для своей операционной системы (SunOS, Solaris; Unix-система), в настоящее время используетстся как в большинстве Unix-систем, так и в Windows.

· Прикладные клиент-серверные технологии Windows:

o (D -)COM (англ. ( D istributed) C omponent O bject M odel - модель составных объектов) и др. - Позволяет одним программам выполнять операции над объектами данных используя процедуры других программ. Изначально данная технология предназначена для их «внедрения и связывания объектов» (OLE англ. O bject L inking and E mbedding ), но, в общем, позволяет писать широкий спектр различных прикладных серверов. COM работает только в пределах одного компьютера, DCOM доступна удаленно через RPC.

o Active-X - Расширение COM и DCOM для создания мультимедиа-приложений.

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

Большинство внутренних и сетевых специфических серверов Windows работают через универсальные серверы (RPC, (D-)COM).

Сетевые службы обеспечивают функционирование сети, например серверы DHCP и BOOTP обеспечивают стартовую инициализацию серверов и рабочих станций, DNS - трансляцию имен в адреса и наоборот.

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

Серверы AAA и Radius обеспечивают в сети единую аутентификацию, авторизацию и ведение логов доступа.

Информационные службы. К информационным службам можно отнести как простейшие серверы сообщающие информацию о хосте (time, daytime, motd), пользователях (finger, ident), так и серверы для мониторинга, например SNMP. Большинство информационных служб работают через универсальные серверы.

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

Файл-серверы представляют собой серверы для обеспечения доступа к файлам на диске сервера.

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

Другие серверы позволяют монтировать дисковые разделы сервера в дисковое пространство клиента и полноценно работать с файлами на них. Это позволяют серверы протоколов NFS и SMB. Серверы NFS и SMB работают через интерфейс RPC.

Недостатки файл-серверной системы:

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

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

Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.

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

Серверы доступа к данным обслуживают базу данных и отдают данные по запросам. Один из самых простых серверов подобного типа - LDAP (англ. Lightweight Directory Access Protocol - облегчённый протокол доступа к спискам).

Для доступа к серверам баз данных единого протокола не существует, однако все серверы баз данных объединяет использование единых правил формирования запросов - язык SQL (англ. Structured Query Language - язык структурированных запросов).

Службы обмена сообщениями позволяют пользователю передавать и получать сообщения (обычно - текстовые).

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

Для организации конференций существует серверы новостей, работающие по протоколу NNTP.

Для обмена сообщениями в реальном времени существуют серверы чатов, стандартный чат-сервер работает по протоколу IRC - распределенный чат для интернета. Существует большое количество других чат-протоколов, например ICQ или Jabber.

Серверы удаленного доступа

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

Для обеспечения доступа к командной строке служат серверы telnet, RSH, SSH.

Графический интерфейс для Unix-систем - X Window System, имеет встроенный сервер удаленного доступа, так как с такой возможностью разрабатывался изначально. Иногда возможность удаленного доступа к интерфейсу Х-Window неправильно называют «X-Server» (этим термином в X-Window называется видеодрайвер).

Настольные СУБД

Краткий обзор СУБД

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

К ним относятся dBase III – PLUS (фирма Achton-Tate), Clipper (фирма Nantucket Inc.), FoxPro (фирма Fox Software), FoxBase+ (фирма Fox Software), Visual FoxPro (фирма Microsoft), СУБД PARADOX (фирма Borland International), Microsoft Access (фирма Microsoft).

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

Основными производителями таких систем обработки и хранения данных являются 3 корпорации: Oracle, Microsoft и IBM. Диаграмма соотношения объемов продаж соответствующих систем (источник: IDC Report, Май 2006) приводится на рис. 3.4.

Рис. Продажи ПО систем хранения данных в мире

Наиболее распространенными клиент-серверными системами здесь соответственно являются системы Oracle (разработчик компания Oracle), MS SQL Server (разработчик компания Microsoft), DB2 , Informix Dynamic Server (компания IBM).

Архитектура "файл-сервер" Работа построена следующим образом :

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

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

· На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.

· Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя всœе сведения о физической структуре БД, расположенной на файловом сервере.

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

· При крайне важности (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.

· Результат СУБД возвращает в приложение.

Архитектура "клиент – сервер". Итак, в результате работа построена следующим образом:

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

· На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, ᴛ.ᴇ. по сети от клиента к серверу передается лишь текст запроса.

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

· Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Рассмотрим, как выглядит разграничение функций между сервером и клиентом.

· Функции приложения-клиента:

o Посылка запросов серверу.

o Интерпретация результатов запросов, полученных от сервера.

o Представление результатов пользователю в некоторой форме (интерфейс пользователя).

· Функции серверной части:

o Прием запросов от приложений-клиентов.

o Интерпретация запросов.

o Оптимизация и выполнение запросов к БД.

o Отправка результатов приложению-клиенту.

o Обеспечение системы безопасности и разграничение доступа.

o Управление целостностью БД.

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

Трехзвенная (многозвенная) архитектура "клиент – сервер". в результате работа построена следующим образом:

· База данных в виде набора файлов находится на жестком диске специально выделœенного компьютера (сервера сети).

· СУБД располагается также на сервере сети.

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

· Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.

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

· Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, ᴛ.ᴇ. по сети от сервера приложений к серверу БД передается лишь текст запроса.

· СУБД инкапсулирует внутри себя всœе сведения о физической структуре БД, расположенной на сервере.

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

· Сервер приложений возвращает результат в клиентское приложение (пользователю).

· Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

18.03.2014

Источник: Журнал "Технологии Защиты" № 1, 2014

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

Терминология

Частая ошибка многих специалистов по безопасности - некорректное использование термина «база данных» (БД) вместо термина «система управления базами данных» (СУБД). Давайте разберёмся, что к чему.

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

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

То есть, упрощённо, «база данных» – это сами данные, представленные в виде совокупности файлов на дисках, с которыми как раз работает «система управления базами данных» (СУБД) – программный продукт, имеющий средства для создания, наполнения, модификации и поиска по базам данных.

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

Требования к СУБД, применяемым в СКУД

Какие же особенные требования следует предъявить к СУБД, используемой в СКУД с точки зрения пользователя?

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

Виды СУБД

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

Способ доступа к БД:

1. Клиент-серверные СУБД
2. Файл-серверные СУБД
3. Встраиваемые СУБД

В клиент-серверных СУБД (Microsoft SQL Server, Oracle, Firebird, PostgreSQL, InterBase, MySQL и др.) вся обработка данных ведётся в одном месте, на сервере, в том же месте, где хранятся (обычно) данные, при этом к файлам данных имеет доступ только один сервер, одна система - это сама СУБД. Приложения-клиенты при этом посылают запросы на обработку и получение данных из СУБД и получают ответы; приложения-клиенты не имеют непосредственного доступа к файлам данных. Все промышленные СУБД на данный момент являются именно клиент-серверными.

В файл-серверных СУБД (Paradox, Microsoft Access, FoxPro, dBase и др.), наоборот, приложения имеют общий доступ ко всем файлам базы данных (хранящимся обычно в каком-то разделяемом файловом хранилище) и совместно обрабатывают эти данные. Каждое приложение самостоятельно обрабатывает данные. На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах - недостатком. Проблема в том, что файл-серверные СУБД не имеют многих преимуществ клиент-серверных, таких как: кэширование данных, параллелизм запросов, высокая производительность и обладают рядом недостатков (сложности с поддержанием целостности базы, восстановлением, блокировками и т.д.), что приводит в свою очередь к пониженной надёжности и производительности. Состояние базы в файловых СУБД необходимо постоянно отслеживать и проводить операции по её «лечению» с помощью встроенных или сторонних утилит.

Встраиваемые СУБД (SQLite, Firebird Embedded, Microsoft SQL Server Compact и др.) поставляются в составе готового программного продукта, не требуя процедуры самостоятельной установки. Встраиваемые СУБД предназначены для локального хранения данных приложения и не рассчитаны на коллективное использование в сети. К примеру, встраиваемая бесплатная СУБД SQLite широко используется в известной мобильной ОС Android, разработанной в компании Google, и во многих мобильных приложениях.

Схема лицензирования:

1. Бесплатные СУБД
2. Коммерческие промышленные СУБД (большинство производителей предлагают также бесплатную ограниченную версию)

Файл-серверные и встраиваемые СУБД практически все являются бесплатными, из бесплатных клиент-серверных СУБД наиболее известные: Firebird, PostgreSQL и MySQL.

Чисто коммерческий продукт, разработанный компанией Borland: СУБД InterBase. Ранее у этой СУБД была бесплатная версия с открытым исходным кодом: InterBase 6.0, но проект InterBase 6.0 Open Source Edition перестал поддерживаться компанией Borland. В 2001 году группа энтузиастов создала отдельный Open source проект СУБД Firebird, упомянутой выше, который получил широкую известность и множество поклонников среди разработчиков.

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

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

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

Плюсы коммерческих СУБД: хорошая задокументированность, высокая производительность, масштабируемость, надёжность, поддерживаемость, наличие встроенных инструментов для разработки и администрирования. Вероятность того, что компания Oracle, Microsoft или IBM перестанут поддерживать свои системы, стремится к нулю.

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

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

Компания-производитель	Бесплатные версии	Ограничения
Microsoft	SQL Server 2005 Express Edition (2005, 2008, 2008 R2, 2012)	Размер базы данных - до 4 Гб, количество баз не ограничено, использует не более 1 Гб оперативной памяти и только 1 процессор (ядро) на многопроцессорных и многоядерных машинах. Поддерживаемые платформы: только Windows 2005 – только x86, 2008 – x86 и x64.
	SQL Server 2008 Express Edition
	SQL Server 2008 R2 Express Edition	Размер базы данных - до 10 Гб, количество баз не ограничено, использует не более 1 Гб оперативной памяти и только 1 процессор (ядро) на многопроцессорных и многоядерных машинах. Поддерживаемые платформы: только Windows x86 и x64.
	SQL Server 2012 Express Edition
Oracle	Oracle Database 11g Express Edition, (Oracle Database XE)	Суммарно до 11Гб пользовательских данных, использует не более 1Гб оперативной памяти и только 1 процессор (ядро) на многопроцессорных и многоядерных машинах. Поддерживаемые платформы: Windows x86, Linux x64.
IBM	IBM DB2 Express-C	Размер базы не ограничен, используется до 4Гб оперативной памяти и до 2-х процессоров. Поддерживаемые платформы: Windows x86 и x64, Linux x86 и x64, Unix x86 и x64, Solaris x86 и x64, Mac OS X

При превышении максимального размера базы запись в БД прекратится, но эту проблему легко предотвратить. В основном, объём требуется для хранения постоянно накапливающихся в системе событий, остальные данные (настройки контроллеров, данные субъектов доступа, уровни доступа и т.п.) относительно статичны и только на сверхкрупных системах могут превысить ограничения бесплатных Express-версий. Необходимо настроить средствами вашей СУБД процедуру периодического удаления старых событий из БД. Во многих СКУД эти процедуры предусмотрены разработчиками и их надо просто настроить.

Что касается ограничений по производительности: если система небольшая, не подразумевает больших нагрузок на СУБД, спокойно можно ограничиться бесплатной редакцией, её будет более чем достаточно. Если же задача накладывает повышенные требования на подсистему СУБД: большое количество пользователей в системе, большой трафик событий и поток обновлений данных в системе (объекты с большим количеством временных посетителей) и высокие требования к глубине архива событий, то всегда можно перейти с бесплатной редакции на коммерческий вариант, оплатив необходимую лицензию.

СУБД в СКУД

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

Производитель	СКУД	СУБД
Parsec	ParsecNET 3	Microsoft SQL Server (в поставке 2005 Express, поддерживаются также версии 2008, 2008 R2, 2012) – центральная БД; SQLite - локальные базы рабочих станций.
Elsys	Бастион 2	Oracle (в поставке 11g Express)
Perco	S20	Firebird
НВП Болид	Орион ПРО	MS SQL Server (в поставке 2005 Express)
РусГард	RusGuard	MS SQL Server (в поставке 2008 R2 Express)
Равелин ЛТД	Gate	Microsoft Access
ПромАвтоматика Сервис	Сфинкс	MySQL
Кодос	ИКБ Кодос	Firebird
TSS	Семь Печатей	Firebird
Bosсh	Building Integration System BIS	Microsoft SQL Server (в поставке 2008 Express Edition)
Honeywell	NexWatch (Honeywell Security)	Microsoft SQL Server
Siemens	SiPass	Microsoft SQL Server
ААМ Системз	Apacs	Microsoft SQL Server, Firebird
	Lyrix	Oracle, Microsoft SQL Server, Borland InterBase

Как видно, большинство производителей СКУД поставляют бесплатную версию промышленной клиент-серверной СУБД Microsoft SQL Server Express Edition и свободную (бесплатную) кроссплатформенную СУБД Firefird (примерно 50 на 50).

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

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

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

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

• При выборе СКУД обратите внимание на то, какая СУБД поставляется совместно с системой.
• Если вы эксплуатируете СКУД, то выясните, какая СУБД в ней используется.
• Оцените трафик данных и нагрузку в вашей системе, чтобы определиться с требуемыми аппаратными ресурсами сервера СУБД и нужной редакцией СУБД (проконсультируйтесь у производителя вашей СКУД при необходимости).
• Если в вашей СКУД используется Express-версия Microsoft SQL Server или Oracle, то необходимо задаться вопросом: «Насколько нам хватит бесплатного объёма базы?». Настройте периодическое удаление из базы старых событий средствами СКУД (если таковые имеются) либо же рассмотрите вопрос о миграции на платную неограниченную версию СУБД.
• Настройте резервное копирование баз данных средствами СКУД или же средствами СУБД и регулярно проверяйте его выполнение.
• Найдите специалиста по СУБД (администратора), к которому можно будет обратиться в случае повреждения базы данных, узнайте в технической поддержке производителя СКУД возможность предоставления такого рода услуг.

Представим, что в ваше распоряжение попала какая-либо база данных. Она содержит очень полезные, для вас или кого-то ещё, сведения. Однако вы ничего не сможете с ней сделать!
Можно попытаться открыть её текстовым редактором и извлечь часть данных. Но это будет лишь набор данных в непонятном для вас порядке. Ещё меньше пользы вы получите из БД, если она будет зашифрована. Отсюда возникает вопрос - с помощью чего была создана структура базы данных, и как потом с ней работать?

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

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

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

Современная СУБД состоит из:

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

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

Основными функциями СУБД являются

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

Кстати, по этой теме вы можете скачать презентацию в PowerPoint.

Классификации СУБД

Существует несколько признаков, по которым можно классифицировать СУБД.

СУБД по модели данных бывают:

• Иерархические СУБД
• Сетевые СУБД
• Реляционные СУБД
• Объектно-ориентированные СУБД
• Объектно-реляционные СУБД

В настоящее время в серьезных проекта используются 2 последних типа.

СУБД по степени распределённости

• Локальные (СУБД размещается только на одном компьютере)
• Распределённые (части СУБД могут размещаться на 2-х и более компьютерах).

Наверняка, вам будет полезным тест по СУБД, который есть на нашем проекте.

По способу доступа к БД

Файл-серверные СУБД

В них файлы с данными расположены централизованно на специальном файл-сервере. СУБД же должны быть расположены на каждом клиенте (рабочей станции). Доступ СУБД к данным производится посредством локальной сети. Поддержка синхронизации чтений и обновлений осуществляется за счет временных блокировок затребованных файлов.

Плюсом этой архитектуры можно назвать низкую нагрузку на файловый сервер.

К минусам же: высокая загрузка трафиком локальной сети; сложность или невозможность централизованного управления; нельзя обеспечить такие важные характеристики как надёжность, доступность и безопасность. Файл-серверные СУБД используют в локальных приложениях; в системах с малой интенсивностью обработки данных и небольшими пиковыми нагрузками на базу данных.

Сейчас её при создании крупной информационной системы не используют.

Примеры файл-серверных СУБД:

• dBase,
• FoxPro,
• Microsoft Access,
• Paradox,
• Visual FoxPro.

Клиент-серверные СУБД

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

Недостатком такого типа СУБД можно назвать повышенные требования к серверу.

Достоинствами: более низкую загрузку локальной сети; преимущества централизованного управления; поддержку высокой надёжности, доступности и безопасности.

Примеры клиент-серверных СУБД:

• Caché,
• Firebird,
• IBM DB2,
• Informix,
• Interbase,
• MS SQL Server,
• MySQL, Oracle,
• PostgreSQL,
• Sybase Adaptive Server Enterprise,
• ЛИНТЕР.

Встраиваемые СУБД

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

Примеры встраиваемых СУБД:

• Firebird Embedded,
• BerkeleyDB,
• Microsoft SQL Server Compact,
• OpenEdge,
• SQLite,
• ЛИНТЕР.

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