Классическая реляционная модель данных требует, чтобы данные хранились в так называемых плоских таблицах.
Более точно, пользователи и приложения, обращающиеся к данным, должны работать с данными так, как если бы они размещались в таких таблицах. В упрощенном виде плоская таблица - это таблица, каждая ячейка, которой может быть однозначно идентифицирована указанием строки и столбца таблицы. Кроме того, в одном столбце все ячейки должны содержать данные одного простого типа.
Реляционная модель основана на теории множеств и математической логике. Такой фундамент обеспечивает математическую строгость реляционной модели данных.
В свою очередь, на основе реляционной модели были разработаны различные языки для доступа к реляционным данным, такие как SEQUEL, SQL, QUEL и другие. Фактическим промышленным стандартом в настоящее время стал язык SQL (Structured Query Language - язык структурированных запросов).
Кроме реляционных, объектно-ориентированных и многомерных СУБД, также давно известны иерархические и сетевые базы данных.
Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, управляющая реляционными базами данных.
Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
– каждый элемент таблицы — один элемент данных;
– все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);
– каждый столбец имеет уникальное имя;
– одинаковые строки в таблице отсутствуют;
– порядок следования строк и столбцов может быть произвольным.
Базовыми понятиями реляционных СУБД являются:
-атрибут;
-отношение;
-кортеж.
Объектно-ориентированная СУБД — реализующая объектно-ориентированный подход. Эта система управления обрабатывает данные как абстрактные объекты, наделённые свойствами, в виде неструктурированных данных, и использующие методы взаимодействия с другими объектами окружающего мира.
Примеры объектно-ориентированной СУБД:
-IBM Lotus Notes/Domino
-Jasmine
-ObjectStore
-Caché
-СООБЗ Cerebrum
-db4objects
OLAP(On-line Analytical Processing) - многомерныебазыданных.
Программное обеспечение OLAP используется при обработке данных из различных источников. Эти программные продукты позволяют реализовать множество различных представлений данных и характеризуются тремя основными чертами: многомерное представление данных; сложные вычисления над данными; вычисления, связанные с изменением данных во времени.
В СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов: гиперкубов (все хранимые в базе данных ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) и/или витрин данных, представляющих собой предметно-ориентированные подмножества хранилища данных, спроектированные для удовлетворения нужд отдельной группы (сообщества) пользователей и удовлетворяющие требованиям защиты от несанкционированного доступа в организации; они обеспечивают более быструю реакцию на запросы сведений за счет того, что обращения поступают к относительно небольшим блокам данных, необходимых для конкретной группы пользователей. Для достижения сравнимой производительности реляционные системы требуют тщательной проработки схемы базы данных, определения способов индексации и специальной настройки. В случае многомерных баз данных, как правило, не требуется даже указание на то, по каким реквизитам (группам реквизитов) требуется индексация данных. Ограничения SQL остаются реальностью, что не позволяет реализовать в реляционных СУБД многие встроенные функции, легко обеспечиваемые в системах основанных на многомерном представлении данных. Вместе с тем, реляционные СУБД обеспечивают качественно более высокий уровень защиты данных и разграничения прав доступа, а также имеют более развитые средства администрирования и реальный опыт работы с большими и сверхбольшими базами данных. В то время, как для многомерных баз данных, в настоящее время отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными. Многомерные СУБД не поддерживают репликацию данных, наиболее часто используемую в качестве механизма загрузки.
Многомерные базы, в силу чисто исторических причин, “не умеют” работать с большими объемами данных. На сегодняшний день, их реальный предел - база объемом в 10-20 гигабайт. И хотя это ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С этим нельзя не считаться. К тому же, за счет денормализации и предварительно выполненной агрегации, 20 гигабайт в многомерной базе, в лучшем случае эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда, для систем основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. Здесь необходимо остановиться на основном недостатке многомерных баз данных – неэффективному, по сравнению с реляционными базами данных, использованию внешней памяти. В основе многомерного подхода лежит представление данных в виде многомерных гиперкубов, при этом обычно предполагается, что внутри такого гиперкуба нет пустот. То есть все ячейки куба всегда заполнены. Это связано с тем, что данные в них обычно хранятся в виде множества логически упорядоченных блоков (массивов), имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей. В многомерных СУБД обычно предполагается, что блоки, полностью заполненные неопределенными значениями, не хранятся, это обеспечивает лишь частичное решение проблемы. Данные в таких системах хранятся в упорядоченном виде. Неопределенные значения устраняются, и то частично, только в том случае, если мы за счет выбора порядка сортировки сгруппируем их в максимально большие непрерывные группы. Следовательно, использование многомерных СУБД оправдано только при следующих условиях:
-объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок;
-набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба);
-время ответа системы на нерегламентированные запросы является наиболее критичным параметром;
-требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций.
Однако неверно было бы противопоставлять или говорить о какой либо конкуренции реляционного и многомерного подходов. Эти два подхода взаимно дополняют друг друга. Реляционный подход никогда не предназначался для решения на его основе задач, требующих синтеза, анализа и консолидации данных. Предполагалось, что такого рода функции, должны реализовываться с помощью внешних по отношению к реляционным СУБД инструментальных средств. В настоящее время, многомерные СУБД всё чаще используются не только как самостоятельный программный продукт, но и как аналитические средства в хранилищах данных или традиционных оперативных системам, реализуемых средствами реляционных СУБД. Такое решение позволяет наиболее полно реализовать и использовать достоинства каждого из подходов: компактное хранение детализированных данных и поддержка очень больших баз данных, обеспечиваемые реляционными СУБД и простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые многомерными СУБД.
Достоинства этих СУБД
-в случае использования многомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных денормализована, содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам.
-многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.
А так же они имеют и ряд недостатков:
- необходимость привлечения высококвалифицированных программистов для малейших изменений структуры базы данных.
- невозможность для конечного пользователя самостоятельно анализировать данные в порядке, не предусмотренном программистами.
Иерархическая СУБД (ИСУБД) - система управления базами данных, использующих в своей основе древовидную структуру.
Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор существуют базы, которые поддерживаются этой СУБД. Иерархические модели имеют древовидную структуру, где каждому узлу соответствует один сегмент, представляющий собой поименованный линейный кортеж полей данных. Каждому сегменту соответствует один входной и несколько выходных сегментов. Каждый элемент структуры лежит на единственном иерархическом пути, начинающемся от корневого. Иерархические базы данных наиболее пригодны для моделирования структур, по своей природе являющихся иерархическими. В качестве примеров можно привести воинские подразделения или сложные механизмы, состоящие из более простых узлов, которые в свою очередь тоже можно подвергнуть декомпозиции. Тем не менее существует значительное количество организаций, не сводящихся к простой иерархии. В этой модели запрос, направленный вниз по иерархии, прост, однако запрос, направленный вверх по иерархии, более сложен. К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархической базой данных является файловая система, состоящая из корневой директории, в которой имеется древовидная структура поддиректорий и файлов.