Модели данных

Информация, а также организация ее получения - основа проектирова­ния информационных систем. Для более эффективной организации данных применяются информационные модели. Модель данных (понятие которой впервые ввел в 1970 г. Кодд) отражает взаимосвязь между объектами.

База данных, как уже упоминалось, состоит из файлов (таблиц), которые связаны между собой, файлы - из записей и сохраняются на внешней памяти, запись - из полей (реквизитов). Реквизиты объединяются в запись в соответствии с определенными связями. Принцип связей между реквизитами (полями) определяет структуру базы данных. Применяются древовидная, сетевая и реляционная структуры.

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

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

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

Модель данных - это формально определенная структура представления данных (имитация структуры). Модель должна быть адекватной объекту управления. При проектировании информационных систем она отража­ется моделями данных, как минимум, в двух уровнях: логическая и физическая структура. Логическая структура есть представление логической организации данных в виде множества типов записей и связей между ними.

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

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

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

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

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

В начале 60-х гг., когда не было персональных компьютеров, применялись иерархическая и сетевая модели данных. В начале 70-х гг. появилась реляционная модель. Эти три модели различаются способами представления взаимосвязей между объектами.

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

Самая высокая вершина называется корнем (главный тип объекта), а остальные, находящиеся на нижних уровнях иерархии, — подчиненными. Корень (первый уровень) не подчиняется ни одной вершине. Все остальные вершины (типы объектов) связаны с одной и только одной вершиной, которая размещена на более высоком уровне. Взаимосвязь между объектами напоминает генеалогическое дерево (рисунок 2.3).

Взаимосвязь между главными и подчиненными объектами устанавливается типом «один-ко многим» (1:М). Как видно из схемы иерархической модели данных, ее древовидная структура состоит из узлов и дуг. Узел - совокупность атрибутов, которые описывают объект. Каждый объект характеризуется надежной совокупностью основных атрибутов. Например, объект «студент» может иметь такие атрибуты: фамилия, имя, отчество, номер группы и др.

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

Иерархическая модель данных — эффективное средство описания объектов с подобной структурой. В ней существует сильная зависимость между описанием структуры данных и способом их записи на внешние носители (диски).

Сетевая модель данных. Всетевой модели понятие главного и подчиненных объектов иное, чем в иерархической модели: любой объект здесь может быть и главным, и подчиненным; каждый объект может участвовать в любом количестве взаимосвязей (рисунок 2.4).

Данные представляются при помощи записей и связей. Запись (объект) в сетевой модели (в отличие от иерархической) может иметь множество как подчиненных ей записей, так и записей, которым она сама подчинена.

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

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

В этой модели объекты и взаимосвязи между ними представлены при помощи таблиц (рисунок 2.5). Одна таблица представляет один объект и состоит из столбцов и строк. Каждая строка таблицы представляет собой одну запись, а каждый столбец - одно поле записей. Таблица обладает следующими свойствами:

• каждый элемент таблицы (на пересечении строки и столбца) есть один элемент данных;

• столбцам присваиваются уникальные имена;

• элементы столбца имеют одинаковую природу (однородны);

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

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

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

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

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

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

• простота представления данных (таблица);

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

• независимость приложений пользователя от данных (при включении или удалении таблиц);

• возможность изменения состава атрибутных отношений;

• отсутствие необходимости описывать схемы данных (в иерархических и сетевых моделях — надо).

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

Двенадцать правил Кодда. Этим правилам, сформулированным Коддом, должна соответствовать реляционная СУБД [7, с. 64-65]:;.

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

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

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

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

5 Правило исчерпывающего подъязыка данных. Реляционная система может •поддерживать различные языки и режимы взаимодействия с пользователем (например, режим вопросов и ответов). Однако должен существовать, по крайней мере один язык, операторы которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает следующие элементы:

• определение данных;

• определение представлений;

• обработка данных (интерактивная и программная);

• условие целостности;

• идентификация прав доступа;

• границы транзакций (начало, завершение и отмена).

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

7 Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при чтении данных, но и при их добавлении, обновлении и удалении.

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

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

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

11 Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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