71938

Организация отношений между данными: иерархическая, сетевая, реляционная

Реферат

Информатика, кибернетика и программирование

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

Русский

2014-11-14

896.09 KB

10 чел.

Министерство сельского хозяйства Российской Федерации

Федеральное образовательное учреждение высшего

профессионального образования

«Пермская государственная сельскохозяйственная академия

имени академика Д.Н. Прянишникова»

Кафедра информационных систем

РЕФЕРАТ

Организация отношений между данными:

иерархическая, сетевая, реляционная

 Выполнил:

студент группы БЖ-41б

Чунарев А.В.

Проверил:

Климов В.Г.

Пермь, 2012

Оглавление

Введение…………………………………………………………………………………..…………3

  1.  Иерархическая организация отношений между данными
  2.   Основные положения…………………...……………………………………………….…4
  3.   Структура данных в иерархической модели организации данных……………………..4
  4.   Управляющая часть………………………………………………………………………...5
  5.   Представление связей в иерархической модели………………………………………….5
  6.   Операции над данными, определенные в иерархической модели………………………6
  7.   Преимущества и недостатки иерархической модели…………………………………….6
  8.   Известные иерархические СУБД………………………………………………………….7
  9.  Сетевая организация отношений
  10.   Основные положения………………………………………………………………………8
  11.   Структура организации данных…………………………………………………………...8
  12.   Отображение информационной схемы на сетевую модель данных…………………...10
  13.   Преимущества и недостатки сетевой организации данных……………………………11
  14.   Примеры сетевых СУБД………………………………………………………………….12
  15.  Реляционная организация отношений
  16.   Основные положения……………………………………………………………………..13
  17.   Структура реляционной организации данных…………………………………………..13
  18.   Организация связей между таблицами…………………………………………………..15
  19.   Модели базы данных на логическом и физическом уровнях…………………………..16
  20.   Преимущества и недостатки реляционной организации данных……………………...19

Выводы……………………………………………………………………………………………..20

Список литературы………………………………………………………………………………...21

 

Введение

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

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

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

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

К каждой модели предъявляются следующие требования:

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

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

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

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

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

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

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

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

  1.  Иерархическая организация отношений между данными
  2.   Основные положения

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

Рис.1. Модель иерархической организации

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

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

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

  1.   Структура данных в иерархической модели организации данных

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

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

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

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

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

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

  1.  Управляющая часть иерархической модели

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

Определены следующие способы доступа:

- иерархически последовательный;

- иерархически индексно-последовательный;

- иерархически прямой;

- иерархически индексно-прямой;

- индексный.

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

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

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

  1.   Операции над данными, определенные в иерархической модели

ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.

ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

УДАЛИТЬ некоторую запись и все подчиненные ей записи.

ИЗВЛЕЧЬ корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей.

ИЗВЛЕЧЬ СЛЕДУЮЩУЮ ЗАПИСЬ (следующая запись извлекается в порядке левостороннего обхода дерева).

В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 1 тысячи руб.)

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

  1.   Преимущества и недостатки иерархической модели данных

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

Иерархическая древовидная структура имеет ряд преимуществ и всегда удовлетворяет следующим условиям:

  1.  На первом уровне может находиться только один узел, называемый корневым. Иерархия неизменно начинается с корневого узла.
  2.  Для каждого узла указывают ключевые данные, которые описывают заданный объект.
  3.  На низших уровнях могут находиться зависимые узлы. Узел, находящийся на предшествующем уровне, является исходным для новых зависимых узлов. Зависимые узлы могут добавляться как в вертикальном, так и горизонтальном направлении без всяких ограничений.

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

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

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

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

  1.  простота понимания;
  2.  простота оценки операционных характеристик.

Недостатки модели:

  1.  отношения могут быть реализованы только искусственно;
  2.  могут быть избыточные данные;
  3.  усложняются операции включения и удаления;
  4.  удаление исходных объектов ведет к удалению порожденных объектов;
  5.  процедурный характер манипулирования данными;
  6.  доступ к любому порожденному узлу возможен только через корневой узел;
  7.  сильная зависимость логической и физической БД;
  8.  сильно ограниченный набор структур запроса.

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

  1.   Известные иерархические СУБД

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.

Time-Shared Date Management System (TDMS) компании Development Corporation;

Mark IV Multi - Access Retrieval System компании Control Data Corporation;

System - 2000 разработки SAS-Institute;

Серверы каталогов, такие, как LDAP и Active Directory (допускают чёткое представление в виде дерева).

По принципу иерархической БД построены иерархические файловые системы и Реестр Windows.

 

  1.  Сетевая организация отношений между данными
  2.   Основные положения

