2. Объектно-ориентированная  СУБД

 

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

Примеры объектно-ориентированной СУБД:

• IBM Lotus Notes/Domino
• Jasmine
• ObjectStore
• Caché
• СООБЗ Cerebrum
• db4objects

1.1.3. Многомерная СУБД

 

OLAP(On-line Analytical Processing) - многомерные базы данных.

Программное обеспечение OLAP используется при обработке данных из различных источников. Эти программные продукты позволяют реализовать множество различных представлений данных и характеризуются тремя основными чертами: многомерное представление данных; сложные вычисления над данными; вычисления, связанные с изменением данных во времени.

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

Многомерные базы, в силу чисто исторических причин, “не умеют” работать с большими объемами данных. На сегодняшний день, их реальный предел - база объемом в 10-20 гигабайт. И хотя это ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С этим нельзя не считаться. К тому же, за счет денормализации и предварительно выполненной агрегации, 20 гигабайт в многомерной базе, в лучшем случае эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда, для систем основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. Здесь необходимо остановиться на основном недостатке многомерных баз данных – неэффективному, по сравнению с реляционными базами данных, использованию внешней памяти. В основе многомерного подхода лежит представление данных в виде многомерных гиперкубов, при этом обычно предполагается, что внутри такого гиперкуба нет пустот. То есть все ячейки куба всегда заполнены. Это связано с тем, что данные в них обычно хранятся в виде множества логически упорядоченных блоков (массивов), имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей. В многомерных СУБД обычно предполагается, что блоки, полностью заполненные неопределенными значениями, не хранятся, это обеспечивает лишь частичное решение проблемы. Данные в таких системах хранятся в упорядоченном виде. Неопределенные значения устраняются, и то частично, только в том случае, если мы за счет выбора порядка сортировки сгруппируем их в максимально большие непрерывные группы. Следовательно, использование многомерных СУБД оправдано только при следующих условиях:

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

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

Достоинства этих СУБД

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

А так же они  имеют и ряд недостатков:

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

1.1.4. Иерархическая СУБД

 

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

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор существуют базы, которые поддерживаются этой СУБД. Иерархические модели имеют древовидную структуру, где каждому узлу соответствует один сегмент, представляющий собой поименованный линейный кортеж полей данных. Каждому сегменту соответствует один входной и несколько выходных сегментов. Каждый элемент структуры лежит на единственном иерархическом пути, начинающемся от корневого. Иерархические базы данных наиболее пригодны для моделирования структур, по своей природе являющихся иерархическими. В качестве примеров можно привести воинские подразделения или сложные механизмы, состоящие из более простых узлов, которые в свою очередь тоже можно подвергнуть декомпозиции. Тем не менее существует значительное количество организаций, не сводящихся к простой иерархии. В этой модели запрос, направленный вниз по иерархии, прост, однако запрос, направленный вверх по иерархии, более сложен. К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархической базой данных является файловая система, состоящая из корневой директории, в которой имеется древовидная структура поддиректорий и файлов.  

Недостатки СУБД иерархического типа:

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

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

1.1.5. Сетевая СУБД

 

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

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

Недостатки сетевых СУБД:

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

 

1.2. Обзор рынка программного обеспечения СУБД в РБ

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

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

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

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

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

– база данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности;

– база данных должна удовлетворять выявленным и вновь возникающим требованиям  конечных пользователей;

– база данных должна легко расширяться при реорганизации и расширении предметной области;

– база данных должна легко изменяться при  изменении программной и аппаратной среды;

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

– данные до включения в базу данных должны проверяться на достоверность;

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

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

Рассмотрим  средства разработки, которые предлагает Microsoft: