Проектирование реляционных баз данных

ЦЕЛИ И ЗАДАЧИ РАБОТЫ
1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
1.1. Общие положения
1.2 12 . правил Кода
1.3. Этапы проектирования базы данных
1.3.1. Инфологическое проектирование
1.3.2. Определение требований к операционной обстановке
1.3.3. Выбор СУБД и других программных средств
1.3.4. Логическое проектирование БД
1.3.5. Физическое проектирование БД
1.4. Особенности проектирования реляционной базы данных
1.4.1. Нормализация отношений
2. ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
2.1. Инфологическое проектирование
2.1.1. Анализ предметной области
2.1.2. Анализ информационных задач и круга пользователей системы
2.2. Определение требований к операционной обстановке
2.3. Выбор СУБД и других программных средств
2.4. Логическое проектирование реляционной БД
2.4.1. Преобразование ER.диаграммы в схему базы данных
2.4.2. Составление реляционных отношений
2.4.3. Нормализация полученных отношений (до 4НФ)
2.4.3. Определение дополнительных ограничений целостности
2.4.4. Описание групп пользователей и прав доступа

Проектирование базы данных (БД) – одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы (ИС). В результате её решения должны быть определены содержание БД, эффективный для всех её будущих пользователей способ организации данных и инструментальные средства управления данными.
Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:
1. Корректность схемы БД, т.е. база должна быть гомоморфным образом моделируемой предметной области (ПО), где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных.
2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).
3. Эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных).
4. Защита данных (от аппаратных и программных сбоев и несанкционированного доступа).
5. Простота и удобство эксплуатации.
6. Гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.
Удовлетворение требований 1–4 обязательно для принятия проекта.

1. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация, сопровождение. Теория и практика, 2-е изд. : Пер. с англ. : Уч. пос. – М.: Изд. дом "Вильямс", 2000. – 1120 с.
2. Тиори Т., Фрай Дж. Проектирование структур баз данных : В 2-х кн.: Пер. с англ. – М.: Мир, 1985.
3. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – 2-е изд. – М.: Финансы и статистика, 1989. – 350 с.
4. Грабер М. Введение в SQL. – М.: 1998.

Дисциплина: Информатика, Программирование, Базы данных
Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 32 страниц
В избранное:

Министерство образования и науки Республики Казахстан
Казахский экономический университет им. Т. Рыскулова

Кафедра: Прикладная информатика

Курсовая работа
На тему: Проектирование реляционных баз данных

Выполнил: Абилкаир Ерлан
Студен: 3-го курса
Специальности: ИСвЭ 304 гр.
Проверила: ст. преподаватель
Неверова Е.Г

Алматы 2007 г.
СОДЕРЖАНИЕ
ЦЕЛИ И ЗАДАЧИ РАБОТЫ
1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
1.1. Общие положения
1.2 12 - правил Кода
1.3. Этапы проектирования базы данных
1.3.1. Инфологическое проектирование
1.3.2. Определение требований к операционной обстановке
1.3.3. Выбор СУБД и других программных средств
1.3.4. Логическое проектирование БД
1.3.5. Физическое проектирование БД
1.4. Особенности проектирования реляционной базы данных
1.4.1. Нормализация отношений
2. ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
2.1. Инфологическое проектирование
2.1.1. Анализ предметной области
2.1.2. Анализ информационных задач и круга пользователей системы
2.2. Определение требований к операционной обстановке
2.3. Выбор СУБД и других программных средств
2.4. Логическое проектирование реляционной БД
2.4.1. Преобразование ER–диаграммы в схему базы данных
2.4.2. Составление реляционных отношений
2.4.3. Нормализация полученных отношений (до 4НФ)
2.4.3. Определение дополнительных ограничений целостности
2.4.4. Описание групп пользователей и прав доступа

