Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Базы Данных Лекции

.pdf
Скачиваний:
50
Добавлен:
15.04.2015
Размер:
318.07 Кб
Скачать

Основные принципы организации баз данных

1. Понятие базы данных

К организации данных в системах автоматизированной обработки информации возможны два подхода:

1.Каждый пользователь системы создает наборы данных, необходимых для решения его задач, и пишет программы обработки данных. Например, в рамках ВУЗа различные подразделения (деканат, отдел кадров, бухгалтерия и т.п.) могут создать свои подсистемы, предназначенные для решения определенных задач.

2.Вся информация, описывающая определенную предметную область, хранится, интегрировано, в единой базе данных (БД) и каждый из пользователей имеет доступ к тем данным, которые необходимы ему для решения его задач.

Первый из подходов имеет ряд недостатков:

В различных подсистемах часто хранится одна и та же информация (сведения о студентах, о преподавателях и т.п.), т.е. данные дублируются, и возникает избыточность информации. При появлении изменений в данных необходимо обновлять многочисленные наборы данных и если отдельные наборы окажутся не скорректированы, возникнет противоречивость данных.

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

При появлении в подсистеме новых задач, а, следовательно, и новых данных придется вносить изменения в уже созданные программы, т.к. данные описаны в каждой из прикладных программ (описаны типы и форматы данных, типы файлов). В подобном случае говорят, что прикладные программы зависят от хранимых данных.

При хранении данных в БД перечисленные недостатки снимаются. Однако в этом случае возникает другой недостаток: у данных нет единого хозяина. Из-за этого снижается ответственность за правильность хранимых данных и нарушается секретность. Для устранения этого недостатка в БД разрабатывается специальная система защиты.

БД - это совокупность специальным образом организованных данных, описывающих определенный класс объектов или определенную предметную область и используемая различными пользователями и приложениями для решения своих задач.

Слова "специальным образом организованные" означают то, что БД должна строиться по определенным правилам и должна удовлетворять ряду определенных требований.

Комплекс программных и языковых средств, обеспечивающих создание и функционирование БД, называется Системой Управления Базой Данных - СУБД.

Совокупность БД, СУБД, технических средств и обслуживающего персонала образует банк данных (БнД). Комплекс программных средств, управляющих БнД,

называется Системой Управления Банком Данных (СУБнД).

2. Требования, предъявляемые к БД

Правильно спроектированная БД должна удовлетворять следующим требованиям:

1.Минимальная избыточность. Непротиворечивость.

2.Целостность данных.

3.Независимость данных.

4.Возможность ведения (добавления и удаления) и актуализации (корректировки, модификации) данных.

5.Безопасность и секретность.

6.Высокая производительность. Минимальные затраты.

2

7. Соблюдение стандартов.

1.Минимальная избыточность означает то, что данные в БД не должны дублироваться. Избыточность данных, если она существует, влечет две опасности:

-неоправданно большой расход памяти; -нарушение непротиворечивости данных, т.е. возникновение такой ситуации, когда в

различных местах машинной памяти хранятся противоречивые данные. Возникновение противоречивости чрезвычайно опасно для БД.

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

2.Целостность данных означает то, что в БД должны храниться только правильные данные. Разрушение и искажение данных возможно в результате неосторожных действий пользователей, в результате ошибок в программах и сбоев оборудования.

Для обеспечения целостности и предотвращения возможности ввода неправильных данных должны разрабатываться средства контроля правильности вводимых данных. Например, можно использовать процедуры, проверяющие принадлежность вводимых значений определенному диапазону допустимых значений. В БД должны быть предусмотрены средства защиты данных от нечаянных и предумышленных искажений, средства восстановления испорченных данных. Различные СУБД в той или иной мере располагают такими средствами.

Существуют специальные методы и приемы обеспечения целостности.

3.Независимость данных означает то, что прикладные программы не должны зависеть от хранимых данных, т.е. от способа хранения данных в физической памяти. Это позволяет добавлять в БД новые данные, изменять структуры хранения данных, создавать на БД новые приложения. Ранее созданные программы при этом не должны "чувствовать" эти изменения. СУБД обычно обеспечивают это требование.

