Ресиверы и Прошивки
Различные архитектурные решения, используемые при реализации многопользовательских субд. краткий обзор субд. Обзор систем управления базами данных (субд) для систем контроля и управления доступом (скуд). Функции сервера БД

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

Выводы

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

· имеют визуальные средства проектирования форм, отчетов и приложений;

· предоставляют доступ к данным серверных СУБД;

· приобрели средства публикации данных в Internet и в той или иной степени поддерживают создание приложений для редактирования данных с помощью Web-браузеров;

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

2. 3. Архитектура «клиент-сервер»

2.3.1. Недостатки архитектуры «файл-сервер»

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

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

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

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

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

2.3.2. Состав «клиент-серверной» ИС

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

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

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

· хранение и резервное копирование данных;

· поддержка ссылочной целостности данных согласно определенным в базе данных правилам;

· протоколирование операций и ведение журнала транзакций.

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

· сервера баз данных, управляющего данными и выполняющего запросы клиентских приложений;

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

2.3.3. Преимущества архитектуры «клиент-сервер»

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

· Одним из важнейших преимуществ архитектуры «клиент-сервер» является снижение сетевого трафика при выполнении запросов. Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен – выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. Т. е. в клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит от числа записей в таблицах, к которым произведен запрос.

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

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

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

Таким образом, технология «клиент-сервер» решает многие проблемы, возникающие при использовании настольных СУБД.

На сегодняшний день известно более двух десятков серверных СУБД, однако наиболее популярными, исходя из числа продаж, следует признать Oracle, Microsoft SQL Server, Informix, Sybase.

Сведения о производителях перечисленных выше СУБД представлены в следующей таблице:

Таблица 2. Серверные СУБД

Как правило, данные СУБД обладают следующими свойствами:

Реализованы для нескольких платформ;

Обладают удобными административными утилитами;

Позволяют осуществлять резервное копирование данных;

Поддерживают параллельную обработку данных в многопроцессорных системах;

Поддерживают выполнение распределенных запросов;

Поддерживают средства разработки и генераторы отчетов;

Поддерживают публикацию данных в Internet.

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

Выполнил Колпаков Анатолий

Архитектура “клиент-сервер”.

Базовый принцип - принцип централизации хранения и обработки данных.

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

Функции сервера БД:

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

хранение и резервное копирование данных,

поддержка ссылочной целостности данных согласно определенным в базе данных правилам,

протоколирование операций и ведение журнала транзакций.

Преимущества архитектуры “клиент-сервер”:

1. Снижение сетевого трафика при выполнении запросов.

2. Возможность хранения бизнесправил

3. Снижение требований к рабочим станциям.

Сервисы серверных СУБД:

Реализация для нескольких платформ. Обслуживание репликаций Административные утилиты Резервное копирование данных

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

Поддержка OLAP и создания хранилищ данных Распределенные запросы и транзакции Средства проектирования данных

Поддержка собственных и “чужих” средств разработки и генераторов отчетов

Поддержка доступа к данным с помощью Internet

Наиболее популярные серверных СУБД:

Sybase

Informix

DB2

Oracle

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

Microsoft

Первая версия Microsoft SQL Server, совместно разработанная в 1988 году компаниями Microsoft и Sybase, предназначалась для платформы OS/2. Последующие версии этого сервера баз данных предназначались для платформы Windows NT и со временем были тесно интегрированы с этой операционной системой. Для других платформ версии этого сервера не выпускались и не выпускаются.

Sybase Серверные продукты компании Sybase происходят от двух “предков”. Первым из них является одна из ранних версий Microsoft SQL Server, созданная совместно Microsoft и Sybase. Результатом деятельности компании Sybase в этом направлении является продукт под названием Adaptive Server Enterprise.

Еще одна линия серверных продуктов Sybase ведет свое начало от сервера баз данных Watcom SQL Anywhere, отличавшегося компактностью и простотой администрирования Последняя версия этого продукта называется Adaptive Server Anywhere 6.03.

Informix

Ведущий продукт фирмы Informix - Informix Dynamic Server, последняя версия которого называется Informix Dynamic Server 2000 (выпущена в сентябре 1999 года). Данный продукт поддерживает платформы UNIX и Microsoft Windows NT и обеспечивает эффективную работу как на одно-, так и на многопроцессорных системах, а также в кластерах. Сервер построен по архитектуре Dynamic Scalable Architecture (DSA), обеспечивающей мощные средства для параллельной обработки данных.

Технология ODBC(Open Data Base Connectivity).

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

Локальные и централизованные базы данных. Настольные СУБД.

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

Центр. БД: БД, размещ-ся на одном комп-м сервере сети. С компа пол-ля запускается СУБД с сервера и в рез-те на нем созд-ся копия СУБД. По каждому запр. Пол-ля к БД все д-е пересыл-ся на его комп независимо от того, сколько их нужно реально для вып-я з-са. В рез-те на комп. Пол-ля созд. Локальная копия БД. Затем СУБД вып-т з-с. Данная арх-ра именуется файл-сервер.

Наст.: dBase, Paradox, FoxPro,Access.

1-я пром. Версия появ-сь в нач. 80-х гг. Она им. Ср-ва для: манипуляции д-ми dBase всех версий; созд. Форм, отчетов и приложений; публикации д-х в Интернете и т.д.

dbase превращ-ся в некоммерч. Продукт с доступными исх-ми текстами прогр. СУБД Paradox

Версия Paradox сод-т ср-ва: манипуляции д-ми Paradox и dbase, публикации д-х и отчетов в Интернете и созд. Web-клиентов; доступа к д-м формата Par-x из Windows-приложений и др.

