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

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

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

Выбор СУБД как процесс

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

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

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

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

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

СУБД как часть проекта

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

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

Таблица 2. Создавать или нет новую СУБД?

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

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

Некоторые современные СУБД (например, Vertica и VoltDB) стали результатом исследовательских проектов, в рамках которых был создан прототип будущей системы (C-Store — прототип Vertica, H-Store — прототип VoltDB), проверенный затем на реальных практических задачах. Однако для массового создания новых СУБД такой путь невозможен: далеко не каждая компания готова финансировать подобные исследовательские проекты.

Иррациональный мир современных СУБД

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

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

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

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

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

Там, где бессильны универсальные СУБД

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

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

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

***

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

Литература

1. M. Stonebraker. «One Size Fits All»: An Idea Whose Time Has Come and Gone. URL: http://dl.acm.org/citation.cfm?id=1054024 (дата обращения: 18.09.2017).
2. Венкат Гудивада, Дана Рао, Виджай Рагхаван. Ренессанс СУБД: проблема выбора // Открытые системы.СУБД. — 2016. — №3. — С. 12–17. URL: https://www.osp.ru/os/2016/03/13050249 (дата обращения: 18.09.2017).
3. M. Stonebraker. New SQL: An Alternative to NoSQL and Old SQL for New OLTP Apps. URL: https://cacm.acm.org/blogs/blog-cacm/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext (дата обращения: 18.09.2017).
4. Андрей Николаенко. Эталонные тесты СУБД: что было, что стало, что будет // Открытые системы.СУБД. — 2017. — №2. — С. 35–39. URL: https://www.osp.ru/os/2017/02/13052225 (дата обращения: 10.09.2017).

Константин Селезнев ([email protected]) — ведущий инженер-программист, группа компаний «РЕЛЭКС» (Воронеж).

Поделитесь материалом с коллегами и друзьями

www.osp.ru

Обзор современных реляционных СУБД

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

• MS Access,
• Visual FoxPro,
• MySQL,
• PostgreSQL,
• Sybase,
• SQL Server,
• Oracle,
• DB2
• и др.

Рассмотрим наиболее распространенные из них.

СУБД MS Access

Программа Access функционирует под управлением операционной системы Windows и обладает стандартизованным интерфейсом приложений Windows.

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

Обработка информации в процессе работы с БД осуществляется с помощью макросов или VBA программ.

Открытая БД может обмениваться данными с внешними БД. Внешней базой данных может быть любая БД, которая поддерживает протокол ODBC и расположена на удаленном сервере, или одна из БД СУБД Access, dBASE или Paradox.

Access позволяет создавать и выполнять запросы на выборку, добавление данных, удаление и обновление.

Запрос можно создать с помощью QBE или SQL. Программой Access поддерживается механизм OLE (связывание и встраивание объектов) и механизм DDE (динамический обмен данными).

СУБД Visual FoxPro

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

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

Visual FoxPro характеризует высокая скорость обслуживания БД.

С помощью стандарта ODBC и SQL-запросов для выборки данных Visual FoxPro может работать с базами данных dBase, Paradox, Access и т. д., с серверами баз данных – Oracle MS SQL Server и др.

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

Visual FoxPro поддерживает механизмы OLE и DDE работы с Windows приложениями.

Visual FoxPro позволяет создавать сетевые приложения, которые функционируют в сетях под управлением MS LAN Manager, MS Windows и др.

MS SQL Server

Microsoft SQL Server широко используется в области БД и для анализа данных, позволяет быстро создавать масштабируемые решения электронной коммерции, приложений для бизнеса и хранилищ данных. SQL Server поддерживает язык XML и протокол HTTP, средства повышения доступности и быстродействия, которые позволяют обеспечить бесперебойную работу и распределить нагрузку, функции улучшения настройки и управления.

Платформа анализа данных SQL Server, которая интегрирована с MS Office, позволяет открыть доступ к необходимой бизнес-информации с помощью интерфейса MS Word и MS Excel.

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

Oracle

Oracle включает СУБД и средства разработки и анализа данных.

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

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

spravochnick.ru

9 Разновидности современных субд

В настоящее время известны сотни СУБД, однако, наибольшую популярность завоевали Access, Fox Pro, SQL SERVER фирмы Microsoft, Paradox ,Visual dBase фирмы Borland, Oracle, Informix, DB2, SQL Base и др.

MS Access 2002

Наиболее популярная реляционная СУБД настольного типа, предназначенная для работы, как пользователей средней квалификации, так и профессиональных разработчиков баз данных. Может применяться локально и в сети с архитектурой «файл-сервер». Входит в состав пакета Microsoft Office Professional. Для фирм малого бизнеса MS Access стала де факто стандартом.

