Содержание

Обзор систем управления базами данных (СУБД) для систем контроля и управления доступом (СКУД)

Пивоваров Семён

Руководитель отдела разработки ПО Parsec

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

Источник: 
статья была опубликована в журнале «Технологии Защиты» № 1, 2014
(обновлена 14 мая 2020 года)

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

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

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

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

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

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

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

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

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

Виды СУБД

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

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

  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, упомянутой выше, который получил широкую известность и множество поклонников среди разработчиков.

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

Сравнение свободных и коммерческих СУБД

Свободные СУБД

+

  • Бесплатно.
  • Менее требовательны к железу.
  • Богатый функционал.
  • Хорошая производительность.
  • Надежность.

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

+

  • Высокая производительность.
  • Масштабируемость.
  • Надёжность.
  • Поддерживаемость.
  • Задокументированность.
  • Встроенные инструменты для разработки и администрирования.

  • Требовательность к ресурсам.
  • Высокая цена.

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

Компания-производитель Бесплатные версии Ограничения
Microsoft SQL Server 2005/2008 Express Edition Размер базы данных — до 4 Гб, количество баз не ограничено, использует не более 1 Гб оперативной памяти и только 1 процессор (ядро) на многопроцессорных и многоядерных машинах. Поддерживаемые платформы: только Windows 2005 — только x86, 2008 — x86 и x64.
SQL Server 2008 R2/2012/2014/2016/2017/2019 Express Edition Размер базы данных — до 10 Гб, количество баз не ограничено, использует не более 1 Гб оперативной памяти и только 1 процессор (ядро) на многопроцессорных и многоядерных машинах. Поддерживаемые платформы: только Windows x86 и x64.
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 (в поставке 2012 Express, заявлена поддержка версий 2008 R2 и выше) — центральная БД; SQLite — локальные базы рабочих станций.
Elsys Бастион 2 Oracle (в поставке 11g Express), заявлена поддержка версий Oracle 12с, Oracle SE2, также может использоваться СУБД PostgreSQL 10 или Postgres Pro
Perco S20 Firebird 2.0
НВП Болид Орион ПРО

Microsoft SQL Server (в поставке 2012 Express), заявлена поддержка версий 2008/2012/2014

РусГард RusGuard Microsoft SQL Server (в поставке 2014 Express), заявлена поддержка версий 2014/2016
Равелин ЛТД Gate Microsoft Access
ПромАвтоматика Сервис Сфинкс MySQL
Кодос ИКБ Кодос Firebird
TSS Семь Печатей Firebird
Bosсh Access PE
Microsoft SQL Server (рекомендуется версия 2014 Express Edition)
Honeywell Pro-Watch Microsoft SQL Server 2012/2014/2016
Siemens SiPass Microsoft SQL Server 2000
ААМ Системз Apacs 3000 Firebird 2. 5 (входит в комплект поставки), поддерживается также Microsoft SQL Server 2017
Lyrix Borland Interbase 2007 (в комплекте поставки), поддержка Oracle 10g и Microsoft SQL Server 2005

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

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

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

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

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

Рекомендации

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

 

Хотите узнать больше?

Пройдите бесплатный курс «Основы систем контроля и управления доступом» в Академии Parsec. На курсе будут рассмотрены основные компоненты СКУД, их назначение и принципы работы, основные термины, необходимые для понимая устройства и специфики работы систем контроля доступа. По окончании курса вы получите сертификат.

 

Конфигуратор СКУД

Автоматический подбор оборудования и программного обеспечения профессиональной системы контроля доступа Перейти к подбору

Определение СУБД. Что такое система управления базами данных?

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

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


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

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



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

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



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


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

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



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


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

Кстати, по этой теме вы можете скачать презентацию в 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,
  • ЛИНТЕР.

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


Список литературы по теме:


  1. Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с.
  2. Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-университет информационных технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1436 с.
  3. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс = Database Systems: The Complete Book. — Вильямс, 2003. — 1088 с. C. J. Date Date on Database: Writings 2000–2006. — Apress, 2006. — 566 с.


Файловая система NTFS Что такое информация?

Типы СУБД — Платформа CUBA. Руководство по разработке приложений

3.3.2. Типы СУБД

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

Платформа «из коробки» поддерживает следующие СУБД:

cuba.dbmsType cuba.dbmsVersion JDBC driver

HSQLDB

hsql

org.hsqldb.jdbc.JDBCDriver

PostgreSQL 8.4+

postgres

org.postgresql.Driver

Microsoft SQL Server 2005

