Презентация к лекции
Роль баз данных в корпоративных системах
Базы данных являются критически важной частью корпоративных информационных систем. Речь идет о больших, часто распределенных и разнородных массивах информации, которые взаимодействуют друг с другом. В идеале они формируют «приборную доску» — единый срез бизнес-результатов предприятия. Сюда входит динамика по управлению персоналом (текучесть кадров, карьерное планирование) и финансам (движение средств, доходы и расходы) с детализацией до уровня конкретных подразделений.
Клиент-серверная архитектура и базы данных
При реализации архитектуры «клиент-сервер» для систем управления базами данных (СУБД) выделяются два программных компонента:
•
Клиент (front-end): приложение на стороне пользователя.
•
Сервер базы данных (back-end): специализированное ПО, обрабатывающее запросы.
Пользователь взаимодействует с графическим или веб-интерфейсом, вводя параметры (например, при заказе билетов). Клиент кодирует эти параметры и передает на сервер. Сервер формирует запрос на языке
SQL (Structured Query Language), направляет его к данным, получает ответ, преобразует его (часто в формат HTML) и возвращает пользователю.
Стандартизация разработки ускоряется за счет хранения
ограничений целостности прямо на сервере. Пример: в системе продаж билетов нельзя допустить бронирование одного места двумя пассажирами. Проверка таких условий максимально близко к данным ускоряет обработку запросов.
Клиент-серверная архитектура синтезирует лучшие черты предшественников:
•
Мейнфреймы: централизованное администрирование, безопасность, отказоустойчивость.
•
Файл-серверы: невысокая стоимость реализации и задействование ресурсов клиентских машин (современные ПК достаточно мощны и могут брать на себя часть вычислений).
Эволюция архитектур обработки данных
1. Локальная архитектура (персональный компьютер)
СУБД (например, MS Access, FoxPro), приложение и файлы данных физически находятся на одном компьютере. Для корпоративных систем этот подход не годится: объемы данных могут достигать петабайт, их невозможно собрать в оперативном режиме из множества филиалов для консолидированного отчета.
2. Файл-серверная архитектура
Данные хранятся на выделенном файловом сервере, а на клиентских машинах установлены приложение и СУБД.
•
Плюсы: совместный доступ к файлам, безопасность хранения (данные физически не унести).
•
Минусы: вся бизнес-логика и обработка SQL-запросов происходят на клиенте. Сеть перегружается из-за пересылки больших объемов сырых данных. При обновлении ПО приходится переустанавливать СУБД на каждом компьютере.
3. Клиент-серверная архитектура
СУБД переносится на сервер. На клиенте остается только прикладная логика.
•
Схема работы: Клиент инициирует запрос, сервер (где находятся и СУБД, и данные) выполняет все вычисления и возвращает результат.
•
Преимущества: разгружается сеть, не нужна повторная настройка СУБД на каждом клиенте. Рабочие станции могут быть менее мощными, так как основная нагрузка ложится на сервер.
Выделение сервера баз данных обеспечивает согласованность информации для всех пользователей.
Сервер баз данных (SQL Server)
Сервер баз данных — это не физический компьютер, а программный компонент (возможно, распределенный или кластерный), использующий стандартный интерфейс языка SQL. Стандарты (ANSI SQL-92 и более поздние) обеспечивают совместимость продуктов от разных вендоров (Oracle, Microsoft и др.).
Это самое нагруженное и критичное звено системы. Требование — максимальная производительность при любом числе пользователей и сложности запросов.
Многопоточная и многопроцессная обработка
Для обеспечения производительности на сервере используются два подхода:
•
Многопроцессная архитектура (Oracle): при каждом подключении пользователя создается отдельный процесс (экземпляр приложения).
o
Плюс: хорошая масштабируемость.
o
Минус: большой расход оперативной памяти.
•
Многопоточная архитектура (MS SQL Server, Sybase): запускается один процесс с множеством потоков.
o
Плюс: меньшая нагрузка на аппаратное обеспечение, эффективное разделение времени между задачами.
Балансировка загрузки и трехуровневая архитектура
Чтобы снять лишнюю нагрузку с SQL-сервера, применяется гибкая балансировка. Прикладное ПО логически делится на три слоя:
•
Презентационная логика (PL — Presentation Layer): интерфейс пользователя.
•
Бизнес-логика (BL — Business Layer): правила работы приложения (проверка данных, транзакции).
•
Логика доступа к ресурсам (AL — Access Layer): взаимодействие с БД.
Трехзвенная (трехуровневая) архитектура возникает при вынесении бизнес-логики на отдельный
сервер приложений.
Толстый и тонкий клиент
В зависимости от того, где находится бизнес-логика, выделяют два типа клиентов:
•
Тонкий клиент
На клиенте находится только презентационная логика (веб-браузер или минимальное приложение). Бизнес-логика и логика доступа работают на сервере.
o
Преимущества: простота централизованного обновления и миграции, низкие требования к оборудованию (вплоть до бездисковых станций), высокая безопасность (пользователь не может скопировать или изменить критичный код и данные).
•
Толстый клиент (RDA — Remote Data Access)
На клиенте сосредоточены и презентационная, и бизнес-логика. На сервере — только логика доступа к данным.
o
Применение: эффективен в стабильных системах, не требующих частых изменений. Недостаток — любое изменение бизнес-правил требует обновления ПО на тысячах клиентских машин.
Краткие итоги
Путь эволюции корпоративных систем работы с данными отражает непрерывное стремление к оптимальному разделению труда между вычислительными мощностями. Изначальная монолитность, когда и данные, и их обработка были слиты на одном устройстве, быстро уперлась в физические ограничения объемов и невозможность коллективной работы. Попытка централизовать только хранение (файл-сервер) обнажила другую крайность — перегрузку сети сырыми данными и хаос в обслуживании клиентских мест, где на каждом требовалась настройка полноценной СУБД.
Решением стало структурное выделение сервера базы данных. В этой модели сервер берет на себя не только хранение, но и обработку, работая на стандартизированном языке SQL. Такой подход позволил гарантировать целостность информации непосредственно в точке ее обработки, исключив противоречия на клиентских уровнях. Однако консолидация всей вычислительной мощности на SQL-сервере превратила его в самое узкое и критичное место системы. Дальнейшее развитие техники направлено на тонкую настройку этого баланса через концепцию многозадачности: выбор между созданием тяжеловесных процессов на каждое подключение или легковесных потоков внутри одного процесса определяет, как система будет масштабироваться под нагрузкой.
Практическая реализация гибкости достигается в трехуровневой архитектуре, где бизнес-правила выносятся на отдельный сервер приложений. Это позволяет решить дилемму между функциональностью и стоимостью владения. «Тонкий клиент», лишенный прикладной логики, становится универсальным терминалом, который почти не требует обслуживания на местах, радикально снижая затраты при масштабировании сети на тысячи пользователей. Оборотная сторона — «толстый клиент», где логика приложения работает непосредственно на станции пользователя, замыкаясь на сервер только за сырыми данными. Эта модель незаменима там, где требуется высокая скорость реакции интерфейса и глубокая автономность, но платой за это становится сложность централизованного обновления.
Финальный вывод заключается в отсутствии универсального решения. Выбор архитектуры — это всегда поиск компромисса между стоимостью обновлений, требованиями к безопасности, пропускной способностью сети и сложностью администрирования. Понимание природы трех логических слоев приложения позволяет проектировщику осознанно жертвовать одним ресурсом ради другого, превращая архитектурные ограничения в конкурентные преимущества бизнеса.
Корпоративные системы оперируют огромными распределенными базами данных, формируя единую «приборную доску» бизнеса. Для их обслуживания используется архитектура «клиент-сервер». Пользователь через клиентское приложение (front-end) вводит параметры, которые кодируются и направляются на сервер. Сервер базы данных (back-end) обрабатывает запрос на языке SQL и возвращает готовый результат, часто в виде HTML.
Хранение ограничений целостности (например, запрет двойного бронирования мест) максимально близко к данным на сервере ускоряет обработку и повышает надежность. В этой архитектуре сервер становится центральным, самым нагруженным звеном.
Эволюция архитектур:
1. Локальная: Данные и СУБД на одном ПК. Неприменима для больших объемов и распределенных систем.
2. Файл-сервер: Данные на сервере, СУБД и приложение на клиенте. Перегружает сеть (гоняются файлы) и требует настройки СУБД на каждом ПК.
3. Клиент-сервер: Данные и СУБД переносятся на сервер. На клиенте остается только приложение. Снижается сетевой трафик, централизуется администрирование.
Сервер баз данных (SQL Server) — это программный компонент, работающий по стандартам SQL. Он критически важен для производительности всей системы. Для обработки пиковых нагрузок используются две модели:
• Многопроцессная (Oracle): на каждого пользователя создается отдельный процесс. Масштабируемо, но требует много памяти.
• Многопоточная (MS SQL Server): один процесс с множеством потоков. Экономнее к ресурсам.
Для снятия нагрузки с SQL-сервера применяют функциональное разделение логики приложения:
• Презентационная логика (PL): интерфейс.
• Бизнес-логика (BL): правила обработки, вычисления.
• Логика доступа (AL): взаимодействие с СУБД.
Выделение бизнес-логики на отдельный физический узел создает трехуровневую архитектуру, включающую сервер приложений. В зависимости от размещения BL выделяют:
• «Тонкий клиент»: содержит только презентационную логику (обычно веб-браузер). Бизнес-логика и доступ к данным — на сервере.
o Последствия: низкие требования к ресурсам клиента, простая замена оборудования (вплоть до бездисковых станций), максимальная централизация. Любое изменение правил делается один раз на сервере. Высокая безопасность: код и данные невозможно унести с рабочего места.
• «Толстый клиент» (RDA): на клиенте находятся и интерфейс, и бизнес-логика. На сервере — только данные и прямой доступ к ним (логика AL).
o Последствия: требуется мощный клиентский ПК. Внесение изменений в бизнес-правила крайне затратно, так как требует обновления ПО на тысячах машин.
Также применяется кэширование — сохранение результатов частых запросов в памяти сервера или даже клиента, что разгружает SQL-сервер. Методы удаленного вызова процедур (RPC) помогают скрыть аппаратную неоднородность сети. Выбор между «тонким» и «толстым» клиентом — это всегда компромисс между удобством централизованного управления и гибкостью автономной работы.
1. Клиент-серверная архитектура разделяет задачи: клиент отвечает за интерфейс, сервер — за обработку и целостность данных.
2. Перенос СУБД на сервер избавляет от необходимости настройки ПО на каждом клиенте и разгружает сеть.
3. Сервер базы данных (SQL-сервер) — это критичный программный компонент, а не просто физическая машина.
4. Ограничения целостности должны храниться на сервере, чтобы гарантировать корректность данных (например, исключая двойное бронирование).
5. Многопоточная архитектура (MS SQL) эффективнее расходует память, чем многопроцессная (Oracle), но требует сложного управления потоками.
6. Логика приложений делится на три слоя: презентационный, бизнес-логику и доступ к ресурсам.
7. «Тонкий клиент» содержит только интерфейс, что упрощает администрирование и повышает безопасность корпоративной сети.
8. «Толстый клиент» включает и интерфейс, и бизнес-логику, но требует обновления на каждом рабочем месте при изменениях.
9. Сервер приложений позволяет централизованно управлять бизнес-правилами и гибко балансировать нагрузку.
10. Балансировка нагрузки между клиентом и сервером повышает общую эффективность системы.
11. Кэширование типовых запросов на сервере или клиенте ускоряет доступ к часто используемым данным.
12. Стандарт языка SQL обеспечивает совместимость различных СУБД, но полная переносимость между вендорами может быть ограничена.
1. Почему хранение ограничений целостности на сервере является более эффективным решением, чем на клиенте?
2. Каким образом файл-серверная архитектура перегружает локальную сеть предприятия?
3. В чем принципиальное различие в управлении памятью между многопоточной и многопроцессной архитектурами сервера БД?
4. Какие задачи решает уровень бизнес-логики в трехуровневой архитектуре приложений?
5. За счет чего использование «тонкого клиента» снижает совокупную стоимость владения корпоративной системой?
6. Почему «толстый клиент» становится обременительным при частых изменениях бизнес-процессов?
7. Какое звено в архитектуре клиент-сервер является самым узким местом и почему?
8. Какие компоненты прикладного ПО должны быть перенесены на сервер приложений при переходе от двухуровневой к трехуровневой архитектуре?
9. Чем инициирование запроса клиентом отличается от исполнения запроса сервером с точки зрения распределения нагрузки?
10. Какие преимущества для безопасности данных дает применение бездисковых рабочих станций в роли тонких клиентов?
11. Какую роль играет кэширование запросов в снижении нагрузки на SQL-сервер?
12. В чем недостаток локальной архитектуры ПК при попытке ее масштабирования до уровня корпорации?
