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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


Шпаргалка Шпаргалка по "Базам Данных"

Информация:

Тип работы: Шпаргалка. Добавлен: 14.09.2012. Сдан: 2011. Страниц: 9. Уникальность по antiplagiat.ru: < 30%

Описание (план):


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

Минус пункта 3: возможность нарушения  целостности данных при одновременной работе с БД нескольких пользователей
Примеры СУБД к п.3: dBase III PLUS, dBase IV, FoxBase
Сетевые СУБД
Не имеют  указанного недостатка, т.к. в них  существуют средства контроля, осуществляющие координацию доступа к данным.
При использовании сетевой СУБД обработка запросов пользователя по-прежнему осуществляется на компьютере клиента (минус – из-за необходимости быстродействия).

СУБД  осуществляет контроль целостности  данных. Изменяемая информация недоступна для параллельного изменения, но доступна для параллельного чтения.
Примеры сетевых СУБД: FoxPro 2.5, 2.6; Paradox
Технология  клиент-сервер
БД типа клиент-сервер отличаются от систем файл-сервер тем, что программы СУБД функционально  разделены на 2 части, называемые сервером и клиентом. Между клиентской и серверными частями возможны различные варианты распределения функций.
Клиент – ЭВМ, пользователь или программа. Они делят между собой аппаратные , информационные и программные ресурсы.
Программа-клиент – отвечает за интерфейс с пользователем, используется для преобразования запросов пользователя в команды запросов к серверной части и для проведения обратных преобразований при получении данных.
 В  роли клиента может выступать  пользовательская программа, разрабатываемая для решения прикладной задачи или готовая программа, имеющая интерфейс с серверной программой.

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

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

Модель  архитектуры клиент-сервер:
Для упорядочения разработки сетевого программного обеспечения  и обеспечения возможности взаимодействия любых вычислительных систем международная организация стандартов (ISO) разработала эталонную модель взаимодействия открытых систем (OSI – Open System Interconnection)
Эталонная модель имеет 7 функциональных уровней:
    Физический: рассматриваются стандарты передачи элементарных единиц – битовые протоколы передачи данных.
Характеристики: U0, U1, частота, длина «1» - физические аспекты передачи данных по проводнику
    Канальный: рассматриваются соглашения, связанные с формированием комплекта данных, подлежащих передаче. Из исходного сообщения формируется кадр, подлежащий передаче.
Характеристики: соглашение о передаче, тактовая частота  последовательного кода, обнаружение  и исправление ошибок, возникших  при одном такте передачи.
    Сетевой: организация взаимосвязи между двумя соседними узлами. Соединение организуется на основе маршрутизации, которая использует адреса в пакетах данных.
    Транспортный: организация взаимосвязи группы машин, пакетирование.
    Сеансовый: организация взаимодействия отправитель-получатель. Включает в себя реализацию технологии релейной связи, позволяющей выбирать максимально эффективный путь в текущей ситуации (наличие обходных путей, высокая интенсивность в пути, аварийное состояние), организация арендной платы, функции управления паролями, режимы восстановления связи
    Представительский (представления данных):
    Управляет кодировкой и перекодировкой данных, перемещающихся по сети;
    Обеспечивает представление данных в форматах, понятных пользователю;
    Преобразование пакетов в сообщения;
    Восстановление исходных сообщений.
    Прикладной (уровень приложений): обслуживание рабочего места пользователя, исполнение прикладной программы и индивидуальных запросов.
Функции управления БД относятся к прикладному  уровню.
В протоколе  между сетями согласованы все 7 уровней. Используется принцип вложенности.
Для поддержания  интерфейса с пользователем СУБД реализует следующие основные функции:
    управление данными;
    обработка информации с помощью прикладных программ;
    представление информации в удобном для пользователя виде.
 
Билет 3. Двухзвенная модель распределения функций.
    компьютер, на котором обязательно реализуется функция управления – компьютер-сервер;
    компьютер, на котором поддерживается представление информации – компьютер-клиента.
