Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области 'ДТП'

Разработка клиент-серверного приложения в трехуровневой архитектуре для предметной области 'ДТП'

Министерство образования и науки Украины

Национальный аэрокосмический университет им. Н.Е. Жуковского «ХАИ»

Кафедра № 405

Курсовой проект

на тему

«Разработка клиент - серверного приложения в трехуровневой архитектуре для предметной области «ДТП»

по дисциплине

«Информационные технологии и интегрированные системы управления»

Реферат

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

Разбив систему на функциональные фрагменты, были выделены следующие уровни:

презентационная логика (Presentation Layer - PL);

бизнес-логика (Business Layer - BL);

логика доступа к ресурсам (Access Layer - AL).

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

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

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

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

СОДЕРЖАНИЕ

Реферат

Введение

. Традиционные подходы в моделировании

. Многоуровневые архитектуры клиент - сервер

. Проектное решение, реализующее модель реляционной БД

. Диаграмма функциональных зависимостей

. Спецификация на разработку интерфейса

. Диаграммы классов, реализующих уровни презентации, бизнес - логики и базы данных приложения

. Словесное описание процесса выполнения транзакций

. Специальная часть: «Хранимые процедуры»

.1 Понятие хранимой процедуры

.2 Создание, изменение и удаление хранимых процедур

.3 Выполнение хранимой процедуры

. Инструкция пользователя по работе с приложением

Заключение

Список литературы

архитектура клиент сервер приложение

ВВЕДЕНИЕ

Говоря о прикладных системах, предназначенных для работы с базами данных, чаще всего на ум приходит модель вычислений, основанная на двух взаимодействующих компонентах - клиенте, отвечающем за организацию диалога с пользователем и несущем на себе бизнес-логику, и сервере, обеспечивающем многопользовательскую работу с данными и их целостность. Описанная таким образом архитектура клиент-сервер является более фундаментальным явлением, чем просто способ построения приложений a-la "многопользовательская бухгалтерия". На нынешнем уровне зависимости бизнеса от информационных систем разработчикам приходится сталкиваться не только с задачами реализации адекватных техническим требованиям функциональности и пользовательского интерфейса, но и с оптимизацией обмена данным между различными компонентами системы. Учитывая, что корпоративные системы обладают достаточно высоким уровнем сложности, в процессе их эксплуатации возникает ряд вопросов связанных с надежностью и управляемостью такой системы. Появление такого рода акцентов в процессе проектирования и разработки корпоративных систем приводит к необходимости решения следующей важной задачи - выделения из клиентской и серверной части системы компонентов, несущие на себе строго определенную служебную функциональность.

Целью исследований представленных в данной работе являются:

Разработка полнофункционального клиент - серверного приложения, реализующего прототип информационной системы, необходимой для успешного функционирования предприятий разного типа. Стандартной информационной моделью для курсового проекта должна стать трехуровневая архитектурная модель, реализованная для windows - приложения. Кроме того, в курсовом проекте необходимо реализовать 2 запроса с помощью хранимых процедур.

ТРАДИЦИОННЫЕ ПОДХОДЫ В МОДЕЛИРОВАНИИ

Разобьем систему на функциональные фрагменты.

На верхнем уровне абстрагирования достаточно четко можно выделить следующие компоненты:

презентационная логика (Presentation Layer - PL);

бизнес-логика (Business Layer - BL);

логика доступа к ресурсам (Access Layer - AL).

Таким образом, можно придти к нескольким моделям клиент-серверного взаимодействия:

"Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL. Серверная часть, при описанном подходе, представляет собой сервер баз данных , реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

"Тонкий" клиент. Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.

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

Описанные три модели организации клиент-серверных систем в определенной степени являются ориентирами в задании жесткости связей между различными функциональными компонентами, чем строго описываемыми программами в реальных проектах. Жесткость связей в схеме взаимодействия компонент системы часто определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL), обеспечивающего обмен информацией между различными компонентами.

При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL, AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов (Reporting), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server - AS). Причем, сервер приложений не просто является некоим единым универсальным средним BL-звеном между клиентской и серверной частью системы, но AS существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия.

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

Рисунок 1 - Многоуровневая клиент-серверная модель

Рассмотренные модели имеют следующие недостатки.

) Толстый" клиент:

сложность администрирования;

усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;

усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;

перегружается сеть вследствие передачи по ней необработанных данных;

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

) "Толстый" сервер:

усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;

производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;

программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;

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

Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер.

2. МНОГОУРОВНЕВЫЕ АРХИТЕКТУРЫ КЛИЕНТ - СЕРВЕР

В трехуровневой архитектуре "тонкий" клиент не перегружен функциями обработки данных, а выполняет свою основную роль системы представления информации, поступающей с сервера приложений. Такой интерфейс можно реализовать с помощью стандартных средств Web-технологии - браузера, CGI и Java. Это уменьшает объем данных, передаваемых между клиентом и сервером приложений, что позволяет подключать клиентские компьютеры даже по медленным линиям типа телефонных каналов. Кроме того, клиентская часть может быть настолько простой, что в большинстве случаев ее реализуют с помощью универсального браузера. Но если менять ее все-таки придется, то эту процедуру можно осуществить быстро и безболезненно. Трехуровневая архитектура клиент-сервер позволяет более точно назначать полномочия пользователей, так как они получают права доступа не к самой базе данных, а к определенным функциям сервера приложений. Это повышает защищенность системы (по сравнению с обычно архитектурой) не только от умышленного нападения, но и от ошибочных действий персонала.

3. ПРОЕКТНОЕ РЕШЕНИЕ, РЕАЛИЗУЮЩЕЕ МОДЕЛЬ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

Модель представлена в виде диаграммы в нотации Erwin в графическом виде для логического (рис.2) и физического (рис.3) уровней представления модели.

Рисунок 2 - Логический уровень представления модели

Рисунок 3 - Физический уровень представления модели

4. ДИАГРАММА ФУНКЦИОНАЛЬНЫХ ЗАВИСИМОСТЕЙ

Рисунок 4 - диаграмма функциональных зависимостей

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

5. СПЕЦИФИКАЦИЯ НА РАЗРАБОТКУ ИНТЕРФЕЙСА

Рисунок 5 - Form 1

На рис.5 textBox1, textBox2, textBox3, textBox4, textBox5 - результат выполнения хранимой процедуры:

"CREATE PROC my_proc_1 ДТП.ДТП_ид AS [номер ДТП], ДТП_Виновник.участник_ид AS виновник, ДТП.дата AS дата, Участник.ФИО AS ФИО, Участник.номер_паспорта AS [номер паспорта], Участник.дом_адрес AS [дом. адрес] ДТП INNER JOIN ДТП_Виновник ON ДТП.ДТП_ид = ДТП_Виновник.ДТП_ид INNER JOIN Пешиходы ON ДТП.ДТП_ид = Пешиходы.ДТП_ид INNER JOIN Участник ON ДТП_Виновник.участник_ид = Участник.участник_ид AND Пешиходы.пешеход_ид = Участник.участник_ид

WHERE (ДТП.дата BETWEEN CONVERT(DATETIME, '2008-08-20 00:00:00', 102) AND CONVERT(DATETIME, '2008-09-17 00:00:00', 102)) ".

Рисунок 6 - Form 2

На рис.6 textBox1, textBox2 - результат выполнения хранимой процедуры: "CREATE PROC my_proc_2 TOP 100 PERCENT COUNT(место) AS [Кол-во ДТП], место dbo.ДТП GROUP BY место ORDER BY COUNT(место) DESC ".

Рисунок 7 - Form 3

На рис. 7 - textBox1, textBox2, textBox3, textBox4, textBox5, textBox6 :

"SELECT ДТП.ДТП_ид AS [номер ДТП], ДТП_Виновник.участник_ид AS виновник, ДТП.дата AS дата, Участник.ФИО AS ФИО, Участник.номер_паспорта AS [номер паспорта], Участник.дом_адрес AS [дом. адрес] ДТП INNER JOIN ДТП_Виновник ON ДТП.ДТП_ид = ДТП_Виновник.ДТП_ид INNER JOIN Пешиходы ON ДТП.ДТП_ид = Пешиходы.ДТП_ид INNER JOIN Участник ON ДТП_Виновник.участник_ид = Участник.участник_ид AND Пешиходы.пешеход_ид = Участник.участник_ид (ДТП.дата BETWEEN CONVERT(DATETIME, '2008-08-20 00:00:00', 102) AND CONVERT(DATETIME, '2008-09-17 00:00:00', 102))".

Рисунок 8 - Form 4

На рис. 8 - textBox1, textBox2, textBox3:

"SELECT Водители.водитель_ид AS водитель, Участник.ФИО AS ФИО, ДТП.дата AS дата Водители INNER JOIN ДТП ON Водители.ДТП_ид = ДТП.ДТП_ид INNER JOIN Участник ON Водители.водитель_ид = Участник.участник_ид

WHERE (Водители.водитель_ид IN (SELECT водитель_ид FROM Водители WHERE (дата BETWEEN CONVERT(DATETIME, '2008/07/15 00:00:00', 102) AND CONVERT(DATETIME, '2008/09/17 00:00:00', 102))GROUP BY водитель_ид HAVING (COUNT(водитель_ид) > 1))) AND (ДТП.дата BETWEEN CONVERT(DATETIME, '2008/07/15 00:00:00', 102) AND CONVERT(DATETIME, '2008/09/17 00:00:00', 102))".

Рисунок 9 - Form 5

На рис. 9 - textBox1, textBox2, textBox3, textBox4, textBox5:

"SELECT VIEW5_new.ДТП_ид, VIEW5_new.[номер участника], VIEW5_2.[кол-во травм], VIEW5_new.дата, VIEW5_new.вид_травмы

FROM VIEW5_new INNER JOIN VIEW5_2 ON VIEW5_new.вид_травмы = VIEW5_2.вид_травмы ORDER BY VIEW5_2.[кол-во травм], VIEW5_new.ДТП_ид".

Рисунок 10 - TABLES_WITH_FK

На рис. 9 - textBox1, DataGrid1(создается при запуске) - выполняется транзакция по добавлению новых данных о ДТП.

Рисунок 11 - Transaction_2

На рис. 10 - DataGrid1 - выполняется транзакция по удалению данных о ДТП.

6. ДИАГРАММА КЛАССОВ, РЕАЛИЗУЮЩИХ УРОВНИ ПРЕЗЕНТАЦИИ, БИЗНЕС - ЛОГИКИ И БАЗЫ ДАННЫХ ПРИЛОЖЕНИЯ

Рисунок 12 - диаграмма классов

7 СЛОВЕСНОЕ ОПИСАНИЕ ПРОЦЕССА ВЫПОЛНЕНИЯ ТРАНЗАКЦИЙ

В данной работе необходимо было выполнить транзакцию по добавлению сведений о новом ДТП. Здесь участвует только таблица ДТП.- команды выполняются в следующей последовательности: вначале выбираются данные из таблицы с помощью команды SELECT, затем происходит добавление записей с помощью команды INSERT, и последним действием происходит сохранение изменений в таблице с помощью команды UPDATE.

При загрузке формы вызываются 2 метода: DTP_Load и DTP_INIT. В методе DTP_Load вычисляется максимальное количество ДТП и max (ДТП_ид)+1 записывается в textBox1. В методе DTP_INIT происходит добавление записей соответствующих таблице ДТП.

По нажатию кнопки button1 происходит обработка исключения, в блоке try инициируется транзакция, подключаем команды модификации данных в транзакцию, если не было исключений транзакция закрепляется (коммитится). В этом случае сразу переходим в блок finally, где закрываем соединение и закрепляем изменения. Если же произошло не предвиденное исключение - происходит откат транзакции.

8. СПЕЦИАЛЬНАЯ ЧАСТЬ: «ХРАНИМЫЕ ПРОЦЕДУРЫ»

8.1 ПОНЯТИЕ ХРАНИМОЙ ПРОЦЕДУРЫ

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

Хранимые процедуры могут значительно увеличить производительность доступа к данным при самых минимальных затратах. Когда Вы помещаете SQL-запросы в процедуры, а не создаете их динамически на страницах, SQL сервер после первого их исполнения кэширует процедуру и план ее исполнения (Execution Plan). Последующие запросы к такой кэшированной процедуре получают необходимые данные из кэша SQL сервера, что и приводит к значительному увеличению производительности.

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

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

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

.2 СОЗДАНИЕ, ИЗМЕНЕНИЕ И УДАЛЕНИЕ ХРАНИМЫХ ПРОЦЕДУР

Создание хранимой процедуры предполагает решение следующих задач

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

планирование прав доступа. При создании хранимой процедуры следует учитывать, что она будет иметь те же права доступа к объектам базы данных, что и создавший ее пользователь;

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

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

Создание новой и изменение имеющейся хранимой процедуры осуществляется с помощью следующей команды:

<определение_процедуры>::=

{CREATE | ALTER } PROC[EDURE] имя_процедуры

[;номер]

[{@имя_параметра тип_данных } [VARYING ]

[=default][OUTPUT] ][,...n]

[WITH { RECOMPILE | ENCRYPTION | RECOMPILE,}]

[FOR REPLICATION]_оператор [...n]

Рассмотрим параметры данной команды.

Используя префиксы sp_, #, ##, создаваемую процедуру можно определить в качестве системной или временной. Как видно из синтаксиса команды, не допускается указывать имя владельца, которому будет принадлежать создаваемая процедура, а также имя базы данных, где она должна быть размещена. Таким образом, чтобы разместить создаваемую хранимую процедуру в конкретной базе данных, необходимо выполнить команду CREATE PROCEDURE в контексте этой базы данных. При обращении из тела хранимой процедуры к объектам той же базы данных можно использовать укороченные имена, т. е. без указания имени базы данных. Когда же требуется обратиться к объектам, расположенным в других базах данных, указание имени базы данных обязательно.

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

Для определения типа данных, который будет иметь соответствующий параметр хранимой процедуры, годятся любые типы данных SQL, включая определенные пользователем. Однако тип данных CURSOR может быть использован только как выходной параметр хранимой процедуры, т.е. с указанием ключевого слова OUTPUT.

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

Ключевое слово VARYING применяется совместно с параметром OUTPUT, имеющим тип CURSOR. Оно определяет, что выходным параметром будет результирующее множество.

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

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

Параметр FOR REPLICATION востребован при репликации данных и включении создаваемой хранимой процедуры в качестве статьи в публикацию.

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

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

Удаление хранимой процедуры осуществляется командой:PROCEDURE {имя_процедуры} [,...n]

.3 ВЫПОЛНЕНИЕ ХРАНИМОЙ ПРОЦЕДУРЫ

Для выполнения хранимой процедуры используется команда:

[[ EXEC [ UTE] имя_процедуры [;номер]

[[@имя_параметра=]{значение | @имя_переменной}

[OUTPUT ]|[DEFAULT ]][,...n]

Если вызов хранимой процедуры не является единственной командой в пакете, то присутствие команды EXECUTE обязательно. Более того, эта команда требуется для вызова процедуры из тела другой процедуры или триггера.

Использование ключевого слова OUTPUT при вызове процедуры разрешается только для параметров, которые были объявлены при создании процедуры с ключевым словом OUTPUT.

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

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

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

9. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ ПО РАБОТЕ С ПРИЛОЖЕНИЕМ

В формах Form 1, Form 2 - выводится одна строка данных и раскидывается по textBox’ам, поэтому пользователю никуда нажимать не нужно.

В формах Form 3, Form 4, Form 5 - записи выводятся построчно, поэтому чтобы получить последующие строки необходимо нажимать на кнопку next.

В форме TABLES_WITH_FK - выводится DataGrid, в который для добавления новых сведений о ДТП необходимо ввести следующие поля таблицы ДТП: кол_во_пострадавших, звание_милиционера, ФИО_милиционера, дата, место, вид_ДТП. ДТП_ид создается автоматически при нажатии на кнопку ”новое ДТП” и записывается автоматически в textBox1. При нажатии на кнопку ”COMMIT (Вся транзакция)” происходит сохранение изменений или откат транзакции, в случае если произошло не предвиденное исключение. Для проверки всех данных таблицы ДТП можно нажать на кнопку ”Вывести все данные таблицы ДТП ”. Если нужно дабавить еще ДТП, то при нажатии на кнопку ”новое ДТП” DataGrid очищается и можно вводить новые поля, которые необходимо добавить.

В форме Transaction_2 - данные таблицы ДТП, которые меньше заданной даты автоматически выводятся в DataGrid. Для того, чтобы удалить какую-либо строку данных, необходимо ее выделить и нажать Delete на клавиатуре. Для сохранения изменений необходимо нажать кнопку ”COMMIT”.

ЗАКЛЮЧЕНИЕ

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

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

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

) Хранимые процедуры сложнее в написании, чем основные операторы SQL, их подготовка требует большей квалификации и опыта.

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

СПИСОК ЛИТЕРАТУРЫ

1. Избачков Ю.С. Информационные системы: Учебник для вузов/ Ю.С.Избачков, Петров В.Н. - Санкт-Петербург, 2006. - 656 с.

. Марченко А.Л. C#. Введение в программирование: Учебное пособие - М., 2005. - 258с.

. Орлик С. Многоуровневые модели в архитектуре клиент-сервер
[http://ods.com.ua/win/rus/db/kbd97/22.htm <http://ods.com.ua/win/rus/db/kbd97/22.htm>] / С. Орлик

. Полякова Л.Н. Лекция: Хранимые процедуры

[<http://www.intuit.ru/department/database/sql/12/2.html>]/ Л.Н.Полякова

. Трёхуровневая архитектура [<http://ru.wikipedia.org/wiki/Трёхуровневая_архитектура>]