Учебное пособие «Теория построения баз данных»


ГОСУДАРСТВЕННОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ТУЛЬСКОЙ ОБЛАСТИ
«ТУЛЬСКИЙ ЭКОНОМИЧЕСКИЙ КОЛЛЕДЖ»






УЧЕБНОЕ ПОСОБИЕ

ПМ 02.Разработка и администрирование баз данных

МДК 02.02.Технология разработки и защиты баз данных


Тема: Базы данных

(для использования с дидактической рабочей тетрадью)

для специальности: 09.02.03 «Программирование в компьютерных системах»



Автор: Голосова А.М



Щекино 2016














Сокращения
БД- база данных
БнД- банк данных
РО- реквизит основание
РП- реквизит признак
РОИ- реквизит основание исходный
РОР- реквизит основание результатный
РПС- реквизит признак справочный
РПГ- реквизит признак группировочный
СУБД- система управления базой данных
СЕИ- составная единица информации
ФЗ – функциональная зависимость
ЭИС – экономическая информационная система



























Содержание
Стр.
Введение
4

1.Теория информации
5

1.1.Единицы информации
5

1.2. База данных. СУБД и её место в системе программного обеспечения ЭВМ.
7

2. Модели данных
9

2.1. Информационные модели данных
9

2.2. Логические модели баз данных
11

2.3. Типы взаимосвязей в модели
18

3. Реляционная модель данных
19

3.1. Основные операции реляционной алгебры
19

3.2. Требования, предъявляемые к базе данных
19

3.3.Достоинства и недостатки реляционных баз данных
19

3.4. Типы ключей
19

4. Нормализация отношений
21

4.1. Нормальные формы
26

4.2. Вторая нормальная форма
26

4.3 Третья нормальная форма
27

4.4. Нормальная форма Бойса-Кодда
28

4.5. Четвертая нормальная форма
29

Список литературы

31











Введение

СУБД - один из самых "долгоживущих" образцов программ: их жизненный цикл может составлять 1020 и более лет.
Сформировавшееся к настоящему времени программное обеспечение ПЭВМ представлено десятками коммерческих программных продуктов, позволяющих создавать и эксплуатировать системы БД практически на всех массовых моделях машин и предназначенных для использования в обстановке различных операционных систем.
Этот инструментарий настолько многообразен, что способен удовлетворять потребности пользователей самых различных категорий от случайного пользователя, для которого обращение к рассматриваемой сфере единичный эпизод, до профессионала высокой квалификации в области разработки систем БД.
Подавляющее большинство СУБД для персональных ЭВМ составляют системы реляционного типа или системы, квалифицированные их разработчиками как реляционные на том основании, что они оперируют базами данных реляционной структуры. Здесь уместно вспомнить Э.Кодда, который предложил считать реляционной такую СУБД, которая не только поддерживает реляционную структуру данных, но и реализует, по крайней мере, операции селекции, проекции и соединения отношений .
Столь массовый выбор реляционной модели данных разработчиками программных средств, для ПЭВМ определялся удобством этой модели для пользователя, а также сравнительной простотой ее реализации.
1. Теория информации

1.1. Единицы информации
Все средства обработки информации на конкретном экономическом объекте объединяются понятием "экономическая информационная система". Элементы реального мира, о которых хранится информация в системе, называют объектами. Объект может быть материальным (служащий, изделие) или нематериальным ( схема документооборота). Компоненты информационной системы - это база данных, концептуальная схема и система управления базами данных, образующие вместе систему хранения и манипулирования данными. В окружающем нас мире выделяются материальные системы различного назначения. Все, что происходит в процессе функционирования материальных систем, может быть описано в форме сообщений. Появление сообщений о событиях, происходящих в материальной системе, представляет собой информационное отображение материальных процессов. Сообщение- набор атрибутов, достаточный для характеристики объекта, процесса или явления. Сообщение может быть выражено на естественном языке, однако часто применяют форматированные сообщения, когда выделяются опорные свойства (параметры) происходящего события и в сообщении приводятся названия свойств и их значения.
Пример сообщения
На склад #2 1.02.08 поступили генераторы от завода «Динамо» в количестве 50 шт. по цене 200 руб.
ФОРМАТИРОВАННЫЙ ВАРИАНТ ЭТОГО СООБЩЕНИЯ:
Название атрибута Значение Название атрибута Значение
Получатель склад #2 Количество 50 шт
Отправитель завод «Динамо» Дата 1.02.05
Изделие генераторы Цена 200 руб
Таких сообщений о поступлении изделий на склады предприятия появляется достаточно много. Они совпадают по названиям параметров и различаются по значениям параметров. В этом случае удобно представление в виде таблицы.

