uzluga.ru
добавить свой файл
1
Лекция №07 - Модели данных

Описание: Иерархическая модель данных. Режимы исключения. Сетевая модель данных. Объектно-ориентированная модель данных. Объектно-реляционная модель данных. Постреляционная модель данных.

Содержание

  • 1 Модель данных

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

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

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

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

  • 2.1 Режимы исключения

  • 3 Сетевая модель данных

  • 4 Объектно-ориентированная модель данных

  • 5 Объектно-реляционная модель данных (Дополнительно)

    • 5.1 О предпосылках ОРСУБД

    • 5.2 Проблемы и перспективы ОРСУБД

  • 6 Постреляционная модель данных

  • 7 Источники и дополнительная литература

    • 7.1 Дополнительная литература

    • 7.2 Источники






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

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

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

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

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

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

Цель построения модели данных заключается в представлении данных в понятном виде. Если такое представление возможно, то модель данных можно легко применить при проектировании базы данных.

Модели данных подразделяются на три категории:

  • объектные (object-based) модели данных,

  • модели данных на основе записей (record-based),

  • физические модели данных.

Первые две используются для описания данных на концептуальном и внешнем уровнях, а последняя — на внутреннем уровне.


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

При создании объектных моделей данных используются следующие понятия:

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

  • Атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать.

  • Связь — это ассоциативное отношение между сущностями.

Ниже перечислены некоторые наиболее общие типы объектных моделей данных.

  • Модель типа "сущность-связь", или ER-модель (Entity-Relationship model).

В настоящее время ER-модель стала одним из основных методов концептуального проектирования баз данных.

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

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

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

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


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

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

Существуют три основных типа логических моделей данных на основе записей:

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

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

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



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

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


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





Представление связей в иерархической модели.

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

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

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

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

Также можно встретить следующее описание типов иерархической модели.

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

К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией. Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями, а также сложность понима­ния для обычного пользователя.

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

Режимы исключения.

    1. Фиксированное

    2. Обязательное

    3. Необязательное



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

Сетевая модель данных – модель, состоящая из записей, элементов данных и связей типа “один ко многим” (1:М), установленных между записями.

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

Для описания схемы сетевой БД используется две группы типов: "запись" и "связь". Тип "связь" определяется для двух типов "запись": предка и потомка. Переменные типа "связь" являются экземплярами связей.

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

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах.





Представление связей в сетевой модели

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

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

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

Системы на основе сетевой модели не получили широкого распространения на практике.

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

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. ООСУБД использую точно такую же модель, что и объектно-ориентированные языки программирования.

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

В манифесте ООБД (Atkinson et al., 1989) предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой БД.

Три класса характеристик:

  • Обязательные.

  • Необязательные.

  • Открытые — позволяют пользователю выбирать свойства.

СУБД

  • Долговременное хранение

  • Использование внешней памяти

  • Параллелизм

  • Восстановление

  • Нерегламентированные запросы

ОО характеристики

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

  2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.

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

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

  5. Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.

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

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

  8. Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.

Необязательные:

  • Множественное наследование

  • Проверка типов

  • Распределение

  • Проектные транзакции

Открытые

  • Парадигмы программирования (процедурное, декларативное)

  • Система представления

  • Система типов

  • Однородность. Реализация — язык программирования — интерфейс.



Объектно-реляционная модель данных (Дополнительно)

О предпосылках ОРСУБД

Эпоха объектно-реляционных баз данных началась десять лет назад, когда в декабре 1996 года компания Informix выпустила объектно-реляционную систему управления базами данных (ОРСУБД) Informix Universal Server. Вслед за ней в 1997 г. на рынке появились ОРСУБД компаний Oracle (Oracle8) и IBM (DB2 Universal Database). До появления ОРСУБД ведущих компаний термин «объектно-реляционная СУБД» связывался с системами Postges-Illustra и UniSQL, разработанными под руководством Майкла Стоунбрейкера и Вона Кима соответственно. (Лишнее)

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

В соответствии с подходом UniSQL, в ОРСУБД должны поддерживаться следующие возможности:

  • n-мерное объектно-ориентированное моделирование;

  • двухмерное реляционное моделирование;

  • наследование;

  • инкапсуляция;

  • постоянство существования объектов (object persistence);

  • композиция классов;

  • полиморфизм;

  • навигационный доступ к объектам;

  • реляционный доступ (соединения);

  • непроцедурный доступ через запросы;

  • интерфейсы для традиционных языков третьего поколения;

  • интерфейсы для объектных языков третьего поколения;

  • интерфейсы для языков четвертого поколения;

  • независимое от языков хранение данных;

  • независимость служб баз данных от файловых систем;

  • поддержка оперативных служб СУБД.

С методологической точки зрения на развитие основного объектно-реляционного подхода и соответствующих средств, специфицированных в стандарте языка SQL, важнейшее влияние оказал Манифест систем баз данных третьего поколения, опубликованный группой авторов под очевидным руководством Майкла Стоунбрейкера в 1990 г. В этом документе постулировались три основных принципа систем следующего поколения:

  • помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил;

  • СУБД третьего поколения должны включить в себя СУБД второго поколения;

  • СУБД третьего поколения должны быть открыты для других подсистем.

Эти принципы развивались в тринадцати технических предложениях, включающих обеспечение развитой системы типов с поддержкой наследования и инкапсуляции. Если внимательно посмотреть на стандарты SQL:1999 и SQL:2003, а также на возможности современных версий СУБД DB2 и Oracle, то можно увидеть отражение в них всех принципов и предложений Манифеста систем баз данных третьего поколения.


Проблемы и перспективы ОРСУБД

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

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

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

Другими словами, аскетичность подхода Кодда, выраженная в классической реляционной модели данных, оказывается пока понятнее и полезнее богатства современной модели данных SQL (думаю, что это равно применимо к объектной модели ODMG и «истинно реляционной» модели Дейта и Дарвена). Для полноценного использования этого богатства требуются понятные и обоснованные методологии.


Постреляционная модель данных

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

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

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

Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.

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

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

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