4.Структура БД должна позволять включать новые и удалять устаревшие данные, корректировать хранимые данные без разрушения логических связей, установленных в схеме БД. Для этого схема БД должна быть правильно разработана, а операции ведения БД не должны нарушать схему БД.

5.Безопасность и секретность означает защиту данных от несанкционированного доступа, преднамеренного и непреднамеренного разрушения данных, хищения данных. Система защиты должна иметь:

-средства идентификации пользователей; -средства ограничения доступа к данным. Каждый пользователь должен работать

только с теми данными, которые необходимы для решения его задач, остальные данные должны быть для него "невидимыми";

-средства, обеспечивающие секретность данных.

Подобные средства содержатся в СУБД или разрабатываются системным программистом.

6.Организация БД и методы доступа к данным должны обеспечивать высокую скорость обработки данных так, чтобы пользователь мог работать с БД в диалоговом режиме. Стоимость обслуживания пользователей не должна быть высокой.

Возможность выполнения этих требований определяется рядом факторов: объемом хранимых данных, быстродействием техники, способом организации данных в БД и во многом зависит от решений, принимаемых разработчиками на этапе создания БД.

7.Представление данных в БД, документация, способ взаимодействия пользователя

сБД должны удовлетворять определенным стандартам. Стандарты могут быть корпоративными, ведомственными, промышленными, национальными и международными. Соблюдение стандартов совершенно необходимо для совместного использования данных и для организации обмена данными между отдельными системами. Например, без принятия определенных стандартов нельзя было бы организовать сеть Internet.

3

3. Уровни представления данных в БД

В БД выделяют 5 уровней представления данных: уровень пользователя, внешний уровень, концептуальный уровень, уровень хранения и физический уровень. Два последних уровня часто рассматривают как единый уровень - внутренний.

Для каждого уровня характерно определенное представление данных и определенный перечень выполняемых функций.

Центральной частью БД является концептуальный уровень представления данных или концептуальная схема. Концептуальная схема (или схема БД) - это описание общей логической структуры данных.

Схема строится на основании изучения той предметной области, в которой будет использоваться БД. В процессе обследования предметной области выделяются объекты предметной области и свойства (характеристики) объектов. Объектом может быть человек, предмет, документ, процесс, явление т.п. Выявляются логические связи между объектами, существующие в предметной области. При этом учитывается круг задач, решаемых на БД, выявляются информационные потребности пользователей, т.е. определяются возможные запросы к БД. На данные, подлежащие хранению в БД, накладываются определенные ограничения, определяются операции, которые будут выполняться над данными. После этого определяется модель данных и строится схема БД. Т. о. концептуальная схема - это логическая структура данных, ограничения, накладываемые на данные и операции с данными.

Разработанная схема описывается на ЯОД (языке описания данных) той СУБД, которая будет использоваться. Описание БД на концептуальном уровне хранится в памяти машины наряду с самими данными и образует так называемые метаданные.

Схема, содержащая конкретные данные, называется экземпляром схемы или текущим состоянием БД. С течением времени текущее состояние меняется, но схема остается неизменной.

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

С БД будут работать люди, имеющие разный уровень компьютерной подготовки, т.е. пользователи разных уровней.

Для пользователей - программистов, решающих конкретные прикладные задачи, разрабатывается внешний уровень представления данных или так называемые подсхемы. В каждую подсхему из схемы выделяется то подмножество данных, которое необходимо для решения задач данного пользователя. Такой пользователь имеет представление о схеме данных, знает, как построена его подсхема, может самостоятельно писать программы обработки данных. Но он не имеет доступа ко всей БД и не может изменять концептуальную схему БД. Работа с БД через подсхему - это эффективное средство защиты данных. В ряде СУБД есть специальные средства создания подсхем (view).

