Модели двухуровневой технологии «клиент-сервер».

Систему баз данных можно рассматривать как систему, где осуществлено распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели называется «клиентом», а другой, обслуживающий клиента, — сервер (машина баз данных). Клиентский процесс запрашивает некоторые услуги, а серверный процесс обеспечивает их выполнение. При этом предполагается, что один серверный процесс может обслужить множество клиентских процессов.

Сервер в простейшем случае — это собственно СУБД. Клиенты — это различные приложения, которые выполняются над СУБД.

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

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

8. Сервер приложений. Трехуровневая модель.

Сервер приложений — это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Преимущества серверов приложений

Целостность данных и кода

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

Централизованная настройка и управление

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

Безопасность

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

Поддержка транзакций

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

Уровень представления реализует пользовательский интерфейс (элементы управления, осуществляющие ввод, вывод и проверку вводимых данных). На уровне бизнес-логики реализована логика работы (правила обработки данных) конкретного приложения. На уровне данных действуют механизмы обращения к хранилищам данных (файлам или базам данных) приложения. Классическое многоуровневое программирование предполагает следование двум важным правилам: обмен данными только между смежными уровнями (например, уровень представления не должен обращаться напрямую к уровню данных) и изоляцию (инкапсуляцию) уровней. Это значит, что взаимодействие между уровнями осуществляется с помощью четко определенных интерфейсов, предоставляющих смежному уровню только те методы, которые ему необходимы. Однако на практике эти правила соблюдаются не всегда. Например, часто бывает удобно объединить уровень бизнес-логики и уровень данных. Важной особенностью многоуровневого программирования является возможность повторного использования классов, реализующих различные уровни. В литературе, посвященной многоуровневому программированию в среде.NET, встречается понятие бизнес-объекта. Бизнес-объекты представляют собой объекты, реализованные на уровне бизнес-логики, в которых определены правила поведения (бизнес-правила) приложения.

9. Характеристика современных реляционных СУБД.

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

· набор инструментов для создания таблиц и отношений между связанными таблицами;

· средства администрирования базы данных;

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

· средства разработки приложений, использующих базы данных.

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

С помощью средств СУБД вы можете:

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

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

· отображать информацию базы данных в графическом виде. Например, нарис. 1.5 выведены, в виде диаграммы, данные о количестве клиентов торговой фирмы по городам;

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

10. Этапы проектирования базы данных.

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

В создании БД как модели ПрО выделяют:

· объектную (предметную) систему, представляющую фрагмент реального мира;

· информационную систему, описывающую некоторую объектную систему;

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

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