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

Размещено на http://www.allbest.ru

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

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

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

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

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

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

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

1.объектные (object-based) модели данных, 2. модели данных на основе записей (record-based), 3.физические модели данных.

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

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

Даталогические - служат для описания структур данных в виде зависимом от используемой СУБД.

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

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

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

Недостатки:

1)сложность реализации и управления 2) сложность программирования и использования приложений 3) малая стандартизация Преимущества: 1) простота идеи 2) безопасность 3) независимость и целостность данных 4) эффективность

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

интегрированный реляционный сетевой связь

2. Сетевая модель. Модель данных «сущность-связь»

2.1 Сетевая модель

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

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

Сетевая модель - это структура, у которой любой элемент может быть связан с любым другим элементом.

Достоинства: Возможность образования произвольных связей и быстрый доступ к данным.

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

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

В сетевой модели данных понятие главного и подчиненного объектов несколько расширены. Любой объект может быть главным и подчиненным. Один и тот же объект может выступать и в роли "владельца" и в роли "подчиненного".

2.2 Модель "сущность - связь"

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

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

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

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

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

3. Реляционная модель. Постреляционная модель

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

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

Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных, которое именуется, как отношение. Строка таблицы носит название картежа, а столбец - атрибута.

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

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

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

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

Отношения обладают следующими важными свойствами: * в них нет одинаковых кортежей; * кортежи не упорядочены сверху вниз; * атрибуты не упорядочены слева на право; * все значения атомарны, т.е. отношения нормализированы.

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

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

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

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

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

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

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

4.1 Многомерная модель

Многомерный подход к представлению данных появился практически одновременно с реляционным, но интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов. Толчком послужила в 1993 году статья Э. Кодда. В ней были сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing - оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных.

В развитии концепций информационных систем можно выделить следующие два направления:

1) системы оперативной (транзакционной) обработки;

2)системы аналитической обработки (системы поддержки принятия решений).

Реляционные СУБДпредназначались для информационных систем оперативной обработки информации и в этой области весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД.

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

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

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

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

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

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

Стандартизированная объектно-ориентированная модель описана в рекомендациях стандарта ODMG -93 (Object Database Management Group - группа управления объектно-ориентированными базами данных). Рассмотрим упрощенную модель объектно-ориентированной БД.

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

Свойства объектов описываются некоторым стандартным типом или типом, конструируемым пользователем (определяется как class). Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса.

Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство.

Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.

5. Объектно-реляционная модель. Физическая модель данных

5.1 Объектно-реляционная модель

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

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

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

Сегодня практически все известные фирмы используют объектные технологии. IBM и Oracle доработали свои СУБД (DB2 и ORACLE8), соответственно, добавив объектную надстройку над реляционным ядром системы, т.е. преобразовали их в объектно-реляционные СУБД. Informixприобрела объектно-реляционную СУБД Illustra и встроила ее в свою СУБД, изменив ее название на универсальный сервер.

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

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

К вопросам организации данных относятся: * выбор типа записи - единицы обмена в операциях ввода-вывода; * выбор способа размещения записей в файле и, возможно, метода оптимизации размещения; * выбор способа адресации и метода доступа к записям. Стадия физического проектирования БД в общем случае включает: * выбор способа организации БД; * разработку спецификации внутренней схемы; * писание отображения концептуальной схемы во внутреннюю. В отличие от ранних СУБД, многие современные системы не предоставляют разработчику какого-либо выбора на этой стадии. Реально к вопросампроектирования физической модели можно отнести: * выбор схемы размещения данных (разделение по файлам или тип RAID-массива); * определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).

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

Литература

1.http://www.e-reading.link/chapter.php/97791/123/Kozlova_-_Informatika__konspekt_lekciii.html

2.http://iu5bmstu.ru

3.С.Д. Кузнецов Базы данных, Академия, 2012 4. М.П. Малыхина Базы данных. Основы, проектирование, использование, БХВ-Петербург, 2006

Размещено на Allbest.ru