Если в отношении между данными порожденный элемент имеет более одного исходного элемента, то это отношение уже нельзя описать как древовидную или иерархическую структуру. Его описывают в виде сетевой структуры. Любая сетевая структура может быть приведена к более простому виду введением избыточности. «БД постоянно грозит опасность стать громоздкими, застывшими и слишком сложными системами. Новые приложения порождают новые виды запросов пользователей к базе, что увеличивает набор логических связей между ее элементами. В итоге многие системы БД оказываются очень сложными в построении и эксплуатации. Если разработчики не придумают ясные и простые схемы организации, эти системы будут подобны паутине» [К.Дейт.].

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

На рис. 2 изображена сетевая структура базы данных в виде графа.

Рис. 2. Графическое изображение сетевой структуры

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

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

  1.   Структура организации данных

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

Рис.3. Пример сетевой структуры БД

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

Веерным отношением W(R,S) называется пара отношений, состоящая из одного основного R, одного зависимого отношения S и связи между ними при условии, что каждое значение зависимого отношения связано с единственным значением основного отношения.

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

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

Сетевые базы данных в зависимости от ограничений на вхождение отношений в веерные отношения разделяются на многоуровневые и двухуровневые сети.

Ограничение двухуровневых сетей состоит в том, что каждое отношение может существовать в одной из перечисленных ниже ролей:

• вне каких-либо веерных отношении;

• в качестве основного отношения в любом количестве веерных отношений;

• в качестве зависимого отношения в любом количестве веерных отношений.

Запрещается существование отношения в качестве основного в одном контексте и одновременно в качестве зависимого в другом контексте.

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

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

Для двухуровневых сетевых СУБД вводятся еще два ограничения (с теоретической точки зрения необязательные):

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

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

Схема сетевой БД содержит следующие компоненты:

S (net) = <A, R, WW, Dom, Rel, Net, V(s)>,

где WW - множество веерных отношений,

Net - вхождение отношений в веерные отношения.

Остальные элементы схемы аналогичны тем, которые введены выше для реляционных баз данных.

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

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

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

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

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

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

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

F = {Fl (Xl), F2 (X2),..., Fi (Xi),..., Fn (Xn)},

где Xi - атрибуты ключа в файле Fi.

Дополнительно вводится граф сетевой структуры В с вершинами {Xl, X2,..., Xi,..., Xn}. Дуга <Xi, Xj> в графе В существует, если Xi является частью Xj и Fj [Xi] является подмножеством Fi. Последнее условие имеет тот же смысл, что и синтаксическое включение отношений в реляционной модели данных. Здесь предполагается, что ключ основного файла содержится в зависимом файле. Граф В аналогичен графу соединений для реляционной БД.

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

Для множества файлов F ациклической базы данных DBA вполне применима операция:

m (DBA) = F1 & F2 & ... & Fi & ...& Fn, называемая максимальным пересечением. Ее аналогом может служить последовательность соединений в реляционной БД.

  1.   Отображение информационной схемы на сетевую модель данных

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

Например, на этапе концептуального проектирования получена информационная схема, изображенная на рис.4:

Рис. 4. Информационная схема

Рис. 5. Сетевая модель данных

Обозначение М/ N1, читается так: Nизделий выполняется М1 инструментами, М1/ М2 читается так: М1 инструмент используется на М2 рабочих местах.

Определенная аналитическая работа требуется при привязке сетевой модели к конкретной СУБД.

  1.   Преимущества и недостатки сетевой организации данных

Сетевые БД обладают рядом преимуществ:

1. Гибкость. Множественные отношения предок/потомок позволяют сетевой БД хранить данные, структура которых сложнее простой иерархии.

2. Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Недостатки:

1. Как и иерархические БД, сетевые БД были очень жесткими.

2. Наборы отношений и структуру записей приходилось задавать наперёд.

3. Изменение структуры БД обычно означало перестройку всей БД.

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

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

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

  1.   Примеры сетевых СУБД

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971г., а в 70-х годах появилось несколько систем, среди которых IDMS.

 

  1.  Реляционная организация отношений между данными
  2.  Основные положения

Реляционная модель данных впервые была предложена американским математиком Коддом в 1970 году. Фундаментальным понятием реляционной БД является отношение. Это отражено и в общем названии подхода - термин реляционный (relational ) происходит от relation (отношение). На физическом уровне отношения представляют собой таблицы. В реляционной модели все данные представлены в виде простых таблиц, разбитых на строки и столбцы. К сожалению, практическое определение понятия «реляционная база данных» оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину Коддом в 1970 году. Поставщики СУБД реализовывали в своих продуктах лишь некоторые черты реляционных систем, и, фактически, потенциальные возможности и смысл реляционного подхода искажались. Только с появлением персональных ЭВМ реляционные и близкие к ним системы неожиданно стали распространяться, практически не оставив места другим моделям.

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