ЦЕЛИ И ЗАДАЧИ РАБОТЫ
Цель курсового проектирования – применение на практике знаний, полученных в
процессе изучения курса "Базы данных", и получение практических навыков
создания автоматизированных информационных систем (АИС), основанных на
базах данных.
1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
1.1. Общие положения
Проектирование базы данных (БД) – одна из наиболее сложных и ответственных
задач, связанных с созданием информационной системы (ИС). В результате её
решения должны быть определены содержание БД, эффективный для всех её
будущих пользователей способ организации данных и инструментальные средства
управления данными.
Основная цель процесса проектирования БД состоит в получении такого
проекта, который удовлетворяет следующим требованиям:
1. Корректность схемы БД, т.е. база должна быть гомоморфным образом
моделируемой предметной области (ПО), где каждому объекту предметной
области соответствуют данные в памяти ЭВМ, а каждому процессу –
адекватные процедуры обработки данных.
2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и
другие ресурсы вычислительной системы).
3. Эффективность функционирования (соблюдение ограничений на время
реакции системы на запрос и обновление данных).
4. Защита данных (от аппаратных и программных сбоев и
несанкционированного доступа).
5. Простота и удобство эксплуатации.
6. Гибкость, т.е. возможность развития и адаптации к изменениям
предметной области иили требований пользователей.
Удовлетворение требований 1–4 обязательно для принятия проекта.

1.2 Двенадцать правил Кодда

В статье, опубликованной в журнале "Computer World", Тэд Кодд сформулировал
двенадцать правил, которым должна соответствовать настоящая реляционная
база данных. Двенадцать правил Кодда приведены в табл. 1.1. Они являются
полуофициальным определением понятия реляционная база данных. Перечисленные
правила основаны на теоретической работе Кодда, посвященной реляционной
модели данных.

Таблица 1.1. Двенадцать правил Кодда, которым должна
соответствовать _
реляционная СУБД.
_
1. Правило информации. Вся информация в базе данных должна быть
предоставлена исключительно на логическом уровне и только одним
способом - в виде значений, содержащихся в таблицах.
2. Правило гарантированного доступа. Логический доступ ко всем и
каждому элементу данных (атомарному значению) в реляционной базе
данных должен обеспечиваться путём использования комбинации имени
таблицы, первичного ключа и имени столбца.
3. Правило поддержки недействительных значений. В настоящей
реляционной базе данных должна быть реализована поддержка
недействительных значений, которые отличаются от строки символов
нулевой длинны, строки пробельных символов, и от нуля или любого
другого числа и используются для представления отсутствующих
данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной
модели. Описание базы данных на логическом уровне должно быть
представлено в том же виде, что и основные данные, чтобы
пользователи, обладающие соответствующими правами, могли работать
с ним с помощью того же реляционного языка, который они применяют
для работы с основными данными.
5. Правило исчерпывающего подъязыка данных. Реляционная
система может поддерживать различные языки и режимы
взаимодействия с пользователем (например, режим вопросов и
ответов). Однако должен существовать по крайней мере один язык,
операторы которого можно представить в виде строк символов в
соответствии с некоторым четко определенным синтаксисом и который
в полной мере поддерживает следующие элементы:
— определение данных;
— определение представлений;
— обработку данных (интерактивную и программную);
— условия целостности;
— идентификация прав доступа;
— границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений. Все представления, которые
теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Возможность
работать с отношением как с одним операндом должна существовать
не только при чтении данных, но и при добавлении, обновлении и
удалении данных.
8. Правило независимости физических данных. Прикладные
программы и утилиты для работы с данными должны на логическом
уровне оставаться нетронутыми при любых изменениях способов
хранения данных или методов доступа к ним.
9. Правило независимости логических данных. Прикладные программы
и утилиты для работы с данными должны на логическом уровне
оставаться нетронутыми при внесении в базовые таблицы любых
изменений, которые теоретически позволяют сохранить нетронутыми
содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности. Должна
существовать возможность определять условия целостности,
специфические для конкретной реляционной базы данных, на
подъязыке реляционной базы данных и хранить их в каталоге, а не в
прикладной программе.
11. Правило независимости распространения. Реляционная СУБД не
должна зависеть от потребностей конкретного клиента.
12. Правило единственности. Если в реляционной системе есть
низкоуровневой язык (обрабатывающий одну запись за один раз), то
должна отсутствовать возможность использования его для того,
чтобы обойти правила и условия целостности, выраженные на
реляционном языке высокого уровня (обрабатывающем несколько
записей за один раз).