mssql

2005

net.sourceforge.jtds.jdbc.Driver

Microsoft SQL Server 2008

mssql

com.microsoft.sqlserver.jdbc.SQLServerDriver

Microsoft SQL Server 2012+

mssql

2012

com. microsoft.sqlserver.jdbc.SQLServerDriver

Oracle Database 11g+

oracle

oracle.jdbc.OracleDriver

MySQL 5.6+

mysql

com.mysql.jdbc.Driver

MariaDB 5.5+

mysql

org.mariadb.jdbc.Driver

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

Java HSQL PostgreSQL MS SQL Server Oracle MySQL MariaDB

UUID

varchar(36)

uuid

uniqueidentifier

varchar2(32)

varchar(32)

varchar(32)

Date

timestamp

timestamp

datetime

timestamp

datetime(3)

datetime(3)

java. sql.Date

timestamp

date

datetime

date

date

date

java.sql.Time

timestamp

time

datetime

timestamp

time(3)

time(3)

BigDecimal

decimal(p, s)

decimal(p, s)

decimal(p, s)

number(p, s)

decimal(p, s)

decimal(p, s)

Double

double precision

double precision

double precision

float

double precision

double precision

Long

bigint

bigint

bigint

number(19)

bigint

bigint

Integer

integer

integer

integer

integer

integer

integer

Boolean

boolean

boolean

tinyint

char(1)

boolean

boolean

String (limited)

varchar(n)

varchar(n)

varchar(n)

varchar2(n)

varchar(n)

varchar(n)

String (unlimited)

longvarchar

text

varchar(max)

clob

longtext

longtext

byte[]

longvarbinary

bytea

image

blob

longblob

longblob

Как правило, всю работу по преобразованию данных между БД и кодом Java выполняет слой ORM совместно с соответствующим JDBC драйвером. Это означает, что при работе с данными через DataManager, EntityManager и запросы на JPQL никакой ручной конвертации выполнять не нужно — вы просто используете типы Java, перечисленные в левой колонке таблицы.

При использовании native SQL через EntityManager.createNativeQuery() или через QueryRunner для разных типов СУБД некоторые типы данных в Java коде будут отличаться от приведенных. В первую очередь это касается атрибутов типа UUID — только драйвер PostgreSQL возвращает значения соответствующих колонок в этом типе, для других серверов это будет String. Для обеспечения независимости кода от используемой СУБД рекомендуется конвертировать типы параметров и результатов запросов с помощью интерфейса DbTypeConverter.

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

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

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

Определение 1

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

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

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

Определение 2

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

СУБД должна постоянно контролировать выполнение этих ограничений.

  • Поддержка транзакций.

Определение 3

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

Пример 1

Допустим, необходимо выполнить следующую последовательность действий:

  1. Определить сумму на счете №1.
  2. Вычислить 10% от этой суммы.
  3. Уменьшить сумму на счете №1 на полученное значение.
  4. Увеличить сумму на счете №2 на это же значение.

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

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

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

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

  • Иерархические. Самыми известными иерархическими СУБД является IMS и Cache . Модель удобна для хранения структур, которые являются иерархическими по своей природе. Иерархической является, например, структура предприятия с подчиненными подразделениями. Однако, большинство предметных областей не соответствуют иерархической структуре. Потому иерерхические СУБД не популярны и используются в основном в устаревших ИС.
  • Сетевые. Известными представителями этого класса являются IDMS и CronosPRO. Данная модель является усовершенствованием иерархической. Высокая сложность и жесткость структуры базы данных также снижают популярность этого класса СУБД;
  • Реляционные. На сегодняшний день реляционные базы данных и СУБД являются стандартом де-факто. Чаще всего, когда речь идет о базе данных, то подразумевается именно реляционная. На рынке ПО существует много представителей этого класса СУБД: MS SQL SERVER,IBM DB2, MySQL, PostgreSQL и т.д. ;
  • Постреляционные. Постреляционная модель основана на тех же принципах, что и реляционная, но без учета требования неделимости данных. Их достоинством является более высокая скорость работы, а недостатком – сложности в обеспечении целостности данных. Типичным представителем являются СУБД uniVerse и UniData;
  • No sql (нереляционные). Модель no sql отличается простотой и гибкостью. Она позволяет добавлять элементы данных в таблицы без предварительного объявления об изменении структуры. Наиболее известные представители MongoDB и CouchDB.
  • Объектные. Этот класс СУБД хранит данные в виде объектов. Такой подход очень удобен для предметных областей со сложной структурой. Недостатком является необходимость использовать процедурные языки для доступа к данным. К современным объектным СУБД относятся POET, Jasmine, Versant, O2, ODB-Jupiter.
  • Объектно-реляционные. Некоторые производители СУБД совмещают в своих продуктах реляционную и объектную модели. К таким «гибридам» относятся Informix Universal Server и Oracle8 Universal Data Server
  • Многомерные. Если реляционная модель хранит данные в двумерных таблицах, то многомерная позволяет добавлять дополнительные измерения. В результате данных хранятся не в таблицах, а в гиперкубах. Многомерные СУБД используются в задачах анализа данных. На многомерной технологии основаны СУБД jBASE, EssBase.

