При таком типе связи каждой записи в одной таблице соответствует несколько записей в связанной таблице. Этот наиболее распространенный тип связей. Для его реализации используются две таблицы. Одна из них представляет сторону "один", другая - сторону "много". Например, нужно иметь информацию о студентах и результатах сдачи ими экзаменов (дата сдачи, предмет, оценка и т.д.). Если все это хранить в одной таблице, то ее объем возрастет и в ней для каждой записи об очередном экзамене должны повторяться все анкетные сведения о студенте. Поскольку Студент и Экзамены - это разные классы объектов, то и свойства их должны храниться в разных таблицах.
Решением этой задачи является создание двух таблиц. Условно назовем их Студенты и Экзамены. В каждой из них хранятся соответствующие свойства. Для связи этих таблиц нужно использовать только часть информации о студенте, сдающем экзамен. Но она должна однозначно определять каждого студента среди всех. Такой информацией может явиться, например, номер зачетки (он уникален для каждого студента).
В таблице со стороны "один" (в нашем примере Студенты) такие поля называются ключевыми. Основное требование к значениям в ключевых полях - это их уникальность для каждой записи (т.е. они не должны повторяться).
Связь типа “много-ко-многим” (М:М)
При таком типе связи множеству записей в одной таблице соответствует множество записей в связанной таблице. Большинство современных СУБД непосредственно не поддерживают такой тип связи. Для его реализации такая связь разбивается на две (и более) связи типа один-ко-многим. Соответсвенно, для хранения информации потребуется уже три таблицы: две со стороны "много" и одна со стороны "один". Связь между этими тремя таблицами также осуществляется по общим полям.
|
|
Основные функции СУБД
Стремление выделить и обобщить управление сложно структурированными данными, явилось причиной создания системы управления данными. Невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных. Прежде всего, система должна знать, что она работает с несколькими информационно связанными файлами, должна знать структуру и смысл каждого поля таблицы файла, а также понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию в других файлах, чтобы их общее содержимое было согласованным.
Понятие согласованности данных является ключевым понятием баз данных. Фактически, если система поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных (БД). Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных (СУ). Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных. Функции управления БД.
1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным.
|
|
2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти.
3. Управление транзакциями
Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД.
2. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log – WAL).
|
|
Для восстановления БД после сбоя используют журнал и архивную копию БД. Архивная копия – это полная копия БД к моменту начала заполнения журнала.
3. Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра, как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу.
Задания по работе
Пример
Преобразуйте следующую сетевую модель в иерархическую, а затем в реляционную.
Сетевая модель
Иерархическая модель
При построении найдите узел из которого стрелки только выходят – это главный узел в модели, далее идут стрелки – подчиненные узлы… Отношения должны быть типа 1:М (1-му главному соответствует несколько подчиненных узлов)
Реляционная модель(отношения типа 1:1 между данными)
Задание 1.
Создать иерархическую и реляционную модели «Деканат»(декан + 2 зам. декана + 3 методиста + 5 студ. групп).
Задание 2.
Преобразовать соотношение «многие ко многим»(M:N) в «один ко многим» (1:N), вставив компонент оценки. Создать таблицы, связи, ключи реляционной модели.
|
|
М N
Задание 3.
Составить таблицы реляционной модели базы данных «Библиотека» (Искусство + ФИО авторов + Произведения).
Вопросы к защите работы
1. Назвать существующие модели баз данных.
2. Дать характеристику иерархическая модели.
3. Дать характеристику сетевая модели.
4. Дать характеристику реляционная модели.
5. Рассказать сущность отношений 1:1, 1:M.
6. Обосновать необходимость создания дополнительного к операционной системе управления в базах данных.
7. Назвать функции СУБД.
8. Рассказать принцип (порядок) преобразования моделей.