Правило 1 напоминает неформальное определение реляционной базы данных,
приведенное ранее.
Правило 2 указывает на роль первичных ключей при поиске информации в базе
данных. Имя таблицы позволяет найти требуемую таблицу, имя столбца
позволяет найти требуемый столбец, а первичный ключ позволяет найти строку,
содержащую искомый элемент данных.
Правило 3 требует, чтобы отсутствующие данные можно было представить с
помощью недействительных значений (NULL), которые описаны в главе 5.
Правило 4 гласит, что реляционная база данных должна сама себя описывать.
Другими словами, база данных должна содержать набор системных таблиц,
описывающих структуру самой базы данных. Эти таблицы описаны в главе 16.
Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных,
например SQL, хотя явно SQL в правиле не упомянут. Такой язык должен
поддерживать все основные функции СУБД — создание базы данных, чтение и
ввод данных, реализацию защиты базы данных и т.д.
Правило 6 касается представлений, которые являются виртуальными
таблицами, позволяющими показывать различным пользователям различные
фрагменты структуры базы данных. Это одно из правил, которые сложнее всего
реализовать на практике. Представления и проблемы их обновления описаны в
главе 14.
Правило 7 акцентирует внимание на том, что базы данных по своей природе
ориентированы на множества. Оно требует, чтобы операции добавления,
удаления и обновления можно было выполнять над множествами строк. Это
правило предназначено для того, чтобы запретить реализации, в которых
поддерживаются только операции над одной строкой.
Правила 8 и 9 означают отделение пользователя и прикладной программы от
низкоуровневой реализации базы данных. Они утверждают, что конкретные
способы реализации хранения или доступа, используемые в СУБД, и даже
изменения структуры таблиц базы данных не должны влиять на возможность
пользователя работать с данными.
Правило 10 гласит, что язык базы данных должен поддерживать
ограничительные условия, налагаемые на вводимые данные и действия, которые
могут быть выполнены над данными.
Правило 11 гласит, что язык базы данных должен обеспечивать возможность
работы с распределенными данными, расположенными на других компьютерных
системах. Распределенные данные и проблемы управления ими описаны в главе
20.
И, наконец, правило 12 предотвращает использование других возможностей
для работы с базой данных, помимо языка базы данных, поскольку это может
нарушить ее целостность.

1.3. Этапы проектирования базы данных
Процесс проектирования включает в себя следующие этапы:
1. Инфологическое проектирование.
2. Определение требований к операционной обстановке, в которой будет
функционировать информационная система.
3. Выбор системы управления базой данных (СУБД) и других инструментальных
программных средств.
4. Логическое проектирование БД.
5. Физическое проектирование БД.
Инфологический подход не предоставляет формальных способов моделирования
реальности, но он закладывает основы методологии проектирования баз данных.

