Шпаргалка по "Информатике"

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

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

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

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

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

Гомогенные и  гетерогенные распределенные БД

РаБД можно классифицировать на гомогенные и гетерогенные.

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

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

 

 

 

 

 

 

 

73.Распределенные  СУБД (РаСУБД). Двенадцать  правил  К. Дейта

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

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

· набор логически связанных  разделяемых данных;

· сохраняемые данные разбиты  на некоторое количество фрагментов;

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

· фрагменты и их реплики  распределены по различным узлам;

· узлы связаны между собой  сетевыми соединениями;

· работа с данными на каждом узле управляется локальной СУБД.

Основные свойства распред. СУБД:

1)прозрачность располож. данных;

2)гетерогенность системы;

3)прозрачность сети(система должна работать в условиях гетерогенной сети);

4)поддержка распред. запросов, изменений, транзакций(пользователь должен иметь возможность выполнять запросы, изменения и транзакции);

5)безопасность(обеспечить защиты всей РБД от несанкц-ого доступа);

6)универсальность доступа(единая методика доступа ко всем данным).

Могут возникать  проблемы:

1)снижение произ-ти за  счёт несбалан-ти и низкой пр-ти  сетей передачи данных;

2)длительная блокировка  данных при выполнении распре-ной транзакций;

3)необходимость обеспеч.  совместимости данных стандартного  типа, для хранения кот. в разных сис-мах используются разл. форматы и кодировки;

4)неэффект. выбор схемы  размещения сис-ных каталогов;

5)увелич. потреб. в ресурсах для координации работы приложений с целью обнаруж. разнообразных коллизий. 

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

1. Локальная автономность. В данном контексте автономность  означю следующее:

· лок. данные принадлежат  локальным владельцам и сопровождаются локально;

· все локальные процессы остаются чисто локальными;

· все процессы на заданном узле контролируются только этим узлом.

2. Отсутствие опоры на  центральный узел. В системе не  должно быть ни одного узла, без которого система не сможет  функционировать, т.е. никакой  конкретный сервис (управление транзакциями, оптимизация запросов и др.) не  должен возлагаться на какой-либо  специально выделенный центральный  узел.

3. Непрерывное функционирование. В идеале в системе не должна  возникать потребность в плановом  останове ее функционирования.

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

5. Независимость от фрагментации. Пользователь должен получать  доступ к данным независимо  от способа их фрагментации.

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

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

8. Обработка распределенных  транзакций. Система должна поддерживать  выполнение транзакций.

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

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

11. Независимость от операционной  системы. Система должна быть  способна функционировать под  управлением различных операционных  систем.

12. Независимость от типа  СУБД.

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

· к какому фрагменту следует  обратиться;

· какую копию фрагмента  использовать, если его данные реплицируются;

· какое из местоположений должно использоваться.

Для обеспечения  целостности РаСУБД – 2 механизма:

-механизм пофазной фиксации  синхронный захват всех объектов  данных, к кот. обращ-ся или происх-ит изменения на всех серверах, либо осущ-ся откат в случае хотя бы 1 ошибки)

-механизм асинхронного  тиражирования (обраб-ка данных  осущ-ся локально, а распред-ые  данные копир-ся на тот сервер, где они должны использов-ся)

Преимущества РаСУБД:

1. Отражение структуры  организации.

2. Разделяемость и локальная  автономность.

3. Повышение доступности  данных.

4. Повышение надежности.

5. Повышение производительности.

6. Экономические выгоды.

7. Модульность системы.

Недостатки РаСУБД:

1. Повышение сложности. 

2. Увеличение стоимости. 

3. Проблемы защиты, связ-ые  с необх-ю контролир-ть доступ  к данным и защитой сетевых  соединений

4. Усложнение контроля за целостностью данных.

5. Недостаточная стандартизация, затрудняющая преобраз-е системы

6. Не накопленный  необходимый  опыт промышленной эксплуатации  распределенных систем

7.  Усложнение процедуры  проектирования БД.

8.  Сложность управления  и потенциальная опасность потери  целостности данных.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

75.Типы интерфейсов  доступа к БД. ODBC (Open Database Connectivity) —программный интерфейс доступа к БД, разраб-ый фирмой Microsoft. В начале 1990 г. существовало несколько поставщиков БД, каждый из которых имел собственный интерфейс. Если приложению было необходимо общаться с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать свой код. Для решения возникшей проблемы Microsoft и ряд других компаний создали стандартный интерфейс для получения и отправки источникам данных различных типов. Этот интерфейс был назван ODBC, или открытая связь с базами данных. C помощью ODBC прикладные программисты могли разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками. MFC усовершенствовала ODBC для разработчиков приложений. Истинный интерфейс ODBC является обычным процедурным API. Вместо создания простой оболочки процедурного API, разработчики MFC создали набор абстрактных классов, представляющих логические сущности в БД.

При применении ODBC требуется помнить, что данная технология доступа к  данным не рассчитана на работу с большим  числом клиентов. ADO — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников в объектно-ориентированном виде. JDBC — платформенно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql. JDBC основана на концепции так называемых драйверов, позволяющих перемещение столбца· выделение столбца; получать соединение с БД по специально описанному URL. Драйверы могут загружаться динамически. Загрузившись, драйвер сам регистрирует себя и вызывается автоматически, когда программа требует URL, содержащий протокол, за который драйвер отвечает.

JDBC API содержит два основных типа интерфейсов: первый - для разработчиков приложений и второй (более низкого уровня) - для разработчиков драйверов. Соединение с БД описывается классом, реализующим интерфейс java.sql.Connection. Имея соединение с БД можно создавать объекты типа Statement, служащие для исполнения запросов к базе данных на языке SQL.

76.OLAP-технология  и хранилище данных (ХД).  Отличия  ХД от базы данных. Классификация  ХД. Технологические решения ХД. Программное обеспечение для  разработки ХД.

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

На базе ХД – OLAP-системы. Для организации хранилищ исп-ся:

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