Глава 6. Типы моделей данных

 

Ядром любой базы данных является модель данных.

Модель данных – совокупность структурированных данных и операций их обработки.

Существуют четыре модели данных - списки, иерархическая, сетевая, реляционная.

Базы данных можно разделить на:

F        БД первого поколения – иерархические, сетевые;

F        БД второго поколения – реляционные;

F        БД третьего поколения – объектно-ориентированные, объектно-реляционные.

 

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

 

Наиболее давно используемой (можно сказать классической) является модель данных, в основе которой лежит иерархическая структура типа дерева (рис.2.40). Дерево — это орграф, в каждую вершину которого кроме первой (корневой) входит только одна дуга, а из любой вершины (кроме конечных) может исходить произвольное число дуг. В иерархической структу­ре подчиненный элемент данных всегда связан только с одним исходным.

Рис.2.40. Иерархическая модель данных

 

Достоинства такой модели несомненны: простота представления предметной области, наглядность, удобство анализа структур эта их описания. К недостаткам следует отнести сложность добавления новых и удаления существующих типов записей, невозможность отображения отношений, отличающихся от иерархических, громоздкость описания и информационную избыточность. Характерные примеры реализации иерархических структур —  язык COBOL и СУБД семейства IMS  и System 2000 (S2K). .

 

6.2. Сетевая модель данных

 

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

Рис. 2.41.Сетевая модель данных

 

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

 

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

 

 

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

 

Реляционная модель была предложена Э.Ф.Коддом (Е.F. Codd) в начале 70-х гг. XX в., и вместе с иерархической и сетевой моделями составляет множество, так называемых великих моделей.

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

F   вся информация в базе данных представлена в виде таблиц.

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

Доктор Э.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «12 правилами Кодда». Чтобы считаться реляционной по Кодду, система управления базами данных должна:

F        представлять всю информацию в виде таблиц;

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

F        использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных;

F        поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;

F        поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах;

F        различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных;

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

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

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

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

Формальный реляционный термин

Неформальный эквивалент

Отношение

Таблица, объект, сущность

Кортеж

Запись, строка

Атрибут

Поле, столбец

 

Определение любой модели данных требует описания трех эле­ментов:

F   определение типов (структур) данных;

F   определение операций над данными;

F   определение ограничений целостности.

 

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

 

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

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

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

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

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

F   выборка;

F   проекция;

F   декартово произведение;

F   объединение;

F   разность. 

На основании пяти основных операций можно также вывести дополнительные операции, такие, как  операции

F   соединения;

F   пересечения;

F    деления.

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

F   множество объектов реляционной модели БД однородно - структура БД определяется только в терминах отношений;

F   основная единица обработки в операциях реляционной модели не запись, а множество записей – отношение.

 

6.3.2. Ограничения целостности

 

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

Различают внутренние и явные ограничения.

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

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

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

Реляционная таблица представляет собой двумерный массив, обладающая определёнными свойствами, которые и определяют внутренние ограничения целостности данных:

F   каждый элемент таблицы – один элемент данных;

F    все столбцы в таблице однородны, то есть все элементы в столбце имеют одинаковый тип;

F    каждый столбец имеет уникальное имя;

F    одинаковые строки в таблице отсутствуют;

F    порядок следования строк и столбцов может быть произвольным.

Данные свойства реляционных таблиц основаны на свойствах математических отношений реляционной алгебры:

F   поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок записей в отношении несущественен;

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

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

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

 

6.4. Нормализация модели данных

 

Одним из принципов проектирования модели данных является ее нормализация — т. е. приведение модели данных к нормальной форме. Это позволяет устранить избыточность хранимой информации и из­бежать аномалий в организации данных. Степень нормализации может быть различной. Результатом нормализации является легко поддерживаемая модель данных, не содержащая неопределенностей и повторений данных.

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

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

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

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

Нормальная форма Бойса—Кодда (усиленная 3 НФ). Отношение (таблица)  на­ходится в НФ Бойса — Кодда, если любая функциональная зави­симость между его полями сводится к полной функциональной зависимости от первичного ключа.

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

Помимо описанных выше нормальных форм, используется 4 НФ, основанная на понятии обобщенной функциональной зависимо­сти. На практике, приведя все отношения (таблицы) к нормальной форме Бойса — Кодда, можно с большой долей уверенности утверж­дать, что они находятся и в 5 НФ, т. е. что нормализация БД завершена.

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

Необходимость нормализации файлов БД  определяется еще по крайней мере двумя обстоятельствами:

F                                     желание группи­ровать данные по их содержимому - позволяет упростить мно­гие процедуры в БД — от организации разграничения доступа до повышения оперативности поиска данных;

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

 

Вернуться к выбору                                  На главную страницу