Многие сообщения легко разделяются на компоненты и представляются в форматированном виде. Форматированные сообщения - это наиболее массовый вид сообщений, хранимых и обрабатываемых в ЭИС. Вместе с тем существует экономическая информация, которую практически невозможно форматировать, например приказы по предприятию. Сообщения в БД обычно являются форматированными и хранятся в виде единиц информации
Единицей информации называется набор символов, которому придается определенный смысл. Минимально необходимы две единицы информации - атрибут и составная единица информации
Атрибутом называется информационное отображение отдельного свойства нeкoтopoгo объекта, процесса или явления. Любое сообщение записывается в форматированном виде как указание свойств (параметров) предметов, о которых мы говорим. Поэтому информационное отображение любого явления представляет собой набор соответствующим образом подобранных атрибутов.
Атрибут соответствует понятию переменной в языках программирования и понятию реквизита в бухгалтерском учете. Атрибут характеризуется именем и значением. Именем атрибута называется его условное обозначение в процессах обработки данных.
Значением атрибута называется величина, характеризующая некоторое свойство объекта, явления, процесса в конкретных обстоятельствах. Все допустимые значения атрибута образуют множество, называемое доменом этого атрибута. Качественные свойства объекта отображают атрибуты-признаки, а количественные атрибуты-основания.
Составная единица информации представляет собой набор из атрибутов и, возможно, других СЕИ. Простейшими СЕИ являются таблицы.
Документ- материальный носитель информации, содержащий оформленные в установленном порядке сообщения и имеющий юридическую силу. Показатель- полное описание количественного параметра, характеризующего объект или процесс и состоящий из одного атрибута- основания и ряда атрибутов признаков. Показатель – минимальная СЕИ, которая сохраняет информативность и достаточна для образования документа. Файл- группа экономических показателей с одинаковым составом атрибутов- признаков. СЕИ позволяет создавать произвольные комбинации из атрибутов. База данных ЭИС хранится в запоминающих устройствах вычислительной системы (ЭВМ). Хранимые представления данных очень часто не соответствуют первоначальному множеству форматированных сообщений.








Рисунок 1. Фрагмент документа.
Концептуальная схема (от слова concept - понятие) представляет собой описание структуры всех единиц информации, хранящихся в БД. Под структурой понимается вхождение одних единиц информации в состав других единиц информации.
1.2. База данных.
СУБД и её место в системе программного обеспечения ЭВМ.

База данных- именованная совокупность взаимосвязанных данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области, используемых в несколькими пользователями и хранящимися с определенной избыточностью.
База данных- совокупность сведений, относящихся к определенной теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности в целом и по частям.
Предметной областью называются элементы материальной системы, информация о которых хранится и обрабатывается в ЭИС.
База данных- один или несколько файлов данных, предназначенных для хранения, изменения и обработки больших объемов взаимосвязанной информации.
База данных- объективная форма представления и организации совокупности данных, систематизированная таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.(
База данных- совокупность связанных между собой таблиц.
База данных - это набор сообщений, которые являются истинными для соответствующей материальной системы и непротиворечивы по отношению друг к другу и к концептуальной схеме.
База данных- информационная модель предметной области.
Системой управления базой данных(СУБД) называется комплекс программ, обеспечивающий централизованное хранение, накопление, модификацию и выдачу данных, входящих в БД.
СУБД- совокупность языковых и программных средств, предназначенных для создания , ведения и совместного использования БД многими пользователями.
Банк данных- система специально организованных данных, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоцелевого использования данных.
База данных предполагает централизованное управление данными, что обеспечивает ряд преимуществ:
сокращение избыточности хранимых данных благодаря однократному хранению каждого сообщения в базе данных,
совместное использование хранимых данных всеми пользователями ЭИС,
обеспечение процедур проверки достоверности информации и процедур ограничения доступа к данным,
совмещение требований к использованию БД со стороны различных пользователей ЭИС.
Пользователей БД можно подразделить на пять типов:
случайные пользователи, взаимодействие которых с ЭИС не обусловлено их служебными обязанностями,
Параметрические(конечные) пользователи, которые работают с ЭИС повседневно, в соответствии с четко определенной областью деятельности, по регламентированным процедурам,
аналитики и исследователи, информационные потребности которых непредсказуемы (в отличие от параметрических пользователей);
прикладные программисты, которые разрабатывают программы для реализации запросов к базе данных. Эти программы используются в основном параметрическими пользователями;
системные программисты, которые разрабатывают служебные программы, расширяющие возможности операционной системы ЭВМ и СУБД, например программы разграничения доступа к данным, проверки достоверности данных, восстановления базы данных после сбоя в работе ЭВМ, программы печати документов и т.п.
Предполагается, что в управлении базой данных принимает участие специальное должностное лицо - администратор базы данных
Современным направлением развития информационного обеспечения производственных и бизнес - процессов являются CALS – технологии. Они направлены на создание единого информационного пространства, основу которых составляют интегрированные базы данных. В России принят адекватный аналог CALS- Информационная поддержка жизненного цикла изделий (ИПИ).
2. Модели данных

2.1. Информационные модели данных


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

Иерархическая модель базы данных

Обычно при работе с деревом выделяю какую-то конкретную вершину, определяют ее как корень дерева и рассматривают особо - в эту вершину не заходит ни одно ребро. В этом случае дерево становится ориентированным 
Корневое дерево как ориентированный граф можно определить следующим образом:
1) имеется единственная особая вершина, называемая корнем, в которую не заходит ни одно ребро;
2) во все остальные вершины заходит только одно ребро, а исходит произвольное количество ребер;
3) нет циклов.
Любой узел дерева является корнем некоторого поддерева, содержащегося в полном дереве. Число поддеревьев узла называют степенью узла. Узел называется концевым, если он имеет нулевую степень. Иногда концевые узлы, называют листьями, а ребра - ветвями. Узел, не являющийся ни корнем, ни концевым узлом, называется узлом ветвления.
Таким образом, иерархическая древовидная структура, ориентированная от корня, удовлетворяет следующим условиям:
- иерархия всегда начинается с корневого узла;
- на первом уровне (i = 1, самый верхний уровень иерархии дерева) может находиться только один узел - корневой;
- на нижних уровнях ( i =2, 3, ..., n) находятся порожденные (зависимые) узлы;
- каждый порожденный узел, находящийся на уровне i, связан только с одним непосредственно исходным узлом (непосредственным родительским узлом), находящимся на более верхнем уровне (i - 1) иерархии дерева;
- каждый исходный узел может иметь один или несколько непосредственно порожденных узлов, которые называются подобными;
- доступ к каждому порожденному узлу выполняется через его непосредственно исходный узел;
- существует единственный иерархический путь доступа к любому узлу, начиная от корня дерева(рис. 2)
корень