Реляционные базы данных и NoSQL-хранилища

Базы данных нужны для хранения данных и их обработки. Бывают реляционные (SQL) и NoSQL системы управления базами данных.

Реляционные базы данных (SQL)

Наиболее распространенными базами данных являются реляционные или SQL — данные в них хранятся во взаимосвязаанных таблицах. Типичные представители SQL СУБД: MySQL / MariaDB, PostgreSQL, MSSQL и Oracle. Первые две — бесплатны и для сайтов используются чаще всего. Вторые две — платные и реже используются в веб-проектах (чаще они применяются в корпоративных приложениях). По сути, для обычных проектов в техническом плане нет существенной разницы какую базу использовать, но в экономическом плане выгоднее использовать самую распространенную MySQL или чуть менее распространенную в простых проектах PostgreSQL — больше разработчиков, ниже стоимость поддержки и разработки.

Базы данных и хранилища NoSQL

Есть еще так называемые NoSQL базы данных и хранилища — MongoDB, CouchDB, Redis, Memcached, Cassandra, Scylla, которые значительно моложе реляционных баз данных, а также существенно отличаются от них по структуре хранения и механикам работы с данными. NoSQL СУБД применяются чаще не для хранения всех данных приложения, а лишь для решения специфических задач (журналирование, кэширование, очереди заданий, распределённое хранение данных) и поэтому менее распространены в простых проектах.

Рекомендации

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

Как правило, выбор системы управления сайтом, фреймворка или даже языка программирования уже в какой-то мере обуславливает выбор базы данных для проекта. Например,  системы управления сайтами на PHP обычно полноценно поддерживает в качестве БД только MySQL, а продукты от Microsoft, как правило, используют в одной связке (например, . NET + MSSQL).

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

Типы данных в СУБД—Справка | ArcGIS Desktop

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

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

Примечание:

Перемещение данных из одной базы данных в другую может вызывать преобразование типов данных.

Подробнее о конвертации данных из одного типа в другой

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

Типы данных Access

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

Тип данных ArcGISТип данных AccessПримечания

OBJECTID

Длинное целое (Long Integer)

OBJECTID является полем AutoNumber.

SHORT INTEGER

Целое (Integer)

LONG INTEGER

Длинное целое (Long Integer)

FLOAT

Одинарной точности (Single)

DOUBLE

Двойной точности (Double)

TEXT

Текст (Text)

DATE

Дата/Время (Date/Time)

BLOB

Объект OLE*

GUID

Число (Number)

Replication ID, возможны повторы

GEOMETRY

Объект OLE*

RASTER

Длинное целое (Long Integer)

*Объекты связывания и встраивания (OLE) представляют собой объекты, которые были созданы в других приложениях и сейчас связаны с Microsoft Access или встроены в него. В данном случае, типы данных Большой двоичный объект (BLOB) и Геометрия (GEOMETRY) не существуют в Access, поэтому объект ArcGIS связывается с базой данных Access.

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

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

Связанные разделы

история, виды, примеры, применение Big Data

NoSQL – это подход к реализации масштабируемого хранилища (базы) информации с гибкой моделью данных, отличающийся от классических реляционных СУБД. В нереляционных базах проблемы масштабируемости (scalability) и доступности (availability), важные для Big Data, решаются за счёт атомарности (atomicity) и согласованности данных (consistency) [1].

Зачем нужны нереляционные базы данных в Big Data: история появления и развития

NoSQL-базы оптимизированы для приложений, которые должны быстро, с низкой временной задержкой (low latency) обрабатывать большой объем данных с разной структурой [2]. Таким образом, нереляционные хранилища непосредственно ориентированы на Big Data. Однако, идея баз данных такого типа зародилась гораздо раньше термина «большие данные», еще в 80-е годы прошлого века, во времена первых компьютеров (мэйнфреймов) и использовалась для иерархических служб каталогов. Современное понимание NoSQL-СУБД возникло в начале 2000-х годов, в рамках создания параллельных распределённых систем для высокомасштабируемых интернет-приложений, таких как онлайн-поисковики [1].