Спектр  моделей архитектуры  клиент-сервер

Модель 4 (RDA):
Программы, реализующие функции представления  и обработки совмещены и выполняются  на КК. Управление данными происходит через среду передачи данных с  помощью языка SQL или интерфейса прикладного программирования (API).
Плюсы: 1.множество СУБД имеют SQL интерфейсы; 2.Инструментальные средства для создания клиентских программ (Delphi и т.д.)
Минусы:1. Высокая загрузка системы передачи данных; 2. Неудобство с точки зрения сопровождения
Модель 2 (сервера БД) – DBS:
Отличается  от 4 тем, что функции КК ограничиваются функциями представления информации, а прикладные функции обеспечиваются приложениями, находящимися на КС.
Примеры: Ingress, Sybase, Oracle
Приложения  реализуются в виде хранимых в  словаре БД процедур.
Плюсы: 1.возможность централизованного администрирования приложения на этапах создания; 2.эффективное использование вычислительных и коммуникационных ресурсов
Минусы: 1.ограничение средств разработки хранимых процедур 2.низкая эффективность использования вычислительных ресурсов (трудно управлять потоком запросов).
Модель 1:
Имеется мощный КС и практически вырожденная клиентская часть системы. Используется для простого отображения информации.
    СУБД в сетях с Х-терминалами и хост-машинами;
    Ранние модели СУБД для малых, средних и больших ЭВМ;
    Системы обслуживания пользователей БД в неоднородной среде.
Плюсы: 1.простота обслуживания и управление доступом; 2.низкая стоимость
Минус – ненадежность
Модель 3:
Обработка данных распределена по двум узлам. Общая  часть прикладных функций реализована на КС (обеспечение целостности и безопасности данных), а специфические функции обработки информации выполняются на КК.
Подобную  модель имеют СУБД использующие информацию из нескольких неоднородных БД.
Модель 5:
Для пользователя – централизована.
Использование мощного КК, данные хранятся и на КК, и на КС, взаимосвязь обеих  БД может быть двух разновидностей:
    в локальной и удаленных базах хранятся отдельные части единой БД (фрагментация)
    локальная и удаленная БД являются синхронизируемыми (тиражирование и репликация)
Плюсы: 1.гибкость; 2.надежность работы
Минус – большие затраты при выполнении одинаковых приложений 

Билет 4. Трехзвенная модель распределения функций
AS -модель

Данная  модель представляет собой систему, при которой каждая из трех функций приложения ( управление данными, обработка, представление) реализуется на отдельном компьютере.
Компонент, реализующий функции представления  информации, взаимодействует с компонентом  приложения как в модели DBS. Компонент приложения, расположенный на отдельном компьютере, связан с компонентом управления данными подобно модели RDA (см. вопрос 3).
Центральным звеном AS-модели является сервер приложения, на котором реализуется несколько прикладных функций, каждая из которых может быть предоставлена всем программам клиента. Серверов приложений может быть несколько, причем каждый из них предоставляет свой вид сервиса. Поступающие от клиентов к серверам запросы помещаются в очередь, из которой могут быть выбраны в соответствии с заданным приоритетом.
Компонент приложения, реализующий функции  представления и являющийся клиентом для сервера приложения, может  служить для организации интерфейса с конечным пользователем (т.е. обеспечивать прием данных от различных устройств  или быть произвольной программой).
Достоинства: 1.гибкость и универсальность (за счет того, что различные функции реализованы на разных компьютерах); 2.- эффективность (за счет разделения функций).
Недостаток: высокие затраты ресурсов компьютера на обмен информацией. 
 