MS SQL Server 7.0.

MS SQL Server 7.0 – это реляционная СУБД построенная по архитектуре «клиент-сервер». Может управлять до 32 767 базами данных, а каждая база данных может включать до 2 млрд. таблиц. В одной таблице может быть до 1024 столбцов, количество строк не ограничено. Позволяет осуществлять до 30 тыс. транзакций в минуту.

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

Oracle 8

Объектно-реляционная СУБД, построенная на основе соединений объектно-ориентированной и реляционной теории. Разработана с ориентацией на операционную систему Windows. СУБД Oracle 8 поддерживает технологию распределенной обработки данных, совмещенную с функционированием централизованной базы данных. Есть данные, что СУБД Oracle 8 может функционировать в среде 10 тыс. пользователей и базах данных объемом 100 терабайт (1 ТВ – 1048 576 000 000 байт) выполняет от 40 до 110 тыс. транзакций в минуту.

Поддерживает совместимость с базами других систем (Access, DB2 и др.).

СУБД Oracle является на сегодняшний день самой мощной, многофункциональной и легко масштабируемой СУБД, построенной по архитектуре «клиент-сервер»

8 Общая характеристика субд мs Access 2007.

Аccess – в переводе с английского означает “доступ”. MS Access – это функционально полная реляционная СУБД. Кроме того, MS Access одна из самых мощных, гибких и простых в использовании СУБД. В ней можно создавать большинство приложений, не написав ни единой строки программы, но если нужно создать нечто очень сложное, то на этот случай MS Access предоставляет мощный язык программирования – Visual Basic Application.

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

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

— система имеет полностью русифицированную версию;

— полная интегрированность с пакетами Microsoft Office: Word, Excel, Power Point, Mail;

— идеология Windows позволяет представлять информацию красочно и наглядно;

— возможность использования OLE технологии, что позволяет установить связь с объектами другого приложения или внедрить какие-либо объекты в базу данных Access;

— технология WYSIWIG позволяет пользователю постоянно видеть все результаты своих действий;

— широко и наглядно представлена справочная система;

— существует набор “мастеров” по разработке объектов, облегчающий создание таблиц, форм и отчетов.

К основным объектам Access относятся таблицы, запросы, формы, отчеты, макросы и модули.

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

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

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

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

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

Работа с формами и отчетами существенно облегчается за счет использования макрокоманд. В MS Access имеется свыше 40 макрокоманд, которые можно включать в макросы. Макрокоманды выполняют такие действия, как открытие таблиц и форм, выполнение запросов, запуск других макросов, выбор опций из меню, изменение размеров открытых окон и т.п. Макрокоманды позволяют нажатием одной (или нескольких одновременно) кнопки выполнять комплекс действий, который часто приходится выполнять в течение работы. С их помощью можно даже осуществлять запуск приложений, поддерживающих динамический обмен данных (DDE), например MS Excel, и производить обмен данными между вашей базой данных и этими приложениями. Один макрос может содержать несколько макрокоманд. Можно также задать условия выполнения отдельных макрокоманд или их набора.

Модуль – объект, содержащий программы на MS Access Basic, которые позволяют разбить процесс на более мелкие действия и обнаружить те ошибки, которые невозможно было бы найти с использованием макросов.

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

studfiles.net

Использование современных СУБД в информационных системах АЭС

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

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

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

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

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

                    Сетевые;

                    Реляционные;

                    Объектно-реляционные;

                    Объектно-ориентированные.

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

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

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

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

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

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

                    Локальные;

                    Распределенные.

Локальные СУБД размещают компоненты системы на одном компьютере.

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

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

                    Файл-серверные;

                    Клиент-серверные;

                    Встраиваемые.

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

Клиент-серверные системы состоят из клиентской части (прикладная программа) и сервера СУБД. Клиент-серверные СУБД обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней программой, и по мере надобности его можно заменить другим. Недостатком клиент-серверных СУБД заключается в необходимости больших вычислительных ресурсов, потребляемых сервером. Примерами клиент-серверной СУБД являются Oracle, MSSQLServer, PostgreSQL, MySQL, ЛИНТЕР.

Встраиваемая система — это своего рода библиотека, которая позволяет хранить большие объёмы данных на локальной машине. Доступ к данным может происходить посредством языка SQL либо через особые функции системы управления. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном программном обеспечении, которое имеет дело с большими объёмами данных. Примерами встраиваемых систем может послужить SQLite, MicrosoftSQLServerCompact, ЛИНТЕР.

Основная задача информационной системы — повышение эффективности и качества бизнес-процессов, в том числе происходящих на атомных электростанциях. ИС также обеспечивают выполнение ряда задач:

                    эффективный мониторинг на всех этапах и процессах жизненного цикла;

                    оптимизация процессов при сооружении и эксплуатации атомных электростанций;

                    преемственности информации между этапами, процессами и проектами.

