Слайд 1Пример
Проектирование баз данных
Слайд 2Результаты собеседования
Я – старший партнер крупной юридической фирмы. Наша фирма
работает в целом ряде областей: нарушения правил дорожного движения, бытовые
споры, гражданские дела, убийства и т.д.
Фирма состоит из отделов – гражданских дел, убийств и т.д., и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т.к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами.
По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Слайд 3Результаты собеседования
Нам нужен список событий по каждому делу (фактически, история
дела). Данные должны включать не только перечень событий, но и
даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т.д.
С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т.д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Слайд 5Концептуальное проектирование БД
Слайд 6Концептуальное проектирование БД
Определение типов сущностей
Определение типов связей
Определение атрибутов и связывание
их с типами сущностей и связей
Определение доменов атрибутов
Определение атрибутов, являющихся
потенциальными и первичными ключами
Специализация или генерализация типов сущностей (необязательный этап)
Создание диаграмм(ы) “сущность-связь” (ER-диаграммы)
Обсуждение концептуальной модели данных с конечными пользователями
Слайд 7Концептуальное проектирование БД
Определение типов сущностей
Слайд 8Результаты собеседования
Я – старший партнер крупной юридической фирмы. Наша фирма
работает в целом ряде областей: нарушения правил дорожного движения, бытовые
споры, гражданские дела, убийства и т.д.
Фирма состоит из отделов – гражданских дел, убийств и т.д., и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т.к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами.
По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Слайд 9Результаты собеседования
Нам нужен список событий по каждому делу (фактически, история
дела). Данные должны включать не только перечень событий, но и
даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т.д.
С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т.д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Слайд 10Концептуальное проектирование БД
Определение типов сущностей
Отдел
Адвокат
Дело
Событие
Человек
Роль
Слайд 11Концептуальное проектирование БД
Определение типов связей
Слайд 12Результаты собеседования
Я – старший партнер крупной юридической фирмы. Наша фирма
работает в целом ряде областей: нарушения правил дорожного движения, бытовые
споры, гражданские дела, убийства и т.д.
Фирма состоит из отделов – гражданских дел, убийств и т.д., и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т.к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами.
По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Слайд 13Результаты собеседования
Нам нужен список событий по каждому делу (фактически, история
дела). Данные должны включать не только перечень событий, но и
даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т.д.
С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т.д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Слайд 14Концептуальное проектирование БД
Определение типов связей
Отдел содержит в штате Адвоката/Адвокат работает
в Отделе
Дело приписано к Отделу/Отдел заведует Делом
Адвокат ведет Дело/Дело принадлежит
Адвокат
Дело является предшественником Дела/ Дело является приемником Дела
Дело состоит из Событий/Событие составляет Дело
Человек участвует в Деле/Дело касается Человека
Человек выступает в Роли/Роль играет Человек
Слайд 15Концептуальное проектирование БД
Слайд 16Концептуальное проектирование БД
Определение атрибутов и связывание их с типами сущностей
и связей
Отдел
Адвокат
Дело
Событие
Человек
Роль
Слайд 17Результаты собеседования
Я – старший партнер крупной юридической фирмы. Наша фирма
работает в целом ряде областей: нарушения правил дорожного движения, бытовые
споры, гражданские дела, убийства и т.д.
Фирма состоит из отделов – гражданских дел, убийств и т.д., и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т.к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами.
По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Слайд 18Результаты собеседования
Нам нужен список событий по каждому делу (фактически, история
дела). Данные должны включать не только перечень событий, но и
даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т.д.
С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т.д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Слайд 19Концептуальное проектирование БД
Определение атрибутов и связывание их типами с сущностей
и связей
Отдел:
Название
Адвокат:
Фамилия
Имя
Отчество
Дата рождения
Дело:
Номер
Описание
Слайд 20Концептуальное проектирование БД
Определение атрибутов и связывание их с типами сущностей
и связей
Событие:
Номер дела
Дата начала
Описание
Код (обозначение кода, полное название)
Человек:
Фамилия
Имя
Отчество
Роль:
Описание
Слайд 21Концептуальное проектирование БД
Слайд 22Концептуальное проектирование БД
Определение доменов атрибутов
Отдел:
Название ТЕКСТ
Адвокат:
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество
ТЕКСТ
Дата рождения ДАТА
Дело:
Номер ЧИСЛО
Описание ТЕКСТ
Слайд 23Концептуальное проектирование БД
Определение доменов атрибутов
Событие:
Номер дела ЧИСЛО
Дата начала ДАТА
Описание
ТЕКСТ
Код
обозначение кода СИМВОЛ
полное название ТЕКСТ
Человек:
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество ТЕКСТ
Роль:
Описание ТЕКСТ
Слайд 24Концептуальное проектирование БД
Слайд 25Концептуальное проектирование БД
Определение атрибутов, являющихся потенциальными и первичными ключами
Отдел:
Номер
ЧИСЛО
Название ТЕКСТ
Адвокат:
Номер ЧИСЛО
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество ТЕКСТ
Дата рождения ДАТА
Дело:
Номер
ЧИСЛО
Описание ТЕКСТ
Слайд 26Концептуальное проектирование БД
Определение атрибутов, являющихся потенциальными и первичными ключами
Событие:
Номер
дела ЧИСЛО
Дата начала ДАТА
Описание ТЕКСТ
Код
обозначение кода СИМВОЛ
полное название ТЕКСТ
Человек:
Номер ЧИСЛО
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество ТЕКСТ
Роль:
Номер ЧИСЛО
Описание ТЕКСТ
Слайд 27Концептуальное проектирование БД
Слайд 28Концептуальное проектирование БД
Специализация или генерализация типов сущностей (необязательный этап)
Адвокат:
Номер
ЧИСЛО
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество ТЕКСТ
Дата рождения ДАТА
Человек:
Номер ЧИСЛО
Фамилия ТЕКСТ
Имя ТЕКСТ
Отчество
ТЕКСТ
Слайд 29Концептуальное проектирование БД
Слайд 30Концептуальное проектирование БД
Слайд 31Концептуальное проектирование БД
Слайд 33Логическое проектирование БД
Преобразование концептуальной модели данных в логическую модель данных
Определение
набора отношений
Проверка модели с помощью правил нормализации
Проверка модели в отношении
транзакций пользователя
Создание диаграммы “сущность-связь” (ER-диаграммы)
Определение требований поддержки целостности данных
Проверка возможностей расширения модели в будущем
Обсуждение логической модели данных с конечными пользователями
Слайд 34Логическое проектирование БД
Преобразование концептуальной модели данных в логическую модель данных
Устранение
связей “многие ко многим”
Удаление рекурсивных связей (необязательно)
Удаление связей с атрибутами
Удаление
множественных атрибутов
Проверка связей “один ко одному”
Удаление избыточных связей
Слайд 35Логическое проектирование БД
Преобразование концептуальной модели данных в логическую модель данных
Устранение
связей “многие ко многим”
Слайд 36Логическое проектирование БД
Преобразование концептуальной модели данных в логическую модель данных
Удаление
рекурсивных связей
Слайд 37Логическое проектирование БД
Преобразование концептуальной модели данных в логическую модель данных
Удаление
избыточных связей
Слайд 38Логическое проектирование БД
Определение набора отношений
Создание сильных и слабых типов сущности
Определение атрибутов являющихся внешними ключами
Представление связи “суперкласс/подкласс”
Слайд 40Логическое проектирование БД
Проверка модели с помощью правил нормализации
Слайд 42Логическое проектирование БД
Проверка модели с помощью правил нормализации
Слайд 43Логическое проектирование БД
Проверка модели в отношении транзакций пользователя
Убедиться в том,
что логическая модель данных позволяет выполнить все транзакции, предусмотренные данным
представлением пользователя
Вручную выполнить каждое действие пользователя
Слайд 44Логическое проектирование БД
Какую роль играет Иванов И.И. в деле 542?
Слайд 47Логическое проектирование БД
Определение требований поддержки целостности данных
Обязательные данные
Ограничения для доменов
атрибутов
Целостность сущностей
Ссылочная целостность
Требования данного предприятия
Слайд 49Физическое проектирование БД
Проектирование таблиц в среде СУБД
Реализация бизнес-правил предприятия в
среде СУБД
Анализ транзакций
Выбор файловой структуры
Определение вторичных индексов
Анализ необходимости введения контролируемой
избыточности данных
Определение требований к дисковой памяти
Разработка пользовательских представлений (видов)
Определение прав доступа
Слайд 51Физическое проектирование БД
Проектирование таблиц в среде СУБД
CREATE TABLE TPersone (
Id_person INTEGER
NOT NULL,
Surname VARCHAR2(40) NOT NULL,
Name VARCHAR2(20) NOT NULL,
Lastname VARCHAR2(40) NULL,
Birthday DATE NULL,
Id_department INTEGER NULL
);
ALTER TABLE TPersone
ADD ( PRIMARY KEY (Id_person) ) ;
ALTER TABLE TPersone
ADD ( FOREIGN KEY (Id_department)
REFERENCES TDepartament
ON DELETE SET NULL ) ;
Слайд 52Физическое проектирование БД
Реализация бизнес-правил предприятия в среде СУБД
Способ реализации зависит
от выбранной СУБД
Могут быть использованы ограничения на таблицы, ограничения
на столбцы, триггеры и т.д.
Слайд 53Физическое проектирование БД
Анализ транзакций
Определение функциональных характеристик транзакций и выделение наиболее
важных из них
Частота выполнения
Отношения и атрибуты, к которым потребуется доступ,
а также тип доступа (выборка, вставка, обновление или удаление)
Атрибуты, используемые в предикатах
Атрибуты, используемые при для соединения таблиц
Ограничения на время выполнения транзакций
Слайд 54Физическое проектирование БД
Выбор файловой структуры
Определение наиболее эффективного файлового представления для
таблиц.
Последовательные файлы(heap)
Хешированные файлы (hash)
Индексно-последовательные файлы (ISAM)
Двоичные деревья (B+-Tree)
Слайд 55Физическое проектирование БД
Выбор файловой структуры
Последовательные файлы(heap)
+ данные загружаются крупными блоками
+
файл таблицы занимает несколько страниц
+ выборке подлежат все ее кортежи
(в любом порядке)
+ таблица имеет дополнительные структуры поиска
- необходим доступ только к некоторым кортежам таблицы
Слайд 56Физическое проектирование БД
Выбор файловой структуры
Хешированные файлы (hash)
Выбор по точному совпадению
поля, использованного для хеширования
+ выборка по диапазону
+ выборка по значению
+
выборка по шаблонам
- выборка полям не используемых для хеширования
Слайд 57Физическое проектирование БД
Выбор файловой структуры
Индексно-последовательные файлы (ISAM)
+ выборка по диапазону
+
выборка по значению
+ выборка по шаблонам
+ выборка по части ключа
+
конкурентный доступ к индексу легко регулируется
- производительность доступа к данным снижается по мере обновления данных (индекс статичный)
Слайд 58Физическое проектирование БД
Выбор файловой структуры
Двоичные деревья (B+-Tree)
+ выборка по диапазону
+
выборка по значению
+ выборка по шаблонам
+ выборка по части ключа
+
производительность доступа к данным НЕ снижается по мере обновления данных (индекс динамический)
- Если данные в таблицы изменяются не часто, то менее эффективна по сравнению с индексно-последовательными файлами (в листьях указатели на данные)
Слайд 59Физическое проектирование БД
Определение вторичных индексов
Индекс – механизм доступа, ускоряющий выборку
данных из таблицы
+ по первичному ключу
+ по внешними ключу
- для
небольших таблиц
- часто обновляемым атрибутам
- длинные символьные строки
- результат – большая часть всех кортежей таблицы
Слайд 60Физическое проектирование БД
Анализ необходимости введения контролируемой избыточности данных
Будет ли способствовать
повышению производительности системы внесение контролируемой избыточности данных (снижение требований к
уровню их нормализации)
Слайд 61Физическое проектирование БД
Определение требований к дисковой памяти
Определение объема дискового пространства,
необходимого для размещения БД
Слайд 62Физическое проектирование БД
Разработка пользовательский представлений (видов)
Вид/представление/виртуальная таблица
объект базы
данных
содержимое выбирается из других таблиц (поименованный запрос)
скрывает реальную структуру
БД
Слайд 63Физическое проектирование БД
Определение прав доступа
Ограничение доступа к данным.
Привилегия – действие,
которое пользователю разрешено выполнять в отношении конкретной таблицы