1.3.1. Инфологическое проектирование
Основными задачами инфологического проектирования являются определение
предметной области системы и формирование взгляда на ПО с позиций
сообщества будущих пользователей БД, т.е. инфологической модели ПО.
Инфологическая модель ПО представляет собой описание структуры и динамики
ПО, характера информационных потребностей пользователей в терминах,
понятных пользователю и не зависимых от реализации БД. Это описание
выражается в терминах не отдельных объектов ПО и связей между ними, а их
типов, связанных с ними ограничений целостности и тех процессов, которые
приводят к переходу предметной области из одного состояния в другое.
Рассмотрим основные подходы к созданию инфологической модели предметной
области.
Функциональный подход к проектированию БД
Этот метод реализует принцип "от задач" и применяется тогда, когда известны
функции некоторой группы лиц иили комплекса задач, для обслуживания
информационных потребностей которых создаётся рассматриваемая БД.
Предметный подход к проектированию БД
Предметный подход к проектированию БД применяется в тех случаях, когда у
разработчиков есть чёткое представление о самой ПО и о том, какую именно
информацию они хотели бы хранить в БД, а структура запросов не определена
или определена не полностью. Тогда основное внимание уделяется исследованию
ПО и наиболее адекватному её отображению в БД с учётом самого широкого
спектра информационных запросов к ней.
Проектирование с использованием метода "сущность-связь"
Метод "сущность–связь" (entity–relation, ER–method) является комбинацией
двух предыдущих и обладает достоинствами обоих. Этап инфологического
проектирования начинается с моделирования ПО. Проектировщик разбивает её на
ряд локальных областей, каждая из которых (в идеале) включает в себя
информацию, достаточную для обеспечения запросов отдельной группы будущих
пользователей или решения отдельной задачи (подзадачи). Каждое локальное
представление моделируется отдельно, затем они объединяются.
Выбор локального представления зависит от масштабов ПО. Обычно она
разбивается на локальные области таким образом, чтобы каждая из них
соответствовала отдельному внешнему приложению и содержала 6-7 сущностей.
Сущность – это объект, о котором в системе будет накапливаться информация.
Сущности бывают как физически существующие (например, СОТРУДНИК или
АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).
Для сущностей различают тип сущности и экземпляр. Тип характеризуется
именем и списком свойств, а экземпляр – конкретными значениями свойств.
Типы сущностей можно классифицировать как сильные и слабые. Сильные
сущности существуют сами по себе, а существование слабых сущностей зависит
от существования сильных. Например, читатель библиотеки – сильная сущность,
а абонемент этого читателя – слабая, которая зависит от наличия
соответствующего читателя. Слабые сущности называют подчинёнными
(дочерними), а сильные – базовыми (основными, родительскими).
Для каждой сущности выбираются свойства (атрибуты). Различают:
1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты
имеют уникальное значение для сущностей данного типа и являются
потенциальными ключами. Они позволяют однозначно распознавать
экземпляры сущности. Из потенциальных ключей выбирается один первичный
ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по
которому чаще происходит обращение к экземплярам записи. Кроме того,
ПК должен включать в свой состав минимально необходимое для
идентификации количество атрибутов. Остальные атрибуты называются
описательными и заключают в себе интересующие свойства сущности.
2. Составные и простые атрибуты. Простой атрибут состоит из одного
компонента, его значение неделимо. Составной атрибут является
комбинацией нескольких компонентов, возможно, принадлежащих разным
типам данных (например, ФИО или адрес). Решение о том, использовать
составной атрибут или разбивать его на компоненты, зависит от
характера его обработки и формата пользовательского представления
этого атрибута.
3. Однозначные и многозначные атрибуты (могут иметь соответственно одно
или много значений для каждого экземпляра сущности).
4. Основные и производные атрибуты. Значение основного атрибута не
зависит от других атрибутов. Значение производного атрибута
вычисляется на основе значений других атрибутов (например, возраст
студента вычисляется на основе даты его рождения и текущей даты).
Спецификация атрибута состоит из его названия, указания типа данных и
описания ограничений целостности – множества значений (или домена), которые
может принимать данный атрибут.
Далее осуществляется спецификация связей внутри локального представления.
Связи могут иметь различный содержательный смысл (семантику). Различают
связи типа "сущность-сущность", "сущность-атрибут" и "атрибут-атрибут" для
отношений между атрибутами, которые характеризуют одну и ту же сущность или
одну и ту же связь типа "сущность-сущность".
Каждая связь характеризуется именем, обязательностью, типом и степенью.
Различают факультативные и обязательные связи. Если вновь порождённый
объект одного типа оказывается по необходимости связанным с объектом
другого типа, то между этими типами объектов существует обязательная связь
(обозначается двойной линией). Иначе связь является факультативной.
По типу различают множественные связи "один к одному" (1:1), "один ко
многим" (1:n) и "многие ко многим" (m:n). ER–диаграмма, содержащая
различные типы связей, приведена на рис. 1. Обратите внимание, что
обязательные связи на рис. 1 выделены двойной линией.

Рис.1. ER–диаграмма с примерами типов множественных связей
Степень связи определяется количеством сущностей, которые охвачены данной
связью. Пример бинарной связи – связь между отделом и сотрудниками, которые
в нём работают. Примером тернарной связи является связь типа экзамен между
сущностями ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Из последнего примера видно,
что связь также может иметь атрибуты (в данном случае это Дата проведения и
Оценка). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей
приведен на рис. 2.

