
- •- Бд и банк данных (БнД).
- •- Лекция 7. Определения и характеристики нормальных форм 1nf, 2nf, 3nf, bcnf. Понятие и виды денормализации.
- •- Процесс нормализации.
- •- Лекция 9. Языки манипулирования данными для реляционной модели. Язык запросов sql, общие характеристики. Основы синтаксиса sql; выражения и основные типы данных языка sql.
- •Схемы хеширования
- •Отображение ключей путем хеширования с цепочками
- •- Основные принципы технологии клиент-сервер.
- •Способы (модели) реализации архитектуры клиент-сервер
- •- Классификация субд по типу модели представления данных.
- •- Виды функциональных зависимостей.
- •- Термины реляционной модели.
- •- Операторы в языке sql.
- •- Уровни представления данных в информационной системе.
- •Трехуровневая модель системы управления базой данных
Способы (модели) реализации архитектуры клиент-сервер
Сегодня технология "клиент-сервер" получает все большее распространение, однако сама по себе она не предлагает однозначных универсальных рецептов проектирования. Она лишь дает общее представление о том, как должна быть организована современная распределенная информационная система. В то же время реализации этой технологии в конкретных программных продуктах и даже в видах программного обеспечения могут различаться весьма существенно.
Один из основных принципов технологии "клиент-сервер" заключается в разделении функций стандартного приложения на три группы, имеющие различную природу. Первая группа - это функции ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области. Наконец, к третьей группе относятся фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.д.).
В соответствии с этим в любом приложении выделяются следующие логические блоки (компоненты):
- компонент представления (presentation), реализующий функции первой группы;
- прикладной компонент (business application), поддерживающий функции второй группы;
- компонент доступа к информационным ресурсам (resource access) или менеджер ресурсов (resource manager), поддерживающий функции третьей группы.
Для реализации этих идей существуют в настоящее время три подхода, каждый из которых реализован в соответствующей модели:
Модель доступа к удаленным данным – RDA (Remote Data Access)
Модель сервера БД – DBS (Data Base Server)
Модель сервера приложений – AS (Application Server)
Рис. 1. Модель доступа к удаленным данным – RDA
Данная модель характеризуется понятиями «тонкий сервер» – «толстый клиент».
Рис. 2. Модель сервера БД – DBS
В этой модели – наоборот: «толстый сервер» – «тонкий клиент».
Рис. 3. Модель сервера приложений – AS
Обратите внимание – в AS-модели и сервер и клиент – «тонкие». Серверов приложений может быть несколько, ориентированных на разные функции.
В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (языка SQL, например, когда речь идет о базах данных). Запросы к информационным ресурсам направляются по сети удаленному компьютеру (серверу базы данных). Последний обрабатывает и выполняет запросы и возвращает клиенту блоки данных (рис.1). Говоря об архитектуре "клиент-сервер", в большинстве случаев имеют в виду именно эту модель.
Главное преимущество RDA-модели лежит в практической плоскости. Сегодня существует множество инструментальных средств, обеспечивающих быстрое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Большинство из них поддерживают графический интерфейс пользователя в MS Windows, технологию ADO, стандарт интерфейса ODBC, содержат средства автоматической генерации кода. Иными словами, основное достоинство RDA-модели заключается в унификации и широком выборе средств разработки приложений. Подавляющее большинство этих средств разработки на языках четвертого поколения (включая и средства автоматизации программирования) как раз и создают коды, в которых смешаны прикладные функции и функции представления.
DBS-модель (рис.2) строится в предположении, что процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления, в то время как собственно прикладные функции реализованы в хранимых процедурах (stored procedure), которые также называют компилируемыми резидентными процедурами, или процедурами базы данных. Они хранятся непосредственно в базе данных и выполняются на компьютере-сервере базы данных (где функционирует и компонент, управляющий доступом к данным, то есть ядре СУБД). Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика DBS-модели – имеется пока только в СУБД, да и то не во всех. На практике часто используются смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).
AS-модель (рис.3) в наибольшей степени отражает сильные стороны технологии "клиент-сервер".
В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за ввод и отображение данных (то есть реализует функции первой группы). Прикладные функции выполняются группой процессов (серверов приложений), функционирующих на удаленном компьютере (или нескольких компьютерах). Доступ к информационным ресурсам, необходимым для решения прикладных задач, обеспечивается ровно тем же способом, что и в RDA-модели. Из прикладных компонентов доступны ресурсы различных типов - базы данных, индексированные файлы, очереди и др. Серверы приложений выполняются, как правило, на том же компьютере, где функционирует менеджер ресурсов, однако могут выполняться и на других компьютерах.
В чем заключается фундаментальное различие между этими моделями? RDA-и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во втором - интегрируется в компонент доступа к информационным ресурсам. Напротив, в AS-модели реализована классическая трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. Собственно, из этой особенности AS-модели и вытекают ее преимущества, которые имеют важнейшее значение для чисто практической деятельности.