
- •Информационное обеспечение систем управления
- •1. Информационные системы и базы данных (лекция 1)
- •1.1. Понятие информационной системы, информационное обеспечение
- •1.2. Понятие базы данных
- •1.3. Понятие системы управления базами данных
- •1.3.1. Обобщенная архитектура субд
- •Предметная область
- •1.3.2. Достоинства и недостатки субд
- •1.4. Категории пользователей базой данных
- •1.4.1. Общая классификация пользователей бд
- •1.4.2. Администратор базы данных
- •1.4.3. Разделение функций администрирования
- •2. Проектирование баз данных (лекция 2)
- •2.1. Жизненный цикл информационной системы
- •2.2. Подходы и этапы проектирования баз данных
- •2.2.1. Цели и подходы к проектированию баз данных
- •«Описание предметной области» ↔ «схема внутренней модели базы данных».
- •2.2.2. Этапы проектирования баз данных
- •3. Архитектуры субд (лекции 3-4)
- •3.1. Телеобработка
- •3.2. Файловый сервер
- •3.3. Технология «клиент/сервер»
- •3.4. Понятие независимости данных
- •4. Инфологическое проектирование базы данных (лекции 5-6)
- •4.1. Модель «сущность-связь»
- •4.2. Классификация сущностей, расширение er-модели
- •4.3. Проблемы er-моделирования
- •5. Выбор субд (лекция 7)
- •5.1. Метод ранжировки
- •5.2. Метод непосредственных оценок
- •5.3. Метод последовательных предпочтений
- •5.4. Оценка результатов экспертного анализа
- •6. Даталогические модели данных (лекции 8-9)
- •6.1. Иерархическая модель
- •6.2. Сетевая модель
- •6.3. Реляционная модель
- •6.4. Достоинства и недостатки даталогических моделей
- •7. Физическая организация данных в субд (лекции 10-11)
- •7.1. Списковые структуры
- •7.1.1. Последовательное распределение памяти
- •7.1.2. Связанное распределение памяти
- •7.2. Модель внешней памяти
- •7.3. Методы поиска и индексирования данных
- •7.3.1. Последовательный поиск
- •7.3.2. Бинарный поиск
- •7.3.3. Индекс - «бинарное дерево»
- •7.3.4. Неплотный индекс
- •7.3.5. Плотный индекс
- •3.3.6. Инвертированный файл
- •8. Внутренний язык субд (лекции 12-13)
- •8.1. Теоретические языки запросов
- •8.1.1. Реляционная алгебра
- •8.1.2. Реляционное исчисление кортежей
- •8.1.3. Реляционное исчисление доменов
- •8.1.4. Сравнение теоретических языков
- •8.2. Определение реляционной полноты
- •8.3. Введение в язык sql
- •8.3.1. Краткая история языка sql
- •8.3.2. Структура языка sql
- •8.3.3. Типы данных sql
- •9. Распределенные базы данных и субд (лекция 14)
- •9.1. Основные определения, классификация распределенных систем
- •9.2. Преимущества и недостатки распределенных субд
- •9.3. Функции распределенных субд
- •9.4. Архитектура распределенных субд
- •9.5. Разработка распределенных реляционных баз данных
- •9.5.1. Распределение данных
- •9.5.2. Фрагментация
- •9.5.3. Репликация
- •9.5.3.1. Виды репликации
- •9.5.3.2. Функции службы репликации
- •9.5.3.3. Схемы владения данными
- •9.5.3.4. Сохранение целостности транзакций
- •9.5.3.5. Моментальные снимки таблиц
- •9.5.3.6. Триггеры базы данных
- •9.5.3.7. Выявление и разрешение конфликтов
- •9.6. Обеспечение прозрачности
- •9.6.1. Прозрачность распределенности
- •9.6.2. Прозрачность транзакций
- •9.6.3. Прозрачность выполнения
- •9.6.4. Прозрачность использования
- •10. Защита и секретность данных. (лекции 15-16)
- •10.1. Понятие информационной безопасности. Основные составляющие
- •10.1.1. Понятие информационной безопасности
- •10.1.2. Основные составляющие информационной безопасности
- •10.2. Распространение объектно-ориентированного подхода на информационную безопасность
- •10.2.1. Основные понятия объектно-ориентированного подхода
- •10.2.2. Применение объектно-ориентированного подхода к рассмотрению защищаемых систем
- •10.3. Наиболее распространенные угрозы
- •10.3.1. Основные определения и критерии классификации угроз
- •10.3.2. Наиболее распространенные угрозы доступности
- •10.3.3. Некоторые примеры угроз доступности
- •10.3.4. Основные угрозы целостности
- •10.3.5. Основные угрозы конфиденциальности
- •10.4. Административный уровень информационной безопасности
- •10.4.1. Основные понятия
- •10.4.2. Политика безопасности
- •10.4.3. Программа безопасности
- •10.5. Управление рисками
- •10.5.1. Основные понятия
- •10.5.2. Подготовительные этапы управления рисками
- •10.5.3. Основные этапы управления рисками
- •10.6. Процедурный уровень информационной безопасности
- •10.6.1.Основные классы мер процедурного уровня
- •10.6.2. Управление персоналом
- •10.6.3. Физическая защита
- •10.6.4. Поддержание работоспособности
- •10.6.5. Реагирование на нарушения режима безопасности
- •10.6.6. Планирование восстановительных работ
- •10.7. Основные программно-технические меры
- •10.7.1. Основные понятия программно-технического уровня информационной безопасности
- •10.7.2. Особенности современных информационных систем, существенные с точки зрения безопасности
- •10.7.3. Архитектурная безопасность
9.6.1. Прозрачность распределенности
Прозрачность распределенности базы данных позволяет конечным пользователям воспринимать базу данных как единое логическое целое. Если СУРБД обеспечивает прозрачность распределенности, то пользователю не требуется каких-либо знаний о фрагментации данных (прозрачность фрагментации) или их размещении (прозрачность расположения).
Если пользователю необходимо иметь сведения о фрагментации данных и расположении фрагментов, то этот тип прозрачности называют прозрачностью локального отображения.
Прозрачность фрагментации является самым высоким уровнем прозрачности распределейности. Если СУРБД обеспечивает прозрачность фрагментации, то пользователю не требуется знать, как именно фрагментированы данные. В этом случае доступ к данным осуществляется на основе глобальной схемы и пользователю нет необходимости указывать имена фрагментов или расположение данных.
Пользователь применяет те же самые SQL-операторы, которые потребовалось бы ввести для получения необходимых результатов в централизованной системе.
Прозрачность расположения представляет собой средний уровень прозрачности распределейности. В этом случае пользователь должен иметь сведения о способах фрагментации данных в системе, но не нуждается в сведениях о расположении данных. При наличии в системе прозрачности расположения в запросах следует указывать имена используемых фрагментов.
Кроме того, дополнительно необходимо воспользоваться операциями соединения (или подзапросами), поскольку некоторые атрибуты могут находиться в разных фрагментах. Основное преимущество прозрачности расположения состоит в том, что база данных может быть подвергнута физической реорганизации и это не окажет никакого влияния на программы приложений, осуществляющих к ней доступ.
С прозрачностью расположения очень тесно связан еще один тип прозрачности – прозрачность репликации. Он означает, что пользователю не требуется иметь сведения о существующей репликации фрагментов. Под прозрачностью репликации подразумевается прозрачность расположения реплик. Однако могут существовать системы, которые не обеспечивают прозрачности расположения, но поддерживают прозрачность репликации.
Прозрачность локального отображения – самый низкий уровень прозрачности распределенности. При наличии в системе прозрачности локального отображения пользователю необходимо указывать как имена используемых фрагментов, так и расположение соответствующих элементов данных.
Очевидно, что в данном случае запрос имеет более сложный вид и на его подготовку потребуется больше времени, чем в двух предыдущих случаях. Маловероятно, чтобы система, предоставляющая только такой уровень прозрачности распределенности, была приемлема для конечного пользователя.
Прямым следствием обсуждавшихся выше вариантов прозрачности распределенности является требование наличия прозрачности именования. Как и в случае централизованной базы данных, каждый элемент распределенной базы данных должен иметь уникальное имя. Следовательно, СУРБД должна гарантировать, что никакие два сайта системы не смогут создать некоторый объект базы данных, имеющий одно и то же имя.
Одним из вариантов решения этой проблемы является создание центрального сервера имен, который будет нести ответственность за полную уникальность всех существующих в системе имен. Однако подобному подходу свойственны такие недостатки, как:
утрата определенной части локальной автономии;
появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);
снижение доступности – если центральный сайт по какой-либо причине станет недоступным, все остальные сайты системы не смогут создавать никаких новых объектов базы данных [7].
Альтернативное решение состоит в использовании префиксов, помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект [7]. Аналогичным образом, необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию. Однако подобный подход приводит к утрате прозрачности распределенности.
Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных [7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.