Модели данных (Основы проектирования баз данных)

Содержание:

Введение

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

• аспект структуры: методы описания типов и логических структур данных в базе данных;
• аспект манипуляции: методы манипулирования данными;
• аспект целостности: методы описания и поддержки целостности базы данных.

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

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

Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т. д.

О терминологии

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

М. Р. Когаловский поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных». В настоящее время в научной литературе термин «модель данных» трактуется в подавляющем большинстве случаев в инструментальном смысле (как инструмент моделирования).

Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных» он определил модель данных как комбинацию трёх компонентов:

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

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

Мы остановимся на более подробном рассмотрении некоторых из них.

Иерархическая сетевая модель строится в виде древовидной структуры. При поиске данных дерево всегда просматривается сверху вниз. Первой СУБД, построенной на базе иерархической модели, стала система IMS, представленная компанией IBM в 1968 г.

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

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

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

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

Реляционная модель данных для СУБД имеет строгое математическое обоснование в виде теории множеств (реляционная алгебра) и исчислении предикатов (реляционное исчисление).

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

Тип данных – аналог типа данных в языках программирования. В современных реляционных БД это символьные, числовые, битовые строки, дата и время.

Домен – допустимое потенциальное множество значений данного типа (например, домен "Телефоны" определен как строка символов, но число его значений ограничено только геми строками, которые могут изображать телефонный номер).

Атрибут – величина, характеризующая свойство объекта, явления, процесса.

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

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

Можно выделить следующие основные правила формирования отношений в форме таблиц:

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

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

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

Характерные особенности реляционных СУБД – это ненавигационность и обеспечение целостности.

К достоинствам реляционной модели можно отнести:

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

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

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

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

К числу СУБД, поддерживающих реляционную модель, относятся MS Access, Dbase, FoxPro, Clipper и др.

Для преодоления недостатков реляционной модели развиваются постреляционная, многомерная и объектно-ориентированная модели.

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

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

К числу СУБД, поддерживающих постреляционную модель, относятся uniVers, Bubba, Dasdb.

Объектно-ориентированная база данных (ООБД) – база данных, основанная на принципах объектно-ориентированной технологии.

Понятийный аппарат ООБД включает:

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

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

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

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

Объектно-ориентированные возможности появляются в ведущих современных СУБД (Oracle, Poet, Versant, Objectivity).

• [1] В них вводится понятие текущего дерева, текущей записи, и перемещение при поиске может осуществляться путем перехода вдоль связи от текущего объекта к следующему.

• [2] Теорию реляционных баз данных, свободную от недостатков прежних моделей, разработал сотрудник исследовательской лаборатории компании IBM Э. Ф. Кодд и в 1970 г. опубликовал статью, посвященную краткому описанию новой модели.

В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными») от компании Computer Associates international Inc. — пример сетевой СУБД.

Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL).

Основной элемент сетевой модели данных — набор, который состоит из типа «запись-владелец», имени набора и типа «запись-член». Запись подчинённого уровня («запись-член») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является «владельцем» (от него отходит «стрелка» связи), и один или более типов записи являются «членами» (на них указывает «стрелка»). Обычно в наборе существует отношение 1:М, но разрешено и отношение 1:1. Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных:

• TurboIMAGE;
• IDMS;
• Встроенная RDM;
• Серверная RDM.

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

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

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server.

«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более».

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

Реляционные таблицы обладают следующими свойствами:

• Все значения атомарны.
• Каждый ряд уникален.
• Порядок столбцов не важен.
• Порядок рядов не важен.
• У каждого столбца есть своё уникальное имя.

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

Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы» может содержать пары «ID-покупателя» и «код-товара». А в таблице «Товар» могут быть пары «код-товара» и «цена». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара» этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

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

Сравнение трёх моделей

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

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

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

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

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

«Один к одному»

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел.

У каждого менеджера может быть только один отдел, и наоборот.

«Один ко многим»

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел.

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

«Многие ко многим»

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

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

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей — первичные и внешние.

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

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

1. Простота использования.
2. Гибкость.
3. Независимость данных.
4. Безопасность.
5. Простота практического применения.
6. Слияние данных.
7. Целостность данных.

Недостатки:

1. Избыточность данных.
2. Низкая производительность.

Другие модели баз данных (ООСУБД)

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

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

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

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

Ссылки на источники

https://www.internet-technologies.ru/articles/modeli-baz-dannyh-sistemy-upravleniya-bazami-dannyh.html

https://studme.org/62414/menedzhment/modeli_dannyh

https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

\