Много информации это просто груда мусора


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



страница9/9
Дата29.04.2018
Размер1.56 Mb.
ТипЛекция
1   2   3   4   5   6   7   8   9

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


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

  2. Направления развития концепций и систем обработки данных

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

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

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

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

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

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


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


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

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


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

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

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

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

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

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




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

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


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

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


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

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


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

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


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

В БД геоинформационной системы (Geographic Information SystemGIS) хранятся разные типы такой пространственной и временной информации, которая используется в землеустройстве и подводных изысканиях. Большинство данных в этих системах получено в результате геологических исследований и на основе аэрофотосъемки, поэтому они могут иметь очень большой объем.
Также имеются научные и медицинские приложения, в которых могут храниться комплексные данные, представляющие такие сложные системы, как молекулярные модели для синтезированных химических компонентов и генетических материалов; экспертные системы, в которых могут храниться знания и правила, предназначенные для использования в приложениях искусственного интеллекта, и др.
Реляционная модель данных и РСУБД имеют определенные недостатки:

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

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


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

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

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




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

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


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

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

Во многих реляционных БД предусмотрено хранение больших бинарных объектов, или BLOB-объектов (Binary Large ObjectsBLOB). BLOB-объект – это значение данных, которое содержит бинарные данные, представляющие рисунок, оцифрованную видео- или аудиозапись, процедуру или любой другой неструктурированный объект. СУБД не обладает никакими сведениями о содержании BLOB-объекта или его внутренней структуре. Это предотвращает выполнение запросов и операций по отношению к сложным и структурированным типам данных. Обычно БД не содержит непосредственно саму информацию, а хранит лишь ссылку на некий файл. Использование BLOB-объектов не является элегантным решением. Хранение такой информации во внешних файлах не позволяет использовать многие средства защиты, которые естественным образом присутствуют в СУБД. BLOB-объекты не могут содержать другие BLOB-объекты, а потому не могут иметь вид составных объектов. BLOB-объекты обычно игнорируют поведенческие аспекты объектов. Например, в некоторой реляционной СУБД рисунок может храниться как BLOB-объект. Однако он при этом будет лишь храниться и отображаться. Не существует возможности управлять его внутренней структурой или отображать отдельные части этого рисунка, так или иначе манипулировать ими.




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

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


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

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


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

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


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




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




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

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


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


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

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

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

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

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

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


Постреляционная модель
Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц. Это означает, что информация в таблице представляется в первой нормальной форме. Существует ряд случаев, когда это ограничение мешает эффективной реализации приложений.
Постреляционная модель данных представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных, хранящихся в записях таблиц. Постреляционная модель данных допускает многозначные поля – поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу.
Например:
Таблица НАКЛАДНЫЕ

Номер накладной

Номер покупателя

0373

8723

8374

8232

7364

8723

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



Номер накладной

Название товара

Количество товара

0373

Сыр

3

0373

Рыба

2

8374

Лимонад

1

8374

Сок

6

8374

Печенье

2

7364

Йогурт

1

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


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

Номер накладной

Номер покупателя

Название товара

Количество товара

0373

8723

Сыр

3







Рыба

2

8374

8232

Лимонад

1







Сок

6







Печенье

2

7364

8723

Йогурт

1

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


Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.
Для описания функций контроля значений в полях имеется возможность создавать процедуры (коды конверсии и коды корреляции), автоматически вызываемые до или после обращения к данным. Коды коррекции выполняются сразу после чтения данных, перед их обработкой. Коды конверсии, наоборот, выполняются после обработки данных.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.
Объектно-ориентированные БД
В объектно-ориентированной концепции предметная область моделируется как множество классов взаимодействующих объектов. Каждый объект характеризуется набором свойств, которые являются его характеристиками, и набором методов работы с этим объектом. Работать с объектом можно только с использованием его методов. Атрибуты объекта могут принимать определенное множество допустимых значений. Набор конкретных значений атрибутов объекта определяет его состояние. Используя методы работы с объектом, можно изменять значение его атрибутов и тем самым изменять состояние самого объекта. Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу.
Одной из наиболее перспективных черт объектно-ориентированной концепции является принцип наследования. Допускается порождение нового класса на основе уже существующего класса, и этот процесс называется наследованием. В этом случае новый класс, называемый подклассом существующего класса, наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различают случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько.
Технология «Хранилищ данных»
Ориентированная на интеграцию данных технология «Хранилищ данных» (Data Warehouse), включающая средства оперативной аналитической обработки данных (OLAP), что позволяет извлекать из БД дополнительные знания.
Для работы с «Хранилищами данных» наиболее значимым становится интеллектуальный анализ данных (ИАД), или data mining, - это процесс выявления значимых тенденций в больших объемах данных.
Наибольший интерес представляет интеграция методов интеллектуального анализа данных с технологией оперативной аналитической обработки данных (On-Line Analytical Processing, OLAP). OLAP использует многомерное представление агрегированных данных для быстрого доступа к важной информации и дальнейшего ее анализа.
В основе концепции оперативной аналитической обработки (OLAP) лежит многомерное представление данных. Термин OLAP ввел Кодд в 1993 году. В своей статье он рассмотрел недостатки реляционной модели, в первую очередь невозможность «объединять, просматривать и анализировать данные с точки зрения множественности измерений», и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.
Хранилища данных могут быть разбиты на два типа:

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




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

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


