Содержание
- 2. BPWin ERWin Предметная область Логическая модель Этапы проектирования базы данных
- 3. Этапы проектирования реляционной БД Предпроектное обследование предметной области. Создание концептуальной (инфологической или функциональной) модели БД. Создание
- 4. Элементы РМД и формы их представления Сущность – это объект любой природы. Данные о сущности хранятся
- 5. Первичный и внешний “ключ” Первичным ключом (ключевым атрибутом) называется атрибут, однозначно идентифицирующий каждый из кортежей (записей
- 6. Ограничения, направленные на обеспечение целостности: Первичный ключ (Primary key, PK) - уникальный идентификатор каждой строки в
- 7. Основные виды связей между таблицами Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя
- 8. Принципы нормализации таблиц Реляционная база должна обладает приведенными ниже характеристиками: 1. Минимизация избыточных данных. В базе
- 9. Нормальные формы таблиц БД 1НФ – отсутствие повторяющихся групп: таблица не содержит повторяющихся группы (“access, excel,
- 10. 2НФ - таблица находится во 2НФ, если она находится в 1НФ и каждый неключевой атрибут функционально
- 11. Этапы нормализации таблицы 1. PK – код поставщика 1 – Ключевые поля; 2 – Поля, не
- 12. Схема данных Результат нормализации исходной таблицы
- 13. Нормализация БД “Лицей”
- 14. 1. отсутствие отдельных полей для данных о студенте затруднит поиск студента. Петров бросил ВУЗ, но в
- 15. От того, как сконструированы таблицы, зависит удобство создания форм для их заполнения, поэтому еще на этапе
- 17. Скачать презентацию
BPWin
ERWin
Предметная
область
Логическая
модель
Этапы проектирования базы данных
BPWin
ERWin
Предметная
область
Логическая
модель
Этапы проектирования базы данных
Этапы проектирования реляционной БД
Предпроектное обследование предметной области.
Создание концептуальной (инфологической или функциональной)
Этапы проектирования реляционной БД
Предпроектное обследование предметной области.
Создание концептуальной (инфологической или функциональной)
Создание логической (даталогической) модели БД.
Нормализация логической модели.
Создание БД (физическое моделирование) и контрольного примера;
Создание интерфейса к БД и отладка его на контрольном примере.
Элементы РМД и формы их представления
Сущность – это объект любой природы.
Элементы РМД и формы их представления
Сущность – это объект любой природы.
Отношение «Остатки товаров на складах»
Первичный и внешний “ключ”
Первичным ключом (ключевым атрибутом) называется атрибут, однозначно идентифицирующий
Первичный и внешний “ключ”
Первичным ключом (ключевым атрибутом) называется атрибут, однозначно идентифицирующий
Роль ключей:
1. Исключение дублирования значений в ключевых атрибутах;
2. Упорядочение кортежей по значениям ключевых атрибутов или смешанное упорядочение - ускорение работы с БД;
3. Организация связанных таблиц через внешний ключ (один или несколько атрибутов, содержащих ссылку на первичный ключ в другой таблице).
Если отношение R2 содержит неключевой атрибут B, значения которого являются значениями ключевого атрибута A отношения R1, то говорят, что атрибут B отношения R2 - внешний ключ отношения A.
СТУДЕНТЫ
ПРЕДМЕТЫ
ЭКЗАМЕНЫ
Ограничения, направленные на обеспечение целостности:
Первичный ключ (Primary key, PK) -
Ограничения, направленные на обеспечение целостности:
Первичный ключ (Primary key, PK) -
Внешний ключ (Foreign key, FK) - ссылка на первичный ключ в той же самой или другой таблице, обеспечивает непротиворечивость и целостность данных
Основные виды связей между таблицами
Между таблицами могут устанавливаться бинарные (между двумя
Основные виды связей между таблицами
Между таблицами могут устанавливаться бинарные (между двумя
При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.
Между двумя таблицами могут устанавливаться четыре вида связи:
один к одному (1:1) - между таблицами «Сотрудник» и «Адреса сотрудников» будет существовать отношение один к одному, если сотрудник имеет один адрес проживания;
один ко многим (1:М) - одной записи основной таблицы соответствует несколько записей вспомогательной таблицы (если сотрудник имеет несколько адресов проживания);
многие к одному (М:1) - разновидность связи 1:М;
многие ко многим (М:М) - нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы (студенты и их успеваемость по разным предметам – в таблице успеваемости могут повторяться и студенты и предметы). Данное отношение создается с помощью дополнительной таблицы.
Индекс – средство ускорения поиска, извлечения, модификации, сортировки записей в таблице благодаря тому, что основная часть работы производится с небольшими индексными файлами, а не с самими таблицами.
Принципы нормализации таблиц
Реляционная база должна обладает приведенными ниже характеристиками:
1. Минимизация избыточных
Принципы нормализации таблиц
Реляционная база должна обладает приведенными ниже характеристиками:
1. Минимизация избыточных
2. Минимальное использование отсутствующих значении (Null-значений). Если кто-то из лицеистов не сдал аттестацию по одной из трех зарезервированных дисциплин, то часть полей в таблице УСПЕВАЕМОСТЬ не будет заполнена.
3. Предотвращение потери информации. Если ввести в таблицу УСПЕВАЕМОСТЬ поле ПРЕПОДАВАТЕЛЬ, а конкретного преподавателя нет в списке кураторов таблицы ГРУППА, то для него не будет заполнено поле в таблице УСПЕВАЕМОСТЬ.
Методику нормализации таблиц разработал американский ученый Эдгар Кодд в 1970 г. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Цель нормализации – избавиться от нефункциональных зависимостей, т.е. от зависимостей, не связанных с первичными ключами.
Были выделены три нормальные формы - 1НФ, 2НФ, ЗНФ. Позже стали выделять нормальную форму Бойса-Кодда (НФБК). Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в ЗНФ.
Нормальные формы таблиц БД
1НФ – отсутствие повторяющихся групп: таблица не содержит
Нормальные формы таблиц БД
1НФ – отсутствие повторяющихся групп: таблица не содержит
2НФ – отсутствие частичной зависимости: каждый неключевой столбец должен зависеть от первичного ключа (возможно, составного), где неключевой столбец – это столбец, который не может претендовать на роль первичного ключа и не может являться частью первичного ключа. Если первичный ключ является простым, отношение автоматически находится в 2НФ.
3НФ – отсутствие транзитивной зависимости: ни один неключевой столбец не должен зависеть от другого неключевого столбца. Транзитивной зависимостью называется функциональная зависимость между неключевыми полями. Значение любого поля, не входящего в первичный ключ, не должно зависеть от значения другого поля, также не входящего в первичный ключ.
Бойса-Кодда - отсутствие в таблице полей, зависящих от части составного ключа таблицы. Если в таблице есть столбец, который может быть самостоятельным ключевым полем, его надо вынести в отдельную таблицу вместе с полями, которые зависят от него. Если первичный ключ является простым, отношение автоматически находится в форме Бойса-Кодда
2НФ - таблица находится во 2НФ, если она находится в 1НФ
2НФ - таблица находится во 2НФ, если она находится в 1НФ
3НФ - таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и ни одно из ее неключевых полей функционально не зависит от любого другого неключевого поля, т.е не надо держать в таблицах поля, которые можно определить из уже существующих полей (например, если есть количество и цена, то не обязательно в таблице держать поле стоимость)
1НФ - таблица находится в 1НФ, если ее атрибуты являются простыми и не содержат повторяющихся полей. Каждое значение поля должно быть неделимо (атомарно).
Этапы нормализации БД
Табллица ПОСТУПЛЕНИЕ ТОВАРОВ
Разбиение адреса
Этапы нормализации таблицы
1. PK – код поставщика
1 – Ключевые поля;
2
Этапы нормализации таблицы
1. PK – код поставщика
1 – Ключевые поля;
2
3 – Поля, не зависящие от ключа;
4 – Поля, зависящие от ключа
2. PK - код товара
3. PK - номер накладной и дата поступления, FK – код поставщика.
4. FK - номер накладной, дата поступления и код товара.
Схема данных
Результат нормализации исходной таблицы
Схема данных
Результат нормализации исходной таблицы
Нормализация БД “Лицей”
Нормализация БД “Лицей”
1. отсутствие отдельных полей для данных о студенте затруднит поиск студента.
1. отсутствие отдельных полей для данных о студенте затруднит поиск студента.
2. Сидоров – студент ГМУ и аттестуется лишь по одному предмету. Вывод – ФИО должны быть разбиты на поля, предметы должны быть записаны в строках, а не в столбцах таблицы
3. последняя запись - Иванов Иван пересдал аттестацию или это другой студент? Введем поле, однозначно определяющее студента – ID или код_студента
4. дублируются записи в полях ФАМИЛИЯ, ИМЯ, ПРЕДМЕТ. Создадим таблицы СТУДЕНТЫ и ПРЕДМЕТЫ, а в таблице АТТЕСТАЦИИ создадим ссылки на записи в них.
Схема данных
От того, как сконструированы таблицы, зависит удобство создания форм для их
От того, как сконструированы таблицы, зависит удобство создания форм для их
SELECT СТУДЕНТЫ.код_студ, СТУДЕНТЫ.Фамилия, СТУДЕНТЫ.Имя
FROM СТУДЕНТЫ;
На форме отсутствует поле ИМЯ, т.к. в поле КОД_СТУД таблицы АТТЕСТАЦИЯ отображается одно значение - ФАМИЛИЯ. В конструкторе формы изменим на вкладке ДАННЫЕ параметр ИСТОЧНИК ЗАПИСЕЙ