FoxPro предост. Возм-сть исп-я деловой графики и др.; им. Ср-ва визуального моделирования объектов, ср-ва публикации д-х в Интернете. Тенденция разв-я этого продукту сост. В том, что из наст. СУБД превр. В ср-во разр-ки прилож-й в арх-ре клиент-сервер. Эта тенденция х-на для наиболее попул. Наст-х СУБД.

Архитектура клиент-сервер. Серверные СУБД

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

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

СУБД Производитель

Oracle 8i, 9i Oracle Corparation

Microsoft SQL Server Microsoft

Informix Informix

9 . Распределенные СУБД

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

Распр. СУБД- программная сист., кот обесп-т управление распр-й БД и прозрачность её распр-сти для пол-й.

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

Ра БД м.б. однородными и неоднор-ми: однор. Им. В своей основе одну СУБД, обычно с единсв-м языком б.д.; неоднор.- 2 или более существенно различ-ся СУБД. Формы распр-я д-х:

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

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

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

10 .Разнообразные СУБД примен-ся как в коммерческих, так и некоммерческих целях. Если сбором информации заним-ся несколько родственных организаций, они могут договорится о стандарте файла данных и обмениваться ими, используя одну и туже СУБД, такую, как dBase, FoxPro, Access, Paradox. Если орган-я инициирует разработку информационной системы, то такая система будет создана на основе пакета, специально предназначенного для этих целей: Clipper, FoxPro, Clarion, Delphi. Если систему предполагается использовать в сетевом варианте, то будет использована сетевая СУБД: Orache, MS SQL, Server. Разнообразные средства СУБД обеспечивают выполнение трёх основных функций: определение данных (можно определить какие сведения могут нах-ся в вашей СУБД, их типы н-р числа или символьные и как они связаны между собой. Можно так задать форматы и условия для проверки данных.), обработка данных (данные можно обработать самыми различными способами: выбрать любые поля, фильтровать, сортировать, объединять данные со связ сними информацией и вычислять итоговые значения. Также можно отобрать некоторые данные, затем изменить, удалить, скопировать их в др таблицу или создать для них новую таблицу), управление данными (можно указать каким пользователям разрешено просмотреть, изменить, вставить данные. Также можно определить правила совместного использования данных. В сер 80-х исследователи БД стали решать вопросы, выходящие за рамки реляционной модели. В результате появились объектно – реляционные и объектно- ориентированные СУБД. В отличии от реляционных БД, берущих начало в управлении данными информационных систем, корни ООСУБД в большей степени лежат в языках программирования. А ООСУБД встроенный язык прогр-я явл-ся и языком манипулирования данными. Больш ООСУБД исп-ся в качестве встроенных языков программир-я С++, Smalltalk, Java. Существуют следующие понятия: объект, классы, наследование, инкопсулирование, расширяемость, конформизм. Главной характерной чертой ООБД явл-ся:- способность хранить информацию о разных объектах с исчерпывающим описанием взаимосвязей между ними и их динамического поведения. В них существует программа, кот-я представляет процедуру, способную производить действия над атрибутами об-та в случае наступления тех или иных событий. Благодаря указанным свойствам ООСУБД поддерживает новый класс БД с умеренно большими совокупностями записей и чрезвычайно сложным набором связей между записями. Если ООСУБД проектировались с «чистого» листа, то объектно – реляционные СУБД явл-ся модификацией реляционных СУБД- объектная ориентация.

11. Коммерческие СУБД: Gem Stone, Vbase, Jrion, PDM, IRST. dBase, FoxPro, Access, Paradox, Orache, MS SQL, Server.

12.Основные этапы разработки БД в среде MS Access:-разработка и описание структуры таблицы данных, -разработка схем данных и задание системы взаимосвязей между таблицами, - разработка системы запросов к таблицам БД и при необходимости, их интеграция в систему данных, - разработка экранных форм ввода/вывода данных, - разр-ка системы отчётов по данным. – разр-ка программных расширений для БД.- разр-ка системы защиты.

MS Access явл-ся настольной СУБД реляционного типа, которая имеет все необходимые средства для выполнения след функций: -добавлять в таблицу одну или несколько записей,- удалять из таблицы одну или несколько записей,- обновлять значения, - находить записи, удовлетворяющих заданному условию. Запрос позволяет объединять данные из нескольких таб-ц, выполнять вычисления над данными из др столбцов таблицы, добавлять, изменять, удалять записи. В форма можно отображать инфор-ю из неск-х таб-ц несколько или одну запись в виде некоторого бланка. Отчёт позволяет извлекать необходимые данные, группировать и сортировать их в нужном виде, вычислять итоговые значения по группам и в целом по всем отобранным записям. Ин может быть дополнен рисунком, диаграммами, комментариями.

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-02

18.03.2014

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

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

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

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

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

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

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

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

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

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

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

Виды СУБД

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

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

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

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

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

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

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

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

Файл-серверные и встраиваемые СУБД практически все являются бесплатными, из бесплатных клиент-серверных СУБД наиболее известные: 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, то необходимо задаться вопросом: «Насколько нам хватит бесплатного объёма базы?». Настройте периодическое удаление из базы старых событий средствами СКУД (если таковые имеются) либо же рассмотрите вопрос о миграции на платную неограниченную версию СУБД.
Настройте резервное копирование баз данных средствами СКУД или же средствами СУБД и регулярно проверяйте его выполнение.
Найдите специалиста по СУБД (администратора), к которому можно будет обратиться в случае повреждения базы данных, узнайте в технической поддержке производителя СКУД возможность предоставления такого рода услуг.

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

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

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

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