Базы данных (стр. 10 )

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

-  стали предоставлять доступ к данным серверных СУБД к моменту появления первых 32-разрядных версий;

-  приобрели средства публикации данных в Internet и поддерживают создание приложений для редактирования данных с помощью Web-браузеров;

-  начали предоставлять возможность хранить описания правил ссылочной целостности внутри БД;

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

Иными словами, история развития настольных СУБД отражает современные тенденции развития информационных систем, такие как создание распределенных систем с использованием Internet или Intranet, применение средств быстрой разработки приложений и массовый перенос приложений, использующих БД, включая настольные приложения, в архитектуру «клиент/сервер».

Серверные СУБД

На сегодняшний день известно более двух десятков серверных СУБД, однако наиболее популярными следует признать Oracle, Microsoft SQL Server, Informix, Sybase, DB2. Сведения о производителях этих СУБД представлены в следующей таблице:

Характерные черты современных серверных СУБД

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

Сервисы, предоставляемые серверными СУБД

1.  Реализация для нескольких платформ.

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

2.  Административные утилиты.

Администрирование сервера БД — удел профессионалов. Однако и профессионал предпочтет удобные утилиты администрирования унылому окну с интерфейсом командной строки. Наличие удобных утилит администрирования иногда оказывается одним из решающих факторов при выборе СУБД. Именно поэтому подавляющее большинство современных СУБД обычно поставляется с подобными утилитами, и их интерфейс в последнее время напоминает интерфейс Windows Explorer.

3.  Резервное копирование данных.

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

4.  Обслуживание репликаций.

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

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

5.  Параллельная обработка данных в многопроцессорных системах.

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

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

6.  Поддержка OLAP и создания хранилищ данных.

Технология оперативной аналитической обработки данных OLAP (On-Line Analytical Processing) представляет собой технологию построения многомерных хранилищ данных (Data Warehouses), как правило, агрегатных, т. е. являющихся результатом обработки набора данных, нередко состоящего из нескольких таблиц.

Многомерные хранилища данных реализуются в виде нереляционной многомерной БД. Такое хранилище обычно управляется отдельным сервером. Многие производители серверных СУБД поставляют такие серверы отдельно (Oracle, Informix), некоторые включают их в состав сервера реляционных БД (Microsoft SQL Server). Нередко с целью повышения конкурентоспособности подобные OLAP-системы строят многомерные хранилища на основе данных из других СУБД, как это сделано, например, в Microsoft SQL Server OLAP Extensions и в Sybase Adaptive Server IQ.

7.  Распределенные запросы и транзакции.

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

8.  Средства проектирования данных.

Многие производители серверных СУБД производят также средства анализа бизнес-процессов и проектирования данных, иногда универсальные (как в случае Sybase DataArchitect), а порой ориентированные на конкретную СУБД (как в случае Oracle Designer). Многие производители СУБД не имеют в своем арсенале собственных средств проектирования данных, ориентируясь на универсальные CASE-средства типа Platinum ERwin. Нередко производители СУБД встраивают в административные утилиты несложные средства проектирования данных, позволяющие визуально редактировать схемы данных, как это сделано, например, в Microsoft SQL Server.

9.  Поддержка собственных и «чужих» средств разработки и генераторов отчетов.

Многие производители серверных СУБД выпускают также средства разработки и генераторы отчетов. Иногда данные средства разработки используют тот же язык программирования, что применяется при написании триггеров и хранимых процедур. Типичный пример подобного подхода реализован в Oracle Developer. Однако чаще средства разработки производителей серверных СУБД используют языки программирования, отличные от языков создания серверного кода (характерный пример — четыре средства разработки Microsoft).

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

10.  Поддержка доступа к данным с помощью Internet.

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

2.  Недостатки реляционных СУБД

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

-  Автоматизированное проектирование.

В БД для систем автоматизированного проектирования (Computer-Aided Design – CAD) должны храниться данные, относящиеся к проектам механических и электротехнических конструкций, например, зданий, самолетов или интегральных микросхем. Такие проекты имеют следующие общие характеристики:

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

2.  Проекты могут быть очень большими, включающими миллионы элементов, часто со многими относительно независимыми подчиненными проектами.

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

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

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

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

-  Автоматизированное производство.