Рис.6. Схема реляционной модели организации данных

Таблица обладает следующими свойствами:

  1.  каждый элемент таблицы представляет собой один элемент данных. Повторяющиеся группы отсутствуют; 
  2.  все столбцы в таблице однородные. Это означает, что элементы столбца имеют одинаковую природу;
  3.  столбцам присвоены уникальные имена; 
  4.  в таблице нет двух одинаковых строк;
  5.  порядок расположения строк и столбцов в таблице безразличен. Таблица такого рода называется отношением. База данных, построенная с помощью отношений, называется реляционной базой данных.

  1.   Структура реляционной организации данных

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

В любой таблице всегда есть как минимум один столбец. В стандарте ANSI / ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует. В СУБД Firebird этот предел составляет 32767 столбцов.

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

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

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

Рис.7. Структура реляционной таблицы Abonent

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

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

Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных. На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей абонента КОНЮХОВ В.С., в столбце Fio содержится значение 'КОНЮХОВ В.С.'. В столбце AccountCD той же строки содержится значение '015527', которое является номером лицевого счета абонента КОНЮХОВ В.С. Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. В реляционной модели данных общая совокупность значений, из которой берутся действительные значения для определенных атрибутов (столбцов) называется доменом. Доменом столбца Fio , например, является множество фамилий абонентов. Каждый столбец всегда определяется на одном домене.

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

  1.   Организация связей между таблицами

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

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

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

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

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

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

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

Обратимся к учебной базе данных. Все связи между таблицами учебной базы данных являются не идентифицирующими с мощностью «один ко многим». Рассмотрим, например, связь «один ко многим» между таблицами Street и Abonent (рис.8).

Рис.8. Связь «один ко многим» между таблицами Street и Abonent

Из рис.8 следует, в столбце StreetCD таблицы Abonent содержится идентификатор улицы, на которой проживает абонент. Столбец StreetCD в таблице Abonent представляет собой внешний ключ, ссылающийся на одноименный столбец таблицы Street. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов улиц, содержащихся в столбце StreetCD таблицы Street. Мощность отношения - «один ко многим», так как на одной и той же улице может проживать (и проживает) множество абонентов, но каждый абонент проживает только на одной определенной улице. Наименование улицы, на которой проживает, например, абонент АКСЕНОВ С.А., можно узнать, определив значение столбца StreetCD в строке таблицы Abonent со значением в столбце Fio, равным 'АКСЕНОВ С. А.' (число 3), и затем отыскав в таблице Street строку с таким же значением в столбце StreetCD (улица ВОЙКОВ ПЕРЕУЛОК).

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

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

  1.   Модели базы данных на логическом и физическом уровнях

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

На логическом уровне проектирование выполняется путем выделения сущностей (Entity), атрибутов сущностей (Attribute) и взаимосвязей между сущностями. Модель «сущность-связь» (Entity - Relationship Model, или ER-модель) была разработана Ченом (Chen) в 1976 году с целью упрощения задачи проектирования баз данных. Логическая модель независима от особенностей физической реализации объекта. На рис.9 представлены отношения между всеми сущностями учебной базы данных в виде ER модели на логическом уровне.

Рис.9. ER модель учебной БД на логическом уровне

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

Модель учебной базы данных на физическом уровне представлена на рис.10.

Рис. 10. ER модель учебной БД на физическом уровне

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

Рядом с именем каждого столбца указывается тип данных этого столбца, или, другими словами, столбец задается на определенном домене.

Предложение NOT NULL, указанное при описании столбца, накладывает ограничение, согласно которому в данном столбце недопустимо хранение NULL значений.

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

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

  1.   Преимущества и недостатки реляционной организации данных

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

  1.  cредства современных СУБД настолько разнообразны, что способны удовлетворить потребности самого широкого круга пользователей;
  2.  позволяет выбирать наиболее адекватные нуждам пользователя, обеспечивая эффективное использование вычислительных ресурсов и существенное сокращение сроков разработки конкретных БД-технологий;
  3.  СУБД позволяет создавать и эксплуатировать системы БД на всех классах и типах ЭВМ.

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

 

Выводы

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

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

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

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

 

Список литературы

  1.  В.В. Аладьев, Ю.Я. Хунт, М.Л. Шишаков. Основы информатики. Учебное пособие. – Москва. 2006.
  2.  К. Дейт. Введение в системы баз данных/ К. Дейт, М., Наука, 2008.
  3.  Бойко, В.В. Проектирование баз данных информационных систем/ В.В. Бойко, В.М. Савинков, М., Финансы и статистика, 2009.
  4.  Макашарипов, С. Эффективная работа с СУБД/ С. Макашарипов, А. Горев, Р. Ахаян, СПб., Питер, 2008.
  5.  Жуков, А. А. Система контроля знаний TSTST/ А. А. Жуков, Л.А. Федякина, М., Информатика и образование, 2006.


 

