|
Реферат: Динамическое распределение памяти (Программирование)
Список - конечная последовательность, состоящая из нуля или более атомов
или Списков.
Рассмотрим Список L = (a: N, b, c: (d: N), e: L), N = (f: ( ), g: (h: L,
j: N)) а соответствующей диаграммой для него будет
Существует много способов для представления Списочных структур в памяти
машины. Обычно все они являются вариациями на одну и ту же основную тему,
согласно которой для представления общих лесов деревьев используются
бинарные деревья: одно поле, скажем RLINK, используется для указания на
следующий элемент Списка, а другое поле DLINK можно использовать для
указания на первый элемент под-Списка.
Тогда Список можно представить в виде:
Но эта простая идея не вполне пригодна для наиболее часто встречающихся
приложений, включающих обработку Списков.
По этой причине верхняя схема обычно заменяется на другую, но теперь
каждый Список начинается с головы Списка. Каждый список содержит
дополнительный узел, называемый головой Списка.
На практике введение этих головных узлов не приводит к реальной потере
памяти, поскольку обнаруживается немало применений для них. Например, можно
потребоваться для счетчика ссылок, или указателя на правый конец Списка,
или для буквенного имени, или для рабочего поля, которое оказывается
полезным в алгоритмах прохождения дерева, и т. д.
В сущности, Список - не что иное, как линейный список, элементы которого
могут содержать указатели на другие Списки. Наиболее распространенными
операциями, которые мы захотим выполнять над Списками, являются обычные
операции, необходимые и для линейных списков (создание, разрушение,
включение, исключение, расщепление, конкатенация), и еще некоторые
дополнительные операции, которые интересны, прежде всего для древовидных
структур (копирование, прохождение, ввод и вывод вложенной информации).
Но поскольку общие Списки могут расти и умирать во время работы программы
совершенно непредвиденным образом, зачастую очень трудно сказать точно,
когда тот или иной узел становиться ненужным. Следовательно, проблема
обслуживания списка свободного пространства представляется значительно
более трудной при работе со Списками.
Представим себе, что мы разрабатываем универсальную систему для обработки
Списков, которая будет использоваться сотнями других программистов. Для
обслуживания списка свободного пространства предлагается два основных
метода: счетчики ссылок и сбор мусора. В методе счетчиков используется
специальное поле в каждом узле, в котором учитывается, сколько стрелок
указывает на этот узел. За таким счетчиком довольно легко следить во время
работы программы, и всякий раз, когда счетчик сбрасывается в нуль, данный
узел становится свободным. Метод сбора мусора использует в каждом узле
специальное поле размером в один бит, которое называют "битом маркировки"
или просто "маркером". В этом случае идея состоит в том, что почти все
алгоритмы не возвращают узлы в список свободной памяти и программа
беззаботно работает до тех пор, пока не исчерпается весь этот список; тогда
алгоритм "сбора мусора", используя биты маркировки, возвращает в свободную
память все узлы, которые в данный момент программе недоступны, после чего
программа продолжает работать.
Ни один из этих методов нельзя считать вполне удовлетворительным.
Принципиальный недостаток метода счетчиков состоит в том, что он не всегда
возвращает в список свободной памяти те узлы, которые фактически являются
свободными. Он хорошо работает с частично перекрывающимися списками. Кроме
того метод счетчиков ссылок отнимает вполне ощутимое пространство в памяти
(правда, иногда это пространство, так или иначе, остается свободным из-за
размера машинного слова).
Кроме неприятной потери одного бита в каждом узле, трудность метода сбора
мусора заключается в том, что он крайне медленно работает, когда загрузка
памяти почти достигает предела; в таких случаях количество свободных ячеек,
полученных с помощью процесса сбора, не окупает затраченных на это усилий.
Те программы, которым не хватает памяти (а это происходит со многими не
отлаженными программами!), часто впустую расходуют массу времени,
многократно и почти бесплодно вызывая сборщик мусора непосредственно перед
тем, как окончательно исчерпать память. Эту проблему можно частично решить,
позволив программисту указывать число k, и если на этапе сбора мусора
найдено не более k свободных узлов, то работа программы прекращается. Еще
одна проблема связана с затруднениями, которые возникают иногда при
определении, какие Списки на данном этапе не являются мусором; если
программист пользуется какими-либо нестандартными приемами или хранит какую-
либо указательную информацию в необычном
месте, то велика вероятность неправильной работы сборщика мусора. Некоторые
наиболее мистические случаи в истории отладки связаны с тем, что во время
выполнения программ, до этого неоднократно работавших, вдруг в неожиданный
может включался сбор мусора. Сбор мусора требует также, чтобы программисты
все время хранили правильную информацию во всех указательных полях, хотя
иногда удобно в полях, к которым программа никогда не обращается оставить
бессмысленную информацию. Можно также отметить, что сбор мусора неудобен
для работы в "реальном режиме", поскольку, даже если сборщик мусора
включается нечасто, он требует в этих случаях много машинного времени .
Хотя сбор мусора требует одного бита маркировки для каждого узла, можно
хранить отдельную таблицу всех битов маркировки, скомпонованных вместе, в
другой области памяти, установив соответствие между адресом узла и его
битом маркировки. Алгоритмы сбора мусора интересны по нескольким причинам.
В первую очередь такие алгоритмы полезны в других ситуациях, когда мы хотим
отметить все узлы, на которые прямо или косвенно ссылается данный узел.
(Можно, например, найти все подпрограммы, к которым прямо или косвенно
обращается некоторая подпрограмма.)
Сбор мусора обычно распадается на две фазы. Мы предполагаем, что
первоначально биты маркировки во всех узлах равны нулю (или мы все их
устанавливаем в нуль). Теперь во время первой фазы отмечаются все узлы, не
являющиеся мусором, отправляясь от узлов, которые непосредственно доступны
из главной программы. Во второй фазе осуществляется последовательный проход
по всей области пула памяти и все неотмеченные узлы заносятся в список
свободного пространства.
Наиболее интересная особенность сбора мусора состоит в том, что во время
работы этого алгоритма в нашем распоряжении остается очень ограниченный
объем свободной памяти, которую можно использовать для управления
алгоритмом маркировки.
Следующий алгоритм маркировки относится, наверное, к наиболее очевидным.
Алгоритм А. (Маркировка.) Пусть вся память, используемая для хранения
Списков, состоит из узлов NODE (1), NODE (2),... ..., NODE (М), и
предположим, что эти слова являются либо "атомами", либо содержат два поля
связи ALINK и BLINK. Предположим, что первоначально все узлы
немаркированные. Назначение этого алгоритма состоит в том, чтобы отметить
все узлы, которые можно достичь по цепочке указателей ALINK и (или) BLINK в
неатомарных узлах, отправляясь от множества "непосредственно доступных"
узлов.
A1 [Начальная установка.] Отметить все "непосредственно доступные" узлы,
т.е. узлы, указатели на которые находятся в фиксированных ячейках в
главной программе и которые служат отправными пунктами для доступа ко
всей памяти. Установить К(1.
А2. [Следует ли за NODE(К) другой узел ?] Установить К(К+1.Если NODE(K) -
атом или немаркированный узел, то перейти к шагу А3. В противном случае,
если узел NODE(ALINK(K)) не отмечен, то отметить его и, если он не атом,
установить К1(min(K1,ALINK(K)). Точно также, если узел NODE(BLINK(K)) не
отмечен, то отметить его и, если он не атом, установить
K1(min(K1,BLINK(K)).
A3. [Конец ?] Установить K(K1. Если K(M, то вернуться к шагу А2, в
противном случае алгоритм завершен.
Возможен несколько лучший вариант, предусматривающий использование стека
фиксированного размера.
Алгоритм B. (Маркировка.) В этом алгоритме используется таблица,
содержащая Н ячеек STACK [0], STACK [1I, ... ..., STACK[H-1] , и
получается тот же результат, что и в алгоритме А .
В этом алгоритме действие "занести Х в стек" означает следующее:
"Установить T((T+l) mod H и STACK[T](X. Если Т = В, то установить В( (В+1)
mod Н и К1(min (Kl, STACK [В])". (Заметим, что Т указывает на текущую
"вершину" стека, а В указывает на одну позицию ниже текущего "низа"; STACK
работает, по существу, как дек, с ограниченным входом.)
B1. [Начальная установка.] Установить Т(Н-1, В(Н-1, Kl(М+1. Отметить все
непосредственно доступные узлы и последовательно занести их адреса в
стек (с помощью только что описанного действия).
B2. [Стек пуст?] Если Т = В, перейти к B5.
BЗ. [Взять из стека верхний элемент.] Установить К(STACK [Т],
T((T-l) mod H.
B4.[Исследовать связи.] Если узел NODE(K) - атом, то вериуться
К B2. В противном случае, если NODЕ(АL1NK(К)) не отмечен, то отметить его
и занести ALINK (К) в стек. Аналогично, если NODE (BLINK (К)) не отмечен,
то отметить его и занести REF (К) в стек. Вернуться к B2.
B5. [Прочесать.] Если K1>М, то алгоритм завершен. (Переменная К1
представляет наименьший адрес, откуда имеется возможность вновь выйти на
узел, который следует отметить.) В противном случае, если NODE(KI) нe
отмечен, увеличить К1 на 1 и повторить этот шаг. Если NODE (К1) отмечен,
то установить К(К1, увеличить К1 на 1 и перейти к B4.
Этот алгоритм можно улучшить, если не заносить в стек X, когда NODE (X)
- атом.
Алгоритм B фактически становится алгоритмом А, когда Н = 1, и очевидно,
эффективность его плавно возрастает с увеличением Н. К сожалению, алгоритм
B не поддается точному анализу по тем же причинам, что и алгоритм А, и мы
не в состоянии указать, при каком Н этот метод будет достаточно быстрым. В
качестве правдоподобного, но не очень надежного можно назвать значение Н =
50, при котором алгоритм B применим для сбора мусора в большинстве случаев.
В алгоритме В используется стек, расположенный в последовательных ячейках
памяти, которые расположены в памяти непоследовательно. Этот факт наводит
на мысль, что в алгоритме мы могли бы организовать стек, каким-то образом
разбросав его по той же самой области памяти» в которой собирается мусор.
Это нетрудно сделать, если предоставить программе сбора мусора немного
больше места, чтобы она могла "вздохнуть свободнее".
Будем считать, например, что все Списки представлены, за тем лишь
исключением, что поле RЕF в каждом головном узле используется для сбора
мусора, а не для счетчика ссылок. Тогда мы можем переработать алгоритм
организовав стек в полях REF головных узлов.
Алгоритм D (Маркировка). Пусть дано множество узлов, имеющих следующие
поля
MARK (одноразрядное поле,первоначально
нулевое в каждом узле),
ATOM (еще одно одноразрядное поле),
ALINK (указательное поле),
BLINK (указательное поле),
Когда ATOM = 0, поля ALINK и BLINK могут содержать ( или указатель на
другой узел того же формата; когда ATOM = 1, содержимое полей ALINK и BLINK
несущественно для данного алгоритма.
Если задан указатель Р0, то этот алгоритм устанавливает 1 в поле MARK в
узле NODE (Р0) и во всех других узлах, до которых можно добраться по
цепочке указателей ALINK и BLINK и в которых ATOM = MARK = 0. В алгоритме
используются три указательные переменные, Т, Q и Р, и связи при выполнении
алгоритма могут быть временно изменены, но так, что после завершения
алгоритма во всех полях ATOM, ALINK и BLINK восстанавливаются их прежние
значения.
D1. [Начальная установка.] Установить Т((, Р(Р0. (Далее в этом алгоритме
переменная Т будет использоваться в двух смыслах: если Т((, то она
указывает на вершину того, что, по существу, является стеком, а узел, на
который указывает Т, некогда содержал связь, равную Р, вместо
"искусственной" стековой связи, находящейся теперь в NODE (Т).)
D2. [Отметить.] Установить MARK (Р) ( 1.
DЗ, [Атом?] Если ATOM (Р) = 1, то перейти к Е6.
D4. [Вниз по ALINK.] Установить Q(ALINK (Р). Если Q(( и MARK (Q) = 0, то
установить ATOM (Р) (1, ALINK (Р)(Т, Т(Р, P(Q и перейти к D2. (Теперь поля
ATOM и ALINK на время изменены и, следовательно, довольно радикально
изменилась списочная структура в некоторых отмеченных узлах. Но в шаге D6
все будет восстановлено.)
D5. [Вниз по BLINK.) Установить Q(BLINK (Р). Если Q(( и MARK(Q)=0, то
установить BLINK (Р)(Т, Т(Р, Р(Q и перейти к D2.
D6. [Вверх.] (В этом шаге устраняются изменения связей, сделанные в шагах
D4 или D5; значение АТОМ (Т) говорит о том, какую из связей ALINK (Т)
или BLINK (Т) следует восстановить.) Если Т=(, алгоритм завершен. В
противном случае установить Q(Т. Если АТОМ (Q)=1, то установить ATOM
(Q)(0, Т(ALINK (Q), ALINK(Q)(P, P(Q и вернуться к D5. Если ATOM (Q) = 0,
то установить Т(BLINK (Q), BLINК(Q)(Р, Р(Q и вернуться к D6.
Блок-схема алгоритма D показана на рисунке,
После
После
ALINK
BLINK
D1.Нач. D2. D3. D4.
Вниз по D5. Вниз по D6. Вверх
установка Отметить Атом? ALINK
Уже BLINK Уже
Да
отмечен отмечен
Обратим внимание на то, что в шагах D4 и D5 искусственно изменяется
списочная структура. Когда происходит возврат к предыдущему состоянию, поле
ATOM говорит о том, какие из связей ALINK и BLINK содержат искусственные
адреса. "Вложения", показанные в нижней части рисунка служат иллюстрацией
того, что в алгоритме каждый неатомарный узел посещается три раза
Доказательство правильности алгоритма D можно построить, основываясь на
индукции по количеству узлов, которые подлежат маркировке. Одновременно
доказывается, что в конце алгоритма Р=Р0. Алгоритм D будет работать
быстрее, если исключить шаг DЗ, а вместо него выполнить проверки "ATOM (Q)
= 1" и соответствующие действия в шагах D4 и D5, а также проверку "ATOM
(Р0) = 1" в шаге D1.
Идею, на которой построен алгоритм D, можно применить не только для
сбора мусора, но и в других задачах.
Время выполнения наилучших из известных программ сбора мусора выражается,
по существу, формулой c1N+c2M, где c1 и c2 — константы, N-количество
маркируемых узлов, а М - общее количество узлов в памяти. Таким образом, М
- N - количество найденных свободных узлов, и время, которое расходуется на
возврат одного такого узла в свободную память, составляет (c1N + c2М)/(М-
N). Пусть N = (М; тогда формула преобразуется к виду (c1( + c2)/(l — ().
Следовательно, если (=3/4, т. е.
память заполнена на три четверти, то потребуется 3c1 + 4c2 единиц времени,
чтобы вернуть в свободную память один узел; если ( =1/4
, то соответствующая величина составляет лишь
1/3c1 + 1/4c2.
Если сбор мусора не используется, то расход времени на один возвращаемый
узел равен константе c3 и, вне всяких сомнений, отношение c3/c1 будет очень
велико. Отсюда мы можем видеть, до какой степени неэффективен сбор мусора,
когда память становится полной, и соответственно, насколько он эффективен,
когда требования к памяти невелики.
Можно объединить сбор мусора с некоторыми другими методами возврата ячеек
в свободную память; эти принципы не исключают друг друга, и в некоторых
системах используются как счетчик ссылок, так и схемы сбора мусора, а кроме
того, программист может явно освобождать узлы.
Реферат на тему: Диплом Программная система "Аттестации ИТ-специалистов"
Министерство образования Российской Федерации
Южно-Уральский государственный университет
Кафедра “Электронные вычислительные машины”
Проект проверен Допустить к защите
Рецензент Зав. кафедрой
И.Л.Кафтанников
“__ ” 2003г. “
“ 2003г.
Программная система «Аттестации ИТ-специалистов»
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
ЮУрГУ- Д 220100.2003.452.00.ПЗ
Консультанты: Руководитель проекта:
Экономическая часть
_И.В. Хлопотова_______ И.Л .Надточий
“__”_____________ 2003г. “__”_____________ 2003г.
Авторы проекта:
Технологическая часть студенты группы_ПС- 300
_Н.С. Колмакова_ ____ Ю.Е Родионов. О.В Калагин
“__”______________2003г. “__”______________2003г.
_Раздел БЖД_________ Нормоконтроль_____
_В.Ф. Бухтояров_____ А.Н. Пустыгин______
“__”______________2003г. “__”______________2003г.
Челябинск
2003г.
ЮЖНО-УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Факультет Приборостроительный
Специальность 220100 “Вычислительные машины,комплексы, системы и сети”
УТВЕРЖДАЮ:
Зав. кафедрой
_________________
“___”_______2003г.
З А Д А Н И Е
по дипломному проекту (работе) студента группы ПС- 300
Родионов Юрий Евгеньевич, Калагин Олег Владимирович
(фамилия, имя, отчество)
1. Тема проекта (работы)
Программная система «Аттестации ИT-специалистов»
утверждена приказом по институту от “____” ___________2002 г. №
__________________
2. Сроки сдачи студентом законченного проекта (работы)
3. Исходные данные к проекту (работе)
1. Технология проведения аттестации ИТ-специалистов
2. Среда разработки Delphi 7.0
3. Требования к системе:
а) Защита информации
б) Возможность корректировки процесса аттестации
в) Возможность удалённого проведения аттестации
4. Содержание расчетно-пояснительной записки (перечень подлежащих
разработке вопросов)
1. Анализ существующих систем. Обзор литературы
2. Архитектура ПС
3. Разработка структур баз данных
4. Технология аттестации с использованием данной системы
5. Разработка компонент программной системы в среде Delphi 7
5. Формирование отчетов
6. Решение проблемы защиты информаци
7. Методика обработки данных ,полученных в результате аттестации
8. Инструкция по эксплуатации
9. Экономический раздел
10. БЖД
12. Заключение
13. Руководство системного администратора
5. Перечень графического материала (с точным указанием обязательных
чертежей
1. Среда разработки
(1лист)
2. Архитектура программного комплекса
(2 лист)
3. Структура базы данных
(1 лист)
4. Технология аттестации
(1 лист)
5. Технология аттестации с использованием программной системы
(1 лист)
6. Методика анализа результатов аттестации
(1 лист)
7. Интерфейс пользователя (1 лист)
8. Схемы алгоритмов
(3 листа)
9. Технология защиты информации
(1 лист)
10.Экономический раздел
(1 лист)
итого : 14 листов
6. Консультанты по проекту (работе), с указанием относящихся к ним разделам
проекта:
| | |Подпись, дата |
|Раздел |Консультант |Задание выдал Задание |
| | |принял |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
7. Дата выдачи задания _________________________2002г.
Руководитель___________________________________________/____________________
___/
Задание принял к
исполнению____________________________/________________________/
КАЛЕНДАРНЫЙ ПЛАН
|№№ |Наименование этапов дипломного |Срок выполнения |Отметка о |
| |проекта (работы) |этапов |выполнении |
| | |проекта (работы) | |
|1. | | | |
|2. | | | |
|3. | | | |
|4. | | | |
|5. | | | |
|6. | | | |
|7. | | | |
|8. | | | |
|9. | | | |
|10. | | | |
|11. | | | |
Зав. кафедрой
_______________________________________/_______________________/
Руководитель проекта
________________________________/_______________________/
Студент-дипломник
__________________________________/_______________________/
____________________________
/_______________________/
Аннотация
Родионов Ю .Е. Калагин О. В Система аттестации ИТ-
специалистов. – Челябинск: ЮУрГУ, ПС, 2003г, 193с.
Библиография литературы –12 наименований,14листов
чертежей ф.А1.
Проанализирован существующий порядок проведения аттестации ИТ –
специалистов, принятый на предприятии ОАО «Троицкая ГРЭС». В существующем
порядке были обнаружены существенные недостатки. Предложен новый порядок
проведения аттестации ИТ-специалистов с использованием программной системы.
Произведён расчёт экономической эффективности внедрения программной системы
аттестации ИТ – специалистов. Среда разработки системы Delphi 7.0 Inprise и
сервер баз данных Interbase.
СОДЕРЖАНИЕ
Введение 6
1 Типовые решения клиент серверных технологий……………………………9
1.1 Архитектуры "файл-сервер" и "клиент-сервер" 9
1.2 Создание приложений для работы с базами данных 12
1.3 Ядро Borland Database Engine (BDE) 15
1.4 Пакет Borland SQL Links for Windows 18
1.5 Использование SQL 22
1.6 Особенности создания систем клиент/сервер 22
1.7 Совместимость / эффективность 23
1.8 Перенос данных 24
1.9 Применение локального сервера InterBase 27
1.10 Локальный сервер InterBase 28
2 Анализ существующей системы. Обзор литературы………………….…….30
3 Архитектура программной системы………………………………………….34
4 Разработка структуры баз данных……………………………………………36
4.1.Общая характеристика реляционной модели данных 36
4.1.Предварительная структура базы данных, нормализация 43
4.1.Окончательная структура базы данных 46
5 Технология проведения аттестации с использованием ИТ-системы 49
5.1.Технология проведения аттестации на ОАО «Троицкая ГРЭС» и ее
недостатки. 49
5.2.Технология проведения аттестации с использованием системы. 49
6. Разработка компонент программной системы в среде 56
7.Формирование отчетов 61
8 Решение проблемы защиты информации 62
9 Методика обработки данных, полученных в результате аттестации. 69
10 Инструкция по экплуатации 70
10.1.Компонент «ИТА: Аттестация» 70
10.1.1.Минимальные системные требования 70
10.1.2 Порядок работы 70
10.2. Компонент «ИТА: Дизайнер-эксперт» 72
10.2.1.Минимальные системные требования 72
10.2.2Порядок работы 72
10.3.Компонент ИТА: Руководитель 75
10.3.1.Минимальные системные требования 75
10.3.2 Порядок работы 76
11 Экономический раздел 78
11.1.Постановка задачи 78
11.2.Построение сетевого графика и расчет его параметров 78
11.2.1.Построение сетевого графика 78
11.2.2.Расчет временных параметров событий сетевого графика 86
11.2.3.Расчет временных параметров работ сетевого графика 88
11.3. Технико-экономические показатели 92
11.3.1.Учет амортизации 92
11.3.2.Расходы на заработную плату исполнителей проекта. 93
11.3.3.Затраты на разработку программной системы аттестации ИТ-
специалистов 94
11.4.Целесообразность использования данного программного продукта 95
11.4.1.Анализ качественных преимуществ 95
11.4.2.Оценка эффективности приминения системы ИТ-тестирования
на предприятии…………………………….…………………………96
11.5.Вывод 97
12 Безопасность жизнедеятельности 98
12.1.Планировка помещения 98
12.2.Требования охраны труда к помещениям 99
12.3.Условия труда на рабочем месте 99
12.4.Освещение рабочих мест 100
12.4.1.Расчет естественного освещения 101
12.4.2.Расчет искусственного освещения 101
12.2.Анализ воздействия электромагнитных излучений 106
12.3.Анализ электробезопасности на рабочем месте 107
12.4.Пожарная профилактика. 108
12.5.Анализ шума на рабочем месте 110
12.6.Эргономические требования 111
13 Заключение 113
Список литературы 114
14 Руководство системного администратора 115
Приложение 1
Исходный текст программного комплекса:…………………………………..119
Введение
В связи с бурным развитием информационных технологий и проникновение их в
системы управления технологическими и бизнес процессами предприятий и
организаций, всё более значимой становится роль специалиста в области
информационных технологий – ИТ - специалиста.
Результатом работы над данным дипломным проектом является анализ
существующей технологии проведения аттестации ИТ-специалистов на
предприятии ОАО «Троицкая ГРЭС», её модификация и автоматизация.
Аттестация персонала становится общепризнанным способом оценки
результативности труда и как следствие важным средством для управления и
организационного развития.
Во многих компаниях регулярно, раз в год или в полгода, проводятся
аттестационные интервью, или собеседования. Обычно их проводит
непосредственный начальник аттестуемого работника. Целью такого
собеседования является налаживание обратной связи с сотрудником, чтобы
ознакомить его с мнением руководства о его деятельности [3].
Аттестационные собеседования носят исключительно оценочный характер, и
проводить их бывает довольно трудно. Деликатность ситуации заключается еще
и в том, что результаты этого интервью могут сказаться на зарплате
сотрудника. Конкретная цель каждого такого собеседования зависит от того,
как интервьюируемый справляется со своими служебными обязанностями.
Аргументом для их проведения является то, что они служит ряду важных
целей.
Оценка помогает определить, во-первых, какие работники требуют большей
подготовки и, во-вторых, результаты программ набора и обучения персонала
[4].
Она помогает установлению и укреплению деловых отношений между
подчиненными и руководителями через обсуждение результатов оценки и, кроме
того, она побуждает руководителей учиться оказывать необходимую помощь.
Оценка для администрации помогает решить, кому следует повысить зарплату,
кого — повысить в должности, а кого — уволить.
Оценка побуждает работников действовать более результативно. Наличие
соответствующей программы и гласность результатов ее выполнения развивают
инициативу, повышают чувство ответственности и стимулируют стремление
работать лучше.
Оценка служит юридической основой переводов, продвижений по службе,
наград и увольнений. Она дает материал для разработки вопросников по найму.
Оценка позволяет получить дополнительную информацию для того, чтобы
определить зарплату и другие вознаграждения работника. Она является
естественным поводом для продолжительной беседы между руководителем и
подчиненным о проблемах работы, в ходе которой они лучше узнают друг друга.
И, наконец, результаты оценки могут быть использованы при разработке
средств отбора персонала, например, тестов [4].
Необходимо учитывать, что в процессе аттестации всегда имеется место для
случаев предубежденности и ошибок. Так, например, менеджеры, проводящие
интервью, могут ориентироваться на проблемы, несущественные для выполнения
конкретных работ, или же придавать слишком малое значение важным слагаемым
результативности труда работника.
Основным вопросом при этом является: "Что следует оценивать?"
Показатели, по которым оцениваются работники, называют критериями оценки.
Сюда относятся, в частности, качество выполняемой работы, ее количество и
ценностная оценка результатов. Важным здесь является то, что оцениваться
должны не личности, а результативность работы.
Для такой оценки необходимо довольно большое количество критериев. Их
отбор — непростая задача. Предпочтения зависят от конкретных целей бизнеса
и сложившейся корпоративной культуры. Если задача — повышение
результативности труда на рабочих местах, то критерии должны
непосредственно относиться к результативности труда. Если для этой или
будущих работ необходимы навыки общения и личные качества — необходимо
делать упор именно на них.
1 Типовые решения клиент серверных технологий
1.1 Архитектуры "файл-сервер" и "клиент-сервер"
Базы данных на персональных компьютерах развивались по направлению от
настольных (desktop), или локальных приложений, когда реально с БД могло
работать одно приложение, до систем коллективного доступа к БД.
Локальное приложение устанавливаются на единичном персональном
компьютере; там же располагаются и БД, с которой работает данное
приложение. Однако необходимость коллективной работы с одной и той же БД
влечет за собой перенос БД на сетевой сервер. Приложение, работающее с БД,
располагается также на сервере. Менее характерным стал другой способ,
заключающийся в хранении приложения, обращающегося к БД, на конкретном
компьютере пользователей ("клиентов"). Были выпущены новые версии локальных
СУБД, которые позволяли создавать приложения, одновременно работающие с
одной БД на файловом сервере. Основной проблемой стала явная или неявная
обработка транзакций и неизбежно встающая при коллективном доступе проблема
обеспечения смысловой и ссылочной целостности БД при одновременном
изменении одних и тех же данных [3].
В ходе эксплуатации таких систем были выявлены общие недостатки файл
серверного подхода при обеспечении многопользовательского доступа к БД. Они
состоят в следующем:
- вся тяжесть вычислительной нагрузки при доступе к БД ложится на
приложение клиента, что является следствием принципа обработки
информации в системах "файл-сервер": при выдаче запроса на выборку
информации из таблицы вся таблица БД копируется на клиентское место,
и выборка осуществляется на клиентском месте;
- локальные СУБД используют так называемый "навигационный подход",
ориентированный на работу с отдельными записями;
- не оптимально расходуются ресурсы клиентского компьютера и сети:
например, если в результате запроса мы должны получить 2 записи из
таблицы объемом 10 000 записей, все 10 000 записей будут
скопированы с файл-сервера на клиентский компьютер; в результате
возрастает сетевой трафик и увеличиваются требования к аппаратным
мощностям пользовательского компьютера. Заметим, что потребности в
постоянном увеличении вычислительных мощностей клиентского компьютера
обусловливаются не только развитием программного обеспечения как
такового, но и возрастанием обрабатываемых объемов информации;
- в БД на файл-сервере гораздо проще вносить изменения в отдельные
таблицы, минуя приложения, непосредственно из инструментальных
средств (например, из утилиты Database Desktop фирмы Borland для
файлов Paradox или dBase); подобная возможность облегчается тем
обстоятельством, что, фактически, у локальных СУБД база данных
понятие более логическое, чем физическое, поскольку под БД понимается
набор отдельных таблиц, сосуществующих в едином каталоге на диске.
Все это позволяет говорить о низком уровне безопасности - как с точки
зрения хищения и нанесения вреда, так и с точки зрения внесение
ошибочных изменений;
- бизнес правила в системах "файл-сервер" реализуются в приложении, что
позволяет в разных приложениях, работающих с одной БД, проектировать
взаимоисключающие бизнес правила; смысловая целостность информации
при этом может нарушаться;
- недостаточно развитый аппарат транзакций для локальных СУБД служит
потенциальным источником ошибок как с точки зрения одновременного
внесения изменений в одну и ту же запись, так и с точки зрения отката
результатов серии объединенных по смыслу в единое целое операций над
БД, когда некоторые из них завершились успешно, а некоторые - нет;
это может нарушать ссылочную и смысловую целостность БД.
Приведенные недостатки решаются при переводе приложений из архитектуры
"файл-сервер " в архитектуру "клиент-сервер ", которая знаменует собой
следующий этап в развитии СУБД. Характерной особенностью архитектуры
"клиент-сервер" является перенос вычислительной нагрузки на сервер БД (SQL-
сервер) и максимальная разгрузка приложения клиента от вычислительной
работы, а также существенное укрепление безопасности данных - как от
злонамеренных, так и просто ошибочных изменений.
БД в этом случае помещается на сетевом сервере, как и в архитектуре "файл-
сервер", однако прямого доступа к БД из приложений не происходит. Функции
прямого обращения к БД осуществляет специальная управляющая программа
сервер БД (SQL-сервер), поставляемая разработчиком СУБД.
Взаимодействие сервера БД и приложения-клиента происходит следующим
образом: клиент формирует SQL-запрос и отсылает его серверу. Сервер, приняв
запрос, выполняет его и результат возвращает клиенту. В клиентском
приложении в основном осуществляется интерпретация полученных от сервера
данных, реализация интерфейса с пользователем и ввод данных, а также
реализация части бизнес правил.
Преимущества архитектуры "клиент-сервер":
• большинство вычислительных процессов происходит на сервере; таким
образом, снижаются требования к вычислительным мощностям компьютера
клиента;
• снижается сетевой трафик за счет посылки сервером клиенту только тех
данных, которые он запрашивал; например, если необходимо сделать из таблицы
объемом 10 000 записей выборку, результатом которой будут всего 2 записи,
сервер выполнит запрос и перешлет клиенту НД из 2 записей;
• упрощается наращивание вычислительных мощностей в условиях развития
программного обеспечения и возрастания объемов обрабатываемых данных: проще
и чаще дешевле усилить мощности на сетевом сервере или полностью заменить
сервер на более мощный, нежели наращивать мощности или полностью заменять
100-500 клиентских компьютеров;
• БД на сервере представляет собой, как правило, единый файл, в котором
содержатся таблицы БД, ограничения целостности и другие компоненты БД.
Взломать такую БД, даже при наличии умысла, тяжело; значительно
увеличивается защищенность БД от ввода неправильных значений, поскольку
сервер БД проводит автоматическую проверку соответствия вводимых значений
наложенным ограничениям и автоматически выполняет необходимые бизнес
правила; кроме того, сервер отслеживает уровни доступа для каждого
пользователя и блокирует осуществление попыток выполнения неразрешенных для
пользователя действий: например, изменения или просмотр таблиц; все это
позволяет говорить о значительно более высоком уровне обеспечения
безопасности БД и ссылочной и смысловой целостности информации;
• сервер реализует управление транзакциями и предотвращает попытки
одновременного изменения одних и тех же данных; различные уровни изоляции
транзакций позволяют определить поведение сервера при возникновении
ситуаций одновременного изменения данных;
• безопасность системы возрастает за счет переноса большей части бизнес
правил на сервер; падает удельный вес противоречащих друг другу бизнес
правил в клиентских приложениях, выполняющих разные действия над БД;
определить такие противоречивые бизнес правила в приложениях клиента все
еще можно, однако намного труднее их выполнить ввиду автоматического
отслеживания сервером БД правильности данных.
Для реализации архитектуры применяют так называемые "промышленные” СУБД,
такие как Borland InterBase, Oracle, Informix, Sybase, DB2, MS SQL Server.
1.2 Создание приложений для работы с базами данных
Delphi 7.0 представляет собой уникальную систему разработки, в которой
технология высокопроизводительной оптимизирующей компиляции сочетается с
визуальными средствами разработки и масштабируемым процессором баз данных.
Это позволяет создавать эффективные приложения Windows, работающие с базами
данных, в том числе и программы для систем клиент/сервер. Для создания
таких приложений в Delphi 7.0 используется объектно-ориентированный подход,
базирующийся на применении различных компонентов (визуальных и не
визуальных), что обеспечивает неограниченную расширяемость и
маcштабируемость. Delphi 7.0 позволяет разработчику быстро создавать и
свободно распространять приложения с архитектурой клиент/сервер, работающие
существенно быстрее и надежнее предыдущего поколения программных продуктов,
которые строились при помощи систем разработки, основанных на
интерпретируемом коде [9].
Большим преимуществом приложений, разрабатываемых в среде Delphi 7.0,-
стала доступность использования как реляционного, так и навигационного
программирования при работе с данными. Такую возможность приложениям Delphi
7.0 предоставляет ядро процессора баз данных Borland Database Engine (BDE).
Использование реляционных методов позволяет манипулировать большими
выборками информации и легко проводить групповые операции. Навигационные
методы дают приложению преимущества быстрого доступа к отдельным полям и
записям таблиц баз данных.
Структурная схема организации доступа приложения к различным базам данных
отражена на рисунке 1.1. В наиболее общем случае работа с данными в Delphi
7.0 осуществляется через BDE, который обеспечивает непосредственную связь с
локальными базами данных и используется при организации доступа к удаленным
серверам. В основе BDE лежит технология Integrated Database API (IDAPI),
уже известная программистам, которые работают с СУБД фирмы Borland. Через
BDE и драйверы Borland SQL Links приложение может связываться с SQL-
серверами. В то же время, BDE поддерживает и интерфейс Open DataBase
Connectivity (ODBC), что позволяет получить доступ не только к любому
удаленному серверу баз данных, для которого имеется драйвер ODBC, но и к
любому источнику структурированных данных.
[pic]
Рис. 1.1. Механизм организации доступа приложения к базам данных
Примечание
ODBC — интерфейс для свободного доступа к данным в гетерогенной среде
реляционных и не реляционных баз данных. Основываясь на базовом интерфейсе
SQL — Call Level Interface, ODBC обеспечивает открытый до ступ к
большинству данных, расположенных на персональном компьютере миникомпьютере
и к базам данных больших ЭВМ, позволяя разработчикам иметь одновременный
доступ к базам данных. Стандарт ODBC полностью поддерживает технологию
клиент/сервер.
В состав стандартной поставки Delphi 7.0 включен локальный сервер
Interbase, который позволяет проводить в Delphi 7.0 автономную разработку
приложений с поддержкой SQL, готовых к переносу в среду клиент/сервер. Он
представляет собой облегченный вариант Interbase Workgroup Server 4.0.
1.3 Ядро Borland Database Engine (BDE)
Как уже отмечалось, использование Delphi 7.0 позволяет разработчику
создавать самые разнообразные приложения для работы с базами данных. Среди
них могут быть как простейшие программки, открывающие два-три поля, так и
мощные приложения, предназначенные для работы в системах клиент/сервер.
Такая универсальность достигается за счет использования ядра BDE. В основе
BDE лежит технология IDAPI, которая включает IDAPI-инфраструктуру и
обработчик запросов [2].
Использование BDE позволяет приложению осуществлять доступ к данным не
только локальных (Paradox и dBase), но и удаленных баз данных,
расположенных на SQL-серверах (Interbase, Sybase, Oracle, Informix, MS SQL
Server), а также в любых форматах, доступных через драйверы ODBC (см. рис.
1.2). BDE поддерживает многопользовательский доступ к гетерогенным базам
данных, связанные запросы к нескольким разнотипным базам данных
одновременно, прямой перенос данных из одного формата в другой.
Программисты могут обращаться к функциям BDE с помощью языков
программирования Borland C++, Borland Pascal, Visual C++, а также любых
других компиляторов С и C++ для Windows.
Архитектура BDEUDAPI основана на драйверах. Для каждого источника данных
существует свой драйвер, который поддерживает не только последнюю версию
источника, но и все предыдущие версии. Именно через такие драйверы
осуществляется связывание и все обращения к данным. BDE поддерживает два
класса драйверов. К первому классу относятся драйверы, обслуживающие SQL-
серверы, причем каждый из этих серверов может использовать собственный
диалект SQL. Во второй класс входят драйверы для локальных баз данных.
Архитектура BDEMDAPI является объектно-ориентированной, поэтому ее
инфраструктура легко расширяется и обобщается. В комплекте BDE содержатся
более пятидесяти языковых драйверов, которые используются всеми драйверами
доступа к данным и всеми общими обработчиками и сортировщиками запросов.
Инфраструктура BDEUDAPI предоставляет обширный набор инструментов, которые
могут использоваться всеми драйверами.
Диспетчер памяти предоставляет дополнительные возможности по управлению
памятью. В отладочном режиме этот модуль помечает, трассирует и разрешает
все попытки использовать память.
Диспетчер буфера основывается на использовании приоритетов и поддерживает
режим совместного использования буферов различными драйверами.
Сортировщик автоматически оптимизирует процесс использования доступной
памяти и вызывается через соответствующую функцию BDE. Он использует
установленный языковый драйвер для работы с различными наборами символов.
Кэш для данных BLOB позволяет производить чтение/запись произвольного
места в бинарном объекте, при переполнении содержимое кэша автоматически
записывается в разделяемый файл. Одновременно может быть открыто любое
количество BLOB.
Генератор SQL транслирует запрос в формате QBE в эквивалентный запрос
SQL, если он предназначен SQL-серверу.
Модуль реструктурирования поддерживает сложные изменения структур таблиц,
в том числе добавление новых полей, удаление полей, изменение их имен,
изменение свойств поля (тип, размер), ссылочной целостности таблицы и т. д.
Также этот модуль создает новую таблицу, трансформирует данные и копирует
их в нее.
Функции пакетной обработки включают копирование данных из одного формата
в другой, переименование таблиц и т. д.
Модуль Xlate оптимизирует процесс преобразования форматов данных.
Модуль таблиц в памяти обеспечивает виртуальную память, ориентированную
на таблицы. Он поддерживает курсоры приложений, как и любые другие курсоры
IDAPI. Работа модуля тесно связана с работой диспетчера буфера.
Модуль поддержки SQL-драйверов используется при создании любых SQL-
драйверов.
Конфигурационный диспетчер участвует в настройке среды BDE при начальной
загрузке.
Системный диспетчер управляет всеми ресурсами системного уровня. Он
отвечает за загрузку драйверов, отслеживание открытых баз данных, курсоров
и контекста каждого приложения.
Общий обработчик запросов поддерживает и SQL и QBE. Он построен с
использованием технологии курсоров BDE и поэтому может работать с любым
источником данных. Если запрос может быть выполнен напрямую, то он сразу
передается серверу. Запрос QBE предварительно транслируется в SQL.
Технология Idapter является составной частью BDE и предназначена для
организации доступа к базам данных, используя стандартный программный
интерфейс драйверов Borland SQL Links. Idapter транслирует вызовы функций
интерфейса IDAPI в вызовы стандартных методов интерфейса ODBC, что
позволяет использовать практически любой драйвер стандарта ODBC в режиме
драйвера IDAPI. При этом могут использоваться любые функции интерфейса
IDAPI. Технология Idapter существенно увеличивает число доступных
через BDE форматов данных. Поставляется совместно с IDAPI, как отдельная
динамическая библиотека.
1.4 Пакет Borland SQL Links for Windows
Пакет Borland SQL Links for Windows предназначен для использования теми
приложениями, работающими с BDE, которым необходим доступ и к локальным
базам данных и к удаленным SQL-серверам. После инсталляции соответствующего
драйвера SQL Links и создания необходимого псевдонима приложение получает
доступ к базам данных необходимого SQL-сервера. Место SQL Links в механизме
доступа к базам данных из приложений Delphi 7.0 показано на рисунке 4.7.
Установленный драйвер выполняет работу по соединению с нужным SQL-
сервером, переводу запросов приложения в соответствующий диалект SQL и
передаче запроса базе данных. Ответ базы данных снова преобразуется им к
виду, воспринимаемому приложением.
Для установки параметров процесса связывания приложения с требуемым
сервером SQL используется утилита конфигурации BDE. Естественно, что перед
выполнением такой настройки необходимо иметь инсталлированный SQL Links с
установленным драйвером для нужного сервера. Все настраиваемые параметры
сосредоточены на странице Drivers утилиты конфигурации (см. рисунок 1.2).
Рис. 1.2. Использование драйвера SQL Links приложением
Первым делом необходимо выбрать нужный драйвер из списка имен драйверов в
левой части панели. В правой части появится список всех параметров драйвера
и их текущих значений. При необходимости, можно переопределить значения
параметров, заданные по умолчанию и сохранить изменения. Эффект от
сделанных установок проявится только при следующем запуске приложения.
Ниже будут рассмотрены общие для всех драйверов SQL Links параметры.
Дополнительную информацию о специфических параметрах каждого драйвера
можно получить, выбрав соответствующее имя в списке утилиты конфигурации
BDE и нажав кнопку Help.
DLL — определяет имя динамической библиотеки SQL Links для драйвера.
Driver Flags — внутренний флаг, изменять этот параметр не рекомендуется.
LangDriver — задает языковый драйвер, который применяется для
манипулирования данными, полученными при помощи драйвера SQL Links. Поле
ввода этого параметра содержит список всех доступных языковых драйверов.
Если выбранный языковый драйвер определен также и в псевдониме приложения,
то он используется для управления любыми данными, полученными от сервера.
Языковый драйвер используется для преобразования данных, если приложение и
сервер используют разные кодовые страницы. В противном случае все
национальные символы превратятся в абракадабру. Если необходимый языковый
драйвер отсутствует, можно использовать параметр SQLQRYMODE для отмены
преобразования данных по правилам базы данных.
Open Mode — определяет режим, в котором SQL Links открывает доступ к базе
данных. Возможные значения: "Чтение3апись" и "Только для чтения". Режим
"Только для чтения" не работает при использовании прямых запросов.
Schema Cache Size — задает число таблиц базы данных, чья структурная
информация кэшируется. Возможные значения: 0—32 (по умолчанию 8).
Schema Cache Time — задает время нахождения структурной информации о
таблицах в кэше. Возможные значения: -1 (по умолчанию) — до закрытия базы
данных; 0 — информация в кэше не размещается; 1-214748347 — число секунд.
Server Name — содержит имя целевого сервера. Для серверов Interbase
обязательно надо задавать маршрут, как это показано в примере:
servername/usr/gds/directoryname/databasename/gdb.
SQLPASSTHRUMODE — определяет режим использования прямых и локальных
запросов при соединении через один псевдоним: NOT SHARED запрещает
одновременное использование прямых и локальных запросов;
SHARED AUTOCOMMIT разрешает совместное использование, причем прямые
запросы ведут себя в соответствии с правилами для локальных запросов, что
означает режим автоматической фиксации транзакций, если только не
установлено явное управление транзакциями или режим группового выполнения;
SHARED NOAUTOCOMMIT разрешает совместное использование, но режим неявной
фиксации транзакций не используется. Поведение прямых запросов зависит от
типа сервера.
Предопределенное значение для серверов Informix — SHARED AUTOCOMMIT, для
остальных серверов SQL — NOT SHARED. Режимы SHARED AUTOCOMMIT и SHARED
NOAUTOCOMMIT не поддерживаются некоторыми предложениями прямых запросов, в
этом случае следует использовать явное управление транзакциями через
функции приложения.
SQLQRYMODE — определяет режим выполнения запросов, возможные значения
приведены в таблице.
Таблица 1.1 Режимы выполнения запросов.
|Значение |Режим |Комментарий |
|NULL |Сервер-локальный |Запрос направляется сначала на сервер, |
| | |затем, при невозможности выполнения, |
| | |выполняется локально |
|SERVER |Только сервер |Запрос направляется только на сервер, в |
| | |случае невозможности выполнения, отменяется|
|LOCAL |Только локальный |Запрос выполняется исключительно локально |
Значение по умолчанию — NULL. На получаемый результат запросов может
влиять установленный языковый драйвер, если локальные базы данных и базы
SQL имеют различные кодовые страницы (см. выше). Для устранения подобных
ошибок необходимо установить для параметра значение SERVER, блокируя таким
образом, выполнение запросов в локальных базах данных.
Type определяет тип используемого сервера. Значение SERVER определяет
использование SQL-сервера. Значение FILE определяет использование обычных
серверов, основанных на файловой системе.
User Name — задает имя пользователя для доступа к серверу.
Version — версия драйвера SQL Links.
Для доступа к серверу SQL необходимо иметь соответствующий псевдоним.
Базовый псевдоним для каждого используемого драйвера SQL Links создается
автоматически при первом изменении параметров драйвера после инсталляции.
1.5 Использование SQL
В этом разделе будут рассмотрены различные аспекты применения запросов
SQL в приложениях, использующих базы данных. Для реализации запросов в
Delphi 7.0 существует специальный компонент — TQuery, расположенный на
странице Data Access Палитры компонентов. Он имеет много общих свойств с
TTable и тоже используется для открытия наборов данных. В то же время
TQuery обладает рядом свойств и методов, которые позволяют использовать все
преимущества запросов SQL для работы с данными. Так, применение TQuery дает
возможность работать с данными нескольких таблиц в одном запросе, отбирать
данные сразу по нескольким критериям. Однако следует помнить, что
использование SQL ведет к некоторому усложнению программного кода
приложения. Кроме того, создание эффективного запроса — дело далеко не
простое и требует наличия определенного опыта в этой области. Запросы SQL
бывают статическими и динамическими. Статические запросы полностью
создаются при отладке приложения, а динамические могут изменять свои
параметры при выполнении приложения.
Приложения Delphi 7.0 при помощи механизма запросов SQL могут
использовать данные:
• таблиц Paradox и dBase, используя синтаксис локального SQL;
• локального сервера Interbase, синтаксис языка поддерживается полностью;
• удаленных серверов SQL через драйверы SQL Links.
1.6 Особенности создания систем клиент/сервер
Возможность создания приложений для работы в составе систем
клиент/сервер, бесспорно, стала большим преимуществом Delphi 7.0.
Инструментарий для разработки таких приложений интегрирован в составе среды
разработчика. Приложения Delphi 7.0, функционирующие на станции-клиенте,
используя возможности BDE и драйверов SQL Links и ODBC, могут получать
доступ к данным удаленных SQL-серверов. В качестве серверов могут быть
использованы Informix, Interbase, Microsoft SQL Server, Oracle, Sybase.
Кроме этого, через BDE и установленный драйвер ODBC возможен доступ к таким
базам, как DB2, Btrieve, Microsoft Access и другим, для которых существует
соответствующий драйвер ODBC.
Приложение, функционирующее на станции-клиенте, обычно создается отдельно
и для уже работающих серверов баз данных. Поэтому, для создания
работоспособной системы клиент/сервер необходимо решить ряд проблем
связывания рабочих станций, совместимости данных при работе одного
приложения-клиента с различными типами серверов, оптимизации
производительности.
1.7 Совместимость / эффективность
Как известно, при создании приложений для систем клиент/сервер всегда
приходится решать проблему выбора между универсальностью и
производительностью. С одной стороны, чем большее количество типов серверов
поддерживается приложением, тем лучше. Но в этом случае значительно
понижается производительность. Впрочем, способ решения этой проблемы
зависит от предназначения создаваемого приложения. Иногда можно
пожертвовать совместимостью, а иногда оказывается не так уж и важна
производительность.
Совместимость по данным в значительной степени зависит от используемых
приложением компонентов. При применении ТТаblе проблем практически не
возникает, а вот при использовании TQuery приходится накладывать
ограничения на синтаксис предложений SQL в зависимости от диалекта SQL,
используемого сервером.
Производительность приложения-клиента может быть повышена при
использовании хранимых процедур сервера, однако это приводит к
дополнительной специализации программы.
В зависимости от типа оборудования, на котором работает приложение, может
возникнуть необходимость в поддержке нескольких коммуникационных
протоколов. Эта проблема решается инсталляцией соответствующего
программного обеспечения на станции-клиенте и сервере, однако, это решение
должно быть предусмотрено еще на этапе проектирования системы
клиент/сервер. Информацию об инсталлированном протоколе необходимо включить
в драйве SQL Links.
В дальнейшем реализация архитектуры "клиент-сервер" будет рассматриваться
для сервера Borland Interbase. Объяснить такой выбор нетрудно. Во-первых,
Interbase - "родной" сервер для Delphi 7.0 (поэтому для доступа к нему не
нужно устанавливать дополнительных драйверов SQL Links, что необходимо при
работе из приложений, написанных на Delphi 7.0, с Oracle, Sybase и другими
СУБД). Во вторых, в поставку Delphi входит локальный (однопользовательский,
на 2 одновременных подключения) сервер Local Borland Interbase. Доступен
также и Interbase для Windows 95 на 4 пользователя.
Локальный Interbase может использоваться для отладочных целей. После
того, как приложение отлажено на локальной версии SQL-сервера, происходит
масштабирование приложения (upsizing). БД переносится на сетевой сервер, а
изменения в клиентских приложениях при этом минимальны - необходимо
изменить псевдоним БД и, может быть, скорректировать некоторые параметры
соединения приложения с сервером.
1.8 Перенос данных
При переносе приложений, ранее разработанных для применения в архитектуре
"файл-сервер", требуется не только частично или полностью переписывать
приложения клиентов, но и преобразовывать локальную БД в серверную. Для
этого под управлением серверной СУБД (например, Interbase) создают БД на
сервере, куда затем "перекачивают" данные из локальных СУБД реализованных,
например, с помощью Paradox. Основная проблема, встающая в этом случае -
несовместимость некоторых форматов данных или их отсутствие. Например,
Interbase не поддерживает поля типа Boolean (Logical), и их необходимо
реализовывать при помощи столбцов типа CHAR(1); Interbase не поддерживает
автоинкрементные поля Paradox - для обеспечения уникальности значений в
числовых полях в БД Interbase используют генераторы и т.д. При
возникновении подобных проблем следует изучить вопросы совместимости типов
данных локальной СУБД и выбранной серверной СУБД.
Преобразование делится на два этапа:
•
• модернизация баз данных до уровня сервера;
• преобразование приложений в приложения-клиенты.
Преобразование позволяет поднять систему приложение-база данных на
качественно новый уровень, так как архитектура клиент/сервер имеет ряд
важных преимуществ. Среди них многопользовательский доступ, возможность
работы с множествами, а не с отдельными записями, использование доступа ко
всем данным, а не к отдельным таблицам.
Преобразование базы данных в сервер содержит ряд этапов.
1. Создание метаданных, основанных на структуре базы данных.
2. Перенос данных на сервер.
3. Разделение данных по типам.
4. Создание паролей и интеграция данных.
5. Контроль транзакций.
6. Управление доступом к данным.
7. Проверка данных.
Delphi обеспечивает два способа преобразования баз данных:
• использование возможностей утилиты Database Desktop для преобразования
таблиц в формат SQL;
• использование при создании приложения компонента TBatchMove.
Оба эти способа копируют структуру данных и переносят сами данные в
формат SQL-сервера. В новую структуру метаданных могут быть добавлены новые
элементы: индексы, хранимые процедуры, триггеры и т. д. Для некоторых типов
серверов более эффективным может стать ручное создание структуры метаданных
с дальнейшим переносом данных, как предлагается выше.
Приложения, созданные для работы с локальными базами | |
