Шпоры по РБД / Шпора_РБД_25-36
.doc|
25. Функциональные логические компоненты приложения. Стр-ра взаимодействия сервисов. Логика представления Клиент ВВОД ВЫВОД
Сервер БД службы описания и манипулирования БД
Компонент файл
сервер сервер
БД сервер транзакций сервер
прилож к с к с к с к
логика
представления х
х
х
х
л.
обработки вв/выв х
х
х
х л.
бизнес приложений х
х
х х
х л.
упр-я данными х
х х
х
х л.
манпул-я данными
х
х
х
х |
26. Стили арх-ры клиент/сервер. Наложение функцион-й логики на стили клиент/серверной арх-ры. 1) стиль арх-ры с файл-сервером отражает схему, в кот. клиент выполняет большую часть обработки данных, а сервер только управляет хранениеми извлечением данных. Фактически выбор записей происходит на стороне клиента 2) логика упр-я данными в стиле арх-ры с сервером БД разделяется между клиентскими и серверными компами. Клиент посылает SQL запрос и возвращается релевантная запросу инф-я 3) стиль арх-ры с сервером транзакций разрешает совместно использовать инф-ю о транзакции клиенту и серверу. 4) арх-ра с сервером приложений позволяет наладить все преимущества клиент-серверных приложений. Приложение размещается на сервере приложений, исполняется на нем и исп-ся неск. клиентами
|
27. Проблемы реализации клиент/серверных с-м.
1) переход от частных с-м к открытым. С-мы должны обеспечить прозрачность для объединения, быть открытыми для доступа др. с-м - это обеспечит стандартизацию описания. 2) от обслуживания кодирования необходимо перейти к анализу проектирования сервера 3) от локализации данных –к распределению 4) от централизованного стиля к распределенной форме упр-я данными 5) от строгой вертик. негибкой орг-и к более горизонт. гибкому стилю.
|
28. Тенденции развития компонентов распределенных с-м. Принципиальным изменением явл-ся -использование разнородного оборудования; -требования к ПО -данные (РБД содержат данные разных форматов) -процедуры (можно обмениваться, что делает с-му гибкой) -персонал
|
29. Инструментарий разработки клиент/серверных приложений. 1) графич. интерфейс пользователя GUI. конструктор GUI позволяет поддерживать интерфейся с различными ОС клиентов (windows, mac, os/2) 2) ключевым элементом с-мы явля-ся словарь данных с центральным хранилищем данных и приложений. 3)важна возм-сть поддерживать различные модели данных- реляционные, иерархические, плоские файлы. Доступ к данным осущ-ся независимо от модели, поэтому исп-ся универс. язык SQL 4) технология создания менеджера или брокера запросов ( доступ к неск. БД) 5) спец. инструментарий разрешения конфликтов в группе. 6) возм-сть создания приложений на основе прототипов в среде быстрой разработки RAD 7)поддержка протоколов промежут. обработки ODBC, IDAPI 8) поддержка нескольких сетевых протоколов TCP/IP, Netbios, IPX/SPX
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
30. Интегрированный подход к созданию клиент/серверных с-м. Основные принципы -изучение инфрастр-ры инф. с-мы -определение клиент/серверной стр-ры. -не внедрять с-му до наступления удобного момента -реализация (исп-ся открытый или стандартизированный инструментарий). Необходимо внедрение новых прогр. ср-в, обеспечение подготовки специалистов, запуск с-мы в эксплуатацию -анализ и оценка (убедиться, что с-ма соответствует критериям, необходимо измерить контр. хар-ки с-мы) |
31. Арх-ры распределенных с-м баз данных. Взаимодействие в распределенных с-мах.
Взаимодействие расп. с-м. LIS – local internal scheme - индивид. описание стр-ры данных, внутр. для каждого сайта в стр-ре РБД GCS – global concept - описание глоб. LCS –local concept - описание, обеспечивающее независимость данных для проведения репликации, фрагментации ES- external scheme - частная реализация глоб. конц. схемы
Глобальное взаимодействие реализуется в модели ANSISPAC посредством глоб. описания или словыря данных.
Локальное взаимодействие обесп-ся поср-вом лок. описания, при этом локальные компоненты упр-я БД свызаны с помощью глоб. ф-й СУБД. |
32. Функциональная схема интегрированной РСУБД. 1. главный администратор концерна, с-мы 2. администратор глобальной БД 3. администратор прикладной с-мы. 4. процессор (обработчик) глоб. концепт. схемы БД 4. GD/D – глоб. описание/ словарь данных 6. сервер приложения, процессор внешней схемы данных 7. обработчик лок. концепт. схемы 8. лок. словарь данных 9. внутренняя конц. схема 10. локальный администратор 11. процессор внутр.схемы. 12. метод доступа внутр. памяти
|
33. Компоненты РСУБД, пользовательский обработчик, процессор обработки данных. 1
Пользовательский процессор: 2.блок упр-я пользоват. интерфейсом 3. контроллер семант. данных 4. глоб. оптимизатор запросов 5. монитор глоб. реализации 6. внешняя схема 7. концепт. схема 8. глоб. описание/ словарь данных
П 9. лок. обработчик запросов 10. лок. менеджер восстановления 11. обработка обращений к БД в режиме реального времени. 12. локаль. концепт. схема 13. журнал данных 14. концепт. схема 15. локальная БД. |
34. Архитектура с-мы мультибаз данных 1. арх-ра РБД с глобальной концепт.схемой
Схема упр-я РБД без глобальной конц.схемы. |
.
пользователи
роцессор
обработки данных:
|
35. Компоненеты с-мы мультибаз данных.
1. пользователи 2. слой мультибаз упр-я БД 3. процессор запросов 4. менеджер транзауций 5. менеджер восстановления данных 6. процессор реального времени 7. БД |
36. Разработка РБД. Порядок разработки и проблемы.
Разработка включает в себя принятие решения по размещению данных между узлами комп. сети (серверами). Распр. СУБД включают в себя модули и приложения. Можно распр-ть данные, компоненты, прикладные программы (запросы, обрабатывающие данные). В качестве параметров - уровень распределения данных, алгоритм доступа к данным, эффективность алгоритма доступа. В уровнях распр-я 3 возможности: - нет распр-я -обеспечили распр-е, а все прогр.ср-ва реализуются на все сайты - распределены и программы и данные (распределенные запросы обслуживаются натразличных сайтах, а данные размещены спец. образом (словарь данных). Когда формируется запрос – сначала ищется порграмма, а потом собирается информация.
|
|
|