Билет 5. Транзакции. Восстановление транзакций
Транзакция
Под транзакцией  понимается неделимая с точки  зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации) такая, что либо результаты всех операторов, входящих в транзакцию, отображаются в БД, либо воздействие всех этих операторов полностью отсутствует. Лозунг транзакции - "Все или ничего": при завершении транзакции оператором COMMIT результаты гарантированно фиксируются во внешней памяти (смысл слова commit - "зафиксировать" результаты транзакции); при завершении транзакции оператором ROLLBACK результаты гарантированно отсутствуют во внешней памяти (смысл слова rollback - ликвидировать результаты транзакции).
Понятие транзакции имеет непосредственную связь с понятием целостности БД. Очень часто БД может обладать такими ограничениями целостности, которые просто невозможно не нарушить, выполняя только один оператор изменения БД. Пусть например существует 2 таблицы: Сотрудники и Отделы, причем в таблице отделы есть поле, хранящее число сотрудников в отделе. Надо принять на работу нового сотрудника. Для этого нужно выполнить 2 оператора: занести новую запись в таблицу сотрудники и изменить запись в таблице отделы. Либо мы сначала изменяем таблицу сотрудники, тогда таблица отделы некоторое время будет неверна, либо сначала изменяем таблицу отделы. В любом случае после выполнения только одного оператора бд будет находиться в противоречивом состоянии.
Поэтому для поддержания подобных ограничений целостности допускается их нарушение внутри транзакции с тем условием, чтобы к моменту завершения транзакции условия целостности были соблюдены. В системах с развитыми средствами ограничения и контроля целостности каждая транзакция начинается при целостном состоянии БД и должна оставить это состояние целостными после своего завершения. Несоблюдение этого условия приводит к тому, что вместо фиксации результатов транзакции происходит ее откат (т.е. вместо оператора COMMIT выполняется оператор ROLLBACK), и БД остается в таком состоянии, в котором находилась к моменту начала транзакции, т.е. в целостном состоянии.
Ни одна СУБД не обладает механизмами деления  процесса обработки данных не отдельные  транзакции, это должен делать прикладной программист с помощью операторов BEGIN TRANSACTION, COMMIT или ROLLBACK
Свойства  транзакций:
    Атомарность (все или ничего) – любая транзакция является неделимой единицей работы
    Согласованность (непротиворечивость) – переводит бд из одного непротиворечивого состояния в другое
    Изолированность – все транзакции выполняются независимо друг от друга, те промежуточные результаты незавершенной транзакции недоступны другим транзакциям
    Продолжительность – результаты успешно завершенной транзакции сохраняются в бд и не могут быть утеряны при дальнейших сбоях
Восстановление  транзакций
Из определения  следует, что транзакции являются единицами  восстановления в СУБД. Общими принципами восстановления являются следующие:
    результаты зафиксированных транзакций должны быть сохранены (COMMIT) в восстановленном состоянии базы данных;
    результаты незафиксированных транзакций должны отсутствовать (ROLLBACK) в восстановленном состоянии базы данных.
