Лекция 9. Проектирование фактографических баз данных и хранилищ данных Подходы к проектированию БД.
реклама
Лекция 9. Проектирование
фактографических баз данных и
хранилищ данных
• Подходы к проектированию БД.
• Этапы нисходящего подхода к
проектированию баз данных.
• Проектирование хранилищ данных.
Подходы к проектированию БД
• Восходящий
• Нисходящий
• Анализ и выявление
атрибутов
• Группировка
атрибутов в
отношения
• Нормализация
отношений
• Физическое
проектирование
• Концептуальное
(инфологическое)
проектирование
• Логическое
(даталогическое)
проектирование
• Физическое
проектирование
Нисходящий подход
Start
Информация о предметной области
Концептуальное проектирование БД
Выбор модели данных
Логическое проектирование БД
Выбор конкретной СУБД
Физическое проектирование БД
БД
Finish
Методология концептуального
проектирования базы данных
• Этап 1. Создание локальной концептуальной модели
•
•
•
•
•
•
•
•
данных исходя из представлений о предметной области
каждого из типов пользователей.
Этап 1.1. Определение типов сущностей.
Этап 1.2. Определение типов связей.
Этап 1.3. Определение атрибутов и связывание их с типами
сущностей и связей.
Этап 1.4. Определение доменов атрибутов.
Этап 1.5. Определение атрибутов, являющихся
потенциальными и первичными ключами.
Этап 1.6. Специализация или генерализация типов
сущностей.
Этап 1.7. Создание диаграммы "сущность-связь".
Этап 1.8. Обсуждение локальных концептуальных моделей
данных с конечными пользователями.
Методология логического
проектирования базы данных
• Этап 2. Построение и проверка локальной логической
•
•
•
•
•
•
•
модели данных на основе представления о предметной
области каждого из типов пользователей.
Этап 2.1. Преобразование локальной концептуальной
модели данных в локальную логическую модель.
Этап 2.2. Определение набора отношений исходя из
структуры локальной логической модели данных.
Этап 2.3. Проверка модели с помощью правил
нормализации.
Этап 2.4. Проверка модели в отношении транзакций
пользователей.
Этап 2.5. Создание диаграмм "сущность-связь".
Этап 2.6. Определение требований поддержки целостности
данных.
Этап 2.7. Обсуждение разработанных локальных
логических моделей данных с конечными пользователями.
Удаление связей типа M:N.
Репетитор
Id_репетитор
Ученик
Id_ученик
Репетитор
Id_репетитор
Ученик
Id_ученик
Занятия
Id_Занятия
Id_Репетитора
Id_ученика
Удаление сложных связей
Репетитор
Id_репетитор
Ученик
Id_ученик
Предмет
Id_предмет
Репетитор
Id_репетитор
Занятия
Id_Занятия
Id_Репетитора
Id_Ученика
Id_предмет
Предмет
Id_предмет
Ученик
Id_ученик
Удаление рекурсивных связей
Сотрудник
руководит
Сотрудник
Подчиненный
сотрудник
Удаление связей с атрибутами
Стаж
Сотрудник
Id_сотрудник
Сотрудник
Id_сотрудник
работает
Трудовая
деятельность
Id_сотрудника
Id_Предприятия
стаж
Предприятие
Id_предприятие
Предприятие
Id_предприятия
Удаление множественных
атрибутов
Предприятие
Id_Предприятие
Номер телефон (множ)
Предприятие
Id_Предприятие
Телефон
Id_Телефон
Id_Предприятие
Номер телефона (един)
Нормализация
Ненормализованная
форма
Таблица, содержащая одну или
несколько повторяющихся групп данных
Атомарность данных
Первая нормальная
форма
Отношение, в котором на пересечении
каждой строки и каждого столбца
содержится только одно значение
Полная функц. зависимость от ключа
Вторая нормальная
форма
Отношение, каждый атрибут которого,
не входящий в состав первичного ключа,
полностью функционально зависит от
этого первичного ключа
Отсутствие транзитивной зависимости
Третья нормальная
форма
Отношение, которое не имеет не
входящих в первичный ключ атрибутов,
которые находились бы в транзитивной
зависимости от этого первичного ключа
Ссылочная целостность
• Случай 1. Вставка новой
строки в дочернее
отношение.
• Случай 2. Удаление строки
из дочернего отношения.
• Случай 3. Обновление
внешнего ключа в строке
дочернего отношения
• Случай 4. Вставка строки
в родительское отношение
• Случай 5. Удаление строки
из родительского
отношения
• Случай 6. Обновление
первичного ключа в строке
родительского отношения
NO ACTION
CASCADE
SET NOLL
SET DEFAULT
NO CHECK
Методология логического
проектирования базы данных
• Этап 3. Создание и проверка глобальной
•
•
•
•
•
логической модели данных.
Этап 3.1. Слияние локальных логических моделей
данных в единую глобальную модель данных.
Этап 3.2. Проверка глобальной логической модели
данных.
Этап 3.3. Проверка возможностей расширения
модели в будущем.
Этап 3.4. Создание окончательного варианта
диаграммы "сущность-связь".
Этап 3.5. Обсуждение глобальной логической модели
данных с пользователями.
Методология физического
проектирования базы данных
• Этап 4. Перенос глобальной логической модели
данных в среду целевой СУБД.
• Этап 4.1. Проектирование основных таблиц в среде
целевой СУБД.
• Этап 4.2. Реализация бизнес-правил предприятия в
среде целевой СУБД.
Методология физического
проектирования базы данных
• Этап 5. Проектирование
•
•
•
•
•
физического представления базы
данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой
структуры.
Этап 5.3. Определение вторичных
индексов.
Этап 5.4. Анализ необходимости
введения контролируемой
избыточности данных.
Этап 5.5. Определение требований
к дисковой памяти.
«-»
Время
отклика
системы
Пропускная
способность
транзакций
«+»
«-»
Дисковая
память
Методология физического
проектирования базы данных
• Этап 6. Разработка механизмов защиты.
• Этап 6.1. Разработка пользовательских
представлений (видов).
• Этап 6.2. Определение прав доступа.
• Этап 7. Организация мониторинга и настройка
функционирования системы.
Привилегии
•
•
•
•
•
•
•
•
Привилегиями называют действия,
которые пользователь имеет право
выполнят в отношении данной
таблицы базы данных или
представления
•
GRANT {privilege_list\ ALL
PRIVILEGES}
ON object name
TO {authorization_id_list\ PUBLIC}
[WITH GRANT OPTION]
•
REVOKE [GRANT OPTION FOR]
{privilege_list\ ALL PRIVILEGES}
ON object_name
FROM {authorization_id_list \
PUBLIC} [RESTRICT \ CASCADE]
•
•
•
•
SELECT — право выбирать
данные из таблицы;
INSERT — право вставлять в
таблицу новые строки;
UPDATE — право изменять
данные в таблице;
DELETE — право удалять
строки из таблицы;
REFERENCES — право
ссылаться на столбцы
указанной таблицы в
описания, требований
поддержки целостности
данных;
USAGE — право
использовать домены,
проверки, наборы символов
и трансляции.
Типичная
архитектура
хранилища данных
и магазины данных
с указанием
информационных
потоков в
хранилище данных
