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

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

Базовыми объектами модели являются:

• элемент данных;
• агрегат данных;
• запись;
• набор данных,

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

Агрегат данных соответствует следующему уровню обобщения в модели. В модели определены агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа.

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

Агрегат типа повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат Зарплата соответствует типу повторяющаяся группа с числом повторений 12.

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

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

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

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

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

В качестве примера рассмотрим таблицу, на основе которой организуем два набора и определим связь между ними:

Экземпляров набора Ведет занятия будет 3 (по числу преподавателей), экземпляром набора Занимается у будет 4 (по числу групп).

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

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

Реляционная модель является удобной и наиболее привычной фор­мой представления данных в виде таблицы. В отличие от иерархиче­ской и сетевой моделей, такой способ представления: 1) понятен пользователю-непрограммисту; 2) позволяет легко изменять схему — присоединять новые элементы данных и записи без изменения соот­ветствующих подсхем; 3) обеспечивает необходимую гибкость при обработке непредвиденных запросов.

Рис 9. Основные понятия реляционной модели

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

Основными понятиями, с помощью которых определяется реля­ционная модель, являются следующие: домен, отношение, кортеж, кардинальность, атрибуты, степень, первичный ключ. Соотношение этих понятий иллюстрируется рисунком.

Таблица

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

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

Остальные ключи, которые можно также использовать в качест­ве первичных, называются потенциальными или альтернативными ключами.

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

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

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

Модель предъявляет к таблицам следующие требования:

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

2) данные в одном столбце должны быть одного типа;

3) каждый столбец должен быть уникальным (недопустимо дуб­лирование столбцов);

4) столбцы размещаются в произвольном порядке;

5) строки размещаются в таблице также в произвольном по­рядке;

6) столбцы имеют уникальные наименования.

Концепция реляционной модели определяется следую­щими двенадцатью правилами.

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

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

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

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

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

• определение данных;

• определение представлений;

• обработку данных (интерактивную и программную);

• условия целостности;

• идентификацию прав доступа;

• границы транзакций (начало, завершение и отмена).

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

7. Правило добавления, обновления и удаления. Возможность рабо­тать с отношением как с одним операндом должна существовать не

только при чтении данных, но и при добавлении, обновлении и уда­лении данных.

8. Правило независимости физических данных. Прикладные про­граммы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL).

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

Правило 5 требует, чтобы СУБД использовала язык реляци­онной базы данных, например SQL. Такой язык должен поддержи­вать все основные функции СУБД — создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т. д.

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

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

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

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

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

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