Для пользователей-непрограммистов разрабатывается уровень пользователя. Такой пользователь (кассир в ж/д кассе, банковский служащий) может ничего не знать о базах данных и программировании. Он знает лишь определенную совокупность действий или простейших команд, которые позволяют ему выполнять свою работу. Такой пользователь имеет доступ только к подсхеме. Для него разрабатывается специальный дружественный интерфейс, обеспечивающий простое и удобное взаимодействие с системой, - интерфейс пользователя-непрограммиста.

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

СУБД построена таким образом, что изменения на внутреннем и концептуальном уровнях не влияют на работающие прикладные программы, т.е. обеспечивается независимость прикладных программ от хранимых данных.

4

Лицо или группа лиц, ответственных за всю БД в целом, за систему защиты и за все уровни представления данных называется Администратором Базы Данных (АБД).

4. Языки баз данных

Основная часть СУБД, используемая программистом, это Язык Данных (ЯД). Существует следующие основные типы ЯД:

ЯОД - язык описания данных, ЯМД - язык манипулирования данными, ЯЗ - язык запросов.

ЯОД обязательно есть в любой СУБД, на нем описывается схема БД.

ЯМД предназначен для доступа к данным и для выполнения манипуляций с данными: чтение или выборка данных, запись в БД, поиск, добавление, удаление, корректировка данных и т.п. (Операции добавления, удаления и корректировки данных называются операциями ведения БД). Различные СУБД содержат различные наборы операторов ЯМД и различные правила их использования.

ЯЗ - это совокупность средств, предназначенных для организации интерфейса пользователя-непрограммиста. Такой язык имеется не во всех СУБД и часто пользовательский интерфейс приходится разрабатывать АБД.

5. Логическая структура данных

Основой концептуальной схемы БД является логическая структура данных. Именно с ее разработки начинается создание любой БД. В логической структуре отображаются все объекты предметной области и их свойства, устанавливаются связи, существующие между объектами в предметной области.

Различают два понятия: тип объекта и экземпляр объекта.

Любой объект описывается следующей триадой: <Имя объекта, Свойства объекта, Значения свойств>

Тип объекта характеризуется первыми двумя компонентами триады. Для свойств устанавливаются имена. Например, имя объекта - СТУДЕНТ, свойства объекта: ФИО, ГРУППА, СРЕДНИЙ БАЛЛ и т.п.

Втеории БД понятие "тип объекта" часто заменяют понятием "СУЩНОСТЬ". Следует помнить, что эти понятия относятся к предметной области.

ВСУБД понятию "тип объекта" соответствует "тип записи", при этом имя объекта часто рассматривается как имя записи. Свойства объекта являются полями записи, каждое поле имеет имя соответствующего свойства.

Конкретные значения свойств определяют конкретный экземпляр объекта данного типа. Например: ФИО - Иванов И.И., ГРУППА - 037, СРЕДНИЙ БАЛЛ - 4,5.

ВСУБД экземпляру объекта соответствует экземпляр записи, значения каждого свойства хранятся в соответствующем поле. Совокупность всех экземпляров записей определенного типа образует файл данных.

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

Подавляющее большинство СУБД для персональных ЭВМ поддерживают реляционную модель данных. Существуют приемы, позволяющие преобразовать иерархическую и сетевую модели в реляционную.

5

5 Основные понятия реляционной модели данных

Реляционная модель была предложена американским математиком Е. Коддом в 1970 г. Это единственная из моделей БД, основанная на специальном разделе математики - теории отношений. Математическая обоснованность позволила сформулировать, достаточно строгие правила построения модели, обеспечивающие ее работоспособность. Языки данных, основанные на математическом аппарате теории отношений, позволяют составлять любые запросы к БД и выполнять разнообразные операции манипулирования данными.

Вреляционной модели все данные представлены в табличной форме. Каждому типу объекта сопоставлена отдельная таблица, имеющая соответствующее имя. Свойствам объекта сопоставлены столбцы таблицы с соответствующими именами. Строки каждой таблицы содержат значения свойств и соответствуют экземплярам объектов данного типа.

Проиллюстрируем вышесказанное небольшим примером.

