- •1.Базы данных, базы знаний и файловые системы.
- •2. Основные типы архитектуры бд.
- •3. Бд и информационные системы.
- •4.Достоинства и недостатки различных типов (моделей) архитектуры бд.
- •5. Базовые понятия реляционной модели. Домен, отношение, кортеж
- •6. Основные свойства отношений.
- •7. Реляционная алгебра. Основные операции.
- •8. Реляционное исчисление.
- •9. Понятие ключа.
- •10.Нормальные формы.
- •11. Языки баз данных.
- •12. Языки реляционных бд.
- •13. Язык sql
- •14. Язык определения данных.
- •15. Язык манипулирования данными.
- •16. Гипертекстовые и мультимедийные бд. Гипертекст.
- •17. Структура, принципы построения и использования гипертекстовых поисковых систем.
- •18. Виды документальных бд.
- •19. Информационно-поисковые каталоги и тезаурусы.
- •20. Распределенные бд.
- •21. Субд в архитектуре «клиент-сервер»
- •22. Модель файлового сервера.
- •23. Модель удаленного доступа к данным.
- •24. Модель сервера бд.
- •25. Модель сервера приложений.
- •26.Основные концепции объектно-ориентированной технологии.
- •27. Технология оперативной обработки транзакций (olap-технология).
- •28. Технология Warehouse
- •29. Data maining
- •30.Case –технология.
21. Субд в архитектуре «клиент-сервер»
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещение их там, где они будут функционировать более эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL и выполняющих поиск, сортировку и агрегирование информации на месте без излишней перекачки данных на рабочие станции.
Другая отличительная черта серверов БД - наличие справочника данных, в котором записаны структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются прежде всего реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов для этой БД.
Переместив с клиента часть логики приложения на сервер, получим систему клиент-сервер с разделенной логикой. Часть прикладной логики может быть реализована на клиенте, а другая часть логики - в виде обработчиков событий (триггеров) и хранимых процедур на сервере БД.
Такая схема при удачном разделении логики приводит к сбалансированной загрузке клиентов и сервера, но при этом затрудняется сопровождение приложений.
На основе многотерминальной системы в качестве сервера приложений также возможно создание архитектуры клиент-сервер. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами.
Двухзвенные схемы приводят к некоторым проблемам в сложных приложениях со множеством пользователей, с запутанной логикой, с неоднородными БД и разнородными входами в БД:
необходимость администрирования приложений для большого числа клиентов при отсутствии унификации в конфигурациях клиентов и средств управления изменениями;
чрезмерное использование хранимых процедур для реализации прикладной логики не способствует переносимости приложений;
возрастает время реакции из-за ожидания завершения пакетного задания на сервере и влияния таких заданий на диалоговых пользователей;
проблема обеспечения целостности распределенной транзакции в неоднородной распределенной БД.
22. Модель файлового сервера.
В отличии от централизованной системы архитектура "файл-сервер" не имеет сетевого разделения компонентов диалога PS и PL (PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала; PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка), использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети.
Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL (BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение) и управления данными DL (DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными). Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации.
Однако такая архитектура имеет два основных недостатка: некоторые запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея непредсказуемое время реакции, тем самым, создавая значительный сетевой график, а также возникающая проблема "толстого клиента" - Windows-интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК.
Помимо перечисленных недостатков нужно отметить, что многие "настольные СУБД", как традиционные инструменты файл-серверных приложений, не отвечают требованиям сохранности данных, в частности не поддерживают транзакции. Однако СУБД для ПК привлекают простотой использования и доступностью, поэтому файл-серверные приложения еще будут использоваться для рабочих групп.