Это означает, что восстанавливается последнее  по времени согласованное состояние  базы данных.
Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:
    Индивидуальный откат транзакции. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль). Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
    Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора (например, срабатывании контроля оперативной памяти) и т.д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти.
    Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.
Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в  журнале, содержащем последовательность записей об изменении базы данных.
Возможны  два основных варианта ведения журнальной информации. В первом варианте для  каждой транзакции поддерживается отдельный  локальный журнал изменений базы данных этой транзакцией. Эти локальные  журналы используются для индивидуальных откатов транзакций и могут поддерживаться в оперативной памяти. Кроме того, поддерживается общий журнал изменений базы данных, используемый для восстановления состояния базы данных после мягких и жестких сбоев.
Этот  подход позволяет быстро выполнять  индивидуальные откаты транзакций, но приводит к дублированию информации в локальных и общем журналах. Поэтому чаще используется второй вариант - поддержание только общего журнала изменений базы данных, который используется и при выполнении индивидуальных откатов.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Билет 7. Блокирование ресурсов.
Существует  два основных метода управления параллельностью, позволяющих организовать одновременное  безопасное выполнение транзакций при  соблюдении определенных ограничений: метод блокировки и метод временных меток. И блокировка, и использование временных меток являются консервативными (или пессимистическими) подходами, поскольку они откладывают выполнение транзакций, способных в будущем в тот или иной момент времени войти в конфликт с другими транзакциями.
Блокировка  – процедура, используемая для управления параллельным доступом к данным. Когда некоторая транзакция получает доступ к базе данных, механизм блокировки позволяет с целью исключения получения некорректных результатов отклонить попытки получения доступа к этим же данным со стороны других транзакций.
Именно  методы блокировки чаще всего используются на практике для обеспечения упорядоченности  параллельно выполняемых транзакций. Существует несколько различных  вариантов этого механизма, однако все они построены на одном и том же фундаментальном принципе: транзакция должна потребовать выполнить блокировку для чтения (разделяемую) или для записи (эксклюзивную) некоторого элемента данных перед тем, как она сможет выполнить в базе данных соответствующую операцию чтения или записи. Блокировка может быть выполнена для элементов самого различного размера – начиная с базы данных в целом и заканчивая отдельным полем конкретной записи. Размер блокируемого элемента задается уровнем детализации устанавливаемого блока. Реально блокировка может осуществляться посредством установки некоторого бита в соответствующем элементе данных, означающего, что этот фрагмент сазы данных является заблокированным. Другой подход состоит в организации списка заблокированных элементов базы. Существуют и другие методы реализации данного механизма.  
Основные  правила метода блокировки:
Блокировка  для чтения – если транзакция установила блокировку элемента данных для чтения, она сможет считать его, но не сможет обновить
Блокировка для записи – если транзакция установила блокировку элемента данных для записи, она может как читать, так и обновлять этот элемент.
Так как  операция чтения не может служить  причиной конфликта, допускается устанавливать  блокировку для чтения одного и того же элемента одновременно со стороны сразу нескольких транзакций. В то же время блокировка элемента для записи предоставляет транзакции эксклюзивное право доступа к нему. Следовательно, до тех пор пока транзакция будет удерживать некоторый элемент заблокированным для записи, никакая другая транзакция не сможет ни считать, ни обновить его. Блокировки обычно используются следующими путями:
    любая транзакция, которой необходимо получить доступ к элементу данных, должна вначале выполнить блокировку этого объекта. Блокировка может запрашиваться для чтения (что позволит иметь доступ к элементу только для чтения) или же для записи. В последнем случае транзакция получит право доступа и для чтения, и для записи.
    Если элемент еще не заблокирован какой-либо иной транзакцией, блокировка элемента будет выполнена успешно. 
    Если элемент  данных в настоящий момент уже заблокирован, СУБД проанализирует, является ли тип полученного запроса совместимым с типом уже существующего блока. Если запрашивается доступ для чтения к элементу, который заблокирован для чтения, доступ к элементу данных будет разрешен. В противном случае транзакция будет переведена в состояние ожидания, которое будет продолжаться до тех пор, пока существующий блок не будет снят.
    Транзакция продолжает удерживать блокировку элемента данных доя тех пор, пока она явным образом не освободит его – либо в ходе выполнения транзакции, либо по ее окончании (успешном или неуспешном). Только после того как с элемента данных будет снята блокировка для записи, другие транзакции смогут "увидеть" результаты проведенной операции записи.
