6 Моделирование данных. Таблицы как сущности данных, строка как объект данных, столбец как атрибут объекта. Моделирование отношений между сущностями при.

Презентация:



Advertisements
Похожие презентации
Нормализация таблиц реляционной базы данных © Панова И.В
Advertisements

Проектирование БД. Нормальные формы В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: первая нормальная.
Реляционная модель – это особый метод рассмотрения данных, содержащий данные в виде таблиц, способов работы и манипуляции с ними в виде связей. структура,
Нормализация реляционной модели данных По учебнику Семакин Н.Г., Хеннер Е.К. Информационные системы и модели © 2006 Медведев Л.Н.
Нормализация данных В IDEF1X (дополнительный материал к лекции по информационному моделированию с использованием методологии IDEF1X)
Что такое связи между таблицами В реляционной базе данных связи позволяют избежать избыточности данных. Например, в ходе создания базы данных, содержащей.
Нормализация данных В IDEF1X (дополнительный материал к лекции по информационному моделированию с использованием методологии IDEF1X)
Виды моделей данных. Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности.
Проектирование баз данных сложная задача. Теорию реляционных баз данных в 70 годах XX века разработал Е. Кодд. Сущность его теории сводится к приведению.
Работа с таблицами в MS Access. Таблицы Единицей хранящейся в БД информации является таблица. Таблица представляет собой совокупность строк и столбцов,
Нормализация реляционной модели данных. Реляционная модель данных – это множество взаимосвязанных отношений. Простейший вариант реляционной модели – одно.
ВИДЫ МОДЕЛЕЙ ДАННЫХ. Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности.
Преобразование ER- модели в реляционную. правила преобразования ER- модели в реляционную. 1. Каждой сущности ставится в соответствие отношение реляционной.
Нормализация отношений "Сложная система, спроектированная наспех, никогда не работает, и исправить её, чтобы заставить работать, невозможно". Законы Мерфи.
Основы проектирования реляционных баз данных. База данных: общее понятие База данных: хранилище информации отражает объект реального мира имитирует деятельность.
Организация данных в виде отдельных файлов Файл с данными по договорам договора Дата Организация Директор Адрес Телефон Файл с данными по письмам исх/вх.
ПОСТРОЕНИЕ ДЕКОМПОЗИЦИИ, УДОВЛЕТВОРЯЮЩЕЙ ТРЕБОВАНИЯМ 3НФ Синтетический подход. Часть 1.
Базы данных Учитель информатики гимназии 1 г. Жуковского Московской области Ю.В.Пашковская.
Схема данных в Access Преподаватель: Французова Г.Н.
Базы данных Реляционная база данных MS Access. Повторение База данных организованная совокупность данных из какой-либо предметной области, предназначенная.
Транксрипт:

6_Моделирование данных. Таблицы как сущности данных, строка как объект данных, столбец как атрибут объекта. Моделирование отношений между сущностями при помощи ключей.

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

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

Элементы РМД и формы их представления Сущность – это объект любой природы. Данные о сущности хранятся в отношении (таблице). Атрибуты представляют собой свойства сущности. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок столбца таблицы. Отношение «Остатки товаров на складах»

Первичный и внешний ключ Первичным ключом (ключевым атрибутом) называется атрибут, однозначно идентифицирующий каждый из кортежей (записей таблицы). Ключ может быть составным (из нескольких атрибутов). Не может содержать значения Null (для атрибута целого типа - значение 0) и всегда должен иметь уникальный индекс. Роль ключей: 1. Исключение дублирования значений в ключевых атрибутах; 2. Упорядочение кортежей по значениям ключевых атрибутов или смешанное упорядочение - ускорение работы с БД; 3. Организация связанных таблиц через внешний ключ (один или несколько атрибутов, содержащих ссылку на первичный ключ в другой таблице). Если отношение R2 содержит неключевой атрибут B, значения которого являются значениями ключевого атрибута A отношения R1, то говорят, что атрибут B отношения R2 - внешний ключ отношения A. СТУДЕНТЫПРЕДМЕТЫ ЭКЗАМЕНЫ

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

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

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

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

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

Этапы нормализации таблицы 1. PK – код поставщик а 1 – Ключевые поля; 2 – Поля, не полностью зависящие от ключа; 3 – Поля, не зависящие от ключа; 4 – Поля, зависящие от ключа 2. PK - код товара 3. PK - номер накладной и дата поступления, FK – код поставщика. 4. FK - номер накладной, дата поступления и код товара.

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

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

1. отсутствие отдельных полей для данных о студенте затруднит поиск студента. Петров бросил ВУЗ, но в БД для его аттестации зарезервирована память. 2. Сидоров – студент ГМУ и аттестуется лишь по одному предмету. Вывод – ФИО должны быть разбиты на поля, предметы должны быть записаны в строках, а не в столбцах таблицы 3. последняя запись - Иванов Иван пересдал аттестацию или это другой студент? Введем поле, однозначно определяющее студента – ID или код_студента 4. дублируются записи в полях ФАМИЛИЯ, ИМЯ, ПРЕДМЕТ. Создадим таблицы СТУДЕНТЫ и ПРЕДМЕТЫ, а в таблице АТТЕСТАЦИИ создадим ссылки на записи в них. Схема данных

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

SELECT Аттестация.*, СТУДЕНТЫ.Фамилия, СТУДЕНТЫ.Имя FROM СТУДЕНТЫ INNER JOIN Аттестация ON СТУДЕНТЫ.код_студ = Аттестация.код_студ; Список полей запроса, которые можно поместить на форму (отображается по команде ВИД – СПИСОК ПОЛЕЙ) 1. Форма в конструкторе 2. Форма в режиме просмотра 3. На форму можно поместить кнопку с генерацией кода поиска записи по значению в поле формы