Моделирование данных

Содержание

Слайд 2

BPWin ERWin Предметная область Логическая модель Этапы проектирования базы данных

BPWin

ERWin

Предметная
область

Логическая
модель

Этапы проектирования базы данных

Слайд 3

Этапы проектирования реляционной БД Предпроектное обследование предметной области. Создание концептуальной (инфологической

Этапы проектирования реляционной БД

Предпроектное обследование предметной области.
Создание концептуальной (инфологической или функциональной)

модели БД.
Создание логической (даталогической) модели БД.
Нормализация логической модели.
Создание БД (физическое моделирование) и контрольного примера;
Создание интерфейса к БД и отладка его на контрольном примере.
Слайд 4

Элементы РМД и формы их представления Сущность – это объект любой

Элементы РМД и формы их представления

Сущность – это объект любой природы.

Данные о сущности хранятся в отношении (таблице). Атрибуты представляют собой свойства сущности. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок столбца таблицы.

Отношение «Остатки товаров на складах»

Слайд 5

Первичный и внешний “ключ” Первичным ключом (ключевым атрибутом) называется атрибут, однозначно

Первичный и внешний “ключ”

Первичным ключом (ключевым атрибутом) называется атрибут, однозначно идентифицирующий

каждый из кортежей (записей таблицы). Ключ может быть составным (из нескольких атрибутов). Не может содержать значения Null (для атрибута целого типа - значение 0) и всегда должен иметь уникальный индекс.
Роль ключей:
1. Исключение дублирования значений в ключевых атрибутах;
2. Упорядочение кортежей по значениям ключевых атрибутов или смешанное упорядочение - ускорение работы с БД;
3. Организация связанных таблиц через внешний ключ (один или несколько атрибутов, содержащих ссылку на первичный ключ в другой таблице).

Если отношение R2 содержит неключевой атрибут B, значения которого являются значениями ключевого атрибута A отношения R1, то говорят, что атрибут B отношения R2 - внешний ключ отношения A.

СТУДЕНТЫ

ПРЕДМЕТЫ

ЭКЗАМЕНЫ

Слайд 6

Ограничения, направленные на обеспечение целостности: Первичный ключ (Primary key, PK) -

Ограничения, направленные на обеспечение целостности:
Первичный ключ (Primary key, PK) -

уникальный идентификатор каждой строки в таблице, предотвращает избыточность данных
Внешний ключ (Foreign key, FK) - ссылка на первичный ключ в той же самой или другой таблице, обеспечивает непротиворечивость и целостность данных
Слайд 7

Основные виды связей между таблицами Между таблицами могут устанавливаться бинарные (между

Основные виды связей между таблицами

Между таблицами могут устанавливаться бинарные (между двумя

таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи.
При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.
Между двумя таблицами могут устанавливаться четыре вида связи:
один к одному (1:1) - между таблицами «Сотрудник» и «Адреса сотрудников» будет существовать отношение один к одному, если сотрудник имеет один адрес проживания;
один ко многим (1:М) - одной записи основной таблицы соответствует несколько записей вспомогательной таблицы (если сотрудник имеет несколько адресов проживания);
многие к одному (М:1) - разновидность связи 1:М;
многие ко многим (М:М) - нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы (студенты и их успеваемость по разным предметам – в таблице успеваемости могут повторяться и студенты и предметы). Данное отношение создается с помощью дополнительной таблицы.
Индекс – средство ускорения поиска, извлечения, модификации, сортировки записей в таблице благодаря тому, что основная часть работы производится с небольшими индексными файлами, а не с самими таблицами.
Слайд 8

Принципы нормализации таблиц Реляционная база должна обладает приведенными ниже характеристиками: 1.

Принципы нормализации таблиц

Реляционная база должна обладает приведенными ниже характеристиками:
1. Минимизация избыточных

данных. В базе данных присутствует избыточность, если одни и те же данные находятся в нескольких местах. Если потребуется информацию изменить, то придется менять во всех записях.
2. Минимальное использование отсутствующих значении (Null-значений). Если кто-то из лицеистов не сдал аттестацию по одной из трех зарезервированных дисциплин, то часть полей в таблице УСПЕВАЕМОСТЬ не будет заполнена.
3. Предотвращение потери информации. Если ввести в таблицу УСПЕВАЕМОСТЬ поле ПРЕПОДАВАТЕЛЬ, а конкретного преподавателя нет в списке кураторов таблицы ГРУППА, то для него не будет заполнено поле в таблице УСПЕВАЕМОСТЬ.
Методику нормализации таблиц разработал американский ученый Эдгар Кодд в 1970 г. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Цель нормализации – избавиться от нефункциональных зависимостей, т.е. от зависимостей, не связанных с первичными ключами.
Были выделены три нормальные формы - 1НФ, 2НФ, ЗНФ. Позже стали выделять нормальную форму Бойса-Кодда (НФБК). Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в ЗНФ.
Слайд 9

Нормальные формы таблиц БД 1НФ – отсутствие повторяющихся групп: таблица не

Нормальные формы таблиц БД

1НФ – отсутствие повторяющихся групп: таблица не содержит

повторяющихся группы (“access, excel, word”) и все ее поля содержат только простые неделимые значения.

2НФ – отсутствие частичной зависимости: каждый неключевой столбец должен зависеть от первичного ключа (возможно, составного), где неключевой столбец – это столбец, который не может претендовать на роль первичного ключа и не может являться частью первичного ключа. Если первичный ключ является простым, отношение автоматически находится в 2НФ.
3НФ – отсутствие транзитивной зависимости: ни один неключевой столбец не должен зависеть от другого неключевого столбца. Транзитивной зависимостью называется функциональная зависимость между неключевыми полями. Значение любого поля, не входящего в первичный ключ, не должно зависеть от значения другого поля, также не входящего в первичный ключ.
Бойса-Кодда - отсутствие в таблице полей, зависящих от части составного ключа таблицы. Если в таблице есть столбец, который может быть самостоятельным ключевым полем, его надо вынести в отдельную таблицу вместе с полями, которые зависят от него. Если первичный ключ является простым, отношение автоматически находится в форме Бойса-Кодда

Слайд 10

2НФ - таблица находится во 2НФ, если она находится в 1НФ

2НФ - таблица находится во 2НФ, если она находится в 1НФ

и каждый неключевой атрибут функционально полно зависит от первичного ключа или каждая запись таблицы может быть однозначно определена по ключу. Зависимость полей от части ключа приводит к повтору информации в этих полях для разных записей таблицы. Определим, существуют ли в таблице поля, не зависящие от ключа (город+улица+дом+корпус) или зависящие от части ключа (поставщик).
3НФ - таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и ни одно из ее неключевых полей функционально не зависит от любого другого неключевого поля, т.е не надо держать в таблицах поля, которые можно определить из уже существующих полей (например, если есть количество и цена, то не обязательно в таблице держать поле стоимость)

1НФ - таблица находится в 1НФ, если ее атрибуты являются простыми и не содержат повторяющихся полей. Каждое значение поля должно быть неделимо (атомарно).

Этапы нормализации БД

Табллица ПОСТУПЛЕНИЕ ТОВАРОВ

Разбиение адреса

Слайд 11

Этапы нормализации таблицы 1. PK – код поставщика 1 – Ключевые

Этапы нормализации таблицы

1. PK – код поставщика

1 – Ключевые поля;
2

– Поля, не полностью зависящие от ключа;
3 – Поля, не зависящие от ключа;
4 – Поля, зависящие от ключа

2. PK - код товара

3. PK - номер накладной и дата поступления, FK – код поставщика.

4. FK - номер накладной, дата поступления и код товара.

Слайд 12

Схема данных Результат нормализации исходной таблицы

Схема данных

Результат нормализации исходной таблицы

Слайд 13

Нормализация БД “Лицей”

Нормализация БД “Лицей”

Слайд 14

1. отсутствие отдельных полей для данных о студенте затруднит поиск студента.

1. отсутствие отдельных полей для данных о студенте затруднит поиск студента.

Петров бросил ВУЗ, но в БД для его аттестации зарезервирована память.

2. Сидоров – студент ГМУ и аттестуется лишь по одному предмету. Вывод – ФИО должны быть разбиты на поля, предметы должны быть записаны в строках, а не в столбцах таблицы

3. последняя запись - Иванов Иван пересдал аттестацию или это другой студент? Введем поле, однозначно определяющее студента – ID или код_студента

4. дублируются записи в полях ФАМИЛИЯ, ИМЯ, ПРЕДМЕТ. Создадим таблицы СТУДЕНТЫ и ПРЕДМЕТЫ, а в таблице АТТЕСТАЦИИ создадим ссылки на записи в них.

Схема данных

Слайд 15

От того, как сконструированы таблицы, зависит удобство создания форм для их

От того, как сконструированы таблицы, зависит удобство создания форм для их

заполнения, поэтому еще на этапе конструирования таблиц можно определить возможность выбора из списка значений для заполнения полей с помощью формы. Форма для таблицы создается по команде ВСТАВКА - АВТОФОРМА

SELECT СТУДЕНТЫ.код_студ, СТУДЕНТЫ.Фамилия, СТУДЕНТЫ.Имя
FROM СТУДЕНТЫ;

На форме отсутствует поле ИМЯ, т.к. в поле КОД_СТУД таблицы АТТЕСТАЦИЯ отображается одно значение - ФАМИЛИЯ. В конструкторе формы изменим на вкладке ДАННЫЕ параметр ИСТОЧНИК ЗАПИСЕЙ