Презентация Проектирование реляционных баз данных на основе принципов нормализации. (Лекция 6) онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Проектирование реляционных баз данных на основе принципов нормализации. (Лекция 6) абсолютно бесплатно. Урок-презентация на эту тему содержит всего 76 слайдов. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Презентации » Информатика » Проектирование реляционных баз данных на основе принципов нормализации. (Лекция 6)
Оцените!
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:76 слайдов
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:0.97 MB
- Просмотров:112
- Скачиваний:1
- Автор:неизвестен
Слайды и текст к этой презентации:
№4 слайд
![Критерии оценки качества](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img3.jpg)
Содержание слайда: Критерии оценки качества логической модели данных
Адекватность базы данных предметной области
Легкость разработки и сопровождения базы данных
Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей)
Скорость выполнения операций выборки данных
№5 слайд
![Адекватность базы данных](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img4.jpg)
Содержание слайда: Адекватность базы данных предметной области
Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
№6 слайд
![Легкость разработки и](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img5.jpg)
Содержание слайда: Легкость разработки и сопровождения базы данных
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.
№7 слайд
![Скорость операций обновления](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img6.jpg)
Содержание слайда: Скорость операций обновления данных (вставка, обновление, удаление)
Основными операциями, изменяющими состояние базы данных, являются операции вставки, обновления и удаления записей.
скорость выполнения операций вставки, обновления и удаления также уменьшается при увеличении количества индексов у таблицы и мало зависит от числа строк в таблице.
№8 слайд
![Скорость операций выборки](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img7.jpg)
Содержание слайда: Скорость операций выборки данных
Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц.
Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.
№9 слайд
![Результаты Исследования OASIG](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img8.jpg)
Содержание слайда: Результаты Исследования OASIG
• Примерно 80-90% компьютеризованных систем не обладают требуемой производительностью.
• При разработке около 80% систем были превышены установленные для этого временные и бюджетные рамки.
• Разработка около 40% систем закончилась неудачно или была прекращена до завершения работы.
• Менее чем 40% систем предусматривали профессиональное обучение и повышение квалификации пользователей во всем необходимом объеме.
• Гармонично интегрировать интересы бизнеса и используемой технологии удалось не более чем в 25% систем.
• Только 10-20% систем отвечают всем критериям достижения успеха.
№10 слайд
![Неудачи при создании](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img9.jpg)
Содержание слайда: Неудачи при создании программного обеспечения были вызваны следующими
причинами:
а отсутствием полной спецификации всех требований;
• отсутствием приемлемой методологии разработки;
• недостаточной степенью разделения общего глобального проекта на отдельные компоненты, поддающиеся эффективному контролю и управлению.
№11 слайд
![Этапы разработки ИС](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img10.jpg)
Содержание слайда: Этапы разработки ИС
Планирование разработки базы данных
Определение требований к системе
Сбор и анализ требований пользователей
Проектирование базы данных
Выбор целевой СУБД (необязательный этап)
Разработка приложений
Создание прототипов (необязательный этап)
Реализация
Преобразование и загрузка данных
Тестирование
Эксплуатация и сопровождение
№12 слайд
![Модель предметной области](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img11.jpg)
Содержание слайда: Модель предметной области
Сотрудники организации выполняют проекты.
Проекты состоят из нескольких заданий.
Каждый сотрудник может участвовать в одном или нескольких проектах, или временно не участвовать ни в каких проектах.
Над каждым проектом может работать несколько сотрудников, или временно проект может быть приостановлен, тогда над ним не работает ни один сотрудник.
Над каждым заданием в проекте работает ровно один сотрудник.
Каждый сотрудник числится в одном отделе.
Каждый сотрудник имеет телефон, находящийся в отделе сотрудника
№13 слайд
![Ввод дополнительных](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img12.jpg)
Содержание слайда: Ввод дополнительных аттрибутов
О каждом сотруднике необходимо хранить табельный номер и фамилию. Табельный номер является уникальным для каждого сотрудника.
Каждый отдел имеет уникальный номер.
Каждый проект имеет номер и наименование. Номер проекта является уникальным.
Каждая работа из проекта имеет номер, уникальный в пределах проекта. Работы в разных проектах могут иметь одинаковые номера.
№14 слайд
![Проектирование схемы БД](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img13.jpg)
Содержание слайда: Проектирование схемы БД
Проектирование схемы БД может быть выполнено двумя путями:
путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;
путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.
№15 слайд
![Процесс проектирования с](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img14.jpg)
Содержание слайда: Процесс проектирования с использованием декомпозиции
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая по следующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
№17 слайд
![Потенциальный ключ](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img16.jpg)
Содержание слайда: Потенциальный ключ
Потенциальным ключом отношения называется набор атрибутов отношения, который полностью и однозначно (функционально полно) определяет значения всех остальных атрибутов отношения, то есть возможный ключ — это набор атрибутов, однозначно определяющий кортеж отношения
Среди всех возможных ключей отношения обычно выбирают один, который считается главным и который называют первичным ключом отношения.
№18 слайд
![СОТРУДНИКИ ОТДЕЛЫ ПРОЕКТЫ Н](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img17.jpg)
Содержание слайда: СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ
Н_СОТР - табельный номер сотрудника
ФАМ - фамилия сотрудника
Н_ОТД - номер отдела, в котором числится сотрудник
ТЕЛ - телефон сотрудника
Н_ПРО - номер проекта, над которым работает сотрудник
ПРОЕКТ - наименование проекта, над которым работает сотрудник
Н_ЗАДАН - номер задания, над которым работает сотрудник
Т.к. каждый сотрудник в каждом проекте выполняет ровно одно задание, то в качестве потенциального ключа отношения необходимо взять пару атрибутов {Н_СОТР, Н_ПРО}.
№21 слайд
![Аномалии вставки INSERT В](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img20.jpg)
Содержание слайда: Аномалии вставки (INSERT)
В отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о сотруднике, который пока не участвует ни в одном проекте.
Точно также нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.
Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).
№22 слайд
![Аномалии обновления UPDATE](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img21.jpg)
Содержание слайда: Аномалии обновления (UPDATE)
если сотрудник меняет фамилию, или проект меняет наименование, или меняется номер телефона, то такие изменения необходимо одновременно выполнить во всех местах, где эта фамилия, наименование или номер телефона встречаются, иначе отношение станет некорректным.
Причина аномалии - избыточность данных, также порожденная тем, что в одном отношении хранится разнородная информация.
№25 слайд
![примеры функциональных](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img24.jpg)
Содержание слайда: примеры функциональных зависимостей:
Зависимость атрибутов от ключа отношения
{Н_СОТР, Н_ПРО} ФАМ
{Н_СОТР, Н_ПРО} Н_ОТД
{Н_СОТР, Н_ПРО} ТЕЛ
{Н_СОТР, Н_ПРО} ПРОЕКТ
{Н_СОТР, Н_ПРО} Н_ЗАДАН
Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника:
Н_СОТР ФАМ
Н_СОТР Н_ОТД
Н_СОТР ТЕЛ
Зависимость наименования проекта от номера проекта:
Н_ПРО ПРОЕКТ
Зависимость номера телефона от номера отдела:
Н_ОТД ТЕЛ
№27 слайд
![НФ Вторая Нормальная Форма](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img26.jpg)
Содержание слайда: 2НФ (Вторая Нормальная Форма)
Определение 3. Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа.
Неключевой атрибут - это атрибут, не входящий в состав никакого потенциального ключа.
№28 слайд
![Пример Отношение СОТРУДНИКИ](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img27.jpg)
Содержание слайда: Пример
Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ не находится в 2НФ, т.к. есть атрибуты, зависящие от части сложного ключа:
Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника является зависимостью от части сложного ключа:
Н_СОТР ФАМ
Н_СОТР Н_ОТД
Н_СОТР ТЕЛ
Зависимость наименования проекта от номера проекта является зависимостью от части сложного ключа:
Н_ПРО ПРОЕКТ
№32 слайд
![Анализ декомпозированных](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img31.jpg)
Содержание слайда: Анализ декомпозированных отношений
Отношения, полученные в результате декомпозиции, находятся в 2НФ. СОТРУДНИКИ_ОТДЕЛЫ и ПРОЕКТЫ имеют простые ключи, следовательно автоматически находятся в 2НФ
отношение ЗАДАНИЯ имеет сложный ключ, но единственный неключевой атрибут Н_ЗАДАН функционально зависит от всего ключа {Н_СОТР, Н_ПРО}.
№33 слайд
![Оставшиеся аномалии вставки](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img32.jpg)
Содержание слайда: Оставшиеся аномалии вставки (INSERT)
В отношение СОТРУДНИКИ_ОТДЕЛЫ нельзя вставить кортеж (4, Пушников, 1, 33-22-11), т.к. при этом получится, что два сотрудника из 1-го отдела (Иванов и Пушников) имеют разные номера телефонов, а это противоречит модели предметной области.
№35 слайд
![НФ Третья Нормальная Форма](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img34.jpg)
Содержание слайда: 3НФ (Третья Нормальная Форма)
Определение 4. Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.
Определение 5. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы.
Отношение СОТРУДНИКИ_ОТДЕЛЫ не находится в 3НФ, т.к. имеется функциональная зависимость неключевых атрибутов (зависимость номера телефона от номера отдела):
Н_ОТД ТЕЛ
№39 слайд
![Приведение ко НФ Для](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img38.jpg)
Содержание слайда: Приведение ко 2НФ
Для приведения данного отношения ко второй нормальной форме следует разбить его на проекции, при этом должно быть соблюдено условие восстановления исходного отношения без потерь.
Такими проекциями могут быть два отношения
(ФИО, Номер зач.кн, Группа)
(Номер зач.кн, Дисциплина, Оценка)
№41 слайд
![Функциональные зависимости](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img40.jpg)
Содержание слайда: Функциональные зависимости
Номер зач.кн. -> ФИО
Номер зач.кн. -> Группа
Номер зач.кн. -> Факультет
Номер зач.кн. -> Специальность
Номер зач.кн. -> Выпускающая кафедра
Группа -> Факультет
Группа -> Специальность
Группа -> Выпускающая кафедра
Выпускающая кафедра -> Факультет
№42 слайд
![Декомпозиция И эти](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img41.jpg)
Содержание слайда: Декомпозиция
И эти зависимости образуют транзитивные группы. Для того чтобы избежать этого, мы можем предложить следующий набор отношений
(Номер.зач.кн., ФИО, Специальность, Группа)
(Группа, Выпускающая кафедра)
(Выпускающая кафедра, Факультет)
Первичные ключи отношений выделены.
№43 слайд
![Алгоритм нормализации Шаг](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img42.jpg)
Содержание слайда: Алгоритм нормализации
Шаг 1 (Приведение к 1НФ). На первом шаге задается одно или несколько отношений, отображающих понятия предметной области.
По модели предметной области (не по внешнему виду полученных отношений!) выписываются обнаруженные функциональные зависимости.
Все отношения автоматически находятся в 1НФ.
№44 слайд
![Шаг Приведение к НФ . Если в](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img43.jpg)
Содержание слайда: Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом:
те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа.
В исходном отношении остаются все ключевые атрибуты
№46 слайд
![Шаг Приведение к НФ . Если в](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img45.jpg)
Содержание слайда: Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов других неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом:
те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение.
В новом отношении ключом становится детерминант функциональной зависимости:
№49 слайд
![Корректность процедуры](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img48.jpg)
Содержание слайда: Корректность процедуры нормализации - декомпозиция без потерь
Определение. Проекция R[X] отношения R на множество атрибутов X называется собственной, если множество атрибутов X является собственным подмножеством множества X атрибутов отношения R (т.е. множество атрибутов X не совпадает с множеством всех атрибутов отношения R ).
Определение. Собственные проекции R1 и R2 отношения R называются декомпозицией без потерь, если отношение R точно восстанавливается из них при помощи естественного соединения для любого состояния отношения R:
R1 JOIN R2 = R
№55 слайд
![Модель сущность связь](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img54.jpg)
Содержание слайда: Модель «сущность—связь»
Основные понятия:
Сущность, с помощью которой моделируется класс однотипных объектов.
Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса.
Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называют ключевым.
сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой.
№57 слайд
![Обязательные и необязательные](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img56.jpg)
Содержание слайда: Обязательные и необязательные связи
Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.
№60 слайд
![принцип категоризации](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img59.jpg)
Содержание слайда: принцип категоризации сущностей
Подтип сущности -- сущности, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне.
Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов.
№68 слайд
![Преобразование ключей . В](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img67.jpg)
Содержание слайда: Преобразование ключей
4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).
№69 слайд
![Связи . Для моделирования](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img68.jpg)
Содержание слайда: Связи
5. Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL).
При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).
№75 слайд
![Разрешение связей типа](/documents_6/5fa8a51c5b54d787b858a8920db90fca/img74.jpg)
Содержание слайда: Разрешение связей типа «многие-ко-многим».
Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью «один-ко-многим», атрибутами этого отношения являются первичные ключи связываемых отношений.
например» в схеме «Библиотека» присутствует связь такого типа между сущностью «Книги» и «Системный каталог». Для разрешения этой неспецифической связи при переходе к реляционной модели, должно быть введено специальное дополнительное отношение, которое имеет всего два атрибута;
ISBN (шифр книги) и KOD (код области знаний).
При этом каждый из атрибутов нового отношения является внешним ключом (FORKING KEY), а вместе они образуют первичный ключ (PRIMARY KEY) повой связующей сущности.
Скачать все slide презентации Проектирование реляционных баз данных на основе принципов нормализации. (Лекция 6) одним архивом:
Похожие презентации
-
Проектирование баз данных на основе принципов нормализации
-
Проектирование реляционной базы данных. Основные принципы проектирования
-
Логическое проектирование реляционной базы данных. Лекция 8
-
Реляционные базы данных. Проектирование баз данных. (Лекция 4)
-
Основы теории реляционных баз данных. Лекция 3
-
Проектирование Баз Данных. Основные понятия Теории Нормализации
-
Технология проектирования реляционных баз данных. Нормализация и функциональные зависимости
-
Тема 12 Введение в технологию баз данных 1 Основные понятия баз данных 2 Типы баз данных 3 Реляционные базы данных 4 Проектирова
-
БАЗЫ ДАННЫХ. ИНФОРМАЦИОННЫЕ СИСТЕМЫ Информационные системы Базы данных (БД) Реляционные БД Работа с таблицами Проектировани
-
Учебный курс Язык UML в анализе и проектировании программных систем и бизнес-процессов Лекция 1 Базовые принципы и понятия техн