исходный узел

порожденный узел

единственный путь доступа к узлу I

узлы, листья


Рисунок 2. Пример иерархического дерева

Если дерево в каждом узле имеет одинаковое число ветвей, а процесс включения новых ветвей в узлы идет сверху вниз, а на каждом уровне дерева слева направо, дерево называется – сбалансированным, упорядоченным. Дерево, в котором допускается не более двух ветвей для одного узла, называется двоичным. Дерево - пример двумерного упорядочивания. Основные внутренние ограничения иерархической модели данных: 1) все типы связей функциональные, т. е. 1: 1, 1: М, М: 1; 2) структура связей древовидная.

Сетевая модель базы данных
Сетевые модели данных, базируются на использовании графовой формы представления данных. В графической диаграмме схемы базы данных вершины графа используются для интерпретации типов сущностей, а дуги – типов связей между типами сущностей. При реализации каждая вершина графа представляется совокупностью описаний экземпляров сущности соответствующего типа. Сеть - связный неориентированный граф, который реализует связь 1:1, 1:N, N:M. Сеть - пример произвольного упорядочивания. Сеть может иметь:
отношения между элементами в виде двунаправленной стрелки,
данные пересечения ( один элемент связан с совокупностью других элементов),
циклы (предшественник узла является его последователем),
петли ( элемент связан с элементами того же типа).