А также другие работы, которые могут Вас заинтересовать

39142. Повышение эффективности диагностирования изделий имеющих активно-индуктивную нагрузку в электрооборудовании автомобилей 254.5 KB
  Однако в условиях массового производства автомобилей когда производительность лимитирована ритмом сборочного конвейера в виду длительности процесса диагностирования всего комплекса автомобильного электрооборудования сплошной выходной контроль его качества существенно затруднен. Таким образом становится актуальной важная научнотехническая задача повышения качества и оперативности диагностирования автомобильного электрооборудования имеющего активноиндуктивную нагрузку решение которой позволит ввести сплошной выходной контроль в массовом...
39143. Оптимизация комбинированной энергетической установки электротранспортного средства 358 KB
  Прежде всего это ограниченный пробег без подзарядки бортового источника энергии. Поэтому актуальной является проблема оптимизации параметров бортовой энергоустановки в том числе совместным применением накопителей энергии различной физической природы в ее составе. Таким образом становится актуальной важная научнотехническая задача повышения энергоэффективности тяговой системы этого транспортного средства решение которой существенно повысит эффективность использования ограниченного запаса энергии на борту внося заметный вклад в...
39144. ИСТОКИ ТОТАЛИТАРИЗМА 100.5 KB
  ИСТОКИ ТОТАЛИТАРИЗМА Тоталитарные движения возможны везде где имеются массы по той или иной причине приобретшие вкус к политической организации. Массы держит вместе не сознание общих интересов и у них нет той отчетливой классовой структурированности которая выражается в определенных ограниченных и достижимых целях. Термин массы применим только там где мы имеем дело с людьми которых в силу либо просто их количества либо равнодушия либо сочетания обоих факторов нельзя объединить ни в какую организацию основанную на общем интересе в...
39145. ВЕРОЯТНОСТНО-СТАТИСТИЧЕСКИЕ МОДЕЛИ ЭКСПЛУАТАЦИИ ЛЕТАТЕЛЬНЫХ АППАРАТОВ 9.88 MB
  В зависимости от физической сущности моделируемого объекта или процесса и характера этого процесса могут использоваться законы распределения непрерывных или дискретных случайных величин. Естественно что при формировании вероятностностатистических моделей широко используются законы распределения случайных величин и правила оперирования с ними определяемые теорией вероятности и статистическими методами анализа. Формирование...
39146. УПРАВЛЕНИЕ ПРОЦЕССАМИ ТЕХНИЧЕСКОЙ ЭКСПЛУАТАЦИИ ЛЕТАТЕЛЬНЫХ АППАРАТОВ 1.47 MB
  Объектом управления является изделие ЛА, техническое состояние которого определяется параметрами , изменение которых во времени представляет собой монотонную случайную функцию времени t (рис. 3.1). Установлены предельно допустимые значения параметров , пересечение которых реализациями случайной функции означает отказ.
39147. Управление процессами технической эксплуатации изделий ЛА, заменяемых по состоянию 3.12 MB
  Лабораторная работа №2 Тема: Управление процессами технической эксплуатации изделий ЛА заменяемых по состоянию. Цель: Использование моделей экранов и замены изделий подверженных износу и старанию для управления процессами технической эксплуатации.Сформировать модель процесса технической эксплуатации изделий заменяемых по состоянию; 2.Определить характеристики процесса технической эксплуатации изделий заменяемые по состоянию; 2.
39149. Программное обеспечение вычислительной техники и автоматизированных систем 100.5 KB
  Техникум-интернат, как учреждение среднего профессионального образования получает право на общеобразовательную деятельность и льготы, представляемые законодательством Российской Федерации через лицензию, выданную Министерством социальной защиты населения Российской Федерации.
39150. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ «УЧЕТ СОЦИАЛЬНЫХ ДАННЫХ СТУДЕНТОВ» НА ПРИМЕРЕ ФКОУ СПО «КАЛАЧЕВСКИЙ ТЕХНИКУМ-ИНТЕРНАТ» 70.8 KB
  Цель данной работы – создание программного модуля учета социальных данных студентов для ФКОУ СПО «Калачевский техникум-интернат». Заказчиком данного программного модуля является социально-педагогическая служба техникума, которой требуется полный и точный контроль над социальными данными всех студентов техникума. Лучшее решение этой задачи – внедрение программного модуля, который автоматизирует данный процесс учета данных.