
- •Введение в бд
- •Файловые системы
- •Системы с базами данных
- •Модели данных
- •Альтернативная терминология Терминология, используемая в реляционной модели, порой может привести к путанице, поскольку помимо предложенных двух наборов терминов существует еще один – третий.
- •Сетевая модель данных
- •Иерархическая модель данных
- •Вопросы:
- •Упражнения:
- •Реляционная модель.
- •Реляционная алгебра. Реляционное исчисление.
- •Реляционная модель
- •Реляционные языки
- •Реляционная алгебра
- •Унарные операции реляционной алгебры
- •Операции с множествами
- •Операции соединения
- •Деление
- •Реляционное исчисление
- •Реляционное исчисление кортежей
- •Реляционное исчисление доменов
- •Другие языки
- •Тема 3 Моделирование данных Модель «сущность-связь»
- •Элементы модели «сущность-связь»
- •Сущность
- •Атрибуты
- •Идентификаторы
- •Три типа бинарных связей
- •Диаграммы «сущность-связь»
- •Изображение атрибутов в диаграммах «сущность-связь»
- •Слабые сущности
- •Подтипы сущностей
- •Пример er-диаграммы
- •Диаграммы «сущность-связь» в стиле uml
- •Сущности и связи в uml
- •Представление слабых сущностей
- •Представление подтипов
- •Конструкции ооп, введенные языком uml
- •Семантическая объектная модель
- •Семантические объекты
- •Определение семантических объектов
- •Атрибуты
- •Кардинальное число атрибута
- •Экземпляры объектов
- •Парные атрибуты
- •Объектные идентификаторы
- •Домены атрибутов
- •Представления семантических объектов
- •Создание семантических объектных моделей данных
- •Пример: база данных администрации нтуу «кпи»
- •Спецификация объектов
- •Типы объектов
- •Простые объекты
- •Составные объекты
- •Гибридные объекты
- •Ассоциативные объекты
- •Объекты вида родитель/подтип
- •Объекты вида архетип/версия
- •Переход от семантической объектной модели к модели «сущность-связь»
- •Вопросы:
- •Упражнения:
- •Тема 4 Нормализация
- •Классы отношений
- •Нормальные формы от первой до пятой
- •Тема 5 Методология проектирования баз данных Введение в методологию проектирования баз данных
- •Методология концептуального проектирования базы данных
- •Методология логического проектирования реляционных баз данных
- •Суть состоит в том, что при устранении избыточности очень важно исследовать значение каждой из связей, существующих между сущностями.
- •Методология физического проектирования базы данных
- •Трехуровневая архитектура ansi-sparc
- •Система управления Базами Данных
- •1. Хранение, извлечение и обновление данных
- •2. Каталог доступный конечным пользователям
- •Поддержка транзакций
- •Сервисы управления параллельностью
- •Сервисы восстановления
- •6. Сервисы контроля доступа к данным
- •Поддержка обмена данными
- •8. Вспомогательные службы
- •Преимущества:
- •Недостатки:
- •Вопросы:
- •Упражнения:
- •История языка sql
- •Особая роль языка sql
- •Используемая терминология
- •Запись операторов sql
- •Манипулирование данными
- •Литералы
- •Простые запросы
- •Выборка строк (конструкция where)
- •Сортировка результатов (конструкция order by)
- •Использование агрегирующих функций языка sql
- •Группирование результатов (конструкция group by)
- •Ограничения на выполнение группирования (конструкция having)
- •Подзапросы
- •Ключевые слова any и all
- •Многотабличные запросы
- •Выполнение соединений
- •Внешние соединения
- •Ключевые слова exists и not exist
- •Комбинирование результирующих таблиц (операции union, intersect и except)
- •Изменение содержимого базы данных
- •Добавление новых данных в таблицу (оператор insert)
- •Модификация данных в базе (оператор update)
- •Удаление данных из базы (оператор delete)
- •Скалярные типы данных языка sql
- •Логические данные (тип boolean)
- •Символьные данные (тип character)
- •Битовые данные (тип bit)
- •Точные числовые данные (тип exact numeric)
- •Округленные числовые данные (тип approximate numeric)
- •Дата и время (тип datetime)
- •Интервальный тип данных interval
- •Скалярные операторы
- •Средства поддержки целостности данных
- •Обязательные данные
- •Ограничения для доменов
- •Целостность сущностей
- •Ссылочная целостность
- •Требования данного предприятия
- •Определение данных
- •Создание баз данных
- •Создание таблиц (оператор create table)
- •Модификация определения таблицы (оператор alter table)
- •Удаление таблиц (оператор drop table)
- •Создание индекса (оператор create index)
- •Удаление индекса (оператор drop index)
- •Представления
- •Создание представлений (оператор create view)
- •Удаление представлений (оператор drop view)
- •Замена представлений
- •Ограничения на использование представлений
- •Обновление данных в представлениях
- •Использование конструкции with check option
- •Преимущества и недостатки представлений
- •Преимущества
- •Недостатки
- •Материализация представлений
- •Использование транзакций
- •Немедленные и отложенные ограничения поддержки целостности данных
- •Управление доступом к данным
- •Идентификаторы пользователей и права владения
- •Привилегии
- •Предоставление привилегий другим пользователям (оператор grant)
- •Отмена предоставленных пользователям привилегий (оператор revoke)
- •Приложение
- •Тема 7.3 Хранимые процедуры и функции. Триггеры.
- •Создание хранимых процедур и функций
- •Простые формы выражений
- •Поддержка транзакций
- •Свойства транзакций
- •Архитектура базы данных
- •Управление параллельным доступом
- •Проблема потерянного обновления
- •Проблема зависимости от незафиксированных результатов (или "грязного" чтения)
- •Проблема анализа несогласованности
- •Упорядочиваемость и восстанавливаемость
- •Конфликтная упорядочиваемость
- •Упорядочиваемость по просмотру
- •Восстанавливаемость
- •Методы управления параллельным доступом
- •Методы блокировки
- •Двухфазная блокировка
- •Управление параллельным выполнением при использовании индексных структур
- •Защелки
- •Взаимоблокировка
- •Тайм-ауты
- •Предотвращение взаимоблокировок
- •Обнаружение взаимоблокировок
- •Частота выполнения операции обнаружения взаимоблокировок
- •Возобновление нормальной работы после обнаружения взаимоблокировки
- •Использование временных отметок
- •Правило записи Томаса
- •Сравнение методов
- •Упорядочение временных отметок в случае многих версий
- •Оптимистические методы упорядочения
- •Степень детализации блокируемых элементов данных
- •Иерархия степеней детализации
- •Блокировка с учетом нескольких степеней детализации
- •Восстановление базы данных
- •Необходимость восстановления
- •Транзакции и восстановление
- •Управление буферами базы данных
- •Функции восстановления
- •Механизм резервного копирования
- •Файл журнала
- •Создание контрольных точек
- •Методы восстановления
- •Метод восстановления с использованием отложенного обновления
- •Метод восстановления с использованием немедленного обновления
- •Метод теневого страничного обмена
- •Улучшенные модели транзакций
- •Модель вложенных транзакций
- •Эмуляция механизма вложенных транзакций с помощью точек сохранения
- •Хроники
- •Модель многоуровневых транзакций
- •Динамическая реструктуризация
- •Модели рабочих потоков
- •Общий обзор методов обработки запросов
- •Основные этапы обработки запросов
- •Динамическая и статическая оптимизация запросов
- •Декомпозиция запросов
- •Нормализация
- •Семантический анализ
- •Упрощение
- •Реструктуризация запросов
- •Эвристический подход к оптимизации запросов
- •Правила преобразования операций реляционной алгебры
- •Оценка стоимости операций реляционной алгебры
- •Статистические показатели базы данных
- •Вариант 6. Поиск по равенству значению кластеризующего (вторичного) индекса
- •Вариант 7. Поиск по равенству значению некластеризующего (вторичного) индекса
- •Составные предикаты
- •Конъюнктивная выборка без дизъюнкций
- •Выборки с дизъюнкциями
- •Конвейерная обработка данных
- •Тема 10
- •Основные типы угроз
- •Контрмеры – компьютерные средства контроля
- •Авторизация пользователей
- •Привилегии
- •Права владения и привилегии
- •Представления (подсхемы)
- •Резервное копирование и восстановление
- •Поддержка целостности
- •Шифрование
- •Raid (массив независимых дисковых накопителей с избыточностью)
- •Средства защиты субд Microsoft Access
- •Установка пароля
- •Защита на уровне пользователя
Тема 5 Методология проектирования баз данных Введение в методологию проектирования баз данных
Прежде чем приступить к рассмотрению собственно методологии, полезно узнать, что она собой представляет, в частности то, как методология концептуального и логического проектирования базы данных соотносится с физическим проектированием.
Что такое методология проектирования
Методология проектирования – структурированный подход, предусматривающий использование специализированных процедур, технических приемов, инструментов, документации и нацеленный на поддержку и упрощение процесса проектирования.
Методология проектирования предусматривает разбиение всего процесса на несколько фаз, каждая из которых, в свою очередь, состоит из нескольких этапов. На каждом этапе разработчику предлагается набор технических приемов, позволяющих решать задачи, стоящие перед ним на данной стадии разработки. Кроме того, методология предлагает методы планирования, координации, управления, оценки хода разработки проекта, а также структурированный подход к анализу и моделированию всего набора предъявляемых к базе данных требований и позволяет выполнить эти действия стандартизированным и организованным образом.
Концептуальное, логическое и физическое проектирование базы данных
В предлагаемой методологии проектирования баз данных весь процесс разработки разделяется на три основные фазы: концептуальное, логическое и физическое проектирование.
Концептуальное проектирование базы данных – процедура конструирования информационной модели предприятия, не зависящей от каких-либо физических условий реализации.
Фаза концептуального проектирования базы данных начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся: выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная вычислительная платформа и любые другие физические особенности реализации.
Логическое проектирование базы данных – процесс конструирования информационной модели предприятия на основе существующих конкретных моделей данных, не зависимой от используемой СУБД и прочих физических условий реализации.
Фаза логического проектирования базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (например, предполагается использование некоторой реляционной СУБД). Логическая модель данных является источником информации для фазы физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения.
Физическое проектирование базы данных – процесс создания описания конкретной реализации базы данных, размещаемой во вторичной памяти. Предусматривает описание структуры хранения данных и методов доступа, предназначенных для осуществления наиболее эффективного доступа к информации.
Фаза физического проектирования базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Между фазами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать некоторого пересмотра логической модели данных.
Важнейшие факторы успешного завершения проектирования базы данных
Ниже приведены некоторые рекомендации, следовать которым необходимо для успешного завершения процедуры проектирования базы данных:
Поддерживать постоянную и активную связь с будущими пользователями приложения.
При проведении процедур моделирования данных придерживаться рекомендаций, приведенных при обсуждении предлагаемой методологии.
Разрабатывать систему исходя из существующих характеристик данных.
Создавать модель данных с учетом требований поддержки их структурной целостности и согласованности.
Дополнять предлагаемые данной методологией процедуры технологическими приемами концептуализации, нормализации и проверки целостности транзакций.
Для представления модели данных как можно шире использовать диаграммы.
Для описания дополнительных семантических требований к данным использовать средства языка DBDL (Database Design Language).
В дополнение к диаграммам моделей данных разработать словарь описания данных.
Без колебаний возвращаться к уже выполненным ранее этапам, если это требуется для достижения оптимальных результатов.
Общий обзор процедуры проектирования базы данных
В целом, процедура разработки включает следующие этапы:
Концептуальное проектирование базы данных
Этап 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. Обсуждение разработанных локальных логических моделей данных с
конечными пользователями.
Этап 3. Создание и проверка глобальной логической модели данных.
Этап 3.1. Слияние локальных логических моделей данных в единую
глобальную модель данных.
Этап 3.2. Проверка глобальной логической модели данных.
Этап 3.3. Проверка возможностей расширения модели в будущем.
Этап 3.4. Создание окончательного варианта диаграммы "сущность-связь".
Этап 3.5. Обсуждение глобальной логической модели данных с
пользователями.
Физическое проектирование базы данных (с использованием реляционной СУБД)
Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.
Этап 4.1. Проектирование основных отношений.
Этап 4.2. Разработка способов получения производных данных.
Этап 4.3. Реализация ограничений предметной области.
Этап 5. Проектирование физического представления базы данных.
Этап 5.1. Анализ транзакций.
Этап 5.2. Выбор файловой структуры.
Этап 5.3. Определение индексов.
Этап 5.4. Оценка потребности в дисковом пространстве.
Этап 6. Проектирование пользовательских представлений.
Этап 7. Проектирование средств защиты.
Концептуальное и логическое проектирование базы данных включает три основных этапа. Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представлений о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей.
На втором этапе локальные концептуальные модели данных преобразуются в локальные логические модели данных (для реляционной модели данных). На этом этапе из моделей данных удаляются нежелательные элементы, затрудняющие реализацию моделей данных в среде реляционных СУБД. Затем корректность логических моделей данных проверяется с помощью правил нормализации. Нормализация представляет собой эффективное средство, позволяющее убедиться в структурной согласованности, логической целостности и минимальной избыточности принятой модели данных. Дополнительно модель данных проверяется с целью выявления возможности осуществления транзакций, которые будут выполняться пользователями создаваемого приложения. Все эти проверки позволяют получить необходимую уверенность в том, что принятая модель данных является вполне корректной. Локальные логические модели данных при необходимости можно использовать для генерации прототипов реализаций базы данных, предназначенных для отдельных типов пользователей приложения.
На третьем этапе выполняется интеграция локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей).
В предлагаемой методологии проектирования существенная роль отводится конечным пользователям, которые постоянно привлекаются разработчиками для ознакомления и проверки создаваемых моделей данных и сопроводительной документации. Проектирование баз данных обычно представляет собой итеративный процесс, имеющий конкретную точку начала и включающий неограниченное число циклов улучшений и доработок. Хотя в нашем изложении этот процесс выглядит как четко определенная последовательность процедур, следует особо подчеркнуть, что это ни в коей мере не означает, что разработка базы данных непременно должна выполняться именно в такой манере. Весьма вероятно, что сведения, полученные при выполнении некоторого этапа, могут потребовать изменить решения, принятые на одном из предыдущих этапов. Поэтому считаем, что практика предварительного анализа возможных результатов выполнения последующих этапов может оказаться полезной при выполнении начальных этапов разработки. Предлагаемую методологию следует рассматривать как общую схему, которая позволит повысить общую эффективность работы по проектированию баз данных.