В настоящее время имеется достаточно много разработок информационных систем, ядром которых является база данных. Вопросам разработки и использования баз данных в информационных системах посвящены работы российских ученых [1,2,4].

Одним из ярких примеров внедрения ИС на АЭС является информационная система «База Данных Вывода из Эксплуатации ядерных и радиационно-опасных объектов», которая реализует технологию информационной поддержки вывода из эксплуатации ядерных и радиационно-опасных объектов [5].

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

Система введена в эксплуатацию на Курской АЭС в ноябре 2013 года, за время работы получила множество одобрительных отзывов мировых экспертов.

Другим примером активного использования ИС в атомной индустрии может послужить ИС для проведения квалификации на сейсмостойкость электрооборудования системы управления защитой АЭС.

Основной задачей электрооборудования СУЗ АЭС является обеспечение безопасности функционирования АЭС при возникновении аварийных ситуаций, в частности, при сейсмических воздействиях. Структура базы данных для информационной системы была разработана в среде MS Access 2007.

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

ИС разработана для реакторов типа ВВЭР и в настоящее время эксплуатируется более чем на пятидесяти энергоблоках АЭС России и за рубежом.

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

Литература:

1.      Виштак Н. М. Тестирование как один из важнейших этапов создания информационных систем // Н. М. Виштак, А. Д. Шведченко // Технические науки — от теории к практике. — 2014. — № 36. — С. 17–22.
2.      Виштак О. В. Объектная модель хранилища данных информационно-аналитической системы вузовского центра дополнительного образования / О. В. Виштак, И. А. Штырова // Объектные системы. — 2011. — № 5 (5). — С. 49–52.
3.      Грибко В. М. Информационная система поддержки жизненного цикла оборудования при сооружении и эксплуатации АЭС/ В. М. Грибко // АТОМЭКС. — М., 2010. — № 1. — С. 59–63.
4.      Фролов Д. А. Анализ видов компьютерных обучающих систем для подготовки персонала промышленного предприятия и современных технологий их построения / Д. А. Фролов // Инновационные информационные технологии. — 2013. — Т. 1. № 2. — С. 431–434.
5.      Черников О. Г. Разработка базы данных для вывода из эксплуатации блоков ЛАЭС / О. Г. Черников, В. А. Шапошников, В. Л. Тихоновский [и др.] // Рациональное управление предприятием. — М., 2008. — № 1– С. 36–38

moluch.ru

Обзор: Рынок BI в России 2013, Современные СУБД: оптимум и идеал

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

В большинстве крупных компаний сегодня накапливаются терабайты важных бизнес-данных. СУБД внедряется для регулярного пополнения хранилища данных и их дальнейшего анализа. Со временем эта система становится основой как для принятия повседневных решений, так и для долгосрочного планирования. Соответственно, чем дольше компания существует на рынке и чем больше она становится, тем больше данных скапливается в ее архивах. Так, рекордсмен по числу данных компания Google в 2012 году обрабатывала в день до 24 ПБ информации (1 петабайт – это примерно 20 млн кабинетов, заполненных документами). Какие же требования компании должны предъявлять к системам, которые будут работать с этим необъятным ресурсом?

Лидеры мирового рынка СУБД, 2012

Источник: IBISWorld Database, 2013

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

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

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

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

Множество вариантов

При выборе решения CIO должны ориентироваться на потребности бизнеса. «Мне не пришлось выбирать тип системы СУБД, так как на момент «получения» ИТ-инфраструктуры уже был выбран Microsoft SQL Server. Процесс был актуален, но мы поняли, что для нашей компании выгоднее и наименее безболезненно будет просто обновить версию СУБД. Считаю, что основной функционал современной СУБД – это средства построения, отказоустойчивость и резервное хранение. Текущее решение меня устраивает, так как оно удовлетворяет всем моим требованиям, а я, соответственно, стремлюсь удовлетворять требования бизнеса», – отметил Александр Кириченко, руководитель отдела автоматизации компании «7 Цветов».

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

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

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

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

СУБД в облаках

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

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

«Каким сегодня должен быть оптимальный функционал СУБД? Я не знаю ответа на этот вопрос, более того, полагаю, что его не существует. Не может быть одного лучшего решения для систем разного класса. Для учетных систем нужен один функционал, для аналитических – другой, для обработки плохо структурированной информации – третий. В первую очередь стоит задумываться о задаче, которую мы собираемся решать, использую ту или иную СУБД», — считает Владимир Недобой, заместитель директора департамента интеграционных технологий, компания R-Style.

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

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

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

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

Евгений Смирнов

www.cnews.ru