Реляционная модель данных
В основе реляционной модели используется понятие «отношения», представляющего собой подмножество декартова произведения доменов.
Домен - это некоторое множество элементов, например множество целых чисел или множество допустимых значений, которые может принимать объект по некоторому свойству, и т. п.
Декартовым произведением доменов D1, D2, ..., Dk
D= D1 Х D2 Х ...Х Dk
где D1 = {d1.1, d1.2, ..., d1.i, ..., d1.n, },
D2= {d2.1, d2.2, ..., d2.i.. ..., d2.n.}, ...,
Dk = {dk.l, dk.2, ..., dk.ik ' .,., dk.nk}'
называется множество всех кортежей длины k, т. е. состоящих из k элементов - по одному из каждого домена
Пример. Если D1 ={A, 2), D2 = {В, С}, Dз ={4, 5, D}, то k=3 и соответственно декартово произведение
D = D1 Х D2 Х D3 = {(А, В, 4), (А, В, 5), (А, В, D), (А, С, 4), (А, С, 5), (А, С, D), (2, В, 4), (2, В, 5),(2, В, D), (2, С, 4), (2, С, 5), (2, С, D)}
Отношением R на множествах D1, D2, ..., Dk называется подмножество декартова произведения D1 Х D2 Х ...Х Dk. Отношение R, определенное на множествах D1, D2 ,... Dk (причем не обязательно, чтобы эти множества были различными), есть некоторое множество кортежей арности «k»: (dl.i, d2.i, ..., di.ik ), таких, что d1.i принадлежит D1, d2.i -D2 и т. д.:RHYPER13 EMBED Equation.3 HYPER14HYPER15 D1 Х D2 Х ...Х Dk Элементами отношения являются кортежи. Арность ( степень ) кортежа определяет арность( степень ) отношения. Отношение арности 1 называют унарным, арности 2 - бинарным, арности 3 - тернарным, арности «k» k-арным. Количество кортежей в отношении называется кардинальностью. Поскольку отношение есть множество, то в нем не должны встречаться одинаковые кортежи. Порядок кортежей в отношении несущественен.
Модель «сущность-связь»

Модель «сущность-связь» или Entity - Relationship (ER) представляет собой обобщение реляционной модели данных путем разделения отношений, описывающих предметную область на две группы- сущностей и связей. Она положена в основу значительного количества коммерческих CASE- продуктов, которые поддерживают полный цикл разработки СУБД или отдельные его стадии. Ключевыми элементами модели «сущность-связь» являются сущности, атрибуты, идентификаторы и связи.
Сущность - это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Примерами сущностей могут служить СОТРУДНИК , КЛИЕНТ , ПРОДАВЕЦ или ПРОДУКТ.
Сущности одного и того же типа группируются в классы сущностей. Так, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК. В тексте классы сущностей обозначаются заглавными буквами.
Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей - это совокупность однотипных сущностей, и описывается он структурой или форматом сущностей, его составляющих. Экземпляр сущности представляет конкретную сущность, такую как КЛИЕНТ 12345; он описывается значениями атрибутов данной сущности. Обычно класс сущностей содержит множество экземпляров сущности. Например, класс КЛИЕНТ содержит множество экземпляров - по одному на каждого клиента, о котором имеется запись в базе данных
У сущностей есть атрибуты, или, как их иногда называют, свойства, которые описывают характеристики сущности. Примерами атрибутов могут служить ИмяСотрудника, ДатаНайма и КодКвалификации. В тексте для записи имен атрибутов используются как прописные, так и строчные буквы. В модели «сущность-связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты
Исходное определение модели «сущность-связь» включает в себя композитные атрибуты и многозначные атрибуты. В качестве примера композитного
атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером многозначного атрибута может служить атрибут ДоверенноеЛицо сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента. Атрибут может быть одновременно и композитным, и многозначным - например, композитный атрибут Телефон, состоящий из группы атрибутов {КодРегиона, МестныйНомер}, будучи многозначным, позволяет иметь в базе данных несколько телефонных номеров одного и того же лица. В большинстве версий модели «сущность-связь» однозначные композитные атрибуты игнорируются, и требуется, чтобы многозначные атрибуты (будь они составные или нет) преобразовывались в сущности.
Экземпляры сущностей имеют идентификаторы - атрибуты, с помощью которых эти экземпляры именуются, или идентифицируются. Например, экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по атрибутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника. Такие атрибуты, как Зарплата или ДатаНайма, вряд ли могут служить идентификаторами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атрибуты не способны однозначно указать на конкретного сотрудника. Точно так же сущности класса КЛИЕНТ могут идентифицироваться по атрибутам НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут идентифицироваться по атрибуту НомерЗаказа.
Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным либо не уникальным. Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности. Если идентификатор является не уникальным, его значение будет указывать на некоторое множество экземпляров. ТабельныйНомер является, скорее всего, уникальным идентификатором, а ИмяСотрудника - неуникальным. Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами. Примерами могут служить идентификаторы вида {КодРегиона, МестныйНомер}, {НазваниеПроекта, НазваниеЗадачи} и {Имя, Фамилия, ДобавочныйНомерТелефона}.
Взаимоотношения сущностей выражаются связями. Модель «сущность-связь» включает в себя классы связей и экземпляры связей. Классы связей выражают взаимоотношения между классами сущностей, а экземпляры связи -



Продавец-заказ Родитель


Рис. 3. Различные степени связей

взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты. Класс связей может соединять несколько классов сущностей. Число
классов сущностей, участвующих в связи, называется степенью связи.
Схемы, изображенные на рис. 3, называются диаграммами «сущность-связь». Классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба. Имя сущности указывается внутри прямоугольника, а имя связи указывается рядом с ромбом. Если сущность обязана участвовать в связи (рис. 4), на линию связи помещают перпендикулярную черту. Если сущность может (но не обязана) участвовать в связи, на линию связи помещают овал.

















Рисунок 4. Диаграмма «сущность-связь»
В модели «сущность-связь» определен особый тип сущности, называемый слабой сущностью. К слабым сущностям относятся такие сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью. Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных отдела кадров с классами сущностей СОТРУДНИК и ПОДЧИНЕННЫЙ. Предположим, существует правило, что экземпляр сущности СОТРУДНИК может существовать, не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ, но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо сущностью класса СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой. Это означает, что запись о сущности ПОДЧИНЕННЫЙ может появиться в базе данных только в том случае, если эта сущность имеет связь с какой-либо сущностью класса СОТРУДНИК.





2.3. Типы взаимосвязей в модели


На практике часто используются связи, устанавливающие различные виды соответствия между объектами связанных типов,- 1:1,1:N, M;N.
Связь «один к одному» означает, что каждому экземпляру первого объекта соответствует только один экземпляр второго объекта.
Связь «один ко многим » означает, что каждому экземпляру первого объекта соответствует несколько экземпляров второго объекта.
Связь «многие ко многим » означает, что каждому экземпляру первого объекта соответствует несколько экземпляров второго объекта и наоборот.
Объекты СТУДЕНТ И СТИПЕНДИЯ связаны отношением «один к одному».
Объекты ГРУППА И СТУДЕНТ связаны отношением «один ко многим ». Объекты СТУДЕНТ И ПРЕПОДАВАТЕЛЬ связаны отношением «многие ко многим ».
В реляционной модели объекты представлены в виде таблиц. При взаимосвязи «многие ко многим » одна из таблиц будет избыточной. Для удаления избыточности следует построить таблицу перекрестных ссылок и модифицировать избыточную таблицу.
Таблица1. «Клиент» Таблица 2. «Продавец»




Таблица3. Перекрестные ссылки







3. Реляционная модель данных

3.1. Основные операции реляционной алгебры

Самостоятельная работа с книгой [1], с 85-90

3.2. Требования, предъявляемые к базе данных

Самостоятельная работа с книгой [1], с 11-13

3.3 . Достоинства и недостатки реляционных баз данных

Реляционная модель данных в настоящее время является промышленным стандартом. Она уменьшает дублирование данных, предотвращает проблемы , СВЯЗАННЫЕ СО вставкой и удаления данных.
В некоторых случаях нормализация нежелательна.
Нормализованные схемы неестественны.
Когда исходная таблица разбивается на две или более возникает необходимость в дополнительной обработке при последующем их объединении.
Всегда необходимо контролировать ограничения ссылочной целостности.

3.4. Типы ключей

Ключ - это один или несколько столбцов, идентифицирующие строку отношения. Ключ может быть уникальным или неуникальным. Ключ, содержащий два или более атрибута, называется композитным или составным ключом. Уникальных ключей может быть несколько. При проектировании базы данных один из этих уникальных идентификаторов необходимо выбрать на роль первичного ключа. Прочие уникальные ключи называются ключами- кандидатами, вторичными или вероятными, поскольку они являются кандидатами на роль первичного ключа. Вероятным ключом отношения называется такое множество атрибутов, что каждое сочетание их значений встречается только в одной строке отношения, и никакое подмножество атрибутов этим свойством не обладает. Вероятных ключей в отношении может быть несколько.
С помощью функциональных зависимостей определяется понятие ключа отношения, точнее ряд разновидностей ключей – вероятные(ключи-кандидаты), первичные и вторичные.
Таблица 4
ZEN
RAM
AST
SPIM
BIG


31
dwa
wii
73


21
bun
cup
40

30
30
mun
lam
58


31
sab
wii
40


30
sab
irt
38

Можно утверждать, что вероятным ключом отношения является атрибут ZEN (значения в столбце ZEN не повторяются). Кроме того, еще один вероятный ключ представлен парой атрибутов RAM, АSТ.
Когда в отношении присутствует несколько вероятных ключей, одновременное слежение за ними очень затруднено и целесообразно выбрать один из них в качестве основного (первичного). Первичным ключом отношения называется такой вероятный ключ, по значениям которого производится контроль достоверности информации в отношении. Если найдена группа атрибутов, которая функционально определяет все атрибуты отношения по отдельности, и эту группу нельзя сократить, то найден первичный ключ отношения. Применительно к экономической информации в подавляющем большинстве случаев отношения, полученные из существующих экономических документов, содержат единственный вероятный ключ, который является и первичным ключом. Это объясняется тем, что содержимое экономических документов понимается всеми пользователями одинаково. Первичный ключ часто называется просто ключ.
Суррогатный ключ- уникальный идентификатор, используемый в качестве ключа отношения( счетчик в Access). Это короткие числа, которые никогда не меняются, т.е. идеальные первичные ключи. С другой стороны его значения не имеют смысла для пользователя (в отчетах их опускают) и может получиться путаница при построении запросов. На практике имеются проектировщики, которые используют суррогатный ключ, и проектировщики, которые пользуются информативными первичными ключами.

4. Нормализация отношений
Реляционная модель является промышленным стандартом хранения и обработки информации в базах данных. Нормализация - методика преобразования отношений, имеющих нежелательные свойства для улучшения их характеристик.
Реляционные СУБД хранят данные в форме отношений, которые представляют собой особую разновидность таблиц. Оmношенuем называется двухмерная таблица, обладающая характеристиками
Строки содержат данные о сущности.
Столбцы содержат данные об атрибутах сущности.
Ячейки таблицы содержат одиночные значения, повторяющиеся элементы в ячейке недопустимы
Все записи в одном столбце имеют один и тот же тип.
Каждый столбец имеет уникальное имя.
Порядок следования столбцов не важен.
Порядок следования строк не важен.
Не может быть двух идентичных строк.
Таблица должна иметь ключ
Таблица 5. Таблица, где в одной ячейке имеется несколько записей

Номер Сотруд.
Имя
Фамилия
Отдел
Адрес
Эл.Почты
Телефон

100
Джерри
Джонсон
Бухгалтерия
JJ@somewhere.com
236-9987

200

Мэри
Абернати
Финансы
MA@somewhere.com
444-8898

300
Лиз
Сматерс
Финансы
LS@somewhere.com
777 -0098

400
Том
Карутерс
Бухгалтерия
TC@somewhere.com
236-9987





Факс
266-9987





Домашний телефон:
555-7171

500
Том

Джексон
Произ-во
Т J@somewhere.com
444-9980

600
Элеонора

Калдера
Юридич.
EC@somewhere.com
767-0900






Факс
236-9987



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

Таблица 6. Соотношение понятий
Традиционные системы
Теория баз данных
FoxPro/Access

Таблица
Отношение
Таблица

Строка
Кортеж
Запись

Столбец
Атрибут
Поле

Ячейка
Значение атрибута
Значение поля



К сожалению, не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может иметь неэффективную или неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиями модификации. Аномалии могут быть устранены путем разбиения исходного отношения на два или более новых отношения. В большинстве случаев переопределенные, или нормализованные, отношения являются более предпочтительными.
Рассмотрим отношение СЕКЦИЯ на рис. 5. Если мы удалим строку с данными о студенте номер 100, мы потеряем информацию не только о том, что этот студент является лыжником, но и о том, что абонемент в секцию лыж стоит $200. Это называется аномалией удаления. Суть ее в том, что удаляя информацию об одной сущности (студент с номером 100 является лыжником), мы теряем факты, относящиеся к другой сущности (плата за абонемент в секцию лыж составляет $200). Выполнив одну операцию удаления, мы теряем информацию о двух сущностях. СЕКЦИЯ (HoмeрCтvдeнтa, Секция, Плата) Секция-Плата (Секция, Плата)
Секция-Студент (Секция, HoмeрCтvпeнтa)
Секция Секция-Студент Секция-Плата
Номер
Студента
Секция
Плата

100
Лыжи
200

150
Плавание
50

175
Сноуборд
50

200
Плавание
50


Номер
Студента
Секция

100
Лыжи

150
Плавание

175
Сквош

200
Плавание


Секция
Плата

Лыжи
200

Плавание
50

Сквош
50




Рисунок 5.Аномалия удаления и вставки


На примере того же самого отношения можно продемонстрировать аномалию вставки. Допустим, нам нужно записать в базу данных информацию о том, что абонемент в секцию подводного плавания стоит $175. НО мы не можем ввести эти сведения в отношение СЕКЦИЯ, пока хотя бы один студент не запишется в секцию подводного плавания. Это ограничение выглядит глупо. Почему для того, чтобы указать стоимость абонемента, требуется ждать, пока кто-нибудь не запишется в секцию? Это ограничение называется аномалией вставки. Суть его в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.
Аномалии, присутствующие в отношении на рис. 5, можно интуитивно описать следующим образом. Проблемы возникают из-за того, что отношение СЕКЦИЯ содержит факты, относящиеся к двум различным темам, а именно:
1) кто из студентов какую секцию посещает;
2) какова абонементная плата в каждой из секций.
Суть процесса нормализации состоит в следующем. Каждое нормализованное отношение должно иметь одну-единственную тему. Любое отношение, затрагивающее две или более темы, следует разбить на два или более отношения, у каждого из которых будет только одна тема. Когда мы обнаруживаем отношение с аномалиями модификации, мы устраняем эти аномалии, разбивая отношение на два или более новых отношения, каждое из которых имеет собственную тему. Центральная задача проектирования базы данных - определение количества отношений (или иных составных единиц информации) и их атрибутного состава.
Задача группировки атрибутов в отношения, набор которых заранее не фиксирован, допускает множество различных вариантов решений. Рациональные варианты группировки должны учитывать следующие требования:
множество отношений должно обеспечивать минимальную избыточность представления информации,
корректировка отношений не должна приводить к двусмысленности или потере информации,
перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.
Нормализация представляет собой один из наиболее изученных способов преобразования отношений, позволяющих улучшить характеристики БД по перечисленным критериям.
Ограничения на значения, хранимые в реляционной базе данных, достаточно многочисленны. Соблюдение этих ограничений в конкретных отношениях связано с наличием так называемых нормальных форм. Процесс преобразования отношений базы данных к той или иной нормальной форме называется нормализацией отношений. Нормальные формы (НФ) нумеруются последовательно от 1 по возрастанию, и чем больше номер нормальной формы, тем больше ограничений на хранимые значения должно соблюдаться в соответствующем отношении. Функциональные зависимости определяются для атрибутов, находящихся в ОДНОМ и том же отношении, удовлетворяющем l НФ.
О любой таблице данных, удовлетворяющей определению отношения, говорят, что она находится в первой нормальной форме (lНФ)
Простейший случай функциональной зависимости охватывает 2 атрибута. В отношении R(A,B,... ) атрибут А функционально определяет атрибут В, если в любой момент времени каждому значению А соответствует единственное значение В (обозначается А ( В).
Иначе говорят, что В функционально зависит от А (обозначается В = f(A) ). Отсутствие функциональной зависимости обозначается А-/( В. Примеры функциональных зависимостей приведены в таблицах 6 и 7.
Таблица 6 Таблица 7

ФИО
ГодРож

Иванов ИИ
1960

3уев ВВ
1963

Смирнов СС
1960

Яшина ИМ
1961


Магазин
Расч. счет

ММ3
704098

Динамо
122095

АТЭ
440162





ФИО( ГодРож
ГодРж --/(ФИО
Магазин(Расч. счет
Расч.счет(Магазин




Таблица 8. Студент
Номер Студ
ФИО
Номер Комнаты
Телефон
Курс
Семестр
Предмет
Оценка

31801
Иванов ИИ
21
45-45-45
2
3
Математика
4





2
4

5





2
4
Физкультура
5

31811
Петров ПП
21
45-45-45
2
3
Математика
4





2
4

4





2
4
Физкультура
3

32823
Сидоров СС
34
45-46-00
1
1
Физика
4





1
2

4





1
2
История
3


Таблица 8 не является отношением.
Таблица 9. Отношение «Студент»
Номер Студ
ФИО
Номер Комнаты
Телефон
Курс
Семестр
Предмет
Оценка

31801
Иванов ИИ
21
45-45-45
2
3
Математика
4

31801
Иванов ИИ
21
45-45-45
2
4
Математика
5

31801
Иванов ИИ
21
45-45-45
2
4
Физкультура
5

31811
Петров ПП
21
45-45-45
2
3
Математика
4

31811
Петров ПП
21
45-45-45
2
4
Математика
4

31811
Петров ПП
21
45-45-45
2
4
Физкультура
3

32823
Сидоров СС
34
45-46-00
1
1
Физика
4

32823
Сидоров СС
34
45-46-00
1
2
Физика
4


Сидоров СС
34
45-46-00
1
2
История
3

Таблица 9 является отношением.
Функциональные зависимости атрибутов таблицы 9:
НомерСтуд(ФИО
НомерСтуд( НомерКомн
НомерКомн( Телефон Телефон(НомерКомн
НомерСтуд,Курс,Семестр,Предмет( Оценка
Ключ отношения: НомерСтуд,Курс,Семестр,Предмет










Рисунок 6. Диаграмма функциональных зависимостей



4.1. Нормальные формы


Отношения в первой нормальной форме могут иметь аномалии модификации. Чтобы устранить эти аномалии, мы разбиваем исходное отношение на два или более новых отношения. Когда мы делаем это, новые отношения оказываются в некоторой другой нормальной форме. Какая именно форма это будет, зависит от того, какие аномалии мы устранили, а также от того, каким аномалиям подвержены получившиеся отношения.

4.2. Вторая нормальная форма (2НФ)

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


ФИО
Группа
Факультет

Петров
101
ЭИ

Федин
101
ЭИ

Aлешин
102
БД

Яшина
102
БД


Функциональные зависимости таблицы 10:
ФИО, Группа ( Факультет,
ФИО ( Факультет.
Группа ( Факультет
Ключ отношения Таблица 10- ФИО.
Избыточность данных в таблице 10 связана с тем, что принадлежность группы к факультету указывается столько, сколько студентов обучается в этой группе
Таблица 11
Номер
Секция
Плата

Студента



100
Лыжи
200

100
Гольф
65

150
Плавание
50

175
Сноуборд
50

175
Плавание
50

200
Плавание
50

200
Гольф
65

Отношение Таблица 11 имеет аномалии модификации. Если мы удалим строку с данными о студенте номер 175, мы потеряем тот факт, что абонемент в секцию сноуборда стоит 50 руб. Кроме того, мы не можем ввести информацию о новой секции, пока в эту секцию не запишется хотя бы один студент. Таким образом, данное отношение подвержено как аномалии удаления, так и аномалии вставки. Функциональные зависимости таблицы 11:
НомерСтудента, Секция ( Плата Секция( Плата
Таблица 11 не находится во 2НФ. Отношение, не соответствующее 2НФ, характеризуется избыточностью хранимых данных.

Таблица 12
Магазин
Изделие
Цена
План

Салют
М22
50
200

Салют
К14
40
100

Триумф
М22
50
300

Триумф
Т62
60
100

Вероятным ключом в Таблице 12
являются атрибуты Магазин, Изделие.
Функциональные зависимости отношения :
Магазин,Изделие(План Изделие ( Цена
Магазин, Изделие( Цена
Таблица 12 не находится во 2НФ.
4.3. Третья нормальная форма (ЗНФ)

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

Таблица 13. ПРОЖИВАНИЕ
Номер
Студента
Общежитие
Плата

100
№1
3200

150
№2
3100

200
№1
3200

250
№3
3100

300
№1
3200

Здесь НомерСтудента является идентификатором студента, а Плата - это плата за проживание в общежитии.
Предположим, что все студенты, проживающие в одном общежитии, платят одинаковую сумму. Поскольку НомерСтудента является первичным ключом, мы знаем, что НомерСтудента -> НазваниеОбщежития, НомерСтудента ->Плата. Таким образом, НомерСтудента - это одновременно и первичный ключ, и детерминант. Кроме того, поскольку все студенты, проживающие в одном общежитии, платят одинаково, то НазваниеОбщежития -> Плата. Следовательно, НазваниеОбщежития является детерминантом, но не первичным ключом. Отношение не находится в третьей нормальной форме.

4.4. Нормальная форма Бойса - Кодда (НФБК)

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




4.5. Четвертая нормальная форма (4НФ)

Таблица 13. СТУДЕНТ





Номер
Специализация
Секция

студента



100
Музыка
Плавание

100
Бухгалтерский учет
Плавание

100
Музыка
Теннис

100
Бухгалтерский учет
Теннис

150
Математика
Оздоровительный бег


Студент(НомерСтудента, Специализация, Секция)
Многозначные зависимости:
НомерСтудента (( Специализация
НомерСтудента (( Секция
Отношение находится в 3НФ и в НФБК.

Вообще говоря, многозначная зависимость существует, когда отношение имеет минимум три атрибута, причем два из них являются многозначными, а их значения зависят только от третьего атрибута. Другими словами, в отношении R (А, В, С) существует многозначная зависимость, если атрибут А многозначным образом определяет В и С, а сами В и С не зависят друг от друга. Как мы видели из предыдущего примера, НомерСтудента многозначно определяет атрибуты Специализация и Секция, но сами Специализация и Секция не зависят друг от друга. Многозначные зависимости приводят к аномалиям модификации
Для начала обратите внимание на избыточность данных в таблице 13. Студентке номер 100 посвящено четыре записи, в каждой из которых указана одна из ее специализаций и одна из посещаемых ею секций. Если бы те же данные хранились в меньшем количестве строк (скажем, было бы две строки - одна для музыки и плавания, а другая для бухгалтерского учета и тенниса), это дезориентировало бы пользователей. Получалось бы, что студентка номер 100 плавает только тогда, когда специализируется на музыке, а в теннис играет только тогда, когда специализируется на бухгалтерском учете. Но такая интерпретация нелогична. Специальности и секции совершенно независимы друг от друга. Поэтому, чтобы избежать таких неверных заключений, мы храним все сочетания специальностей и секций.
Номер
Секция

студента


100
Лыжи

100
Плавание

100
Теннис

150
Оздоровительный бег

Чтобы устранить эти аномалии, мы должны избавиться от многозначной зависимости. Мы сделаем это, создав два отношения, в каждом из которых будет только один многозначный атрибут. Результирующие отношения не будут иметь аномалий. Это отношения СТУДЕНТ-СПЕЦИАЛИЗАЦИЯ (НомерСтудента, Специализация) и СТУДЕНТ-СЕКЦИЯ (НомерСтудента, Секция), изображенные на рис. 8.
Номер
Специализация

студента


100
Музыка

100
Бухгалтерский учет

150
Математика










Рис. 8. Устранение многозначной зависимости

Т.о. отношение находится в 4НФ, если оно находится в НФБК и не имеет многозначных зависимостей. В результате нормализации получится 2 отношения. По ним можно восстановить исходное отношение.
5 НФ связана с зависимостями, которые можно разделить на несколько более мелких отношений с обязательными ключами, но затем невозможно восстановить.














Список литературы

Основная:
Голицина О.Л, Максимов Н.В., Попов И.И. Базы данных. Учебное пособие для ССУЗов.- М.:ФОРУМ:ИНФРА-М, 2014.- 400с.
Голицына О. Л., Партыка Т. Л., Попов И. И. Основы проектирования баз данных.- М.:ФОРУМ:ИНФРА-М, 2012.- 416 с.
Кузнецов С. Д. Базы данных.- М.: Академия, 2012.- 496с
Фуфаев Э. В.,. Фуфаев Д. Э. Разработка и эксплуатация удаленных баз данных.- М.: Академия, 2012.- 256 с.
Фуфаев Э. В., Фуфаев Д. Э. Базы данных.- М.: Академия, 2012.- 320 с.

Дополнительная:
1. Крёнке. Д. Теория и практика построения баз данных.9-е издание.- СПб.: Питер, 2005.- 859 с.
2. Кузин А.В., Демин В.М. Разработка баз данных в системе Microsoft Access: учебник.- М.:ФОРУМ:ИНФРА-М, 2009.- 224с.
3. Сенов А. Access 2010.- СПб.: Питер, 2011 .- 288 с.


Интернет- ресурсы:

1. Кириллов В.В. Основы проектирования реляционных баз данных[Электронный ресурс]- Электрон. текстовые дан. - СПб.: [ Cкачайте файл, чтобы посмотреть ссылку ] изд., 2013. – Режим доступа: [ Cкачайте файл, чтобы посмотреть ссылку ]






( Закон «О правовой охране программ для ЭВМ и баз данных»









HYPER13 PAGE HYPER146HYPER15


Ребенок

Отец

Мать

Продавец

Заказ

Курс

СТУДЕНТ

Плата


НомСтудента

ФИОСтудента

НазОбщежития

КолКомнат

Местоположение

ОБЩЕЖИТИЕ

КодПр
ИмяПр
КодКл

Р1
Ирина
К6

Р2
Мария
К3

Р3
Надежда
К5

Р1
Ирина
К4

Р1
Ирина
К3

Р1
Ирина
К6



КодКл
ИмяКл

К1
Сергей

К2
Василий

К3
Николай

К4
Сергей

К5
Иван

К6
Сергей



КодПр
КодКл

Р1
К6

Р2
К3

Р3
К5

Р1
К4

Р1
К3

Р1
К6



ФИО

НомерСтуд

НомерКомн


Телефон

Курс,Семестр,Предмет

Оценка





Приложенные файлы

  • doc FILE2
    Учебное пособие
    Размер файла: 334 kB Загрузок: 4