В БД для автоматизированного производства (Computer-Aided Manufacturing – CAM) хранятся данные, аналогичные данным CAD-систем, а также данные о дискретных (например, автомобилях на конвейере) или непрерывных (например, продукты химического синтеза) продуктах. В химической промышленности широко используются приложения, которые отслеживают информацию о состоянии системы: температура в реакторе, скорость потоков и уровень выхода продуктов реакции. Существуют также приложения, которые контролируют различные физические процессы, например, открытие клапанов, позволяющих передавать большое количество теплоты к реактору или увеличить поток в охлаждающий системах. Такие приложения часто имеют иерархическую структуру, в которой приложения высокого уровня отслеживают работу всего предприятия в целом, а приложения низкого уровня – отдельные производственные процессы. Эти приложения должны работать в режиме реального времени и быть способны эффективно управлять процессами для поддержания оптимальной производительности в рамках заданных допусков. Вычислительные системы должны хранить огромный объем данных с иерархической природой, а также сложные связи между данными.

-  Автоматизированная разработка программного обеспечения.

В БД системы автоматизированной разработки программного обеспечения (Computer-Aided Software Engineering – CASE) хранятся данные, относящиеся к различным этапам жизненного цикла разработки программного обеспечения: планированию, сбору и анализу требований, проектированию, реализации, тестированию, сопровождению и документированию. CASE-проекты могут быть очень большими и для их реализации обычно применяется коллективная разработка.

-  Офисные информационные системы и мультимедиа системы.

БД офисной информационной системы (Office Information System – OIS) хранит данные, которые относятся к управлению бизнес-информацией, с помощью компьютера, включая электронную почту, документы, счета и т. д. Для предоставления большей поддержки в этой области необходимо иметь дело с типами данных в более широком диапазоне, чем просто имена, адреса, даты и деньги. Современные системы способны работать с текстами произвольного формата, фотографиями, диаграммами, аудио - и видеозаписями. Например, мультимедиа-документ может содержать текст, фотографии, электронные таблицы и голосовые комментарии. Документы могут обладать особой структурой (HTML). Документы могут совместно использоваться многими пользователями с помощью таких средств, как электронная почта и электронные доски объявлений, функционирующие в среде Internet. Такие приложения должны уметь хранить данные с более богатой структурой, чем простейшие записи, состоящие из чисел и коротких текстовых строк.

-  Цифровое издательское дело.

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

-  Геоинформационные системы.

В БД геоинформационной системы (Geographic Information System – GIS) хранятся разные типы такой пространственной и временной информации, которая используется в землеустройстве и подводных изысканиях. Большинство данных в этих системах получено в результате геологических исследований и на основе аэрофотосъемки, поэтому они могут иметь очень большой объем.

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

Реляционная модель данных и РСУБД имеют определенные недостатки:

-  Слабое представление сущностей реального мира.

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

-  Семантическая перегрузка.

Реляционная модель обладает только одной конструкцией для представления данных и связей между данными – отношением. Например, для представления связи типа N:N между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье – для представления связи. Не существует никакого механизма для установления различий между сущностями и связями или между разными типами связей, заданными между сущностями. Например, связь типа 1:N может иметь разный смысл: имеет, владеет, управляет и т. д. Если бы подобные различия можно было отразить в схеме, то операциям можно было бы придать определенный семантический смысл. Из-за отсутствия подобных возможностей говорят, что реляционная модель семантически перегружена.

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

-  Слабая поддержка ограничений целостности и корпоративных ограничений.

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

-  Однородная структура данных.

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

-  Ограниченный набор операций.

Реляционная модель обладает только фиксированным набором операций, включающим операции с множествами и записями, определенные в спецификации SQL, которая не допускает определения новых операций. Это накладывает большие ограничения на моделирование поведения объектов «реального мира». Например, в GIS-приложении обычно используются точки, линии, группы линий и многоугольники, для работы с которыми требуются операции определения расстояния, нахождения пересечения и оценки включения.

-  Трудности организации рекурсивных запросов.

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

-  Проблема рассогласования.

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

1.  Язык SQL является декларативным языком программирования, который оперирует строками данных, а такой высокоуровневый язык, как язык С, является процедурным языком программирования, который может управлять только одной строкой данных за один раз.

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

3.  Из-за использования двух различных типов систем невозможно организовать в автоматическом режиме контроль типов во всем приложении в целом.

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

Вопросы для самоконтроля

1.  Какие настольный СУБД Вам известны?

2.  Перечислите основные закономерности развития настольных СУБД.