Помимо  этих правил, в некоторых системах транзакциям разрешается устанавливать  блокировку для чтения, которая позже  может расширяться и преобразовываться в блокировку для записи. Такой подход повышает эффективность работы, позволяя транзакция сначала проанализировать данные, а затем принять  решение, следует ли их изменять. Если механизм расширения блокировки не поддерживается, транзакция вынуждена будет удерживать блокировку для записи в отношении всех элементов данных, которые ей могут понадобиться обновить в некоторый момент своего выполнения, а это потенциально снижает возможный уровень параллельности обработки данных в системе. По этой же причине в некоторых системах транзакциям разрешается устанавливать блокировку элемента данных для записи, с последующим сужением ее до уровня блокировки для чтения.
Для обеспечения  упорядоченности следует использовать дополнительный протокол, определяющий моменты установки и снятия блокировки для каждой из  транзакций. Самым известным из таких протоколов является метод двухфазной блокировки.
Двухфазная  блокировка – транзакция выполняется  по протоколу двухфазной блокировки, если в ней все операции блокирования предшествуют первой операции разблокирования.
В соответствии с основным правилом этого протокола, каждая транзакция может быть разделена  на две фазы: Фазу нарастания, в которой выполняются все необходимые блокировки и не освобождается ни одного из элементов данных; и фазу сжатия, в которой освобождаются все выполненные ранее блокировки и не может быть затребовано ни одной новой. Нет никакой необходимости в том, чтобы все требуемые блокировки были установлены одновременно. Как правило, транзакция устанавливает некоторые блокировки, выполняет определенную обработку, после чего может затребовать установку дополнительных необходимых ей блокировок. Однако она не может освободить ни одного из блоков, пока не достигнет той стадии, на которой ей уже не потребуется установка новых блокировок. Работа ведется по следующим правилам:
    прежде чем начать работу с элементом данных, транзакция должна выполнить его блокировку. Блокировка может устанавливаться для чтения или для записи, в зависимости от типа требуемого доступа.
    Как только транзакция освободит некоторый установленный ею блок, она уже не имеет права затребовать блокировки новых элементов.