Вообще термин NoSQL обозначает «не только SQL» (Not Only SQL), характеризуя ответвление от традиционного подхода к проектированию баз данных. Изначально так называлась опенсорсная база данных, созданная Карло Строззи, которая хранила все данные как ASCII-файлы, а вместо SQL-запросов доступа к данным использовала шелловские скрипты [3]. В начале 2000-х годов Google построил свою поисковую систему и приложения (GMail, Maps, Earth и прочие сервисы), решив проблемы масштабируемости и параллельной обработки больших объёмов данных. Так была создана распределённые файловая и координирующая системы, а также колоночное хранилище (column family store), основанное на вычислительной модели MapReduce. После того, как корпорация Google опубликовала описание этих технологий, они стали очень популярны у разработчиков открытого программного обеспечения. В результате этого был создан Apache Hadoop и запущены основные связанные с ним проекты. Например, в 2007 году другой ИТ-гигант, Amazon.com, опубликовав статьи о своей высокодоступной базе данных Amazon DynamoDB. Далее в эту гонку NoSQL- технологий для управления большими данными включилось множество корпораций: IBM, Facebook, Netflix, eBay, Hulu, Yahoo! и другие ИТ-компаний со своими проприетарными и открытыми решениями [1].

Многообразие NoSQL-решений

Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных

Все NoSQL решения принято делить на 4 типа:

  1. Ключ-значение (Key-value) – наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы [4]. Такие СУБД применяются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в масштабируемых Big Data системах, включая игровые и рекламные приложения, а также проекты интернета вещей (Internet of Things, IoT), в т.ч. индустриального (Industrial IoT, IIoT). Наиболее известными представителями нереляционных СУБД типа key-value считаются Oracle NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB, которые поддерживают высокую разделяемость, обеспечивая беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД [2].
  2. Документно-ориентированное хранилище, в котором данные, представленные парами ключ-значение, сжимаются в виде полуструктурированного документа из тегированных элементов, подобно JSON, XML, BSON и другим подобным форматам [4]. Такая модель хорошо подходит для каталогов, пользовательские профилей и систем управления контентом, где каждый документ уникален и изменяется со временем [2].  Поэтому чаще всего документные NoSQL-СУБД используются в CMS-системах, издательском деле и документальном поиске. Самые яркие примеры документно-ориентированных нереляционных баз данных – это CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML [1].
  3. Колоночное хранилище, которое хранит информацию в виде разреженной матрицы, строки и столбцы которой используются как ключи. В мире Big Data к колоночным хранилищам относятся базы типа «семейство столбцов» (Column Family). В таких системах сами значения хранятся в столбцах (колонках), представленных в отдельных файлах. Благодаря такой модели данных можно хранить большое количество атрибутов в сжатом виде, что ускоряет выполнение запросов к базе, особенно операции поиска и агрегации данных [4]. Наличие временных меток (timestamp) позволяет использовать такие СУБД для организации счётчиков, регистрации и обработки событий, связанных со временем: системы биржевой аналитики, IoT/IIoT-приложения, систему управления содержимым и т.д. Самой известной колоночной базой данных является Google Big Table, а также основанные на ней Apache HBase и Cassandra. Также к этому типу относятся менее популярные ScyllaDB, Apache Accumulo и Hypertable [1].
  4. Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для отображения и хранения данных [4]. Поскольку рёбра графа являются хранимыми, его обход не требует дополнительных вычислений (как соединение в SQL). При этом для нахождения начальной вершины обхода необходимы индексы. Обычно графовые СУБД поддерживают ACID-требования и специализированные языки запросов (Gremlin, Cypher, SPARQL, GraphQL и т.д.) [1]. Такие СУБД используются в задачах, ориентированных на связи: социальные сети, выявление мошенничества, маршруты общественного транспорта, дорожные карты, сетевые топологии [3]. Примеры графовых баз: InfoGrid, Neo4j, Amazon Neptune, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan, ArangoDB.
