Проектирование логической структуры базы данных

Концепция функциональной зависимости.

Рассмотрим концепцию функциональной зависимости которая по сути является связью типа многие к одному между множествами атрибутов внутри отношения.

S (студенты)
SN	NAME	GROUP	SPEC

P (предметы)
PN	PNAME	TEACHER	KAFEDRA

SP (оценки)
PN	NAME	SN	OCENKA

 

 

Тогда можно говорить о том что имеется функциональная зависимость между множеством атрибутов {SN,PN} и {OCENKA}, то есть множеству пар кортежей номеров студенческих билетов и кодов предметов советует одно значение оценки по предмету.

Для первого случая рассмотрим определение функциональной зависимости, если R -некоторое отношение, а Х и Y некоторые подмножества множества атрибутов отношения R, то Y функционально зависима от Х при условии что каждое значение Х отношения R связанно с одним значением множества Y отношения R.

Например, в отношении SP все кортежи удовлетворяют условию {SN,PN} соответствует SP.

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

PN соответствует NAME выполняется для всех возможных отношений SP.

Таким образом если R является переменной от отношения а X Y некоторые подмножества множества атрибутов отношения R то Y функционально зависима от Х при условии что для любого допустимого значения R каждое значение Х связанно с одним значением множества Y.

Кроме того если Х является потенциальным ключом отношения R то все атрибуты Y отношения должны быть функционально зависимы от Х.

PN соответствует {PN,NAME,SN,OCENKA}.

Если же отношение R функциональной зависимости удовлетворяет функциональной зависимости где из Х -> Y но Х не является потенциальным ключом, то можно говорить об избыточности R.

Так в отношении R, PN сведения о фамилии студента повторяются каждый раз при вводе оценки.

Принципиально, некоторые функциональные зависимости могут означать существование некоторых других функциональных зависимостей. Например: зависимость {SN,PN}->SP означает и зависимости {SN,PN}->NAME и {SN,PN}->OCENKA

В более сложном случае, если имеется отношение R с тремя атрибутами X Y Z, то приусловии выполнения функциональных зависимостей из X ->Y и из Y->Z, очевидно, имеет место зависимость X->Z.

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

Таким образом изложенное выше понятие и определение позволяют перейти к вопросам нормализации БД.

 

 

Нормализация БД

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

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

В теории реляционных БД выделяется следующая последовательность нормальных форм:

· 1-я нормальная форма (1НФ);

· 2-я нормальная форма (2НФ);

· 3-я нормальная форма (3НФ);

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

· 4-я нормальная форма (4НФ);

· 5-я нормальная форма или нормальная форма проекции соединения (5НФ\НФПС).

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

Основные свойства нормальных форм:

1. Каждая следующая нормальная форма в некотором смысле лучше пред идущей;

2. При переходе к следующей нормальной форме свойства пред идущих нормальных форм сохраняется;

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

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

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

Допустим что отношение SP содержит всю информацию о студенческой группе.

SP
PN	NAME	SN	OCENKA

SP1(оценки)
OCENKA	SN	SPEC	GROUND	PN

 

SN

SPEC

Group

OCENKA

PN

Для SP1 имеем в качестве первичного ключа имеем комбинацию {SN,PN}. Кроме того, имеет место функциональная зависимость номера группы студента, и его специальности {GROUND ->SPEC} если построить диаграмму функциональных зависимостей для отношения SP1 то она будет иметь вид

 

Нежелательность такой структуры связанно с тем что не ключевые атрибуты не являются взаимно зависимыми, или с тем что не ключевые атрибуты не все неприводимо зависимы от первичного ключа.{GROUP и SPEC зависимы от SN каждый в отдельности}.

Кроме того возникают дополнительные проблемы связанные с избыточностью SP1.Так при выполнении операции INSERT (вставка) нельзя вставить данные о студентах и студенческой форме если ещё ими не сдавался экзамен, ведь для такого случая не будет известно значение первичного ключа. При выполнении операции удаления DELETE будет удалена информация о конкретной оценке студента по конкретному экзамену но информация о том в какой группе и на какой специальности этот студент учится.

