ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 28.07.2021

Просмотров: 486

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

  • формирование экранных изображений;

  • чтение и запись в экранные формы информации;

  • управление экраном;

  • обработка движений мыши и нажатие клавиш клавиатуры.

Бизнес-логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием раз личных языков программирования, таких как C, C++, Cobol, SmallTalk, VisualBasic.

Логика обработки данных (Data manipulation Logic) — это часть кода приложения, которая связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используются язык запросов и средства манипулирования данными стандартного языка SQL. Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения.

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

В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой про граммы.

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

  • распределенная презентация (Distribution presentation, DP);

  • удаленная презентация (Remote Presentation, RP);

  • распределенная бизнес-логика (Remote business logic, RBL);

  • распределенное управление данными (Distributed data management, DDM);

  • удаленное управление данными (Remote data management, RDA).

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



  1. Физические модели баз данных, файловые структуры, индексные файлы. Расчет времени доступа к произвольной записи. [3. c. 162-180, 18 ­– тема 11].


Немного истории

Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне.


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

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


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

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

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

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

В устройствах с последовательным доступом для получения доступа к некоторому элементу требуется «перемотать (пройти)» все предшествующие ему элементы информации.

Файлы с постоянной длиной записи, расположенные на устройствах прямого доступа (УПД), являются файлами прямого доступа.

В этих файлах физический адрес расположения нужной записи может быть вычислен по номеру записи (NZ).

Каждая файловая система СУФ поддерживает некоторую иерархическую файловую структуру, включающую чаще всего не ограниченное количество уровней иерархии в представлении внешней памяти.

Для каждого файла в системе хранится следующая информация:

  • имя файла;

  • тип файла (например, расширение или другие характеристики);

  • размер записи;

  • количество занятых физических блоков;

  • базовый начальный адрес;

  • ссылка на сегмент расширения;

  • способ доступа (код защиты).


Для файлов с постоянной длиной записи адрес размещения записи с номером K может быть вычислен по формуле

ВА + (К — 1) * LZ + 1, 

где ВА — базовый адрес, LZ — длина записи.

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

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

Файлы с переменной длиной записи всегда являются файлами последовательного доступа. Они могут быть организованы двумя способами:

  1. Конец записи отличается специальным маркером.

 

  1. В начале каждой записи записывается ее длина.

LZ1

Запись1

LZ2

Запись2

LZ3

Запись3

Здесь LZN — длина N-й записи.

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

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

NZ = F ( K ),

где NZ — номер записи, K — значение ключа, F( ) — функция.

Функция F() при этом должна быть монотонной, чтобы обеспечивать однозначное соответствие.


Про индексные файлы

Используется при организации доступа по первичному ключу. Такой файл состоит из двух частей:

  • Сам индексный файл

  • Файл для которого создается инлекс



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

В зависимости от организации индексной и основной областей различают 2 типа файлов: с плотным индексом и с неплотным индексом.

Файлы с плотным индексом называются также индексно-прямыми файлами, а файлы с неплотным индексом называются также индексно-последовательными файлами.



С плотным индексом


В этих файлах основная область содержит последовательность записей одинаковой длины, расположенных в произвольном порядке, а структура индексной записи в них имеет следующий вид (рис. 11.3):

Значение ключа

Номер записи

Рис. 11.3. Структура плотного индекса


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



Время доступа к произвольной записи



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

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

Tn = log 2N,

где N — число элементов.



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

Tn = log 2N бл. инд. + 1.




Попробуем усовершенствовать способ хранения файла: будем хранить его в упорядоченном виде и применим алгоритм двоичного поиска для доступа к произвольной записи. Тогда время доступа к произвольной записи будет существенно меньше. Для нашего примера это будет:

T = log2KBO = log 212 500 = 14 обращений к диску.

И это существенно меньше, чем 12 500 обращений при произвольном хранении записей файла. Однако и поддержание основного файла в упорядоченном виде — операция сложная.

Неплотный индекс строится именно для упорядоченных файлов. Для этих файлов используется принцип внутреннего упорядочения для уменьшения количества хранимых индексов. Структура записи индекса для таких файлов имеет следующий вид (рис. 11.4).

Значение ключа

Номер блока

Рис. 11.4. Структура неплотного индекса

 

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



  1. Сервер баз данных MS SQL Server. Принципы написания и отладки хранимых процедур и триггеров.[3. с.259-270, 18 – темы 7, 8, 9].



Триггеры



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


В MS SQL SERVER 2000 появился новый вид триггера INSTEAD OF триггер. Его принципиальное отличие от обычных (AFTER) триггеров состоит в том, что он выполняется не после выполнения операции вставки/изменения/удаления, а вместо нее.

Простейший оператор создания триггера имеет вид:

CREATE TRIGGER < имятриггера >

ON < имятаблицы >

FOR [DELETE] [,] [INSERT] [,] [UPDATE]

AS

SQL- операторы (тело триггера)

В конкретных СУБД этот оператор может существенным образом отличаться. Для создания триггеров в MS SQL Server 2000 используется специальная команда:

CREATE TRIGGER имятриггера

ON таблица

[WITH ENCRYPTION]

{

{FOR | AFTER | INSTEAD OF }{[DELETE] [,] [INSERT] [,] [UPDATE] }

[WITH APPEND]

[NOT FOR REPLICATION]

AS

{ IF UPDATE (столбец _i) 

[ {AND | OR} UPDATE (столбец _j)]

[ ... n] 

| IF (COLUMNS_UPDATED() { побитовый _ оператор } битовая _ маска)

{оператор_сравнения} битовая_маска_столбца [... n ]

}

инструкции_SQL [ ... n ]

}

}


В параметре FOR задается тип триггера AFTER (после выполнения операции модификации) и INSTEAD OF (вместо выполнения операции модификации) и одна или несколько операций модификации, которые запускают данный триггер.

Опция WITH APPEND необходима, только если установленный уровень совместимости не превышает 65 и используется для создания дополнительных триггеров.

Параметр WITH ENCRIPTING имеет тот же смысл, что и для хранимых процедур, он скрывает исходный текст тела триггера.


Смотрите также файлы