 Любая современная сетевая СКУД нуждается в базе данных, так как является по своей сути информационной системой, предназначенной для хранения, обработки и анализа информации о происходящих на защищаемом объекте событиях. Также в СКУД должны храниться настройки оборудования, коды карт и личные данные пользователей, уровни доступа и другая нужная информация.
Разберемся в терминологии
Частая ошибка многих специалистов по безопасности – некорректное использование термина «база данных» (БД) вместо термина «система управления базами данных» (СУБД). Давайте разберемся, что к чему.
База данных – представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины.
Система управления базами данных (СУБД) – совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
То есть упрощенно «база данных» – это сами данные, представленные в виде совокупности файлов на дисках, с которыми как раз работает «система управления базами данных» (СУБД) – программный продукт, имеющий средства для создания, наполнения, модификации и поиска по базам данных.
Разработчики различных приложений, в том числе и разработчики СКУД, работают именно с СУБД и выбирают СУБД под свои нужды.
Требования к СУБД, применяемым в СКУД
Какие же особенные требования следует предъявить к СУБД, используемой в СКУД, с точки зрения пользователя?
Во-первых, надежность: никакие данные не должны пропасть!
Сбои должны быть минимизированы и не должны приводить к потерям данных, базы должны быть надежно защищены от несанкционированного доступа, на режимных объектах могут потребоваться функции шифрования данных, необходимо также обеспечивать регулярное резервное копирование баз данных и возможность восстановления из архива при необходимости.
•
Во-вторых, производительность: СУБД должна обеспечивать приемлемый уровень производительности для решения возложенных на нее задач.
•
В-третьих, на мой взгляд, – это уверенность в том, что СУБД будет поддерживаться производителем и вы не останетесь один на один с проблемой в случае какого-то серьезного сбоя или сложной ситуации.
•
Виды СУБД
СУБД на данный момент существует великое множество, и классифицируются они по разным признакам. Но мы не будем останавливаться в данной статье на всем многообразии этих типов, опустим перспективные и экзотические технологии типа объектно-ориентированных и иерархических СУБД. Стандартом де-факто в современных информационных системах являются реляционные СУБД, в которых данные хранятся в табличном виде, о них мы и будем говорить. Так чем же различаются все эти системы? Перечислю ключевые параметры, важные как для разработчиков, так и для пользователей системы.
Способ доступа к БД:
1) Клиент-серверные СУБД
• Файл-серверные СУБД
• Встраиваемые СУБД
В клиент-серверных СУБД (Microsoft SQL Server, Oracle, Firebird, PostgreSQL, InterBase, MySQL и др.) вся обработка данных ведется в одном месте, на сервере, в том же месте, где хранятся (обычно) данные, при этом к файлам данных имеет доступ только один сервер, одна система – это сама СУБД. Приложения-клиенты при этом посылают запросы на обработку и получение данных из СУБД и получают ответы; приложения-клиенты не имеют непосредственного доступа к файлам данных. Все промышленные СУБД на данный момент являются именно клиент-серверными.
В файл-серверных СУБД (Paradox, Microsoft Access, FoxPro, dBase и др.), наоборот, приложения имеют общий доступ ко всем файлам базы данных (хранящимся обычно в каком-то разделяемом файловом хранилище) и совместно обрабатывают эти данные. Каждое приложение самостоятельно обрабатывает данные. На данный момент файл-серверная технология считается устаревшей, а ее использование в крупных информационных системах – недостатком. Проблема в том, что файл-серверные СУБД не имеют многих преимуществ клиент-серверных, таких как кэширование данных, параллелизм запросов, высокая производительность, и обладают рядом недостатков (сложности с поддержанием целостности базы, восстановлением, блокировками и т. д.), что приводит в свою очередь к пониженной надежности и производительности. Состояние базы в файловых СУБД необходимо постоянно отслеживать и проводить операции по ее «лечению» с помощью встроенных или сторонних утилит.
Встраиваемые СУБД (SQLite, Firebird Embedded, Microsoft SQL Server Compact и др.) поставляются в составе готового программного продукта, не требуя процедуры самостоятельной установки. Встраиваемые СУБД предназначены для локального хранения данных приложения и не рассчитаны на коллективное использование в сети. К примеру, встраиваемая бесплатная СУБД SQLite широко используется в известной мобильной ОС Android, разработанной в компании Google, и во многих мобильных приложениях.
Схема лицензирования:
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 Express Edition и свободную (бесплатную) кроссплатформенную СУБД Firefird (примерно 50 на 50).
Конкретный выбор той или иной СУБД – дело вкуса и предпочтений каждого производителя, благо выбор есть. При выборе разработчики учитывают также вопросы удобства и простоты администрирования, наличие встроенных бесплатных инструментов для администрирования и разработки.
СУБД для СКУД помимо высокой надежности и производительности должна быть удобной и недорогой в поддержке. Разработчики СКУД прекрасно понимают, что даже на крупных объектах зачастую нет выделенных специалистов для обслуживания СКУД, обладающих навыками администрирования СУБД, поэтому стараются включать в свои продукты функции, облегчающие и автоматизирующие процессы обслуживания базы данных.
Прежде всего резервное копирование БД – основа основ, которая позволяет администратору системы спокойно спать. Все СУБД имеют собственные средства для создания резервных копий, но хорошим тоном считается, когда функция резервного копирования интегрирована в продукт и администратору необходимо лишь включить/настроить ее и периодически проверять функционирование.
Вторая частая проблема – восстановление данных после сбоя. Здесь опять же на выручку приходит свежая резервная копия, но если ее нет или критично восстановление всех возможных данных, то потребуются дополнительные усилия. К счастью, в промышленных СУБД (чего не скажешь о старых файловых СУБД типа Paradox) такие явления происходят нечасто, их может вызвать разве что «умирающий» жесткий диск или сбой электропитания. В этом случае потребуются услуги специалиста-администратора СУБД, который сможет с помощью встроенных в любую серьезную СУБД инструментов восстановить максимум из возможного. Также следует учесть, что некоторые производители СКУД в рамках технической поддержки оказывают услуги по восстановлению баз.
Рекомендации
При выборе СКУД обратите внимание на то, какая СУБД поставляется совместно с системой.
Если вы эксплуатируете СКУД, то выясните, какая СУБД в ней используется.
Оцените трафик данных и нагрузку в вашей системе, чтобы определиться с требуемыми аппаратными ресурсами сервера СУБД и нужной редакцией СУБД (проконсультируйтесь у производителя вашей СКУД при необходимости).
• Если в вашей СКУД используется Express-версия Microsoft SQL Server или Oracle, то необходимо задаться вопросом: «Насколько нам хватит бесплатного объема базы?»
Настройте периодическое удаление из базы старых событий средствами СКУД (если таковые имеются) либо же рассмотрите вопрос о миграции на платную неограниченную версию СУБД.
• Настройте резервное копирование баз данных средствами СКУД или же средствами СУБД и регулярно проверяйте его выполнение.
• Найдите специалиста по СУБД (администратора), к которому можно будет обратиться в случае повреждения базы данных, узнайте в технической поддержке производителя СКУД возможность предоставления такого рода услуг.
|