Рис.2. Пример ER–диаграммы с однозначными и многозначными атрибутами
После того, как созданы локальные представления, выполняется их
объединение. При небольшом количестве локальных областей (не более пяти)
они объединяются за один шаг. В противном случае обычно выполняют бинарное
объединение в несколько этапов.
При объединении проектировщик может формировать конструкции, производные по
отношению к тем, которые были использованы в локальных представлениях.
Такой подход может преследовать следующие цели:
• объединение в единое целое фрагментарных представлений о различных
свойствах одного и того же объекта;
• введение абстрактных понятий, удобных для решения задач системы,
установление их связи с конкретными понятиями, использованными в
модели;
• образование классов и подклассов подобных объектов (например, класс
"изделие" и подклассы типов изделий, производимых на предприятии).
На этапе объединения необходимо выявить и устранить все противоречия.
Например, одинаковые названия семантически различных объектов или связей
или несогласованные ограничения целостности на одни и те же атрибуты в
разных приложениях. Устранение противоречий вызывает необходимость возврата
к этапу моделирования локальных представлений с целью внесения в них
соответствующих изменений.
По завершении объединения результаты проектирования являют собой
концептуальную инфологическую модель предметной области. Модели локальных
представлений – это внешние инфологические модели.
1.3.2. Определение требований к операционной обстановке
На этом этапе производится оценка требований к вычислительным ресурсам,
необходимым для функционирования системы, определение типа и конфигурации
конкретной ЭВМ, выбор типа и версии операционной системы. Объём
вычислительных ресурсов зависит от предполагаемого объёма проектируемой
базы данных и от интенсивности их использования. Если БД будет работать в
многопользовательском режиме, то требуется подключение её к сети и наличие
соответствующей многозадачной операционной системы.
1.3.3. Выбор СУБД и других программных средств
Выбор СУБД является одним из важнейших моментов в разработке проекта БД,
так как он принципиальным образом влияет на весь процесс проектирования БД
и реализацию информационной системы. Теоретически при выборе СУБД нужно
принимать во внимание десятки факторов. Но практически разработчики
руководствуются лишь собственной интуицией и несколькими наиболее важными
критериями, к которым, в частности, относятся:
• тип модели данных, которую поддерживает данная СУБД, её адекватность
потребностям рассматриваемой предметной области;
• характеристики производительности системы;
• запас функциональных возможностей для дальнейшего развития ИС;
• степень оснащённости системы инструментарием для персонала
администрирования данными;
• удобство и надежность СУБД в эксплуатации;
• стоимость СУБД и дополнительного программного обеспечения.
1.3.4. Логическое проектирование БД
На этапе логического проектирования разрабатывается логическая структура
БД, соответствующая логической модели ПО. Решение этой задачи существенно
зависит от модели данных, поддерживаемой выбранной СУБД.
Результатом выполнения этого этапа являются схемы БД концептуального и
внешнего уровней архитектуры, составленные на языках определения данных
(DDL, Data Definition Language), поддерживаемых данной СУБД.