3.  Какие серверные СУБД Вам известны?

4.  Перечислите характерные черты современных серверных СУБД.

5.  Перечислите предметные области, в которых реляционные СУБД не справляются.

6.  Перечислите основные недостатки реляционных СУБД.

Тема 12. Тенденции развития современных баз данных.

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

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

-  объектно-ориентированные БД;

-  технология «Хранилищ данных» (Data Warehouse);

-  интеграция с Internet-технологиями;

-  темпоральные БД;

-  дедуктивные БД;

-  многомерные БД.

1.  Постреляционная модель

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

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

Например:

Таблица НАКЛАДНЫЕ

Таблица НАКЛАДНЫЕ-ТОВАРЫ

В представленных реляционных таблицах связь установлена по полю Номер накладной. Постреляционная модель для этой задачи имеет вид:

Таблица НАКЛАДНЫЕ

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

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

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

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

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

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

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

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

3.  Технология «Хранилищ данных»

Ориентированная на интеграцию данных технология «Хранилищ данных» (Data Warehouse), включающая средства оперативной аналитической обработки данных (OLAP), что позволяет извлекать из БД дополнительные знания.

Для работы с «Хранилищами данных» наиболее значимым становится интеллектуальный анализ данных (ИАД), или data mining, - это процесс выявления значимых тенденций в больших объемах данных.

Наибольший интерес представляет интеграция методов интеллектуального анализа данных с технологией оперативной аналитической обработки данных (On-Line Analytical Processing, OLAP). OLAP использует многомерное представление агрегированных данных для быстрого доступа к важной информации и дальнейшего ее анализа.

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

Хранилища данных могут быть разбиты на два типа:

1.  Корпоративные хранилища данных (enterprise data warehouses). Корпоративные хранилища данных содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Обычно такие хранилища охватывают целый ряд аспектов деятельности корпорации и используются для принятия как тактических, так и стратегических решений.

2.  Киоски данных (data marts). Киоски данных содержат подмножество корпоративных данных и строятся для отделов или подразделений внутри организации. Киоски данных часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела. Киоск данных может получать данные из корпоративного хранилища (зависимый киоск), или данные могут поступать непосредственно из оперативных источников (независимый киоск).

Киоски и хранилища данных строятся по сходным принципам и используют практически одни и те же технологии.

4.  Интеграция с Internet-технологиями

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

В будущем статические HTML-страницы все чаще станут заменяться системами управления динамически формируемым содержимым. HTML расширяется до XML, языка расширяемой разметки, который лучше описывает структурированные данные.

Для разработки Интернет-приложений, которые связаны с БД, широко используются новые средства программирования: это язык PERL, язык PHP (Personal Home Page Tools), язык Javascript и ряд других.

5.  Темпоральные БД

Перспективным направлением развития БД является появление темпоральных БД, т. е. БД, чувствительных ко времени.

Фактически БД моделирует состояние объектов предметной области в некоторый текущий момент времени. Однако в ряде прикладных областей необходимо исследовать именно изменение состояний объектов во времени. Если использовать чисто реляционную модель, то требуется строить и хранить дополнительно множество отношений, имеющих одинаковые схемы, отличающиеся временем существования или снятия данных. Гораздо перспективнее и удобнее для этого использовать специальные механизмы снятия срезов по времени для определенных объектов БД. Основной тезис темпоральных систем состоит в том, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователю) все его состояния во временном интервале [t1,t2).

6.  Дедуктивные БД

Еще одним из перспективных направлений развития БД является направление, связанное с объединением технологии экспертных систем и БД и развитие дедуктивных БД.

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

7.  Многомерные БД

Для обеспечения быстрой обработки данных при их анализе используются разнообразные приемы. Одним из них является организация данных в виде так называемых многомерных БД (МБД). Информация в МБД хранится не в виде индексированных записей в таблицах, а в форме логически упорядоченных массивов. Единой общепризнанной многомерной модели хранения данных не существует. В МБД отсутствует стандартизованный метод доступа к данным, и они могут отвечать требованиям специфической аналитической обработки данных.

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

Пример сравнения реляционной и многомерной организаций данных:

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

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

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

Вопросы для самоконтроля

1.  Расскажите о перспективах развития баз данных.

2.  Какие новые технологии, применяемые в теории баз данных, Вам известны?

Краткий конспект лекций

по дисциплине

«Базы данных»

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8 9 10