Рассмотрим фрагмент предметной области, связанной с обработкой информации о поставках на предприятие комплектующих изделий. В БД предстоит хранить сведения о поставщиках, изделиях и объемах поставок каждого изделия каждым из поставщиков

Впредметной области можно выделить два объекта: ПОСТАВЩИК и ИЗДЕЛИЕ. Каждый из объектов характеризуется рядом вполне определенных свойств. Анализ возможных запросов к БД и задач обработки данных позволяет установить, какие именно сведения о каждом из объектов следует хранить в БД.

Пусть из БД необходимо получать сведения о том, какие изделия и в каком количестве поставляются определенным поставщиком; из какого города поставляются определенные изделия, в каком городе расположен определенный поставщик и т.п. Тогда определим для объектов следующие свойства.

ПОСТАВЩИК (П#, Имя поставщика, Город) ИЗДЕЛИЕ (И#, Наименование, Вес)

Каждому поставщику и каждому изделию присвоим свой уникальный номер. Символами П# и И# обозначены номера поставщиков и номера изделий.

Таким образом, нами определены два типа объектов предметной области. Установим тип связей, существующих между объектами.

Известно, что каждый поставщик поставляет несколько изделий, а каждое изделие, в сою очередь, поставляется различными поставщиками. Следовательно, между этими объектами существует логическая связь типа М:М. Каждой из связей можно поставить в соответствие определенное значение, например, определить количество поставляемых изделий.

М

ПОСТАВЩИК ИЗДЕЛИЕ.

М

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

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

Связи типа 1:М обычно устанавливаются введением в связываемые таблицы дополнительных столбцов. Для установления связи М:М создается дополнительная связующая таблица, с которой каждая из связываемых таблиц связывается отношением 1:М. Если между таблицами должна устанавливаться связь 1:1, то эти таблицы можно объединить в одну.

Создадим связующую таблицу ПОСТАВКИ (П#, И#, Количество).

6

Эту таблицу можно рассматривать как третий объект предметной области.

Между таблицами ПОСТАВЩИК и ПОСТАВКИ связь 1:М устанавливается по столбцу П#. Это значит, что каждой строке таблицы ПОСТАВЩИК (с определенным номером поставщика) соответствует несколько строк таблицы ПОСТАВКИ (это строки с тем же номером поставщика). Между таблицами ИЗДЕЛИЕ и ПОСТАВКИ также устанавливается связь 1:М по столбцу И#. Таблицы ПОСТАВЩИК и ИЗДЕЛИЕ связываются отношение М:М через таблицу ПОСТАВКИ.

В связующей таблице присутствуют столбцы, уже имеющиеся в других таблицах. Для того, чтобы в БД не хранить многократно длинные символьные строки, поставщикам и изделиям были присвоены номера П# и И#. Такой прием позволяет уменьшить объем хранимых данных и несколько упростить процедуры установления связей между таблицами.

 

 

ПОСТАВЩИК

 

 

 

 

 

П#.

Имя поставщ.

 

Город

 

 

 

 

 

 

 

 

 

 

П1

Восход

 

Тула

 

 

 

 

 

 

П2

Заря

 

Самара

 

 

 

 

 

 

 

 

 

 

П3

Салют

 

Тула

 

 

 

 

 

 

 

 

 

 

 

 

ИЗДЕЛИЕ

 

 

 

И#

Наименование

Вес

 

 

 

 

 

И1

Болт

12

 

 

 

И2

Гайка

8

 

 

 

 

 

И3

Гвоздь

6

 

 

 

 

 

И4

Винт

14

 

 

 

 

 

 

 

ПОСТАВКИ

П#

И#

Количество

 

 

 

П1

И1

300

 

 

 

П1

И2

200

 

 

 

П1

И3

200

 

 

 

П2

И1

200

 

 

 

П2

И2

500

 

 

 

П3

И4

80

 

 

 

Таблицы реляционной модели строятся по определенным правилам. Некоторые из них таковы:

-в таблице не должно быть столбцов с одинаковыми именами;

-в каждом столбце содержатся данные одного и того же типа и одинакового смысла;

-в таблицах не должно быть повторяющихся строк;

Ряд других очень важных правил рассматривается ниже.

При соблюдении всех правил построения таблиц каждую из них можно рассматривать как математическое отношение (relation).В этом случае над таблицами можно выполнять математические операции реляционной алгебры и теории множеств. Именно эти операции положены в основу ЯМД реляционных СУБД.

Для реляционной модели используются термины, принятые в теории отношений. Имя отношения - это имя таблицы, атрибут отношения - это столбец таблицы с

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

степень или арность.

7

Рассмотренная модель содержит три тернарных отношения (три таблицы с тремя столбцами).

6. Основные операции над отношениями

Над отношениями можно выполнять операции теории множеств (объединение отношений, пересечение отношений, дополнение отношения и др.), а также операции реляционной алгебры (композиция отношений, сцепление отношений и проекция отношения).

Рассмотрим основные операции реляционной алгебры, положенные в основу языков данных многих коммерческих систем управления реляционными БД.

Пусть имеются два отношения: отношение с именем R и отношение с именем S. Каждое из отношений имеет арность 2 (бинарные отношения). Отношение R состоит из атрибутов А1 и А2, отношение S - из атрибутов А2 и А3.

Сцепление отношений.

Можно выполнить операцию сцепления двух отношений по одинаковым значениям одноименных атрибутов Ai. Атрибуты, по которым выполняется сцепление, должны быть определены на одном и том же домене. Операцию сцепления обозначим символом *.

Сцеплением отношений R и S называется новое отношение R*S, состоящее из кортежей <x, y, z>, для которых кортеж <x, y> принадлежит R, а <y, z> принадлежит S.

Пример 1.

Определим результат выполнения операции сцепления отношений R и S, атрибуты которого А2 определены на одном и том же домене. Это значит, что если в столбце с именем А2 таблицы R содержатся, например, названия городов, то и в столбце А2 таблицы S также содержатся названия городов.

R

 

 

 

S

 

 

R*S

 

 

 

R*M

А1

 

А2

 

А2

А3

 

А1

А2

А3

 

А1

 

А2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

a

 

b

 

b

k

 

a

b

k

 

a

 

b

c

 

b

 

d

f

 

c

b

k

 

c

 

b

 

 

 

 

 

 

 

 

 

 

 

 

 

 

c

 

d

 

d

p

 

c

d

f

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

e

 

q

 

 

 

 

c

d

p

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Врезультате сцепления двух бинарных отношений получено новое тернарное отношение, кортежи которого оказались "сцеплены" по одинаковым значениям атрибута А2

Иными словами, в результате сцепления двух таблиц, состоящих из двух столбцов, получена новая таблица, состоящая из трех столбцов. Строки результирующей таблицы "сцеплены" по одинаковым значениям, находящимся в столбцах с именем А2.Таким образом, информация из одной таблицы оказалась "привязанной" к информации из другой таблицы.

Вобщем случае, если отношение R имеет арность m, а отношение S - арность n , то R*S будет иметь арность m+n-1.

Можно выполнить сцепление отношения с множеством.

Пусть множество М является одноэлементным и содержит одно значение {b} из того же домена, что и значения атрибута А2 отношения R. Тогда результатом операции сцепления будет отношение R*M, состоящее из тех кортежей отношения R, у которых значение атрибута А2 равно b.

Иными словами, в результате сцепления таблицы R с константой b из таблицы R оказались выбранными стоки, содержащие в столбце А2 значение b (см. Пример 1). Если в

8

столбце А2 содержались, например, названия городов, то из таблицы отберутся строки с заданным названием города.

Проекция отношения.

Проекцией отношения R на его атрибут Аi называется множество, состоящее из различных значений этого атрибута. Операция проекции обозначается R [Аi].

Пример 2.

Найдем проекцию отношения R на его атрибут А2. В результате получим множество {b, d, q}. Иными словами, результатом проекции является множество различных значений, образующих столбец А2 таблицы R.

7. Ключи отношений

Внутри каждого отношения реляционной модели обязательно должен существовать атрибут, однозначно идентифицирующий каждый кортеж отношения. Такой атрибут называется первичным (основным) ключом отношения.

Иными словами, в каждой таблице должен присутствовать столбец, значения в котором не повторяются. Каждое значение, присутствующее в таком столбце, определяет единственную строку в таблице. Поскольку каждый столбец соответствует определенному свойству объекта, то этот столбец соответствует такому свойству, каждое значение которого присуще одному единственному экземпляру объекта данного типа.

Первичный ключ используется для доступа к записям в реляционных БД.

В таблице ИЗДЕЛИЕ первичным ключом является атрибут И#, а в таблице ПОСТАВЩИК - П#.

Если в отношении нет атрибута, который можно принять в качестве первичного ключа (т.е. среди свойств объекта не нашлось ни одного, однозначно идентифицирующего каждый объект), то в качестве первичного ключа можно использовать некоторую совокупность атрибутов. Например, в отношении ПОСТАВКИ в качестве первичного ключа выступает совокупность атрибутов П#, И#, т.к. сведения об объеме поставок конкретного изделия конкретным поставщиком можно получить только тогда, когда известен номер поставщика и номер поставляемого им изделия. Каждая комбинация значений этих атрибутов уникальна для каждого кортежа и однозначно его идентифицирует. Такой ключ называется составным.

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

Для реляционных БД очень важным является также понятие внешнего ключа отношения. Атрибут, являющийся первичным ключом одного отношения и входящий в составной первичный ключ другого отношения является внешним ключом этих отношений. Так, например, внешним ключом отношений ПОСТАВЩИК и ПОСТАВКИ является атрибут П#, а внешним ключом отношений ИЗДЕЛИЯ и ПОСТАВКИ является атрибут И#.

Через внешний ключ можно выполнить операцию сцепления двух отношений. Так, например, можно определить все поставки, производимые поставщиком П1, выполнив сцепление отношения ПОСТАВЩИК и ПОСТАВКИ по П1 (напомним, что между этими отношениями существует логическая связь типа 1:М).

Все отношения реляционной модели должны иметь внешние ключи, так как именно через внешние ключи осуществляются связи 1:М и М:М. На практике в качестве внешнего ключа отношения, находящегося на стороне М, может использоваться и не ключевой атрибут.

8. Нормализация отношений реляционной БД

Отношения реляционной БД можно привести к такому виду, который обеспечил бы наилучшие свойства БД. Процесс приведения отношений к такому виду называется нормализацией. При работе с ненормализованными отношениями в процессе ведения БД

9

(при выполнении операций добавления и удаления строк в таблицы) могут возникнуть так называемые аномалии включения и удаления. Аномалия включения проявляется в том, что некоторые нужные данные невозможно ввести в БД до тех пор, пока не будут известны некоторые связанные с ними дополнительные сведения. Аномалия удаления связана с возникновением таких ситуаций, когда при удалении устаревших данных вместе с ними из БД исчезают и нужные сведения.

Известно 5 нормальных форм (НФ) отношений. Нормализация выполняется поэтапно. Сначала отношение приводится к первой НФ (1НФ), затем - ко 2НФ и т.д. вплоть до 5НФ. Однако для устойчивой работы БД часто оказывается достаточным, если ее

отношения находятся в 3НФ.

Между формами существует следующая связь. Если отношение находится в 3НФ, то это значит, что оно уже находится во 2НФ и 1НФ.

Первая нормальная форма

Считается, что отношение находится в 1НФ, если значение каждого его атрибута не структурировано. Это означает, что на пересечении каждого столбца и каждой строки таблицы должно находиться одно единственное значение.

В рассмотренной нами выше предметной области о поставках на предприятие изделий поставщик П1 поставляет в определенных количествах изделия И1, И2 и И3, поставщик П2 - изделия И1 и И2, а поставщик П3 - изделие П4. Отобразим эти данные в таблице ПОСТАВКИ 1. Такой вид таблицы типичен для многих документов. Так, например, в одну колонку таблицы часто помещают фамилию, имя и отчество человека или адрес, содержащий почтовый индекс, город, улицу, номер дома, номер квартиры.

Номера поставщиков П# уникальны, и этот атрибут можно принять в качестве первичного ключа отношения.

 

 

ПОСТАВКИ 1

 

 

ПОСТАВКИ

 

 

ПК

 

 

 

 

 

П#

 

 

 

 

П#

И#

 

Кол

И#

 

Кол

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

И1

 

300

 

П1

И1

 

300

П1

И2

 

200

 

П1

И2

 

200

 

И3

 

200

 

П1

И3

 

200

П2

И1

 

200

 

П2

И1

 

200

И2

 

500

 

П2

И2

 

500

 

 

 

 

П3

И4

 

80

 

П3

И4

 

80

 

 

 

 

 

 

 

 

 

Можно заметить, что в отношении ПОСТАВКИ 1 значения ключа П# идентифицирует сразу несколько значений не ключевых атрибутов И# и Кол, что недопустимо. (В таблице на пересечении, например, строки П1и столбца И# содержится несколько значений номеров изделий ). Это отношение находится не в 1НФ.

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

Вторая нормальная форма

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

10

Пусть в проектируемой БД помимо перечисленных ранее сведений о поставках необходимо хранить также сведения о стоимости перевозок грузов из тех городов, откуда производятся поставки. Для этого введем свойство Тариф, значение которого определяет стоимость перевозок единицы груза, например, одной тонны, из каждого города. Предположим, что на начальном этапе проектирования логической структуры данных не удалось выявить типы объектов предметной области и связи, существующие между ними, подобно тому, как это было сделано в п.5. Тогда все имеющиеся сведения представим в виде одной таблицы ПОСТАВКИ 2 (в эту таблицу для упрощения не включены наименования изделий, так как в дальнейших рассуждениях это свойство не будет иметь для нас значения).

 

 

 

 

 

ПОСТАВКИ 2

 

 

 

 

 

 

 

П#

И#

Кол

Имя поставщика

Город

 

Тариф

 

 

 

 

 

 

 

П1

И1

300

Восход

Тула

 

10

 

 

 

 

 

 

 

П1

И2

200

Восход

Тула

 

10

 

 

 

 

 

 

 

П1

И3

200

Восход

Тула

 

10

 

 

 

 

 

 

 

П2

И1

200

Заря

Самара

 

15

 

 

 

 

 

 

 

П2

И2

500

Заря

Самара

 

15

 

 

 

 

 

 

 

П3

И4

80

Салют

Тула

 

10

 

 

 

 

 

 

 

Отметим, что у этого отношения первичный ключ составной - П# И#.

Рассмотрим следующую ситуацию. Пусть ведутся переговоры о поставках с новым предприятием Победа, расположенном в городе Тамбове. Требуется включить в таблицу сведения об этом предприятии и сведения о тарифе по доставки грузов с этого предприятия. Мы не сможем этого сделать. Это предприятия еще ничего не поставляет и код поставляемых изделий неизвестен, т.е. И# =0, а у составного первичного ключа ни одна из компонент не может быть нулевой. В этом и состоит аномалия включения.

Если же какое-либо предприятие, например, Заря перестанет поставлять нам изделия, то для него И# =0. Из таблицы придется исключить все сведения об этом предприятии, в том числе и те, которые мы хотели бы сохранить. В этом состоит аномалия удаления.

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

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

Ключ отношения составной, но он, целиком, определяет лишь атрибут Кол. Атрибуты Имя поставщика, Город и Тариф зависят лишь от части первичного ключа, так как именно номер поставщика однозначно определяет имя предприятия, название города, а

следовательно, и тариф. Это отношение находится не во 2НФ. Для приведения его ко 2НФ надо выделить группы атрибутов, зависящие от частей составного ключа, в отдельные таблицы.

В таблицу ПОСТАВЩИК1 выделим атрибуты П#, Имя поставщика, Город, Тариф. Ключ этого отношения - П#. В таблицу ПОСТАВКИ выделим атрибуты П#, И#, Кол. Здесь

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.