1.3.5. Физическое проектирование БД
Этап физического проектирования заключается в увязке логической структуры
БД и физической среды хранения с целью наиболее эффективного размещения
данных, т.е. отображении логической структуры БД в структуру хранения.
Решается вопрос размещения хранимых данных в пространстве памяти, выбора
эффективных методов доступа к различным компонентам "физической" БД.
Результаты этого этапа документируются в форме схемы хранения на языке
определения данных (DDL). Принятые на этом этапе решения оказывают
определяющее влияние на производительность системы.
Одной из важнейших составляющих проекта базы данных является разработка
средств защиты БД. Защита данных имеет два аспекта: защита от сбоев и
защита от несанкционированного доступа. Для защиты от сбоев разрабатывается
стратегия резервного копирования. Для защиты от несанкционированного
доступа каждому пользователю доступ к данным предоставляется только в
соответствии с его правами доступа.
1.4. Особенности проектирования реляционной базы данных
Проектирование реляционной базы данных проходит в том же порядке, что и
проектирование БД других моделей данных, но имеет свои особенности.
Проектирование схемы БД должно решать задачи минимизации дублирования
данных и упрощения процедур их обработки и обновления. При неправильно
спроектированной схеме БД могут возникнуть аномалии модификации данных. Они
обусловлены отсутствием средств явного представления типов множественных
связей между объектами ПО и неразвитостью средств описания ограничений
целостности на уровне модели данных.
Для решения подобных проблем проводится нормализация отношений.
1.4.1. Нормализация отношений
В рамках реляционной модели данных Э.Ф. Коддом (E.F. Codd) был разработан
аппарат нормализации отношений и предложен механизм, позволяющий любое
отношение преобразовать к третьей нормальной форме.
Нормализация схемы отношения выполняется путём декомпозиции схемы.
Декомпозицией схемы отношения R называется замена её совокупностью схем
отношений Аi таких, что
,
и не требуется, чтобы отношения Аi были непересекающимися.
Введём понятие простого и сложного атрибута. Простой атрибут – это атрибут,
значения которого атомарны (т.е. неделимы). Сложный атрибут может иметь
значение, представляющее собой конкатенацию нескольких значений одного или
разных доменов. Аналогом сложного атрибута может быть агрегат или
повторяющийся агрегат данных.
Первая нормальная форма (1НФ).
Отношение приведено к 1НФ, если все его атрибуты простые.
Для того чтобы привести к 1НФ отношение, содержащее повторяющиеся атрибуты
(агрегаты), нужно построить декартово произведение всех повторяющихся
агрегатов с кортежами, к которым они относятся. Для идентификации кортежа в
этом случае понадобится составной ключ, включающий первичный ключ исходного
отношения и идентифицирующие атрибуты агрегатов.
Введём понятие функциональной зависимости. Пусть X и Y – атрибуты
некоторого отношения. Если в любой момент времени каждому значению X
соответствует единственное значение Y, что Y функционально зависит от X
(X→Y). Атрибут (группа атрибутов) Х называется детерминантом.
В нормализованном отношении все неключевые атрибуты функционально зависят
от ключа отношения. Говорят, что неключевой атрибут функционально полно
зависит от составного ключа, если он функционально зависит от ключа, но не
находится в функциональной зависимости ни от какой части составного ключа.
Вторая нормальная форма (2НФ).
Отношение находится во 2НФ, если оно приведено к 1НФ и каждый
неключевой атрибут функционально полно зависит от составного
ключа.
Для того чтобы привести отношение ко 2НФ, нужно:
• построить его проекцию, исключив атрибуты, которые не находятся в
функционально полной зависимости от составного ключа;
• построить дополнительно одну или несколько проекций на часть
составного ключа и атрибуты, функционально зависящие от этой части
ключа.
Рассмотрим понятие транзитивной зависимости. Пусть X, Y, Z – атрибуты
некоторого отношения. При этом X→ Y и Y→ Z, но обратное соответствие
отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят,
что Z транзитивно зависит от X
(X→→Z).
Третья нормальная форма (3НФ).
Отношение находится в 3НФ, если оно находится во 2НФ и каждый
неключевой атрибут нетранзитивно зависит от первичного ключа.
Для того чтобы привести отношение к 3НФ, нужно:
• построить его проекцию, исключив транзитивно зависящие от ключа
атрибуты;
• построить дополнительно одну или несколько проекций на детерминанты
исходного отношения и атрибуты, функционально зависящие от них.
Введём понятие многозначной зависимости. Многозначная зависимость
существует, если заданным значениям атрибута X соответствует множество,
состоящее из нуля (или более) значений атрибута Y (X–Y).
Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной
называется такая многозначная зависимость X–Y, для которой Y ⊂ €X или X
U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная
зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не
выполняется, то такая зависимость называется нетривиальной.
Четвертая нормальная форма (4НФ).
Отношение находится в 4НФ, если оно находится в 3НФ и в нём
отсутствуют нетривиальные многозначные зависимости.
Для того чтобы привести отношение к 4НФ, нужно построить две или более
проекции исходного отношения, каждая из которых содержит ключ и одну из
многозначных зависимостей.
Нормализация отношений позволяет сократить дублирование данных, но
появление новых отношений порождает проблему поддержки семантической
целостности данных.

2. ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

В качестве примера возьмем базу данных компании, которая занимается
издательской деятельностью.

2.1. Инфологическое проектирование

2.1.1. Анализ предметной области

База данных создаётся для информационного обслуживания редакторов,
менеджеров и других сотрудников компании. БД должна содержать данные о
сотрудниках компании, книгах, авторах, финансовом состоянии компании и
предоставлять возможность получать разнообразные отчёты.
В соответствии с предметной областью система строится с учётом следующих
особенностей:
• каждая книга издаётся в рамках контракта;
• книга может быть написана несколькими авторами;
• контракт подписывается одним менеджером и всеми авторами книги;
• каждый автор может написать несколько книг (по разным контрактам);
• порядок, в котором авторы указаны на обложке, влияет на размер
гонорара;
• если сотрудник является редактором, то он может работать одновременно
над несколькими книгами;
• у каждой книги может быть несколько редакторов, один из них –
ответственный редактор;
• каждый заказ оформляется на одного заказчика;
• в заказе на покупку может быть перечислено несколько книг.
Выделим базовые сущности этой предметной области:
• Сотрудники компании. Атрибуты сотрудников – ФИО, табельный номер, пол,
дата рождения, паспортные данные, ИНН, должность, оклад, домашний
адрес и телефоны. Для редакторов необходимо хранить сведения о
редактируемых книгах; для менеджеров – сведения о подписанных
контрактах.
• Авторы. Атрибуты авторов – ФИО, ИНН (индивидуальный номер
налогоплательщика), паспортные данные, домашний адрес, телефоны. Для
авторов необходимо хранить сведения ... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.