SlideShare a Scribd company logo
Лекция № 10
Тема: Проектирование баз
данных. Проблемы
проектирования. Метод
нормальных форм.
План:
1. Проблемы проектирования.
2. Избыточное дублирование данных и аномалии. Формирование
исходного отношения.
3. Метод нормальных форм.
4. Зависимости между атрибутами.
5. Выявление зависимостей между атрибутами.
6. Нормальные формы.
7. Пятая нормальная форма.
Проблемы проектирования
 Проектирование информационных систем, включающих в себя базы данных,
осуществляется на физическом и логическом уровнях. Решение проблем
проектирования на физическом уровне во многом зависит от используемой СУБД,
зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю
предоставляется возможность настройки отдельных параметров системы, которая не
составляет большой проблемы.
 Логическое проектирование заключается в определении числа и структуры таблиц,
формировании запросов к БД, определении типов отчетных документов, разработке
алгоритмов обработки информации, создании форм для ввода и редактирования
данных в базе и решении ряда других задач.
 Решение задач логического проектирования БД в основном определяется спецификой
задач предметной области. Наиболее важной здесь является проблема структуризации
данных, на пей мы сосредоточим основное внимание.
 При проектировании структур данных для автоматизированных систем можно
выделить три основных подхода:
 Сбор информации об объектах решаемой задачи в рамках одной таблицы (одного
отношения) и последующая декомпозиция ее на несколько взаимосвязанных таблиц на
основе процедуры нормализации отношений.
 Формулирование знаний о системе (определение типов исходных данных и их
взаимосвязей) и требований к обработке данных, получение с помощью CASE -
системы (системы автоматизации проектирования и разработки баз данных) готовой
схемы БД или даже готовой прикладной информационной системы.
 Структурирование информации для использования в информационной системе в
процессе проведения системного анализа на основе совокупности правил и
рекомендаций.
Избыточное дублирование
данных и аномалии
 Следует различать простое (неизбыточное) и избыточное
дублирование данных. Наличие первого из них
допускается в базах данных, а избыточное дублирование
данных может приводить к проблемам при обработке
данных. Приведем примеры обоих вариантов
дублирования.
 Пример неизбыточного дублирования данных
представляет приведенное на рис. 5.1 отношение С_Т с
атрибутами Сотрудник и Телефон. Для сотрудников,
находящихся в одном помещении, номера телефонов
совпадают. Номер телефона 4328 встречается несколько
раз, хотя для каждого служащего номер телефона
уникален. Поэтому ни один из номеров не является
избыточным. Действительно, при удалении одного из
номеров телефонов будет утеряна информация о том, по
какому номеру можно дозвониться до одного из
служащих.
Рис. 10.1 - Избыточное дублирование
 Избыточное дублирование данных создает
