[vsesdal]
Тип работы: Курсовая теория
Предмет: Информатика
Страниц: 32
Год написания: 2014
ВВЕДЕНИЕ 3
1 Данные и информация 5
1.1 Начало развития электронных систем баз данных 7
1.2 Базы данных и персональные компьютеры 11
1.3 Выводы по главе 14
2 Структура базы данных 16
2.1 Различия файловой системы управления и системы управления базами данных 16
2.2 Компоненты системы базы данных 17
2.3 Приложения, использующие системы управления базами данных 18
2.4 Компоненты СУБД 20
2.5 Выводы по главе 20
3 Администрирование и безопасность баз данных 22
3.1 Базы данных и основные задачи администрирования 22
3.2 Вопросы безопасности в контексте аббревиатуры CIA 25
ЗАКЛЮЧЕНИЕ 29
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 31
Учебная работа № 430265. Тема: Администрирование баз данных
Выдержка из похожей работы
Некоторые проблемы администрирования баз данных
…..ребует минимальное количество операций ввода-вывода. В реляционных системах, как правило, организована автоматическая оптимизация – пользователь может не задумываться над способом выражения своих запросов, т.е. над тем, как сформулировать запрос, чтобы система выполнила его с максимально возможной производительностью. Более того, существует реальная возможность, что оптимизатор сформулирует запрос лучше, чем пользователь. Во-первых, автоматический оптимизатор располагает некоторыми статистическими данными о состоянии отношений, благодаря которым он способен более точно оценивать эффективность любой стратегии реализации конкретного запроса. Во-вторых, если с течением времени статистика базы данных значительно изменится (например, база данных будет физически реорганизована), то для реализации запроса может потребоваться совсем иная стратегия, чем до реорганизации; другими словами, может понадобиться повторная оптимизация, или реоптимизация.
В реляционных системах процесс реоптимизации – это просто повторная обработка исходного запроса системным оптимизатором. В-третьих, оптимизатор – это программа, поэтому он более “настойчив” по сравнению с человеком. Оптимизатор вполне способен рассматривать буквально сотни различных стратегий реализации данного запроса, в то время как программист вряд ли изучает более трех-четырех стратегий.
Рассмотрим в качестве примера следующий запрос: найти имена поставщиков, поставляющих тестеры. Выражение реляционной алгебры и команда SQL могут иметь следующий вид:
(((Поставки JOIN (Детали WHERE Имя_Д=Тестер))JOIN Поставщики))[Имя_П].
SELECT Поставщики.Имя_ПFROM Поставщики, Детали,
ПоставкиWHERE Поставщики.ПN=Поставки.ПNAND Поставки.ДN=Детали.ДNAND Детали.Имя_Д=Тестер;
Предположим, что существует порядка 100 строк поставщиков, 50 000 строк поставок и 200 строк деталей. Примерно 1% поставок приходится на деталь «Тестер». Будем полагать, что за одно считывание в оперативную память передается одна запись.
Для обслуживания данного запроса потребуется выполнить последовательность алгебраических операций соединения (Join), выборки (Restrict) и проекции (Project). Большое значение имеет порядок выполнения этих операций. Предположим, что операции будут выполнятьcя в следующем порядке:
1.Выполнить соединение ПОСТАВЩИКИ и ПОСТАВКИ по атрибуту ПN. В худшем случае (при отсутствии индексов и кластеров) для этого потребуется считать 100 записей о поставщиках и для каждой из них считать все 50 000 записей поставок, чтобы создать возможные соединения, т.е. потребуется произвести 100×50 000 (5 миллионов) считываний. В результате будет получено временное отношение Temp1, состоящее из 50 000 строк поставок, соединенных с соответствующими строками поставщиков.
2.Выполнить соединение Temp1 с ДЕТАЛИ по атрибуту ДN. Для этого потребуется считать 50 000 строк отношения Temp1 и каждую из них сравнить с 200 строками ДЕТАЛИ. Потребуется произвести 50 000×200 (10 миллионов) считываний.
.Результатом этого соединения будет временное отношение Temp2, состоящее из всех данных о поставках и поставщиках отношения Temp1, к которым добавлены данные о деталях. Отношение по-прежнему будет состоять из 50 000 строк, но сами строки будут очень длинными, так как они теперь содержат атриб…