Таблица 2.3. Терминология баз данных
 Теория БД____________ Реляционные БД_________ SQL Server __________
Отношение (Relation) Таблица (Table) Таблица (Table)
Кортеж (Tuple) Запись (Record) Строка (Row)
Атрибут (Attribute) Поле (Field)_______________ Столбец или колонка (Column)
Реляционные базы данных
Реляционная база данных — это совокупность отношений, содержащих всю ин формацию, которая должна храниться в базе данных. То есть база данных пред ставляет набор таблиц, необходимых для хранения всех данных. Таблицы реля ционной базы данных логически связаны между собой.Требования к проектированию реляционной базы данных в общем виде можно свести к нескольким правилам.
О Каждая таблица имеет уникальное в базе данных имя и состоит из однотипных строк.
О Каждая таблица состоит из фиксированного числа столбцов и значений. В одном столбце строки не может быть сохранено более одного значения. Например, если есть таблица с информацией об авторе, дате издания, тираже и т. д., то в столбце с именем автора не может храниться более одной фамилии. Если книга написана двумя и более авторами, придется использовать дополнительные таблицы.
О Ни в какой момент времени в таблице не найдется двух строк, дублирующих друг друга. Строки должны отличаться хотя бы одним значением, чтобы была возможность однозначно идентифицировать любую строку таблицы.
О Каждому столбцу присваивается уникальное в пределах таблицы имя; для него устанавливается конкретный тип данных, чтобы в этом столбце размещались однородные значения (даты, фамилии, телефоны, денежные суммы и т. д.).
О Полное информационное содержание базы данных представляется в виде яв ных значений самих данных, и такой метод представления является единствен ным. Например, связь между таблицами осуществляется на основе хранимых в соответствующих столбцах данных, а не на основе каких-либо указателей, искусственно определяющих связи.
О При обработке данных можно свободно обращаться к любой строке или лю бому столбцу таблицы. Значения, хранимые в таблице, не накладывают ни каких ограничений на очередность обращения к данным. Описание столбцов,
Нормализация и ее необходимость
При проектировании структуры базы данных заказчик часто предоставляет раз работчику описание форм и бланков, существующих в бумажном виде. Поэто му, прежде чем приступать к проектированию таблиц для БД, необходимо вы яснить цели проектирования. К ним относятся:
О возможность хранить все необходимые данные в БД;
О исключение избыточности данных;
О необходимость свести количество хранимых таблиц к .минимуму.
При простом переносе полей бумажных форм в таблицы базы данных неиз бежно возникнет ряд проблем — даже для простых двумерных структур прихо дится изменять состав полей
( В дальнейшем при проектировании базы данных эта универсальная таблица может быть разбита на несколько таблиц, имеющих более простую структуру и связанных друг с другом.
Нормализация таблиц — это формальный аппарат ограничений на формиро вание таблиц, описывающий разбиение таблиц на две или более частей и обес печивающий применение лучших методов добавления, изменения и удаленияданных; или еще проще — процесс представления данных в виде простых дву мерных таблиц, который позволяет устранить дублирование этих данных и обес печивает непротиворечивость хранимых в базе данных. Таким образом,окончательной целью нормализации является получение такого проекта базы данных, в котором любая часть информации хранится лишь в одном месте, то есть исключается избыточность информации. Это делается не столько с цельюэкономии места (в некоторых случаях нормализованные таблицы занимают боль ше места, чем ненормализованные), сколько для исключения возможности проти воречий в хранимых данных. Если исходить из структуры данных, то нормализациейназывается процесс превращения сетевой или иерархической структуры данных в реляционную.
Основой процесса нормализации является предложенный Е. Коддом в рам ках реляционной теории аппарат, называемый нормализацией отношений. Им выделено три формы нормальных отношений, которые в дальнейшем были до работаны, и предложен механизм перехода от формы к форме, а кроме того было добавлено еще три специальных формы. Итого, существует шесть форм „ нормальных отношений. Но, как правило, необходимо и достаточно привести базу данных к третьей нормальной форме.
Таблица считается нормализованной на определенном уровне, когда она удов летворяет условиям, накладываемым соответствующей формой нормализации. Процесс нормализации представляет собой последовательное изменение струк туры таблиц до тех пор, пока она не будет удовлетворять требованиям после дней формы нормализации. Существуют следующие шесть форм нормализации: О первая нормальная форма (First Normal Form, INF);
О вторая нормальная форма (Second Normal Form, 2NF);
О третья нормальная форма (Third Normal Form, 3NF);
О нормальная форма Бойса - Кодда (Brice - Codd Normal Form, BCNF);
О четвертая нормальная форма (fourth Normal Form, 4NF);
О пятая нормальная форма, или нормальная форма проекции-соединения (Fifth Normal Form, 5NF или PJ/NF).
При описании нормальных форм используется несколько понятий.
О Функциональной зависимостью между полями A и В называется зависимость, при которой каждому значению А в любой момент времени соответствует единственное значение В из всех возможных. Примером функциональной за висимости может служить связь реки и моря, так как одна река впадает в единственное море и с течением времени эта связь не меняется.
О Полной функциональной зависимостью между составным полем А и полем В называется зависимость, при которой поле В зависит функционально от поля А и не зависит функционально от любого подмножества поля А.
О Многозначная функциональная зависимость. Поле А однозначно определяет поле В, если для каждого значения поля А существует хорошо определенное множество соответствующих значений поля В. Например, если рассматривать таблицу предметов и оценок учеников в школе, то поле с оценкой имеет хо рошо определенное множество допустимых значений (1, 2, 3, 4, 5). Кроме того, количество предметов в школе также ограничено.
О Транзитивная функциональная зависимость между полями А и С наблюдает ся в том случае, если поле В функционально зависит от поля А и поле С функ ционально зависит от поля В. В то же время не существует функциональнойзависимости поля А от поля В.
О Несколько полей взаимно независимы, если ни одно из них не является функ ционально зависимым от другого поля.
О Неключевым полем таблицы называется каждое поле, не входящее в состав первичного ключа.
Первая нормальная форма
Таблица находится в первой нормальной форме тогда, когда она не содержит повторяющихся полей и составных значений полей (то есть каждое поле долж но содержать одно значение, а не их комбинацию).
Вторая нормальная форма
Таблица находится во второй нормальной форме, если она удовлетворяет требовани ям первой нормальной формы и все ее поля, не входящие в первичный ключ, связа ны полной функциональной зависимостью с первичным ключом, то есть любое неключевое поле однозначно идентифицируется полным набором ключевых полей.
Итак, таблица, находящаяся во второй нормальной форме, должна удовле творять следующим правилам:
О таблица должна содержать данные об одном типе объектов;
О каждая таблица должна содержать одно поле или несколько полей, образую щих уникальный идентификатор (или первичный ключ) для каждой строки;
О все поля, не имеющие ключа, должны определяться полным уникальным иден тификатором данной таблицы.
Если таблица имеет простой первичный ключ, состоящий только из одного
Третья нормальная форма
Таблица находится в третьей нормальной форме, если она удовлетворяет опре делению второй нормальной формы и ни одно из ее неключевых полей функ ционально не зависит от любого другого неключевого поля. Можно сказать, чтотаблица находится в третьей нормальной форме, если она находится во второй нормальной форме и каждое неключевое поле нетранзитивно зависит от пер вичного ключа.
Требование третьей нормальной формы сводится к тому, чтобы все нёключевые поля зависели только от первичного ключа и не зависели друг от друга. Другими словами, нужно иметь возможность изменять значение любого неключевого поля, не изменяя значения любого другого поля базы данных. Это требо вание исключает любое поле, значения в котором получаются как результат вычислений, использующих значения других полей.
Лекция 6. Распределенные базы данных
Основная задача систем управления распределенными базами данных состоит в обеспечении средства интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных как к единой базе данных.
При этом должны обеспечиваться:
· простота использования системы;
· возможности автономного функционирования при нарушениях связности сети или при административных потребностях;
· высокая степень эффективности.
Возможны однородные и неоднородные распределенные базы данных. В однородном случае каждая локальная база данных управляется одной и той же СУБД. В неоднородной системе локальные базы данных могут относиться даже к разным моделям данных. Сетевая интеграция неоднородных баз данных - это актуальная, но очень сложная проблема. Многие решения известны на теоретическом уровне, но пока не удается справиться с главной проблемой - недостаточной эффективностью интегрированных систем.
Заметим, что более успешно практически решается промежуточная задача - интеграция неоднородных SQL-ориентированных систем. Понятно, что этому в большой степени способствует стандартизация языка SQL и общее следование производителей СУБД принципам открытых систем.
Мы ограничимся рассмотрением проблем однородных распределенных СУБД на примере System R*.
Распределенная система управления базами данных System R
Основную цель проекта можно сформулировать следующим образом: обеспечить средства интеграции локальных баз данных System R, располагающихся в узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных так, как если бы они были централизованы. При этом должны обеспечиваться:
· легкость использования системы;
· возможности автономного функционирования при нарушениях связности сети или при административных потребностях;
· высокая степень эффективности.
Для решения этих проблем было необходимо принять ряд проектных решений, касающихся декомпозиции исходного запроса, оптимального выбора способа выполнения запроса, согласованного выполнения транзакций, обеспечения синхронизации, обнаружения и разрешения распределенных тупиков, восстановления состояния баз данных после разного рода сбоев узлов сети.
Легкость использования системы достигается за счет того, что пользователи System R (разработчики прикладных программ и конечные пользователи) остаются в среде языка SQL, т.е. могут продолжать работать в тех же внешних условиях, что и в System R (и SQL/DS и DB2). Возможность использования SQL основывается на обеспечении System R прозрачности местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в запросе пользователя объектов данных; одна и та же прикладная программа, включающая предложения SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запроса в соответствии с расположением данных в распределенной системе.
Обеспечению автономности узлов сети в System R уделяется очень большое внимание. Каждая локальная база данных администрируется независимо от других. Возможны автономное подключение новых пользователей, смена версии автономной части системы и т.д. Система спроектирована таким образом, что в ней не требуются централизованные службы именования объектов или обнаружения тупиков. В индивидуальных узлах не требуется наличие глобального знания об операциях, выполняющихся в других узлах сети; работа с доступными базами данных может продолжаться при выходе из строя отдельных узлов сети или линий связи.
Высокая степень эффективности системы является одним из наиболее ключевых требований к распределенным системам управления базами данных вообще и к System R в частности. Для достижения этой цели используются два основных приема.
Во-первых, в System R выполнению запроса предшествует его компиляция. В ходе этого процесса производится поиск употребляемых в запросе имен объектов баз данных в распределенном каталоге и замена имен на внутренние идентификаторы; проверка прав доступа пользователя, от имени которого производится компиляция, на выполнение соответствующих операций над базами данных и выбор наиболее оптимального глобального плана выполнения запроса, который затем подвергается декомпозиции и по частям рассылается в соответствующие узлы сети, где производится выбор оптимальных локальных планов выполнения компонентов запроса и происходит генерация модулей доступа в машинных кодах. В результате множество действий производится на стадии компиляции до реального выполнения запроса. Обработанная посредством прекомпилятора System R прикладная программа, включающая предложения SQL, может в дальнейшем выполняться много раз без дополнительных накладных расходов. Использование распределенного каталога, распределенная компиляция и оптимизация запросов являются наиболее интересными и оригинальными аспектами проекта System R.
Вторым средством повышения эффективности системы является возможность перемещения удаленных отношений в локальную базу данных. Диалект SQL, используемый в System R, включает предложение MIGRATE TABLE, при выполнении которого указанное отношение переносится в локальную базу данных. Это средство, находящееся в распоряжении пользователей, конечно, в ряде случаев может помочь добиться более эффективного прохождения транзакций. Естественно, как и для всех операций, операция MIGRATE по отношению к указанному отношению доступна не любому пользователю, а лишь тем, которые обладают соответствующим правом.
Прежде, чем перейти к более детальному изложению наиболее интересных аспектов реализации System R, упомянем некоторые средства, которые разработчики этой системы предполагали реализовать на начальной стадии проекта, но которые реализованы не были (причем некоторые из них, видимо, и не будут никогда реализованы). Предполагалось иметь в системе средства горизонтального и вертикального разделения отношений распределенной базы данных, средства дублирования отношений в нескольких узлах с поддержкой согласованности копий и средства поддержания мгновенных снимков состояния баз данных в соответствии с заданным запросом.
Как и в случае разделенных отношений, кроме существенных проблем поддержания согласованности копий, проблемой является и разумное использование копий, наличие которых должно было бы учитываться оптимизатором.
Создание мгновенного снимка состояния баз данных в соответствии с заданным запросом на выборку должно было производиться с использованием новой конструкции SQL.
DEFINE SNAPSHOT ()
AS
REFRESHED EVERY
При выполнении предложения фактически производится выполнение указанного в нем запроса на выборку, а результирующее отношение сохраняется под указанным в предложении именем в локальной базе данных в том узле, в котором выполняется предложение. После этого мгновенный снимок периодически обновляется в соответствии с запомненным запросом.
Можно обновить мгновенный снимок, не дожидаясь истечения временного интервала, указанного в определении, путем выполнения предложения REFRESH SNAPSHOT .
Разумное использование мгновенных снимков более реально, чем использование разделенных отношений и копированных отношений, поскольку их можно в некотором смысле рассматривать как материализованные представления базы данных. Имя мгновенного снимка можно было бы использовать прямо в запросе на выборку там, где можно использовать имена базовых отношений или представлений. Большие проблемы связаны с обновлением отношений через их мгновенные снимки, поскольку в момент обновления содержимое мгновенного снимка может расходиться с текущим содержимым базового отношения.
По отношению к мгновенным снимкам проблем поддержания согласованного состояния мгновенного снимка и базовых отношений не существует, поскольку автоматическое согласование не требуется. Что же касается разделенных отношений и раскопированных отношений, то для них эта проблема общая и достаточно трудная. Во-первых, согласование разделов и копий вызывает существенные накладные расходы при выполнении операций модификации хранимых отношений. Для этого требуется выработка и соблюдение специальных протоколов модификации.
Во-вторых, введение копированных отношений обычно производится не столько для увеличения эффективности системы, сколько для увеличения доступности данных при нарушении связности сети. В системах, в которых применяется этот подход, при нарушении связности сети работа с распределенной базой данных обычно продолжается только в одной из образовавшихся подсетей. При этом для выбора подсети используются алгоритмы голосования; решение принимается на основе учета количества связных узлов сети. Применяются и другие подходы, но все они очень дорогостоящие, а самое главное, они плохо согласуются с базовым подходом System R по поводу выбора способа выполнения запроса на стадии его компиляции. Поэтому, как нам кажется, в System R никогда не будут реализованы средства, позволяющие тем или иным способом поддерживать копии отношений в нескольких узлах сети.
|