Если  СУБД поддерживает операции расширения уровня блокировки, то их выполнение допускается  только в фазе нарастания. Подобные действия могут перевести транзакцию в состояние ожидания на то время, пока другие транзакции отменят установленные ими блокировки для чтения данного элемента. Снижение уровня блокировки допускается только в фазе сжатия.
Проблема, связанная с двухфазной блокировкой, может иметь место при любых  схемах освобождения заблокированных элементов. Эта проблема носит название взаимной блокировки и является следствием того факта, что любая транзакция может быть переведена в состояние ожидания освобождения требуемого ей элемента данных. Если две транзакции будут ожидать освобождения элементов, заблокированных другой транзакцией из этой же пары, то возникнет состояние взаимной блокировки. Кроме того, транзакции могут входить в состояние бесконечного ожидания (самоблокировки), не имея возможности установить требуемую им новую блокировку, хотя СУБД не будет фиксировать состояния взаимной блокировки. Эта ситуация возможна в случаях, когда алгоритм перевода транзакций в состояние ожидания недоработан и не принимает во внимание время, на протяжении которого транзакция уже находится в состоянии ожидания. Для исключения самоблокировок может использоваться система приоритетов, в которой приоритет транзакции тем выше, чем дольше она находится в состоянии ожидания. Альтернативным вариантом является использование для ожидающих транзакций очереди, построенной по схеме "первым пришел, первым обслуживается".
Взаимная  блокировка
Взаимная  блокировка – тупиковая ситуация, которая может возникнуть, когда две (или более) транзакции находятся во взаимном ожидании освобождения блокировок, удерживаемых каждой из них.
В состоянии  взаимной блокировки ни одна из транзакций не в состоянии продолжить свою работу, поскольку каждая ожидает завершения работы другой. Если в системе возникает  состояние взаимной блокировки, вовлеченные  в него приложения не смогут разрешить данную проблему собственными силами. Ответственность за обнаружение взаимных блокировок и выхода тем или иным образом из этой тупиковой ситуации должна быть возложена на СУБД.
Существует  только один способ нарушить состояние  взаимной блокировки – выполнение одной или более транзакций должно быть отменено. Подобное действие будет сопровождаться откатом всех изменений, внесенных отмененными транзакциями. Ситуация взаимной блокировки должна быть абсолютно прозрачной для конечных пользователей, поэтому СУБД следует автоматически перезапустить все отмененные ею транзакции.
Существует  два общих метода обработки взаимных блокировок: предупреждение этих ошибочных  ситуаций и выявление взаимных блокировок с последующим их устранением. При  использовании метода предупреждения взаимных блокировок СУБД заранее определяет ситуации, в которых транзакция сможет вызвать появление данной ошибки, и предотвращает из возникновение. При использовании метода выявления и устранения взаимных блокировок, СУБД допускает появление подобных ситуаций в системе, однако затем распознает их появление и организует выход из сложившейся тупиковой ситуации. Поскольку метод выявления и устранения проще метода предупреждения, в большинстве систем используется именно этот вариант действий.
Предупреждение  взаимных блокировок
Один  из возможных подходов предупреждения взаимных блокировок состоит в установлении порядка выполнения транзакций на основе использования временных отметок. Были предложены два возможных алгоритма. Первый алгоритм, получивший название "ожидание-отмена", требует, чтобы более старые транзакции ожидали завершения более новых. В противном случае транзакция отменяется и перезапускается с той же самой временной отметкой. Однако рано или поздно она станет самой старой из активных транзакций и уже не будет отменена. Второй алгоритм, "отмена-ожидание", использует диаметрально противоположный подход: только более новые транзакции могут ожидать завершения более старой транзакции. Если более старая транзакция потребует выполнения блокировки элемента данных, уже заблокированного более новой транзакцией, последняя будет отменена.
Выявление взаимных блокировок
Выявление взаимных блокировок обычной производится с помощью конструкции, называемой графом ожиданий. Этот граф отражает зависимость транзакций друг от друга. Транзакция Ti зависит от транзакции Tj в том случае, если транзакция Tj заблокировала элемент данных, необходимый для продолжения работы транзакции Ti.
Взаимная  блокировка имеет место в том  и только в том случае, если граф ожиданий содержит петлю.
Поскольку наличие петли в графе ожиданий является необходимым и достаточным  условием существования в системе  ситуации взаимной блокировки, алгоритм выявления этих ошибочных ситуаций предполагает генерирование через  регулярные интервалы времени графа текущих ожиданий в системе и анализ его на наличие петель. Выбор интервала времени между последовательными генерациями графа имеет важное значение. Если установленный интервал окажется слишком малым, выявление взаимных блокировок создаст в системе заметную перегрузку. Если выбранный интервал будет слишком большим, наличие взаимной блокировки может оставаться незамеченным достаточно продолжительное время. Динамический алгоритм выявления взаимных блокировок начинает свою работу с некоторого исходного значения интервала. Каждый раз после генерации графа, не указывающего на наличие взаимной блокировки, интервал может быть увеличен – например, удвоен. При каждом обнаружении ситуации взаимной блокировки интервал укорачивается – например, наполовину. Кроме того, необходимо установить максимальное и минимальное значение интервала 
Билет
9.Распределенные БД и основные принципы их создания.
Распределенные  базы данных (РБД) – совокупность логически  взаимосвязанных баз данных, распределенных в компьютерной сети.
По  Дейту: РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
а)каждый узел – это полноценная СУБД сама по себе;
б)узлы взаимодействуют между собой  таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
Каждый  узел сам по себе является системой базы данных. Любой пользователь может  выполнить операции над данными  на своем локальном узле точно  так же, как если бы этот узел вовсе  не входил в распределенную систему. Распределенную систему баз данных можно рассматривать как партнерство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределенных баз  данных («правило 0»): Для пользователя распределенная система должна выглядеть так же, как нераспределенная система.
Фундаментальный принцип имеет следствием определенные дополнительные правила или цели. Таких целей всего двенадцать:
1.Локальная  независимость. Узлы в распределенной  системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2.Отсутствие  опоры на центральный узел. Локальная  независимость предполагает, что  все узлы в распределенной  системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3.Непрерывное  функционирование. Распределенные  системы должны предоставлять  более высокую степень надежности и доступности.
4.Независимость  от расположения. Пользователи не  должны знать, где именно данные  хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5.Независимость  от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации ее физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6.Независимость  от репликации. Система поддерживает  репликацию данных, если данная  хранимая переменная-отношение –  или в общем случае данный  фрагмент данной хранимой переменной-отношения – может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7.Обработка  распределенных запросов. Суть в  том, что для запроса может  потребоваться обращение к нескольким  узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8.Управление  распределенными транзакциями. Существует 2 главных аспекта управления  транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределенной среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент – процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределенных систем базируется на механизме блокирования, точно так, как и в нераспределенных системах.
9.Аппаратная  независимость. Желательно иметь  возможность запускать одну и  ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределенной системы как равноправные партнеры.
10.Независимость  от операционной системы. Возможность  функционирования СУБД под различными операционными системами.
11.Независимотсть от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12.Независиомть  от типа СУБД. Необходимо, чтобы  экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД. 

