Проектирование баз данных Пример
Результаты собеседования Я – старший партнер крупной юридической фирмы. Наша фирма работает в целом ряде областей: нарушения правил дорожного движения, бытовые споры, гражданские дела, убийства и т. д. Фирма состоит из отделов – гражданских дел, убийств и т. д. , и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т. к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами. По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Результаты собеседования Нам нужен список событий по каждому делу (фактически, история дела). Данные должны включать не только перечень событий, но и даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т. д. С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т. д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Проектирование баз данных
Концептуальное проектирование БД
Концептуальное проектирование БД 1. 2. 3. 4. 5. 6. 7. 8. Определение типов сущностей Определение типов связей Определение атрибутов и связывание их с типами сущностей и связей Определение доменов атрибутов Определение атрибутов, являющихся потенциальными и первичными ключами Специализация или генерализация типов сущностей (необязательный этап) Создание диаграмм(ы) “сущность-связь” (ERдиаграммы) Обсуждение концептуальной модели данных с конечными пользователями
Концептуальное проектирование БД 1. Определение типов сущностей
Результаты собеседования Я – старший партнер крупной юридической фирмы. Наша фирма работает в целом ряде областей: нарушения правил дорожного движения, бытовые споры, гражданские дела, убийства и т. д. Фирма состоит из отделов – гражданских дел, убийств и т. д. , и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т. к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами. По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Результаты собеседования Нам нужен список событий по каждому делу (фактически, история дела). Данные должны включать не только перечень событий, но и даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т. д. С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т. д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Концептуальное проектирование БД 1. Определение типов сущностей Отдел Адвокат Дело Событие Человек Роль
Концептуальное проектирование БД 2. Определение типов связей
Результаты собеседования Я – старший партнер крупной юридической фирмы. Наша фирма работает в целом ряде областей: нарушения правил дорожного движения, бытовые споры, гражданские дела, убийства и т. д. Фирма состоит из отделов – гражданских дел, убийств и т. д. , и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т. к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами. По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Результаты собеседования Нам нужен список событий по каждому делу (фактически, история дела). Данные должны включать не только перечень событий, но и даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т. д. С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т. д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Концептуальное проектирование БД 2. Определение типов связей Отдел содержит в штате Адвоката/Адвокат работает в Отделе Дело приписано к Отделу/Отдел заведует Делом Адвокат ведет Дело/Дело принадлежит Адвокат Дело является предшественником Дела/ Дело является приемником Дела Дело состоит из Событий/Событие составляет Дело Человек участвует в Деле/Дело касается Человека Человек выступает в Роли/Роль играет Человек
Концептуальное проектирование БД
Концептуальное проектирование БД 3. Определение атрибутов и связывание их с типами сущностей и связей Отдел Адвокат Дело Событие Человек Роль
Результаты собеседования Я – старший партнер крупной юридической фирмы. Наша фирма работает в целом ряде областей: нарушения правил дорожного движения, бытовые споры, гражданские дела, убийства и т. д. Фирма состоит из отделов – гражданских дел, убийств и т. д. , и в административных целях каждое дело приписывается к конкретному отделу. Каждый из адвокатов также приписан к конкретному отделу, но только для выписки счетов и расчетов по заработной плате, т. к. адвокат может работать над другими делами в других отделах. Адвокаты могут работать над несколькими делами. По каждому делу мы хотим хранить его описание. Закрытое дело может быть позже открыто вновь. Вновь открытым делам мы присваиваем новые номера, но новый номер должен быть связан со старым.
Результаты собеседования Нам нужен список событий по каждому делу (фактически, история дела). Данные должны включать не только перечень событий, но и даты, когда событие вступает в силу. Дела должны опознаваться по уникальному номеру, который указывается в списке с каждой датой события и его описанием. Каждое событие имеет специальный код. Например, О – открытое, Т – слушание дела, L – проиграно и т. д. С одним делом связано несколько человек: адвокат, судья, ответчик, свидетель и т. д. В разных делах одни и те же люди могут выступать в разных ролях, но в каждом конкретном деле одна и та же сторона может выступать лишь в одной единственной роли.
Концептуальное проектирование БД 3. Определение атрибутов и связывание их типами с сущностей и связей Отдел: o Название Адвокат: o Фамилия o Имя o Отчество o Дата рождения Дело: o Номер o Описание
Концептуальное проектирование БД 3. Определение атрибутов и связывание их с типами сущностей и связей Событие: o Номер дела o Дата начала o Описание o Код (обозначение кода, полное название) Человек: o Фамилия o Имя o Отчество Роль: o Описание
Концептуальное проектирование БД
Концептуальное проектирование БД 4. Определение доменов атрибутов Отдел: o Название ТЕКСТ Адвокат: o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ o Дата рождения ДАТА Дело: o Номер ЧИСЛО o Описание ТЕКСТ
Концептуальное проектирование БД 4. Определение доменов атрибутов Событие: o Номер дела ЧИСЛО o Дата начала ДАТА o Описание ТЕКСТ o Код • обозначение кода СИМВОЛ • полное название ТЕКСТ Человек: o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ Роль: o Описание ТЕКСТ
Концептуальное проектирование БД
Концептуальное проектирование БД 5. Определение атрибутов, являющихся потенциальными и первичными ключами Отдел: o Номер ЧИСЛО o Название ТЕКСТ Адвокат: o Номер ЧИСЛО o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ o Дата рождения ДАТА Дело: o Номер ЧИСЛО o Описание ТЕКСТ
Концептуальное проектирование БД 5. Определение атрибутов, являющихся потенциальными и первичными ключами Событие: o o Номер дела ЧИСЛО Дата начала ДАТА Описание ТЕКСТ Код • обозначение кода СИМВОЛ • полное название ТЕКСТ Человек: o Номер ЧИСЛО o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ Роль: o Номер ЧИСЛО o Описание ТЕКСТ
Концептуальное проектирование БД
Концептуальное проектирование БД 6. Специализация или генерализация типов сущностей (необязательный этап) Адвокат: o Номер ЧИСЛО o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ o Дата рождения ДАТА Человек: o Номер ЧИСЛО o Фамилия ТЕКСТ o Имя ТЕКСТ o Отчество ТЕКСТ
Концептуальное проектирование БД
Концептуальное проектирование БД
Концептуальное проектирование БД
Логическое проектирование БД
Логическое проектирование БД 1. 2. 3. 4. 5. 6. 7. 8. Преобразование концептуальной модели данных в логическую модель данных Определение набора отношений Проверка модели с помощью правил нормализации Проверка модели в отношении транзакций пользователя Создание диаграммы “сущность-связь” (ER-диаграммы) Определение требований поддержки целостности данных Проверка возможностей расширения модели в будущем Обсуждение логической модели данных с конечными пользователями
Логическое проектирование БД Преобразование концептуальной модели данных в логическую модель данных 1. Устранение связей “многие ко многим” Удаление рекурсивных связей (необязательно) Удаление связей с атрибутами Удаление множественных атрибутов Проверка связей “один ко одному” Удаление избыточных связей
Логическое проектирование БД Преобразование концептуальной модели данных в логическую модель данных 1. Устранение связей “многие ко многим”
Логическое проектирование БД Преобразование концептуальной модели данных в логическую модель данных 1. Удаление рекурсивных связей
Логическое проектирование БД Преобразование концептуальной модели данных в логическую модель данных 1. Удаление избыточных связей
Логическое проектирование БД Определение набора отношений 2. Создание сильных и слабых типов сущности Определение атрибутов являющихся внешними ключами Представление связи “суперкласс/подкласс”
Логическое проектирование БД
Логическое проектирование БД 3. Проверка модели с помощью правил нормализации
Логическое проектирование БД
Логическое проектирование БД 3. Проверка модели с помощью правил нормализации
Логическое проектирование БД 4. Проверка модели в отношении транзакций пользователя Убедиться в том, что логическая модель данных позволяет выполнить все транзакции, предусмотренные данным представлением пользователя Вручную выполнить каждое действие пользователя
Логическое проектирование БД Какую роль играет Иванов И. И. в деле 542?
Логическое проектирование БД
Логическое проектирование БД
Логическое проектирование БД 6. Определение требований поддержки целостности данных Обязательные данные Ограничения для доменов атрибутов Целостность сущностей Ссылочная целостность Требования данного предприятия
Физическое проектирование БД
Физическое проектирование БД 1. 2. 3. 4. 5. 6. 7. 8. 9. Проектирование таблиц в среде СУБД Реализация бизнес-правил предприятия в среде СУБД Анализ транзакций Выбор файловой структуры Определение вторичных индексов Анализ необходимости введения контролируемой избыточности данных Определение требований к дисковой памяти Разработка пользовательских представлений (видов) Определение прав доступа
Физическое проектирование БД
Физическое проектирование БД 1. Проектирование таблиц в среде СУБД CREATE TABLE TPersone ( Id_person INTEGER NOT NULL, Surname VARCHAR 2(40) NOT NULL, Name VARCHAR 2(20) NOT NULL, Lastname VARCHAR 2(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 ) ;
Физическое проектирование БД Реализация бизнес-правил предприятия в среде СУБД 2. Способ реализации зависит от выбранной СУБД Могут быть использованы ограничения на таблицы, ограничения на столбцы, триггеры и т. д.
Физическое проектирование БД Анализ транзакций 3. Определение функциональных характеристик транзакций и выделение наиболее важных из них Частота выполнения Отношения и атрибуты, к которым потребуется доступ, а также тип доступа (выборка, вставка, обновление или удаление) Атрибуты, используемые в предикатах Атрибуты, используемые при для соединения таблиц Ограничения на время выполнения транзакций
Физическое проектирование БД Выбор файловой структуры 4. Определение наиболее эффективного файлового представления для таблиц. Последовательные файлы(heap) Хешированные файлы (hash) Индексно-последовательные файлы (ISAM) Двоичные деревья (B+-Tree)
Физическое проектирование БД Выбор файловой структуры 4. Последовательные файлы(heap) + данные загружаются крупными блоками + файл таблицы занимает несколько страниц + выборке подлежат все ее кортежи (в любом порядке) + таблица имеет дополнительные структуры поиска - необходим доступ только к некоторым кортежам таблицы
Физическое проектирование БД Выбор файловой структуры 4. Хешированные файлы (hash) Выбор по точному совпадению поля, использованного для хеширования + выборка по диапазону + выборка по значению + выборка по шаблонам - выборка полям не используемых для хеширования
Физическое проектирование БД Выбор файловой структуры 4. Индексно-последовательные файлы (ISAM) + выборка по диапазону + выборка по значению + выборка по шаблонам + выборка по части ключа + конкурентный доступ к индексу легко регулируется - производительность доступа к данным снижается по мере обновления данных (индекс статичный)
Физическое проектирование БД Выбор файловой структуры 4. Двоичные деревья (B+-Tree) + выборка по диапазону + выборка по значению + выборка по шаблонам + выборка по части ключа + производительность доступа к данным НЕ снижается по мере обновления данных (индекс динамический) - Если данные в таблицы изменяются не часто, то менее эффективна по сравнению с индексно-последовательными файлами (в листьях указатели на данные)
Физическое проектирование БД 5. Определение вторичных индексов Индекс – механизм доступа, ускоряющий выборку данных из таблицы + по первичному ключу + по внешними ключу - для небольших таблиц - часто обновляемым атрибутам - длинные символьные строки - результат – большая часть всех кортежей таблицы
Физическое проектирование БД 6. Анализ необходимости введения контролируемой избыточности данных Будет ли способствовать повышению производительности системы внесение контролируемой избыточности данных (снижение требований к уровню их нормализации)
Физическое проектирование БД 7. Определение требований к дисковой памяти Определение объема дискового пространства, необходимого для размещения БД
Физическое проектирование БД Разработка пользовательский представлений (видов) 8. Вид/представление/виртуальная таблица объект базы данных содержимое выбирается из других таблиц (поименованный запрос) скрывает реальную структуру БД
Физическое проектирование БД 9. Определение прав доступа Ограничение доступа к данным. Привилегия – действие, которое пользователю разрешено выполнять в отношении конкретной таблицы
Скачать презентацию Проектирование баз данных Пример Результаты собеседования Я
Проектирование баз данных.ppt