
- •Информационная система
- •База данных
- •Системы управления базами данных
- •Основные функции системы управления базами данных.
- •Обзор основных архитектур баз данных
- •5.1. Архитектура файл-сервер
- •5.2. Архитектура “Клиент-Сервер” Основные особенности архитектуры «клиент-сервер»
- •1.Основные задачи проектирования баз данных
- •2. Основные этапы проектирования баз данных
- •2.1. Концептуальное (инфологическое) проектирование
- •2.2. Логическое (даталогическое) проектирование
- •2.3.Физическое проектирование
- •4. Модели «сущность-связь»
- •3. Модель данных
- •Иерархическая модель данных
- •Сетевая модель данных (модель codasyl)
- •Реляционная модель данных
Обзор основных архитектур баз данных
5.1. Архитектура файл-сервер
Данная архитектура стала популярной в тот момент, когда персональные компьютеры стали объединяться в локальные сети на основе файлового сервера (например, Novell Netware). Особо популярной данная архитектура являлась в середине-конце 80 х годов, в период массового объединения персональных компьютеров в локальные вычислительные сети.
Суть этой архитектуры сводится к тому, что на каждом из персональных компьютеров запускается приложение, использующее общие файлы, находящиеся на файловом сервере. Т.е. файлы базы данных по запросу клиентов передаются на персональный компьютер, т.е. рабочую станцию клиента, где они и обрабатываются.
Рис. 2. Однопользовательская информационная система и ее многопользовательский вариант на основе файл-сервера.
По своей сути, такая многопользовательская версия ничем не отличается от однопользовательской версии. Каждый из работающих компьютеров работает с общими данными так, как будто это его собственные персональные данные.
На основе модели файлового сервера функционируют такие популярные СУБД как FoxPro ( Microsoft), dBase (Borland), CF-Clipper (Computer Associates International), Paradox (Borland) и др.
СУБД рассматриваемого класса стоят недорого, просты в установке и освоении. Но они обладают и рядом существенных недостатков:
Сильное увеличение трафика по сети при интенсивной работе нескольких пользователей.
Неудобство совместной работы с системой.
Невозможность отслеживания информации при аппаратных сбоях.
Проблема возможных незакрытых транзакций.
5.2. Архитектура “Клиент-Сервер” Основные особенности архитектуры «клиент-сервер»
В архитектуре клиент-сервер для обработки данных выделяется специальное ядро - так называемый сервер баз данных, который принимает на себя функции обработки запросов пользователей, именуемых теперь клиентами.
Сервер баз данных представляет собой мультипользовательскую версию СУБД, выполненною, как правило, на мощном компьютере. Приложения-клиенты посылают с рабочих станций запросы на выборку (вставку, обновление, удаление) данных. При этом сервер выполняет всю “грязную” работу по отбору данных, отправляя клиенту только требуемый результат.
Рис. 3. Архитектура «клиент-сервер»
Такой подход обеспечивает решение трех важных задач:
- уменьшение нагрузки на сеть
- уменьшение требований к компьютерам-клиентам
- повышение надежности и сохранение логической целостности базы данных.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Но эти СУБД имеют и недостатки:
они намного дороже СУБД предыдущего класса, сложны в освоении,
для эффективной работы этих СУБД требуются высокоскоростные (а поэтому и дорогие) серверы и сети.
в последнее время стал возникать синдром "толстого клиента". Это означает, что клиентское приложение имеет размер, сравнимый или даже превышающий размер программы-сервера базы данных.
Но наиболее важным результатом перехода в архитектуру клиент-сервер является гарантированное сохранение логической целостности базы данных, т.е. система становится более устойчивой и более защищенной. Достигается это благодаря возможности переложить заботу о сохранении целостности базы на сервер.
5.3. Архитектура с использованием сервера приложений (трехзвенная архитектура) В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения:
клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.
Они
могут взаимодействовать друг с другом
по следующей схеме:
Рис.4.
Трехзвенная архитектура
Как
правило, третьим звеном в трехзвенной
архитектуре становится сервер приложений,
т.е. компоненты распределяются следующим
образом:
Представление данных — на стороне клиента.
Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.
Итак, идея сервера приложений заключается в разбиении приложения на две части - собственно клиента и сервера данного приложения. Причем сервер приложений может быть один на много приложений. Клиенты общаются с сервером приложений (или с серверами приложений, никто не запрещает иметь несколько серверов приложений). Клиенты посылают серверу приложений запросы, а получают ответы. Клиенты могут обратиться и непосредственно к серверу базы данных за теми или иными данными. Обращение за данными к серверу базы данных может производить и сервер приложений. Использование сервера приложений в трехзвенной архитектуре позволяет смягчить или свести на нет недостатки традиционной архитектуры “клиент сервер”.
Модели данных для систем баз данных