Ооп бд объектно-ориентированная база данных

Вид материала

Документы

Содержание Многоуровневый "клиент-сервер" 26. Оптимізація роботи з базою даних в режимі мережі. 30. Сервер додатка. Структура сервера додатка. Реєстрація сервера додатка

Подобный материал:

• Программа дисциплины Объектно-ориентированное программирование Рекомендуется для направления, 591.42kb.
• Лекция на тему «Что такое база данных. Реляционная база данных ms access», 67.11kb.
• Абстракции, наследование и полиморфизм, 107.42kb.
• Ms access База данных (БД), 134.51kb.
• Лекция: Методологии моделирования предметной области: Методологии моделирования предметной, 347.91kb.
• Развитие объектно-ориентированных систем управления базами данных, 122.52kb.
• Должна быть конкретной, кратко сформулированной и соответствовать современному уровню, 20.13kb.
• В вычислительной математике, 1443kb.
• Базы данных 2, 398.32kb.
• Лекция на тему: Основы организации баз данных, 393.78kb.

Многоуровневый "клиент-сервер"

Многоуровневая архитектура клиент-сервер (Multitier architecture) – разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов [15]. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

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

Терминал – это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость

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

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

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

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

Плюсами данной архитектуры являются:

• клиентское ПО не нуждается в администрировании;
  
• масштабируемость;
  
• конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
  
• высокая безопасность;
  
• высокая надежность;
  
• низкие требования к скорости канала (сети) между терминалами и сервером приложений;
  
• низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.
  

Минусы :

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

26. Оптимізація роботи з базою даних в режимі мережі.

Особенности управления одновременным доступом

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

• будет нарушена целостность данных;

• приложение будет работать медленнее, чем предусмотрено, даже при небольшом

количестве пользователей;

• будет потеряна возможность масштабирования до большого числа пользователей.

Проблемы одновременного доступа выявлять сложнее всего — трудности сопоставимы с отладкой многопотоковой программы. Программа может отлично работать в уп-

равляемой, искусственной среде отладчика, но постоянно "слетать" в "реальном мире".

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

временно изменяют одну и ту же структуру данных. Такого рода ошибки очень сложно

выявлять и исправлять.

Реализация блокирования

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

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

кирования, предотвращающей одновременное изменени.

Принципы блокирования в СУБД Oracle.

• Oracle блокирует данные на уровне строк и только при изменении. Эскалация блокировок до уровня блока или таблицы никогда не выполняется.

• Oracle никогда не блокирует данные с целью считывания. При обычном чтении

блокировки на строки не устанавливаются.

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

• Сеанс записи данных блокируется, только если другой сеанс записи уже забло-

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

когда не блокирует сеанс записи.

Блокируя ресурс, который мы пытаемся зарезервировать, мы гарантируем, что никакой другой сеанс в это же время не изменяет план использования ресурса. Ему придется ждать, пока наша транзакция не будет зафиксирована — после этого он сможет увидеть сделанное в ней резервирование. Возможность перекрытия планов, таким образом, устранена. Разработчик должен понимать, что в многопользовательской среде иногда необходимо использовать те же приемы, что и при многопотоковом программировании. В данном случае конструкция FOR UPDATE работает как семафор. Она обеспечивает последовательный доступ к конкретной строке в таблице ресурсов, гарантируя, что два сеанса одновременно не резервируют ресурс.

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

Многовариантность - это механизм, с помощью которого СУБД Oracle обеспечивает:

• согласованность по чтению для запросов: запросы выдают согласованные резуль таты на момент начала их выполнения;

• неблокируемые запросы: запросы не блокируются сеансами, в которых изменя ются данные, как это бывает в других СУБД.

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

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

Помните, что при открытии курсора сервер Oracle не "отвечает " на запрос; он никуда не копирует данные при открытии курсора (представьте, сколько времени потре бовало бы открытие курсора для таблицы с миллиардом строк в противном случае). Курсор просто открывается и дает результаты запроса по ходу обращения к данным. Другими словами, он будет читать данные из таблицы при извлечении их через курсор.

В том же (или в другом) сеансе мы затем удаляем все данные из таблицы. Более того, мы даже фиксируем (COMMIT) это удаление. Строк больше нет — не так ли? На самом деле их можно извлечь с помощью курсора Фактически, результирующее множе- ство, возвращаемое командой OPEN, было предопределено в момент открытия курсора. Мы не прочитали при открытии курсора ни одного блока данных таблицы, но результат оказался жестко зафиксированным. Мы не сможем узнать этот результат, пока не извлечем данные, но с точки зрения нашего курсора результат этотнеизменен. Дело не в том, что СУБД Oracle скопировала все эти данные в другое место при открытии курсора; данные сохранил оператор delete, поместив их в область данных под названием сегмент отката.

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

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

30. Сервер додатка. Структура сервера додатка. Реєстрація сервера додатка

Сервер приложений инкапсулирует большую часть бизнес-логики распределенного приложения и обеспеч. доступ клиентов к базе данных. Основной частью сервера приложений является удаленный модуль данных. Во-первых, подобно обычному модулю данных он является платформой для размещения невизуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress. Во вторых, удаленный модуль данных реализует основные ф-и сервера приложений на основе предоставления клиентам интерфейса AppServer или его потомка. Для этого удаленный модуль данных должен содержать необход. число компонентов-провайдеров TDataSetProvider. Эти компоненты передают пакеты данных клиентскому приложению, а точнее компонентам TdientDataSet, а также обеспечивают доступ к методам интерфейса. 
В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi . 
Remote Data Module — удаленный модуль данных, инкапсулирующий сервер Автоматизации. Используется для организации соединений через DCOM, HTTP, сокеты (см. гл. 21). 
Transactioiial Data Module — удаленный модуль данных, инкапсулирующий сервер MTS (Microsoft Transaction Server). 
SOAP Server Data Module — удаленный модуль данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol). 
WebSnap Data Module — удаленный модуль данных, использующий Web-службы и Web-браузер в качестве сервера. 
С каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи клиенту, в модуле данных должен быть связан компонент-провайдер.