Реляционная модель данных. Основные понятия и определения

Модели данных. Классификация.

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

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

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

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

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

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

Объектные модели данных

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

– Модель типа "сущность-связь", или ER-модель.

– Семантическая модель.

– Функциональная модель.

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

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

Модели данных на основе записей

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

– реляционная модель данных (relation data model),

– сетевая модель данных (network data model)

– иерархическая модель данных (hierarchical data model).

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

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

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

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

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

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

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

Физические модели данных

Физические модели данных описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Физических моделей данных не так много, как логических, а самыми популярными среди них являются обобщающая модель (unifying model) и модель па­мяти кадров (frame memory).

Концептуальное моделирование

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

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

5. Этапы разработки информационной структуры базы данных

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

1) Планирование разработки БД. Цель – максимально эффективно реализовать в дальнейшем все этапы жизненного цикла БД и приложений, оптимизировать объем работы, используемые ресурсы, стоимость. На этом этапе производится системный анализ предметной области (структурированность информации, динамичность изменений, характер использования).

2) Определение требований к системе, диапазона действия приложений, состава пользователей и областей применения.

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

4) Концептуальное проектирование, системный анализ объектов и связей:

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

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

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

г) Строится ER – диаграмма. Состав сущностей уточняется, они наделяются точными характеристиками, определяются типы связей между ними. Задаются первичные и внешние ключи.

д) Производится нормализация ER – диаграммы. Обычно нормализация проводится до третьей нормальной формы. При этом количество сущностей увеличивается (декомпозиция отношений).

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

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

После разработки информационной структуры базы данных ее жизненный цикл продолжается созданием приложений, разработкой интерфейса пользователя, прикладных программ. При этом пользователю могут предоставляться для опробования приложения БД, обладающие не полным набором функциональных возможностей – прототипы. После опробования могут быть повторены некоторые этапы для корректировки информационной структуры БД. Реализация приложений производится на языке целевой СУБД: MS SQL Server, Oracle, FoxPro или систем программирования Delphi, VB, C++ и т.д. Разработанные приложения проходят этапы тестирования и отладки, в результате которых может выявиться необходимость дополнительной доработки информационной структуры БД. Этот процесс может продолжаться и в ходе эксплуатации БД.

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

Типы реляционных БД:

– Многофайловая модель

– Однофайловая модель

– Репозитарий БД

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

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

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

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

Основные понятия и определения.

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

Структура реляционных данных

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

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

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

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

Степень – степень отношения определяется количеством атрибутов, кото­рое оно содержит. Отношение только с одним атрибутом имеет степень 1 и называется унарным отношением (или 1-арным кортежем). Отношение с двумя атрибутами называется бинарным, отноше­ние с тремя атрибутами - тернарным, а для отношений с большим количеством атрибутов используется термин n -арный (n-аrу). Определение степени отноше­ния является частью заголовка отношения.

Кардинальность – это количество кортежей, которое содержит отношение.

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

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

Дата добавления: 2015-05-09