Билет 10.Модели распределенных баз данных. Однородные и неоднородные системы.
Однородные  распределенные базы данных:

Однородная  СУБД

Однородные  распределенные СУБД относительно просты и имеют в своей основе одинаковые СУБД с единственным языком запросов (обычно SQL). Однородные системы являются сильносвязанными системами. Их встроенные средства поиска данных и средства обработки запросов оптимизированы и обеспечивают максимальную производительность системы. Существует множество вариантов однородных систем РБД.
Вариант 1:

Вариант 2:

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

Билет 11. Методы построения распределенных БД
1 метод:
проектирование  БД сверху вниз осуществляется в целом  аналогично проектированию централизованных БД:
а) концептуальная модель;
б) логическая модель;
в) реализационная модель;
г) фрагментированная  модель.
При проектировании распределенной БД методом 1 предполагается, что её объекты не будут храниться  в одном месте, а будут распределены по нескольким вычислительным системам. Распределение производится путем  фрагментации или тиражирования.
Фрагментация – декомпозиция объектов БД на 2 или несколько частей.
Горизонтальная  фрагментация – распределение кортежей таблицы по фрагментам. Обычно фрагменты не пересекаются (SELECT <условие>).
Вертикальная  фрагментация – разделение множества атрибутов реляционной таблицы на возможно пересекающиеся подмножества. Фрагменты получаются путем проецирования исходных таблицы.
R1 = R[<список атрибутов>]
Исходную  таблицу можно получить из фрагментов, используя операцию соединения.
Независимо от того, применяется горизонтальная или вертикальная фрагментация, поддерживается глоб. схема, позволяющая воссоздать из имеющихся фрагментов логически централизованную таблицу или другую структуру БД.
    Значительная доля обработки, запрашиваемой приложениями, скорее всего будет относиться к локальным данным.
    использование глобальных схем для обработки локальных запросов – не самый рациональный подход в организации обработки данных.
2 метод:
Тиражирование (репликация) – создание дубликатов данных
Репликанты – это множество различных копий некоторого объекта данных, для которых в соответствии с определенными в БД правилами поддерживаются синхронизация с некоторой главной копией.
Принципы  тиражирования:
    Полное или частичное копирование
    Синхронное или асинхронное обновление копий
    Стратегии доступа: копии доступа для обновления или только для чтения


Тиражирование может быть реализовано разными  способами: с помощью программного интерфейса прикладных программ; с помощью встроенных средств самой БД.
Применение  технологий построения распределенных систем «сверху вниз» с применением  фрагментации и тиражирования возможно только при создании новых приложений. Чаще создание интегрированной среды  осуществляется объединением существующих БД и соответствующих информационных менеджеров в дополнение к некоторым вновь проектируемым компонентам БД. 

Билет 12. Различные типы распределенных БД
Типы  РаБД Однородность Глобальная  схема Обеспечение интерфейса
1) РаБД + + Внутренние функции СУБД
2) Мультибазы  данных с глоб. схемой - + Пользовательский  интерфейс
3) Федеративные  БД - частичная Пользовательский  интерфейс
4) Мультибазы  данных (неодн-е) с общим языком  доступа - функции языка  доступа Пользовательский  интерфейс
5) Однородные системы мультибаз данных + функции языка  доступа Пользовательский  интерфейс + внутренние функции СУБД
6) Интероперабельные  системы множество типов  источников данных отсутствие  глобальной интеграции реализация  интерфейса средствами приложения
Система мультибаз данных – это распределенная система, кот. служит внешним интерфейсом  для доступа к множеству локальных  СУБД или структурируется как  глобальный уровень над локальными СУБД.

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

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

Билет 13. Концептуальная архитектура мультибаз данных

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

Билет 14. Хранилища данных
Хранилища данных -  логически интегрированный источник данных, предназначенный для систем поддержки принятия решений и информационных систем руководителя.

Архитектура


Принципы  организации хранилища.
    Проблемно предметная ориентация: данные объединяются  в категории и хранятся  и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.
    Интегрированность: объединяет данные т.о., что бы они удовлетворяли всем требованиям всего предприятия, а не единственной функции бизнеса.
    Некорректируемость: данные в хранилище данных не создаются, т.е. поступают из внешних источников, не корректируются, не удаляются.
    Зависимость от времени: данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.
Процессы  работы с данными.
    извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.
    Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.
    Анализ.
    Представление.
Источниками данных могут быть: 
      Традиционные системы регистрации операций (БД)
      Отдельные документы
      Наборы данных
Источники данных классифицируются:
    Территориальное и административное размещение.
    Степень достоверности.
    Частота обновляемости.
    Система хранения и управления данными.
Вся эта  информация используется в словаре  метаданных. В словарь метаданных автоматически включаются словари  источников данных. Здесь же форматы  данных для их последующего согласования, периодичность пополнения данных, согласованность во времени.
Задача  словаря метаданных состоит в  том, что бы освободить разработчика от необходимости стандартизировать  источники данных.
Создание  хранилищ данных не должно противоречить  действующим системам сбора и  обработки информации. Специальные компоненты словарей должны обеспечивать своевременное извлечение из словарей и обеспечить преобразование к единому формату на основе словаря метаданных.
Логическая  структура данных хранилища данных отличается от структуры данных источников данных.
Для разработки эф-го процесса преобразования необходима хорошо проработанная модель корпоративных  данных и модель технологии принятия решений.
Данные  для пользователя удобно представлять  в многоразмерных БД, где в качестве размерности могут выступать время, цена или географический регион.
Кроме извлечения данных из БД, принятия решений  важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.
С т.з. пользователя в процессе извлечения знаний  из БД должны решаться след. преобразования: данные ---- информация ---- знания ---- полученные решения.
Методы  выявления и анализа  знаний:
1.Ассоциация.
2. Последовательность  – когда определяются сообщения  связанные между собой во времени.
3.Классиффикация  – выявление характеристик группы, к которой принадлежит объект.
4. Кластеризация  – группы заранее не сформированы.
5. Прогнозирование – моделирование поведения определенного объекта на основе имеющихся знаний.
       Средства извлечения  знаний:
1. Нейронные  сети. Пакеты, к. созданы для прогнозирования  определенной области.
2. Деревья  решений.
3. Индуктивное  обучение.
4. Визуализация данных.
5. Нечеткая логика.
6. Различные  статистические методы. 

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

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

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

Билет 16. Манифест ООБД.
В манифесте  ООБД  (Atkinson et al., 1989)  предлагаются  обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной  и представлять собой БД.
      Три класса характеристик:
    Обязательные.
    Необязательные.
    Открытые – позволяют пользователю выбирать свойства.
Обязательные:

      СУБД

    Долговременное  хранение
    Использование внешней памяти
    Параллелизм
    Восстановление
    Нерегламентированные запросы
      ОО  характеристики
      Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, т.е. любой конструктор можно было применять к любому объекту.
      Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
      Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
      Поддержка типов и классов.  Требуется, что бы  в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указание ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном  для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится   ко времени исполнения, чем ко времени компиляции.)
      Поддержка наследования типов и классов от их предков.  Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
      Перегрузка в сочетание с полным связыванием.  Методы должны применятся к объектам разных типов. Реализация метода должна зависеть  от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполнятся до времени выполнения программы.
      Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
      Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.
Необязательные:
        Множественное наследование
        Проверка типов
        Распределение
        Проектные транзакции

    и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.