Интеграция с Internet-технологиями
Web представляет собой одну громадную БД. Дизайнеры крупнейших Web-серверов с миллионами страниц содержимого постепенно перекладывают задачи управления страницами с файловых систем на системы БД. Системы БД используются в качестве серверов электронной коммерции. Ведущие Web-издатели примериваются к использованию систем БД для хранения информационного наполнения, имеющего сложную природу.
В будущем статические HTML-страницы все чаще станут заменяться системами управления динамически формируемым содержимым. HTML расширяется до XML, языка расширяемой разметки, который лучше описывает структурированные данные.
Для разработки Интернет-приложений, которые связаны с БД, широко используются новые средства программирования: это язык PERL, язык PHP (Personal Home Page Tools), язык Javascript и ряд других.
Темпоральные БД
Перспективным направлением развития БД является появление темпоральных БД, т.е. БД, чувствительных ко времени.
Фактически БД моделирует состояние объектов предметной области в некоторый текущий момент времени. Однако в ряде прикладных областей необходимо исследовать именно изменение состояний объектов во времени. Если использовать чисто реляционную модель, то требуется строить и хранить дополнительно множество отношений, имеющих одинаковые схемы, отличающиеся временем существования или снятия данных. Гораздо перспективнее и удобнее для этого использовать специальные механизмы снятия срезов по времени для определенных объектов БД. Основной тезис темпоральных систем состоит в том, что для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователю) все его состояния во временном интервале [t1,t2).
Дедуктивные БД
Еще одним из перспективных направлений развития БД является направление, связанное с объединением технологии экспертных систем и БД и развитие дедуктивных БД.
Эти БД основаны на выявлении новых знаний из БД не путем запросов или аналитической обработки, а путем использования правил вывода и построения цепочек применения этих правил для вывода ответов на запросы.
Многомерные БД
Для обеспечения быстрой обработки данных при их анализе используются разнообразные приемы. Одним из них является организация данных в виде так называемых многомерных БД (МБД). Информация в МБД хранится не в виде индексированных записей в таблицах, а в форме логически упорядоченных массивов. Единой общепризнанной многомерной модели хранения данных не существует. В МБД отсутствует стандартизованный метод доступа к данным, и они могут отвечать требованиям специфической аналитической обработки данных.
Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации. По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью.
Пример сравнения реляционной и многомерной организаций данных:


Модель

Месяц

Объем

«Жигули»

июнь

12

«Жигули»

июль

24

«Жигули»

август

5

«Москвич»

июнь

2

«Москвич»

июль

18

«Волга»

июль

19




Модель

Июнь

Июль

Август

«Жигули»

12

24

5

«Москвич»

2

18



«Волга»



19


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


Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации.
Разрабатываются также всевозможные системы, основанные на других моделях данных, расширяющих известные модели. В их числе можно назвать дедуктивно-объектно-ориентированные и семантические модели. Некоторые из этих моделей служат для интеграции БД, баз знаний и языков программирования. В некоторых СУБД поддерживается одновременно несколько моделей данных. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.
Каталог: upload -> iblock -> 549
iblock -> Часы-смартфон
iblock -> Руководство пользователя для телефона Apple iPhone 6
iblock -> Руководство по эксплуатации Методика калибровки Технические характеристики. Минимальный радиус кривизны поверхностей контролируемых изделий, 6мм
iblock -> Технические требования
iblock -> Технологические карты
iblock -> Оптимизация процесса восстановления измененных и уничтоженных маркировочных обозначений на блоках двигателей транспортных средств
iblock -> Инструкция по эксплуатации Температурный gsm извещатель Grinson T7 Благодарим Вас за выбор температурного gsm извещателя Grinson T7
549 -> Гост 4011-72 Вода питьевая. Методы измерения массовой концентрации общего железа


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница