17. Архітектура бд клієнт – сервер.

Существует в 2-х реализациях:

1. сервер БД и клиентские приложения.

Между сервером и клиентом могут находится такие объекты:

2. Трехзвенная архитектура:

После создания БД на сервере обычно разрабатывают клиентские приложения. Перед проектированием определяют тип приложения. Это может быть: 1) Система ввода данных. 2) Система обработки транзакций. 3) Система поддержки принятия решений.

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

1. Составляется перечень всех форм приложения.

2. Составляется перечень всех отчетов и других видов выходной информации.

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

процессами.

4. Определяется перечень вспомогательных программ, необходимых для обслуживания приложения.

После составления перечня форм, проектируется их иерархия.

 

18. Проектування застосівників до бд у системі клієнт-сервер.

   После создания БД на сервере обычно разрабатывают клиентские приложения. Перед проектированием определяют тип приложения. Это может быть: 1) Система ввода данных. 2) Система обработки транзакций. 3) Система поддержки принятия решений.

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

1. Составляется перечень всех форм приложения.

2. Составляется перечень всех отчетов и других видов выходной информации.

3. Составляется перечень потоков данных, пересылаемых между формами и отчетами и другими процессами.

4. Определяется перечень вспомогательных программ, необходимых для обслуживания приложения.

После составления перечня форм, проектируется их иерархия.

Проектирование отчетов.

    При проектировании отчетов на первом этапе целесообразно использовать средство быстрой разработки(Мастер) для создания макетов.

    На титульной странице помещается текущее время, дата, имя пользователя, создавшего отчет.

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

Нечисловые данные, как правило, выравниваются по левому краю отчета, а числовые - по правому.     Прототипы отчета согласовываются с руководителем.

Тестирование приложения.

1. Разраб-ся стандартная процедура описания ошибок прил-ия и их исправления. Для этого создается отдельная форма.

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

При тестировании необходимо:

1. Проверить выполнение всех требований или функций данного приложения.

2. Проверить работу всех ограничений на вводимые данные.

3. Пр-ть одновр-ную работу неск-ких копий прил-я на рабочих станциях с большим ч-лом польз-ей и учетом блокир-к.

4. Проверка механизма доступа с попытками несанкционированного доступа (попытками взлома).

5. Проверить сложность приложения на неподготовленном пользователе

столько колонок, сколько элементов приведено в разделе SELECT и столько строк, сколько отобрано групп.

Стадия 2. Выполнение операций UNION, EXCEPT, INTERSECT

Если в операторе SELECT присутствовали ключевые слова UNION, EXCEPT и INTERSECT, то таблицы, полученные в результате выполнения 1-й стадии, объединяются, вычитаются или пересекаются.

Стадия 3. Упорядочение результата

Если в операторе SELECT присутствует раздел ORDER BY, то строки полученной на предыдущих шагах таблицы упорядочиваются в соответствии со списком упорядочения, приведенном в разделе ORDER BY.

Как на самом деле выполняется оператор SELECT:

Шаг 1 (Синтаксический анализ). Поступивший запрос подвергается синтаксическому анализу. На этом шаге определяется, правильно ли вообще (с точки зрения синтаксиса SQL) сформулирован запрос. В ходе синтаксического анализа вырабатывается некоторое внутренне представление запроса, используемое на последующих шагах.

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

Шаг 3 (Генерация планов выполнения запроса и выбор оптимального плана). На этом шаге оптимизатор генерирует множество возможных планов выполнения запроса. Каждый план строится как комбинация низкоуровневых процедур доступа к данным из таблиц, методам соединения таблиц. Из всех сгенерированных планов выбирается план, обладающий минимальной стоимостью.

Шаг 4. (Выполнение плана запроса). На этом шаге план, выбранный на предыдущем шаге, передается на реальное выполнение.