проблемы при обработке кортежей отношения,
названные Э. Коддом «аномалиями
обновления отношения». 0(1 показал, что для
некоторых отношений проблемы возникают
при попытке удаления, добавления или
редактирования их кортежей.
 Аномалиями будем называть такую ситуацию
в таблицах ВД, которая приводит к
противоречиям в БД либо существенно
усложняет обработку данных.
Аномалии
 Выделяют три основные вида аномалий: аномалии
модификации (или редактирования), аномалии
удаления и аномалии добавления.
 Аномалии модификации проявляются в том, что
изменение значения одного данного может повлечь
за собой просмотр всей таблицы и соответствующее
изменение некоторых других записей таблицы.
 Аномалии удаления состоят в том, что при
удалении какого-либо данного из таблицы может
пропасть и другая информация, которая не связана
напрямую с удаляемым данным.
 Аномалии добавления возникают в случаях, когда
информацию в таблицу нельзя поместить до тех пор,
пока она неполная, либо вставка новой записи
требует дополнительного просмотра таблицы.
Формирование исходного
отношения
 Проектирование БД начинается с
определения всех объектов, сведения о
которых будут включены в базу, и
определения их атрибутов. Затем
атрибуты сводятся в одну таблицу -
исходное отношение.
Метод нормальных форм
 Проектирование БД является одним из
этапов жизненного цикла инфор-
мационной системы. Основной задачей,
решаемой в процессе проектирования БД,
является задача нормализации ее
отношений. Рассматриваемый ннже метод
нормальных форм является классическим
методом проектирования реляционных
БД. Этот метод основан на
фундаментальном в теории реляционных
баз данных понятии зависимости между
атрибутами отношений.
Зависимости между
атрибутами
 Рассмотрим основные виды зависимостей между
атрибутами отношений: функциональные,
транзитивные и многозначные.
 Понятие функциональной зависимости является
базовым, так как на его основе формулируются
определения всех остальных видов зависимостей.
 Атрибут В функционально зависит от атрибута А,
если каждому значению А соответствует в точности
одно значение В. Математически функциональная
зависимость В от Аобозначается записью А—>В.
Это означает, что во всех кортежах с одинаковым
значением атрибута А атрибут В будет иметь также
одно и то же значение. Отметим, что А и В могут
быть составными - состоять из двух и более
атрибутов.
Нормальные формы
 Процесс проектирования БД с использованием метода
нормальных форм является итерационным и заключается в
последовательном переводе отношений из первой нормальной
формы в нормальные формы более высокого порядка по
определенным правилам. Каждая следующая нормальная
форма ограничивает определенный тин функциональных
зависимостей, устраняет соответствующие аномалии при
выполнении операций над отношениями БД и сохраняет
свойства предшествующих нормальных форм.
Выделяют следующую последовательность нормальных форм:
 первая нормальная форма (1 НФ);
 вторая нормальная форма (2НФ);
 третья нормальная форма (ЗНФ);
 усиленная третья нормальная форма, или нормальная форма
Бойса - Кодда(БКНФ);
 четвертая нормальная форма (4НФ);
 пятая нормальная форма (5НФ).
Первая нормальная форма
 Отношение находится в 1 НФ, если все его
атрибуты являются простыми (имеют
единственное значение). Исходное отношение
строится таким образом, чтобы оно было в 1
НФ.
 Перевод отношения в следующую нормальную
форму осуществляется методом
«декомпозиции без потерь». Такая
декомпозиция должна обеспечить то, что
запросы (выборка данных по условию) к
исходному отношению и к отношениям,
получаемым в результате декомпозиции, дадут
одинаковый результат.
Вторая нормальная форма
 Отношение находится в 2НФ, если оно находится
в 1НФ и каждый неключевой атрибут
функционально полно зависит от первичного
ключа (составного).
Для устранения частичной зависимости и перевода
отношения в 2НФ необходимо, используя операцию
проекции, разложить его на несколько отношений
следующим образом:
 построить проекцию без атрибутов, находящихся в
частичной функциональной зависимости от
первичного ключа;
 построить проекции на части составного
первичного ключа и атрибуты, зависящие от этих
частей.
Третья нормальная форма.
 Определение 1. Отношение находится в
ЗНФ, если оно находится в 2ИФ и каждый
неключевой атрибут неТранзитивно
зависит от первичного ключа.
 Существует и альтернативное
определение.
 Определение 2. Отношение находится в
ЗНФ в том и только в том случае, если все
неключевые атрибуты отношения взаимно
независимы и полностью зависят от
первичного ключа.
Четвертая нормальная форма.
 Рассмотрим пример нового отношения ПРОЕКТЫ, схема
которого выглядит следующим образом: ПРОЕКТЫ
(Номер проекта, Код_сотрудника, Задание_сотрудника).
Первичным ключом отношения является вся совокуп-
ность атрибутов: Номер_проекта, Код_сотрудника и
Задание сотрудника.
 В отношении содержатся номера проектов, для каждого
проекта - список кодов сотрудников-исполнителей, а
также список заданий, предусмотренных каждым
проектом. Сотрудники могут участвовать в нескольких
проектах, и разные проекты могут содержать одинаковые
задания. Предполагается, что каждый сотрудник,
участвующий в некотором гцюекте, выполняет все
задания по этому проекту (предположение не всегда
справедливо, но желательно для нашего примера).
Пятая нормальная форма.
 Результатом нормализации всех
предыдущих схем отношений были два
новых отношения. Иногда это сделать
не удается, либо получаемые
отношения заведомо имеют
нежелательные свойства. В этом случае
выполняют декомпозицию исходного
отношения на отношения, количество
которых превышает два.

More Related Content

Similar to Lekcia10

пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27helenyakovleva
 
Access 05
Access 05Access 05
Access 05
Alexander Babich
 
раздел 2 модели и типы данных
раздел 2  модели и типы данныхраздел 2  модели и типы данных
раздел 2 модели и типы данныхtatianabtt
 
Infostart 2023 Business Analysis Core Concept Model.pptx
Infostart 2023 Business Analysis Core Concept Model.pptxInfostart 2023 Business Analysis Core Concept Model.pptx
Infostart 2023 Business Analysis Core Concept Model.pptx
ssuser6d9135
 
Фёдор Строк - Базы данных - SQL, ORM, NoSQL
Фёдор Строк - Базы данных - SQL, ORM, NoSQLФёдор Строк - Базы данных - SQL, ORM, NoSQL
Фёдор Строк - Базы данных - SQL, ORM, NoSQLYandex
 
тема 4 2
тема 4 2тема 4 2
тема 4 2asheg
 
Lekcia11
Lekcia11Lekcia11
Lekcia11
Aigerim Serubai
 
Управление Данными. Лекция 1
Управление Данными. Лекция 1Управление Данными. Лекция 1
Управление Данными. Лекция 1
Dmitriy Krukov
 
Концепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системахКонцепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системах
Anatoly Simkin
 
9946
99469946
9946
nreferat
 
информатикаисогд
информатикаисогдинформатикаисогд
информатикаисогд
pks11-1
 
Шаблоны проектирования баз данных — Введение
Шаблоны проектирования баз данных — ВведениеШаблоны проектирования баз данных — Введение
Шаблоны проектирования баз данных — Введение
Denis Beskov
 
базы данных.назаров
базы данных.назаровбазы данных.назаров
базы данных.назаровDifferent_56
 
базы данных.назаров
базы данных.назаровбазы данных.назаров
базы данных.назаровDifferent_56
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
dinarium2016
 
Lekcia12
Lekcia12Lekcia12
Lekcia12
Aigerim Serubai
 
001
001001
001JIuc
 
Простой подход к проектированию сложной системы
Простой подход к проектированию сложной системыПростой подход к проектированию сложной системы
Простой подход к проектированию сложной системы
Anatoly Simkin
 

Similar to Lekcia10 (20)

пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27пр8 сем2 1_проектированиербд_er_model2014_02_27
пр8 сем2 1_проектированиербд_er_model2014_02_27
 
Access 05
Access 05Access 05
Access 05
 
раздел 2 модели и типы данных
раздел 2  модели и типы данныхраздел 2  модели и типы данных
раздел 2 модели и типы данных
 
лекция 10
лекция 10лекция 10
лекция 10
 
Infostart 2023 Business Analysis Core Concept Model.pptx
Infostart 2023 Business Analysis Core Concept Model.pptxInfostart 2023 Business Analysis Core Concept Model.pptx
Infostart 2023 Business Analysis Core Concept Model.pptx
 
Фёдор Строк - Базы данных - SQL, ORM, NoSQL
Фёдор Строк - Базы данных - SQL, ORM, NoSQLФёдор Строк - Базы данных - SQL, ORM, NoSQL
Фёдор Строк - Базы данных - SQL, ORM, NoSQL
 
тема 4 2
тема 4 2тема 4 2
тема 4 2
 
Lekcia11
Lekcia11Lekcia11
Lekcia11
 
Управление Данными. Лекция 1
Управление Данными. Лекция 1Управление Данными. Лекция 1
Управление Данными. Лекция 1
 
Концепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системахКонцепция применения онтологических структур в ERP-системах
Концепция применения онтологических структур в ERP-системах
 
9946
99469946
9946
 
информатикаисогд
информатикаисогдинформатикаисогд
информатикаисогд
 
Шаблоны проектирования баз данных — Введение
Шаблоны проектирования баз данных — ВведениеШаблоны проектирования баз данных — Введение
Шаблоны проектирования баз данных — Введение
 
базы данных.назаров
базы данных.назаровбазы данных.назаров
базы данных.назаров
 
базы данных.назаров
базы данных.назаровбазы данных.назаров
базы данных.назаров
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
 
Lekcia12
Lekcia12Lekcia12
Lekcia12
 
пр000 (2часа)e rwin
пр000 (2часа)e rwinпр000 (2часа)e rwin
пр000 (2часа)e rwin
 
001
001001
001
 
Простой подход к проектированию сложной системы
Простой подход к проектированию сложной системыПростой подход к проектированию сложной системы
Простой подход к проектированию сложной системы
 

More from Aigerim Serubai

Lekcia15
Lekcia15Lekcia15
Lekcia15
Aigerim Serubai
 
Lekcia14
Lekcia14Lekcia14
Lekcia14
Aigerim Serubai
 
Lekcia13
Lekcia13Lekcia13
Lekcia13
Aigerim Serubai
 
Lekcia9
Lekcia9Lekcia9
Lekcia8
Lekcia8Lekcia8
Lekcia7
Lekcia7Lekcia7
Lekcia6
Lekcia6Lekcia6
Lekcia5
Lekcia5Lekcia5
Lekcia4
Lekcia4Lekcia4
Lekcia3
Lekcia3Lekcia3
Lekcia1
Lekcia1Lekcia1
Joomla 3.x guide
Joomla 3.x guideJoomla 3.x guide
Joomla 3.x guide
Aigerim Serubai
 

More from Aigerim Serubai (12)

Lekcia15
Lekcia15Lekcia15
Lekcia15
 
Lekcia14
Lekcia14Lekcia14
Lekcia14
 
Lekcia13
Lekcia13Lekcia13
Lekcia13
 
Lekcia9
Lekcia9Lekcia9
Lekcia9
 
Lekcia8
Lekcia8Lekcia8
Lekcia8
 
Lekcia7
Lekcia7Lekcia7
Lekcia7
 
Lekcia6
Lekcia6Lekcia6
Lekcia6
 
Lekcia5
Lekcia5Lekcia5
Lekcia5
 
Lekcia4
Lekcia4Lekcia4
Lekcia4
 
Lekcia3
Lekcia3Lekcia3
Lekcia3
 
Lekcia1
Lekcia1Lekcia1
Lekcia1
 
Joomla 3.x guide
Joomla 3.x guideJoomla 3.x guide
Joomla 3.x guide
 

Lekcia10

  • 1. Лекция № 10 Тема: Проектирование баз данных. Проблемы проектирования. Метод нормальных форм. План: 1. Проблемы проектирования. 2. Избыточное дублирование данных и аномалии. Формирование исходного отношения. 3. Метод нормальных форм. 4. Зависимости между атрибутами. 5. Выявление зависимостей между атрибутами. 6. Нормальные формы. 7. Пятая нормальная форма.
  • 2. Проблемы проектирования  Проектирование информационных систем, включающих в себя базы данных, осуществляется на физическом и логическом уровнях. Решение проблем проектирования на физическом уровне во многом зависит от используемой СУБД, зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю предоставляется возможность настройки отдельных параметров системы, которая не составляет большой проблемы.  Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.  Решение задач логического проектирования БД в основном определяется спецификой задач предметной области. Наиболее важной здесь является проблема структуризации данных, на пей мы сосредоточим основное внимание.  При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:  Сбор информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений.  Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных, получение с помощью CASE - системы (системы автоматизации проектирования и разработки баз данных) готовой схемы БД или даже готовой прикладной информационной системы.  Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
  • 3. Избыточное дублирование данных и аномалии  Следует различать простое (неизбыточное) и избыточное дублирование данных. Наличие первого из них допускается в базах данных, а избыточное дублирование данных может приводить к проблемам при обработке данных. Приведем примеры обоих вариантов дублирования.  Пример неизбыточного дублирования данных представляет приведенное на рис. 5.1 отношение С_Т с атрибутами Сотрудник и Телефон. Для сотрудников, находящихся в одном помещении, номера телефонов совпадают. Номер телефона 4328 встречается несколько раз, хотя для каждого служащего номер телефона уникален. Поэтому ни один из номеров не является избыточным. Действительно, при удалении одного из номеров телефонов будет утеряна информация о том, по какому номеру можно дозвониться до одного из служащих.
  • 4. Рис. 10.1 - Избыточное дублирование
  • 5.  Избыточное дублирование данных создает проблемы при обработке кортежей отношения, названные Э. Коддом «аномалиями обновления отношения». 0(1 показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактирования их кортежей.  Аномалиями будем называть такую ситуацию в таблицах ВД, которая приводит к противоречиям в БД либо существенно усложняет обработку данных.
  • 6. Аномалии  Выделяют три основные вида аномалий: аномалии модификации (или редактирования), аномалии удаления и аномалии добавления.  Аномалии модификации проявляются в том, что изменение значения одного данного может повлечь за собой просмотр всей таблицы и соответствующее изменение некоторых других записей таблицы.  Аномалии удаления состоят в том, что при удалении какого-либо данного из таблицы может пропасть и другая информация, которая не связана напрямую с удаляемым данным.  Аномалии добавления возникают в случаях, когда информацию в таблицу нельзя поместить до тех пор, пока она неполная, либо вставка новой записи требует дополнительного просмотра таблицы.
  • 7. Формирование исходного отношения  Проектирование БД начинается с определения всех объектов, сведения о которых будут включены в базу, и определения их атрибутов. Затем атрибуты сводятся в одну таблицу - исходное отношение.
  • 8. Метод нормальных форм  Проектирование БД является одним из этапов жизненного цикла инфор- мационной системы. Основной задачей, решаемой в процессе проектирования БД, является задача нормализации ее отношений. Рассматриваемый ннже метод нормальных форм является классическим методом проектирования реляционных БД. Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений.
  • 9. Зависимости между атрибутами  Рассмотрим основные виды зависимостей между атрибутами отношений: функциональные, транзитивные и многозначные.  Понятие функциональной зависимости является базовым, так как на его основе формулируются определения всех остальных видов зависимостей.  Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от Аобозначается записью А—>В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. Отметим, что А и В могут быть составными - состоять из двух и более атрибутов.
  • 10. Нормальные формы  Процесс проектирования БД с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тин функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм. Выделяют следующую последовательность нормальных форм:  первая нормальная форма (1 НФ);  вторая нормальная форма (2НФ);  третья нормальная форма (ЗНФ);  усиленная третья нормальная форма, или нормальная форма Бойса - Кодда(БКНФ);  четвертая нормальная форма (4НФ);  пятая нормальная форма (5НФ).
  • 11. Первая нормальная форма  Отношение находится в 1 НФ, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится таким образом, чтобы оно было в 1 НФ.  Перевод отношения в следующую нормальную форму осуществляется методом «декомпозиции без потерь». Такая декомпозиция должна обеспечить то, что запросы (выборка данных по условию) к исходному отношению и к отношениям, получаемым в результате декомпозиции, дадут одинаковый результат.
  • 12. Вторая нормальная форма  Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа (составного). Для устранения частичной зависимости и перевода отношения в 2НФ необходимо, используя операцию проекции, разложить его на несколько отношений следующим образом:  построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа;  построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей.
  • 13. Третья нормальная форма.  Определение 1. Отношение находится в ЗНФ, если оно находится в 2ИФ и каждый неключевой атрибут неТранзитивно зависит от первичного ключа.  Существует и альтернативное определение.  Определение 2. Отношение находится в ЗНФ в том и только в том случае, если все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.
  • 14. Четвертая нормальная форма.  Рассмотрим пример нового отношения ПРОЕКТЫ, схема которого выглядит следующим образом: ПРОЕКТЫ (Номер проекта, Код_сотрудника, Задание_сотрудника). Первичным ключом отношения является вся совокуп- ность атрибутов: Номер_проекта, Код_сотрудника и Задание сотрудника.  В отношении содержатся номера проектов, для каждого проекта - список кодов сотрудников-исполнителей, а также список заданий, предусмотренных каждым проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут содержать одинаковые задания. Предполагается, что каждый сотрудник, участвующий в некотором гцюекте, выполняет все задания по этому проекту (предположение не всегда справедливо, но желательно для нашего примера).
  • 15. Пятая нормальная форма.  Результатом нормализации всех предыдущих схем отношений были два новых отношения. Иногда это сделать не удается, либо получаемые отношения заведомо имеют нежелательные свойства. В этом случае выполняют декомпозицию исходного отношения на отношения, количество которых превышает два.