Иерархическая модель данных
В ней существует упорядоченность элементов в записи, один элемент считается главным, остальные подчиненными. Данные в записи упорядочены в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться лишь последовательным спуском со ступеньки на ступеньку. Поиск какого-либо элемента данных в такой системе может оказаться довольно трудоемким из-за необходимости последовательно проходить несколько предшествующих иерархических ступеней.
Иерархическую БД образует каталог файлов, хранимых на диске; дерево каталогов, доступное для просмотра в Total Commander, - наглядная демонстрация структуры такой БД и поиска в ней нужного элемента. Такой же БД является родовое генеалогическое дерево.
Сетевая модель данных
Отличается большой гибкостью, так как в ней существует возможность устанавливать дополнительно к вертикальным иерархическим связям горизонтальные связи. Это облегчает процесс поиска требуемых элементов данных, так как уже не требуется обязательного прохождения всех существующих ступеней.
Сетевой БД фактически является Всемирная паутина глобальной компьютерной сети Интернет. Гиперссылки связывают между собой сотни миллионов документов в единую сетевую БД.
Реляционная модель данных
В реляционной БД под записью понимается строка прямоугольной таблицы. Элементы записи образуют столбцы этой таблицы (поля). Все элементы в столбце имеют одинаковый тип (числовой, символьный), а каждый столбец - неповторяющееся имя. Одинаковые строки в таблице отсутствуют.
Преимущества таких БД ─ наглядность и понятность организации данных, скорость поиска нужной информации.
Примером реляционной БД служит ведомость назначения на стипендию, в которой записью является строка с данными о конкретном студенте, а имена полей (столбцов) указывают, какие данные о каждом студенте должны быть записаны в ячейках таблицы.
Любой тип можно свести к реляционному.
Типы данных
Тип данных определяет множество значений, которые может принимать данное поле в различных записях.
Основные типы данных в современных БД:
числовой;
текстовый;
дата / время;
денежный;
логический;
Ключи
Суперключ - это одно или несколько полей таблицы, которые однозначно определяют каждую строку в таблице
Потенциальный (возможный) ключ это суперключ ключ, который содержит минимальный табор полей, необходимых для однозначной идентификации каждой строки в таблице.
Первичный ключ – это потенциальный ключ, выбранный, для однозначной идентификации каждой строки в таблице; обычно выбирают наиболее простой для ввода потенциальный ключ, как правил, числовой.
Ключевое поле таблицы в СУБД Access – это первичный ключ таблицы.
Виды реляционных отношений
один-к-одному;
Каждому значению первичного ключа в главной таблице соответствует одна или не одной записи в подчиненной таблице.
Отношения этого типа используются не очень часто, поскольку большая часть сведений, связанных таким образом, может быть помещена в одну таблицу. Отношение «один-к-одному» может использоваться для разделения таблиц, содержащих много полей, для отделения части таблицы по соображениям безопасности, а также для сохранения сведений, относящихся к подмножеству записей в главной таблице.
один-ко-многим;
Каждому значению первичного ключа в главной таблице соответствует одна, несколько или ни одной записи в подчиненной таблице.
Отношение «один-ко-многим» является наиболее часто используемым типом связи между таблицами.
многие-ко-многим.
При отношении «многие-ко-многим» одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Отношение «многие-ко-многим» представляет собой два отношения «один-ко-многим» с третьей таблицей.
Организация межтабличных связей
один-к-одному – таблицы, связываются по их первичным ключам (первичные ключи обеих таблиц устанавливают одинаковыми);
один-ко-многим –главная таблица (один) связывается по первичному ключу с подчиненной таблицей (многие) по внешнему ключу (это первичный ключ главной таблицы, вставленный в подчиненную таблицу)
многие-ко-многим – для организации такой связи между двумя таблицами создается третья (промежуточная) таблица, в которую вставляются первичные ключи первых двух таблиц. Связываются между собой первая и третья, а также вторая и третья таблицы, тип связи один–ко-многим.
Пример организации БД
Условия целостности данных
Условие целостности служит для обеспечения соответствия записей в подчиненной таблице записям главной таблицы, т.е. удалять данные из ключевого поля главной таблицы нельзя.
Операции каскадное обновление и каскадное удаление связных полей, разрешают операции редактирования и удаления данных в ключевом поле главной таблице, но сопровождаются автоматическими изменениями в связанной таблице.
СУБД используют различные модели данных . Самые старые системы можно разделить на иерархические и сетевые базы данных - это пререляционные модели.
В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок.
«Система управления информацией » (Information Management System ) компании IMB - пример иерархической СУБД.
Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних ) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей » - они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок » вида 1:N . Это достигается путём использования древовидной структуры - она «позаимствована » из математики, как и теория множеств, используемая в реляционной модели.
Рассмотрим в качестве примера иерархической модели данных организацию, хранящую информацию о своём работнике: имя, номер сотрудника, отдел и зарплату. Организация также может хранить информацию о его детях, их имена и даты рождения.
Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. В иерархической базе данных отношение «родитель-потомок » - это отношение «один ко многим ». То есть у дочернего элемента не может быть больше одного предка.
Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок »:
В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента - несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными ») от компании Computer Associates international Inc. - пример сетевой СУБД.
Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.
Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I . Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.
Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL ).
Основной элемент сетевой модели данных - набор, который состоит из типа «запись-владелец », имени набора и типа «запись-член ». Запись подчинённого уровня («запись-член ») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.
Запись старшего уровня («запись-владелец ») также может быть «членом » или «владельцем » в других наборах. Модель данных - это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records , то есть «перекрёстные записи ). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.
В каждом из них один тип записи является «владельцем » (от него отходит «стрелка» связи ), и один или более типов записи являются «членами » (на них указывает «стрелка» ). Обычно в наборе существует отношение 1:М , но разрешено и отношение 1:1 . Сетевая модель данных CODASYL основана на математической теории множеств.
Известные сетевые базы данных:
В реляционной модели, в отличие от иерархической или сетевой, не существует физических отношений. Вся информация хранится в виде таблиц (отношений ) , состоящих из рядов и столбцов. А данные двух таблиц связаны общими столбцами, а не физическими ссылками или указателями. Для манипуляций с рядами данных существуют специальные операторы.
В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle , Sybase , DB2 , Ingres , Informix и MS-SQL Server .
«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более ».
РСУБД - реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц - наборов записей с общими полями.
Реляционные таблицы обладают следующими свойствами:
Некоторые поля могут быть определены как ключевые. Это значит, что для ускорения поиска конкретных значений будет использоваться индексация. Когда поля двух различных таблиц получают данные из одного набора, можно использовать оператор JOIN для выбора связанных записей двух таблиц, сопоставив значения полей.
Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы » может содержать пары «ID-покупателя » и «код-товара ». А в таблице «Товар » могут быть пары «код-товара » и «цена ». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара » этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.
Поскольку отношения здесь определяются только временем поиска, реляционные базы данных классифицируются как динамические системы.
Первая модель данных, иерархическая, имеет древовидную структуру («родитель-потомок »), и поддерживает только отношения типа «один к одному » или «один ко многим ». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка ) неясна и не подходит для иерархической модели.
Вторая, сетевая модель данных , имеет более гибкую структуру, чем иерархическая, и поддерживает отношения «многие ко многим ». Но быстро становится слишком сложной и неудобной для управления.
Третья модель - реляционная - более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.
Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности - учётная запись покупателя. Объекты определяются атрибутами - информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов - как ряд. Ряд также можно определить как экземпляр объекта.
Объекты связываются отношениями, основные типы которых можно определить следующим образом:
В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел .
У каждого менеджера может быть только один отдел, и наоборот.
В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел .
Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.
В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект .
Сотрудник может участвовать в нескольких проектах, и каждый проект может объединять несколько сотрудников.
В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.
Каждая таблица представляет объект.
Каждая таблица состоит из рядов и столбцов.
Отношения между объектами представлены столбцами.
Каждый столбец представляет атрибут объекта.
Значения столбцов выбираются из области или набора всех возможных значений.
Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей - первичные и внешние.
Первичные служат для однозначного определения объекта. Внешний ключ - это первичный ключ одного объекта, существующий как атрибут в другой таблице.
Преимущества реляционной модели данных:
Недостатки:
В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.
Особенности объектно-ориентированных систем управления базами данных (ООСУБД):
А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.
Данные в базах данных организуются в соответствии с одной из моделей данных.
С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. Т.о. основой любой БД является модель данных.
Модель данных – совокупность структур данных и операций по их обработке.
К классическим моделям представления данных относят иерархическую, сетевую и реляционную. Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.
Основные модели представления данных:
1. Иерархическая модель данных представляет информационные отображения объектов реального мира – сущности и их связи в виде ориентированного графа или дерева (рис. 2). Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях. В такой модели у каждого объекта есть только один исходный (за исключением корневого объекта), но в принципе может быть несколько зависимых (порожденных).
Рис.17. Структура иерархической модели
Ветви между объектами отображают наличие некоторого отношения, причем название отношения пишется на ребре. Например, между объектами «клиент» и «заказ» может быть отношение, которое называется «делает», а между «заказ» и «товары» - отношение «состоит из». Этот тип модели отражает вертикальные связи, подчинение нижнего уровня верхнему, т.е. к каждой записи БД есть только один (иерархический) путь от корневой записи.
Примером такой модели может служить БД, содержащая сведения о ВУЗе (на примере БелГСХА)
2. Сетевая модель – является расширением иерархической модели, нов отличие от нее присутствуют горизонтальные связи (рис. 3). В данной модели данных любой объект может быть и главным и подчиненным. Структура называется сетевой, если в отношениях между данными порожденный элемент имеет более одного исходного. Сетевая модель предоставляет большие возможности по сравнению с иерархической, однако она сложнее в реализации и использовании. Примером может служить структура БД, содержащей сведения о студентах, участвующих в НИРС. Возможно участие одного студента в нескольких темах, а также нескольких студентов в разработке одной темы.
Рис. 18. Представление связей в сетевой модели
3. Реляционная модель. Понятие реляционной модели данных (от английского relation – отношение) связано с разработками Эриха Кодда. Эта модель характеризуется простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования аппарата реляционной алгебры для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц, связанных между собой определенными отношениями.
Реляционная таблица обладает следующими свойствами :
ü таблица должна иметь имя;
ü каждый элемент таблицы – один элемент данных;
ü все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный или другой) и длину;
ü каждый столбец имеет уникальное имя;
ü одинаковые строки в таблице отсутствуют;
ü порядок следования строк и столбцов может быть произвольным;
ü таблица должна быть простой, т.е. не содержать составных столбцов;
ü должен быть известен первичный ключ.
Таблица реляционной БД состоит из некоторого числа однотипных записей, или кортежей. Слово «однотипных» означает, что все записи обладают одним и тем же набором атрибутов, или полей, хотя для каждой записи атрибут может принимать свое собственное значение.
Рассмотрим таблицу, содержащую данные о сотрудниках предприятия
Как отмечалось, инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь", которая будет рассмотрена в главе 2.
Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели.
Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".
Сложность практического использования иерархических и и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены в главе 3.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.
1. Иерархический подход к организации баз данных. Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными – одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.
2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе.
3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.
Во-первых , все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель – единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково – таблицами . Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией.
Избежать трудностей манипулирования позволяет второй элемент модели – реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления (полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL.
Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности. Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор, называемый первичным ключом . Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты – текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большой степени поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем – реализация сложных типов данных, связь с языками программирования и т.п. – на ближайшее время превосходство реляционных СУБД гарантировано.
Выше уже упоминалось, что схема создается с помощью некоторого языка определения данных. На самом деле она создается на основе языка определения данных конкретной целевой СУБД, являющегося языком относительно низкого уровня; с его помощью трудно описать требования к данным так, чтобы созданная схема была доступна пониманию пользователей самых разных категорий. Чтобы достичь такого понимания, требуется составить описание схемы на некотором, более высоком уровне, которое будем называть моделью данных. При этом под моделью данных мы будем понимать интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в пределах некоторой предметной области.
Модель является представлением объектов и событий предметной области, а также существующих между ними связей. Модель данных можно рассматривать как сочетание трех указанных ниже компонентов.
· Структурная часть, т.е. набор правил, по которым может быть построена база данных.
· Управляющая часть, определяющая типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, а также операции изменения структуры базы данных).
· Набор ограничений поддержки целостности данных, гарантирующих корректность используемых данных.
Цель построения модели данных заключается в представлении данных в понятном виде. Если такое представление возможно, то модель данных можно будет легко применить при проектировании базы данных. Для отображения архитектуры ANSI-SPARC можно определить следующие три связанные модели данных:
· внешнюю модель данных, отображающую представления каждого существующего в организации типа пользователей;
· концептуальную модель данных, отображающую логическое (или обобщенное) представление о данных, независимое от типа выбранной СУБД;
· внутреннюю модель данных, отображающую концептуальную схему определенным образом, понятным выбранной целевой СУБД.
В литературе предложено и опубликовано достаточно много моделей данных. Они подразделяются на три категории: объектные (object-based) модели данных, модели данных на основе записей (record-based) и физические модели данных. Первые две используются для описания данных на концептуальном и внешнем уровнях, а последняя - на внутреннем уровне.
Объектные модели данных. При построении объектных моделей данных используются такие понятия как сущности, атрибуты и связи. Сущность - это отдельный элемент (сотрудник, изделие, понятие или событие) предметной области, который должен быть представлен в базе данных. Атрибут - это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать, а связь является ассоциативным отношением между сущностями. Ниже перечислены некоторые наиболее общие типы объектных моделей данных.
В настоящее время ER-модель стала одним из основных методов концептуального проектирования баз данных. Объектно-ориентированная модель расширяет определение сущности с целью включения в него не только атрибутов, которые описывают состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. В таком случае говорят, что объект инкапсулирует состояние и поведение.
Модели данных на основе записей. В модели на основе записей база данных состоит из нескольких записей фиксированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существует три основных типа логических моделей данных на основе записей: реляционная модель данных (relational data model), сетевая модель данных (network data model) и иерархическая модель данных (hierarchical data model).
Классификация моделей данных базируется на понятиях о взаимосвязи объектов. Между таблицами базами данных могут существовать четыре типа различных связей: «один к одному»; «один ко многим»; «многие ко многим».
При отношении «один к одному » в каждый момент времени одной записи таблицы «1» соответствует не более одной записи таблицы «2». Например, одному клиенту соответствует только один номер в гостинице. Этот тип связи используют не очень часто, поскольку такие данные могут быть помещены в одну таблицу. Такую связь используют для разделения очень широких таблиц, например, для разделения таблицы с информацией о сотрудниках фирмы на две – служебной и личной информацией.
Связь с отношением «один ко многим » характеризует то, что одному экземпляру информационного объекта «1» соответствует 0,1,2 и более экземпляров объекта «2». Такое отношение существует, например, между таблицами «Поставщики» и «Товары», т.е. каждый поставщик может продавать различные товары, но у каждого товара есть единственный поставщик.
Отношение «многие ко многим » предполагает, что в каждый момент времени одной записи таблицы «1» соответствует несколько экземпляров таблицы «2» и наоборот. Примером может служить связь между информационными объектами «Клиент» и «Банк». Один клиент хранит средства во многих банках. Один банк обслуживает многих клиентов. Реализуется отношение с помощью третьей (связующей) таблицы, ключ которой состоит, по крайней мере, из двух полей, которые являются полями внешнего ключа в исходных таблицах.
Известны три основных типа моделей данных.
Иерархическая модель. Предполагает организацию данных в виде древовидной структуры. Дерево представляет собой иерархию элементов. На самом верхнем уровне структуры находится корень дерева. У одного дерева может быть только один корень, остальные - узлы, называемые порожденными. Каждый узел имеет исходный, находящийся выше него.
Иерархическая базой данных представляет собой как множество отношений и веерных отношений, для которых соблюдаются два ограничения: существует единственное отношение, называемое корневым, которое не является зависимым ни в одном веерном отношении; все остальные отношения (кроме корневого) являются зависимыми отношениями только в одном веерном отношении.
Записью иерархической БД называется множество значений, содержащее одно значение корневого отношения и все вееры, доступные от него. В нашем примере запись образуют данные, относящиеся к одному факультету.
Сетевая модель . В основу модели положены сетевые структуры, в которых любой элемент может быть связан с любым другим элементом. Информационными конструкциями в модели являются отношения и веерные отношения. Последние подразделяют на основные и зависимые. Веерным отношением W(R,S) называется пара отношений R и S и связь между ними при условии, что каждое значение S связано с единственным значением R . Отношение R называют исходным (основным), а S - порожденным (зависимым).
В структуру основного и зависимого отношений вводится дополнительный атрибут, называемый адресом связи, который обеспечивает соответствие каждого значения зависимого отношения S с единственным значением основного отношения R . Адрес связи хранит начальный адрес или номер следующей обрабатываемой записи. Кольцевая структура адресов связи называется веером . Роль "ручки" веера играет запись основного отношения.
Недостатком рассмотренных выше моделей данных является то, что при добавлении новых вершин или установлении новых связей возникают проблемы выгрузки данных из базы и загрузки их в новую структуру. При этом возможна утрата данных или возникновения неопределенных значений данных.
Реляционная модель. В основе структуры данных этоймодели лежит аппарат реляционной алгебры и теории нормализации. Модель предполагает использование двумерных таблиц (отношений).
Ограничения на отношения реляционной модели: каждый элемент таблицы представляет собой простой элемент данных; в таблице нет одинаковых строк; столбцам (полям) присвоены уникальные имена; все строки таблицы имеют одну и ту же структуру; в таблице порядок строк и столбцов произволен.
Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей. Каждая строка таблицы в реляционных базах данных уникальна. Для обеспечения уникальности строк используют ключи, которые содержат одно или несколько полей таблицы. Ключи хранятся в упорядоченном виде, что обеспечивает прямой доступ к записям таблицы во время поиска.