Наконец при выполнении операции Update для которого студента при переводе его из одной группы в другую возникает ситуация когда мы будем вынуждены искать всю информацию об этом студенте внося соответствующие коррективы, либо в отношении будет иметь место несовместимый результат – один и тот же студенты будет одновременно находится в разных группах. Избежать этих ситуаций можно путём замены отношения SP1 на SP2,S

SN

GROUP

SPEC

OCENKA

PN

SN

 

SP2 SP

Такая структура позволяет выполнить без проблем операцию INSERT в отношение SP2, даже при отсутствии информации о сданных экзаменах.

Отношение находится во второй нормальной форме в том случае когда оно уже считается в первой нормальной форме, и каждый не ключевой атрибут полностью (неприводимо) зависит от первичного ключа. Кроме того всякое отношение которое находится в первой нормальной форме и не находится во второй нормальной форме всегда можно преобразовать и свести к нормальному набору отношений, находящихся во второй нормальной форме этот процесс заключается заменой отношения находящегося в первой нормальной форме набором проекций эквивалентных исходному соответственно соединение этих проекций даст исходное отношение. Отношение SP и SP2 находятся во 2НФ с первичным ключом соответственно SN и {SN,PN}. Действительно если над отношениями SP и SP2 произвести соединение по атрибуту SN то получим отношение SP1.

Однако в отношении SP2 из за функциональной зависимости Group -> SPEC всё равно могут возникнуть проблемы при манипуляции с данными. Так при выполнении операции вставка Insert нельзя указать что данная группа относится к некоторой специальности, пока в этой группе не появится хотя бы один студент. Если над отношением SP2 будет выполнена операция удаления DELETE То вместе с информацией о группе будет утрачена информация о специальности по которой проходит обучение данная группа. В тоже время при выполнении операции UPDATE обновление при изменении наименования специальности возникнет необходимость искать информацию обо всём отношении внося соответствующие изменения либо будет иметь место несовместимый результат. Для решения вновь возникших проблем, заменим SP2 на две проекции SG и GS.

SG
SN	GROUP

GS
SPEC	GROUP

 

 

SPEC

GROUP

GROUP

SN

Действительно путём декомпозиции была исключена двойная зависимость атрибута SPEC от первичного ключа SN и атрибута GROUP. Таким образом диаграмма функциональных отношений SG,GS будет иметь вид:

 

 

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

SG
SN	GROUP

GS
SPEC	GROUP

Отношения SG иGS находятся в 3НФ причём первичными ключами в них являются соответственно атрибуты SN и GROUP.

 

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

Введём определение детерминанта – это любой атрибут от которого полностью функционально зависит некоторый другой атрибут. Тогда отношение будет относится в НФБК если каждый детерминант является потенциальным ключом. Для рассмотренных выше примеров можно сказать что отношение SP1 не находится в НФБК а отношение SP, SG, GS находится в НФБК.

Действительно отношение SP1 содержит три детерминанта SN,GROUP и {SN,PN}. Из которых только SN, PN являются потенциальным ключом. Отсюда и сделан вывод что отношение SP1 не находится в НФБК.

Для отношений SP, SG, GS можно говорить что они находятся в НФБК поскольку в каждом из них единственный потенциальный ключ является единственным детерминантом.

 

PR(Предметы)
PN	GROUP	PZAN

 

 

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

Каждый кортеж отношения связывает некоторый предмет с курсом и заданием, которые должны быть выполнены в рамках данного курса. По причине сформулированных выше условий, единственным возможным ключом отношения является составной атрибут {PN,PNAME,PZAN} и нет никаких других детерминантов. Следовательно отношение ПРЕДМЕТЫ находится в НФБК. Но при этом оно обладает недостатками: если например некоторое задание добавляется в отношение ПРЕДМЕТЫ столько кортежей, столько заданий в нем предусмотрено.

Дело в том что в данном отношении существуют многозначные зависимости. В отношении R {A,B,C} Существует многозначная зависимость между А и В (А->->B) в том случае если множество значений В соответствующие паре значений А и С зависит только от А и не зависит от С.

В отношении ПРЕДМЕТЫ существуют следующие две многозначные зависимости

PN->->PNAMЕ PN->->PZAN.

Дальнейшая нормализация отношений, подобных отношению ПРЕДМЕТЫ, основывается на проектировании без потерь. Здесь под последним понимается такой способ декомпозиции отношения при котором исходное отношение полностью и без избыточности восстанавливается. Путём естественного соединения полученных отношений. Таким образом отношения находятся в 4 НФ в том случае если в случае существования многозначной зависимости А->->В все остальные атрибуты отношения многозначно зависят от А. R(A,B,C).

В нашем примере можно произвести декомпозицию отношения ПРЕДМЕТЫ,В два отношения PQ(ПРЕДМЕТЫ_КУРСЫ) PZ(ПРЕДМЕТЫ_ЗАДАНИЯ);

 

PQ
PN	PNAME

PZ
PN	PZAM

 

 

Оба полученных отношения находятся в 4НФ и свободны от отмеченных выше проблем. В рассмотренных до этого момента примерах была декомпозиция одного отношения в два. Иногда это сделать не удаётся, но возможна декомпозиция в большее число отношений, каждый из который обладает лучшими свойствами. Рассмотрим отношение P1 (ПРЕПОДАВАТЕЛИ):

P1(ПЕРПОДОВАТЕЛИ)
TEACHER	KAFEDRA	PNAME

 

 

Предположим что один и тот же преподаватель может работать на разных кафедрах и проводить занятия по нескольким предметам. Первичным ключом этого отношения является полная совокупность его атрибутов. {TEACHER,KAFEDRA,PNAME} В отношении отсутствуют функциональные и многозначные зависимости. Поэтому отношение находится в 4 НФ. Однако в нём могут существовать проблемы которые можно устранить путём декомпозиции в три отношения. Введём понятия зависимости соединения. Отношение R {x,y…,z} удовлетворяет зависимости соединения *{x,y,…,z}.

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

TK = {TEACHER, KAFEDRA}

TP={TEACHER,PNAME}

KP={KAFEDRA,PNAME}

Предположим что в отношении ПРЕПОДОВАТЕЛЬ существует зависимость соединений *(TK,TP,KP).

На примерах легко показать что при в ставках и удалении кортежей из ПРЕПОДОВАТЕЛЕЙ могут возникнуть проблемы. Их можно устранить путём декомпозиции исходного отношения на три новых отношения:

TK
TEACHER	KAFEDRA

 

TP
TEACHER	PNAME

 

TP
TEACHER	PNAME

 

 

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

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

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

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

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

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

 

Объектное моделирование.

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

При этом проявляется ограниченность реляционной модели данных в следующих моментах:

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

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

3. Хотя весь процесс проектирования базы данных происходит на основе учёта зависимости между данными. Реляционная модель не даёт каких либо средств для представления этих зависимостей.

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

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

Наиболее частыми на практике семантическое моделирование используется на первой стадии проектирования БД. При этом в терминах семантический модели производится концептуальная схема БД, которая затем преобразуется к реляционной схеме. Этот процесс выполняется под управлением методик, в которых достаточно чётко оговорены все этапы такого преобразования. В результате производится реляционная схема БД в 3НФ.

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

Рассмотри одну из наиболее важных и распространённых семантических моделей данных – модель «сущность – связи» (Часто её называют кратко ER- модель). На использование разновидностей ER моделей основано большинство современных подходов в проектировании реляционных БД.

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

Основными понятиями ER – модели является сущность, связь и атрибут.

ИНСТИТУТ Политехнический, Железнодорожный

Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. В диаграммах ER – модели сущность представляется в виде прямоугольника, содержащего имя сущности, при этом имя сущности - имя типа, а не некоторого конкретного элемента этого типа.

 

На рисунке приведена сущность ИНСТИТУТ с примерными объектами ПОЛИТЕХНИЧЕСКИЙ и ЖЕЛЕЗНОДОРОЖНЫЙ.

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

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

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

ЗАДАЧА

СТУДЕНТ

Пример: для

 

Решает

На рисунке приведён пример связи между сущностями ЗАДАЧА и СТУДЕНТ. При этом конец связи с именем «ДЛЯ» позволяет соединить с одним студентом более одной задачи, причём каждая задача должна быть связана с каким либо студентом. Конец сущности с именем «РЕШАЕТ» означает, что каждая задача может решаться только одним студентом, причём студент может не иметь задачи, трактовка изображённой диаграммы следующая каждая задача предназначена для одного студента, однако каждый студент может иметь одну или более задач.

ЧЕЛОВЕК

учащийся

 

 

студент

 

 

На рисунке изображена рекурсивная связь, соединяющая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем учащийся устанавливает тот факт, что человек может выступать один или несколько раз в жизни в роли учащегося. Конец связи c именем СТУДЕНТ означает что не каждый человек был студентом.

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

Как в реляционных схемах БД, в ER схемах вводится понятие нормальных форм, причём их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что к формулировки нормальных форм ER схем делают более понятными смысл нормализации реляционных схем. Приведём только очень краткие и неформальные определения трёх первых НФ.

В 1НФ ER- cхемы устраняются повторяющиеся атрибуты или группы атрибутов, то есть производится выявления не явных сущностей «замаскированных» под атрибуты.

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

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

К числу более сложных элементов ER модели относятся следующие:

· Подтипы и супер типы сущностей. Как в языках объектно- ориентированного программирования вводится возможность наследования типа сущности исходя из одного или нескольких супер типов.

· Связи «Многие со многими» иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущностей.

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

· Каскадные удаления экземпляров сущностей. Некоторые связи бывают на столько сильными что при удалении опорного экземпляра сущности (соответствующего концу связи 1) можно удалить и все экземпляры сущности, соответствующие концу связей «многие». Соответствующие требования «Каскадного удаления» можно сформулировать при определении сущности.

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

Эти и другие более сложные элементы модели данных «Сущность – связи» делают её существенно более мощной, но одновременно серьёзно усложняет её использование. Например, сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты, в подтипах могут определяться собственные атрибуты и связи, сущность, на основе которой определяются подтипы, называется супер типы.

Получение реляционной схемы из ER схемы осуществляется следующим образом:

· Каждая простая сущность превращается в отношение, простая сущности - сущность не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения.

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

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

· Связи «многие к одному» и «один к одному» становятся внешними ключами то есть делается копии уникального идентификатора с конца связи «1», и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам допускающий определённые значения. Обязательные связи - столбцам не допускающие неопределённые значения.

· Индексы создаются для первичного ключа, внешних ключей и тех атрибутов которые предполагается использовать в запросах;

· Если в концептуальной схеме присутствовали подтипы, то возможны два способа: все подтипы в одной таблице или для каждого подтипа - отдельная таблица. При применении первого отношение создаётся для наиболее внешнего супер типа, а для подтипов способа могут создаваться представления. В отношении добавляется по крайней мере один столбец содержащий ТИПА; он становится частью первичного ключа. При использовании второго метода для каждого подтипа 1 уровня (для более нижних представление) супер тип воссоздаётся с помощью представления.

· Имеется два способа работы при наличии исключающих связей: общий домен явные внешние ключи. Если остающиеся внешние ключи все в одном домене, то есть имеет общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключение. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи. Во втором случае, если результирующее внешние ключи не относятся к одному домену, то для каждой связи покрываемые дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределённые значения.

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

 

 

Функции и защита БД

Транзакции и параллелизм

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

Поддержание механизма транзакции – показатель уровня развитости СУБД. Корректное поддерживание транзакций одновременно является основой обеспечения целостности БД. Транзакции также составляют основу изолированности пользователей во многопользовательских системах.

Под транзакцией понимается неделимое с точки воздействия на БД последовательность операторов манипулирования данными (чтение, удаление, вставка, модификации) такая что возможны два итога: 1 Результаты всех операторов входящих в транзакцию соответствующе образом отражаются в БД. 2 Воздействие всех этих операторов отсутствует. В СУБД транзакция начинается с оператора begin. При этом если транзакция завершена оператором Commit, то результаты фиксируется во внешней памяти; при завершении транзакции ROLLBACK результаты отсутствуют во внешней памяти.

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