Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ekzamen_GOS.docx
Скачиваний:
1
Добавлен:
01.05.2025
Размер:
8.21 Mб
Скачать

161.Концепция централизованного управления данными, функция администратора данных.

При централизованном управлении должен быть человек - администратор данных (АД), несущий ответственность за данные, безопасность данных. За техническую реализацию решений АД отвечает администратор базы данных (АБД) - профессиональный специалист в области информационных тех­нологий. У АБД должен быть штат из системных программистов и технических ассистентов.

Преимущества централизованного управления данными

1. Возможность сокращения избыточности (дублирования информации).

2. Возможность устранения противоречивости за счет множественного об­новления данных

3. Возможность общего доступа к данным

4. Возможность соблюдения стандартов.

5. Возможность введения ограничений для обеспечения безопасности.

6. Возможность обеспечения целостности (правильности и точности) данных

7. Возможность сбалансировать противоречивые требования.

8. Обеспечение независимости данных

Функции администратора банка данных

1. Анализ предметней области: списание предметной области, выявление ограничений целостности, определение статуса информации, определение потребностей пользователей, определение статуса пользователей.

2. Проектирование структуры базы данных: определение состава и структуры файлов базы данных

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД

4. Первоначальная загрузка, ведение базы данных: разработка технологии первоначальной загрузки и ведения изменения, добавления, удаления записей) БД ввод и контроль ввода.

5. Защита данных

5.1. Обеспечение парольного вход а в систему: регистрация пользователей, назначение и изменение паролей.

5.2. Обеспечение защиты конкретных данных: определение прав доступа групп пользов-лей и от­дельных пользов-лей, определение допустимых операций над данными для отдельных пользователей.

5.3. Тестирование средств защиты данных

5.4. Фиксация попыток несанкционированного доступа к информации.

6. Обеспечение восстановления БД: разработка программно-технологических средств восстановле­ния БД организация ведения системных журналов.

7. Анализ обращений пользователей к БД: сбор статистики обращений пользователей к БД ее хране­ние и анализ

8. Анализ эффективности функционирования БнД и развитие системы: анализ показателей функ­ционирования системы, реорганизация и реструктуризация баз данных, изменение состава баз данных, развитие программных и технических средств.

9. Работа с пользователями: сбор информации об изменениях в предметной области, об оценке поль­зователями работы БнД, определение регламента работы пользователей с ЕнД обучение пользовате­лей, консультирование пользователей.

10. Подготовка и поддержание системных программный средств: сбор и анализ информации о СУБД и ППД приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек; развитие программных средств.

162. Архитектура систем баз данных, технология «клиент сервер».

Трехуровневая архитектура систем БД. Архитектура ANSU/SPARC (Study Group on Data Management Sys­tem) включает три уровня: внутренний, концептуальный и внешний (ри с 4).

Внешний уровень (индивидуальные представления пользователей) . Концептуальный уровень (обобщенное представление пользователей). Внутренний уровень (представление в памяти)

Внутренний уровень- это уровень, наиболее близкий к физическому хранению, т.е. связанный со способами сохране­ния информации на физических устройствах хранения. Внешний уровень связан со способами представления данных для отдельных пользователей.

Концептуальный уровень - является «промежуточным» между внутренним и внешним уровнями. Если внешний уро­вень связан с индивидуальным представлением пользователей, то концептуальный уровень связан с обобщенным пред­ставлением пользователей. Также есть единственное внутреннее представление, отражающее вою базу данных как физи­чески хранимую.

Архитектура клиент/сервер.

На высоком уровне систему баз данных можно рассматривать как систему, состоящую из двух частей - сервера (или машины базы данных) и набора клиентов (или внешнего интерфейса1). Сервер -это собственно СУБД. Клиенты - это различные приложения, которые выполняются «над» СУБД. Они делятся на приложения, написанные пользователями и при­ложения, предоставляемые поставщиками (инструментальные системы).

Машины клиентов могут иметь свои собственные сохраняемые данные, а машина сервера может иметь свои собствен­ные приложения. Отдельная машина клиента может иметь доступ к нескольким разным машинам серверов. Такой доступ предоставляется двумя способами:

1. Клиент получает доступ к любому количеству серверов, но лишь к одному в одно и то же время.

2. Клиент может получать доступ к любому количеству серверов одновременно (т.е за один запрос можно получить комбинированные данные двух или более серверов). В этом случае серверы рассматриваются клиентом как один (с логи­ческой т очки зрения), и пользователь может не знать, на какой именно машине какая часть данных содержится.

Принципы взаимодействия между клиентскими и серверными частями

Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части; системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко в сем серверам баз данных, основанных на SQL.

Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса.

Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.

Типичное разделение функций между клиентами и серверами

В типичном случае на стороне клиента СУБд работает только такое программное обеспечение, которое не имеет непосредственного доступа к БД, а обращается для этого к серверу с использованием языка SQL.

В некоторых случаях хотелось бы включить в состав клиентской части системы некоторые функции для работы с "локальным кэшем4 базы данных, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.

С другой стороны; иногда хотелось бы перенести большую часть прикладной системы на сторону сервера, если розница в мощности клиентских рабочим станций и сервера чересчур велика. В общем-то при использовании RPC это сделать не­трудно. Но требуется, чтобы базовое программное обеспечение сервера действительно позволяло это. В частности, при использовании ОС UNIX проблемы практически не возникают.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]