Виды NoSQL-СУБД

Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки

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

  • линейная масштабируемость – добавление новых узлов в кластер увеличивает общую производительность системы [1];
  • гибкость, позволяющая оперировать полуструктирированные данные, реализуя, в. т.ч. полнотекстовый поиск по базе [2];
  • возможность работать с разными представлениями информации, в т. ч. без задания схемы данных [1];
  • высокая доступность за счет репликации данных и других механизмов отказоустойчивости, в частности, шаринга – автоматического разделения данных по разным узлам сети, когда каждый сервер кластера отвечает только за определенный набор информации, обрабатывая запросы на его чтение и запись. Это увеличивает скорость обработки данных и пропускную способность приложения [5].
  • производительность за счет оптимизации для конкретных видов моделей данных (документной, графовой, колоночной или «ключ‑значение») и шаблонов доступа [2];
  • широкие функциональные возможности – собственные SQL-подобные языки запросов, RESTful-интерфейсы, API и сложные типы данных, например, map, list и struct, позволяющие обрабатывать сразу множество значений [2].

Обратной стороной вышеуказанных достоинств являются следующие недостатки:

  • ограниченная емкость встроенного языка запросов [5]. Например, HBase предоставляет всего 4 функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и Join, несмотря на наличие SQL-подобного языка запросов. Для решения этой проблемы используются сторонние средства трансляции классических SQL-выражений в исполнительный код для конкретной нереляционной базы. Например, Apache Phoenix для HBase или универсальный Drill.
  • сложности в поддержке всех ACID-требований к транзакциям (атомарность, консистентность, изоляция, долговечность) из-за того, что NoSQL-СУБД вместо CAP-модели (согласованность, доступность, устойчивость к разделению) скорее соответствуют модели BASE (базовая доступность, гибкое состояние и итоговая согласованность) [1]. Впрочем, некоторые нереляционные СУБД пытаются обойти это ограничение с помощью настраиваемых уровней согласованности, о чем мы рассказывали на примере Cassandra. Аналогичным образом Riak позволяет настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов за счет задания количества узлов, необходимых для подтверждения успешного завершения транзакции [1]. Подробнее о CAP-и BASE-моделях мы расскажем в отдельной статье.
  • сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка запросов и гибкой модели данных, ориентированной на конкретный случай [5];
  • недостаток специалистов по NoSQL-базам по сравнению с реляционными аналогами [5].

Подводя итог описанию основных аспектов нереляционных СУБД, стоит отметить некоторую некорректность запроса «NoSQL vs SQL» в связи с разными архитектурными подходами и прикладными задачами, на которые ориентированы эти ИТ-средства. Традиционные SQL-базы отлично справляются с обработкой строго типизированной информации не слишком большого объема. Например, локальная ERP-система или облачная CRM. Однако, в случае обработки большого объема полуструктурированных и неструктурированных данных, т.е. Big Data, в распределенной системе следует выбирать из множества NoSQL-хранилищ, учитывая специфику самой задачи. В частности, для самостоятельных решений интернета вещей (Internet of Things), в т.ч. промышленного, отлично подходит Cassandra, о чем мы рассказывали здесь. А в случае многоуровневой ИТ-инфраструктуры на базе Apache Hadoop стоит обратить внимание на HBase, которая позволяет оперативно, практически в режиме реального времени, работать с данными, хранящимися в HDFS.

Нереляционные СУБД находят больше областей приложений, чем традиционные SQL-решения

Источники

  1. https://ru.wikipedia.org/wiki/NoSQL
  2. https://aws.amazon.com/ru/nosql/
  3. https://ru.bmstu.wiki/NoSQL
  4. https://tproger.ru/translations/types-of-nosql-db/
  5. https://habr.com/ru/sandbox/113232/

Related Entries

Введение в SubD (Subdivision Surface Modeling) в Rhino3d v7

В этом видео Фил Кук из Simply Rhino рассматривает SubD, или Subdivision Surface Modeling, который разрабатывается для Rhino v7.

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

Однако объекты

Rhino SubD представляют собой высокоточные сплайновые поверхности и, таким образом, вносят определенный уровень точности в процесс создания сложных форм произвольной формы.В то время как традиционное «push-pull» редактирование ребер, граней и вершин в SubD включено, все команды поверхности Rhino, такие как Loft, Revolve, Sweep 1 & 2 и Extrude, теперь производят прямой вывод SubD.

Точно так же кривая контрольной точки и интерполированная кривая имеют параметры «SubD Friendly», которые позволяют создавать точные поверхности SubD из компоновки кривой аналогичным методом, который можно использовать для моделирования NURBS, но с преимуществом присущей гладкости поверхностей SubD.

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

Посмотрите видео «Введение в инструменты SubD в Rhino v7»: