1) Модель управления файлами

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

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

2) Иерархическая модель

Эта модель была разработана для хранения данных, имеющих иерархическую структуру в виде дерева записей (например, БД библиотеки). В этой модели каждая запись представляла конкретный объект (например, книгу). Между записями существовали отношения типа «предок/потомок», связывающие записи между собой (например, автор à книга à том №1). Чтобы получить доступ к данным БД, программа могла:

- найти конкретную книгу;

- перейти «вниз» на 1 уровень к первому потомку (том №1);

- перейти «вверх» на 1 уровень к предку (автор книги);

- перейти «в сторону» к другому потомку (другая книга этого же автора).

В данной БД можно найти все книги автора по его фамилии: задаём фамилию и находим все записи. Но что делать, если нам известно название книги, но неизвестен автор? Для получения результатов поиска по такому запросу придётся просматривать всех авторов. Книга может иметь несколько авторов, и, в то же время, одним и тем же автором написано несколько книг. Такой тип связи называется «многие-ко-многим» и он не может быть описан с помощью иерархической модели, т.к. в ней предполагается, что каждый потомок имеет только одного предка. Поэтому была придумана сетевая модель.

3) Сетевая модель

Является улучшенной иерархической моделью – в ней одна и та же запись может участвовать в нескольких отношениях «предок/потомок», а такой тип отношений называется множеством.

Преимущества сетевых баз данных:

• Гибкость. множеств отнош «предок-потомок» позволяют хранить данные, стр-ра кот сложнее иерархич;

• Стандартизация : появление стандарта CODASYL стало толчком к развитию сетевых БД;

• Быстродействие: несмотря на более сложную, чем просто иерархия, структуру, сетевые БД почти не уступали иерархическим по быстродействию (множества представлены указателями на физич записи данных).

Недостатки имеют жёсткую структуру и наборы записей – их приходится задавать наперёд; изменение структуры БД обычно означает перестройку всей БД

4) реляционная модель. Реляционная база данных - это совокупность отношений или двумерных таблиц.

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

Концепция реляционной модели:

• Базовые порции данных представляют собой отношения;

• Набор операторов может воздействовать на эти отношения с целью создания других отношений;

• Реляционная база данных должна обеспечивать целостность данных, т.е. данные в ней должны быть точными и согласованными.

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

• Значения полей должны быть атомарными (не могут быть разбиты на более мелкие компоненты);

• Каждая строка должна быть уникальной;

• Порядок строк значения не имеет, по умолчанию они располагаются в порядке их ввода;

• Каждый столбец имеет уникальное имя;

• Значения в столбце должны соответствовать одному типу данных;

• Для хранения данных порядок столбцов значения не имеет;

Первичный ключ - столбец или набор столбцов, однозначно идентифицирующих каждую строку в таблице. Должен содержать конкретное значение

• Первичные ключи должны быть уникальны

• Первичные ключи обычно не подлежат изменению

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

• Внешние ключи основываются на значениях данных и являются логическими, а не физическими указателями

• Значение внешнего ключа должно совпадать со значением существующего первичного ключа или быть неопределенным (Null)

Объекты базы данных:

• Таблица - основная единица хранения данных, состоящая из строк и колонок;

• Индекс - повышает производительность запросов;

• Синоним - альтернативное имя объекта;

• Программная единица - процедура, функция или группа операторов.

Физическая организация данных в реляционной БД.

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

1) поиск записи

Поиск записи в реляционной базе данных производится по файлу индексов. Найдя индекс удовлетворяющей запросу записи, далее по ссылке берутся данные из файла данных.

2) добавление записи

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

При использовании файла индекса вставка (добавление) записи происходит так: в файл индекса (поскольку он в общем случае представляет собой таблицу с 2-мя полями) вставляем новую запись – индекс. При этом из-за малого размера файла индексов по сравнению с файлом данных мы не очень сильно нагружаем систему; сами же данные дописываются в конец файла данных, что даёт возможность производить добавление записей с одинаковой скоростью в независимости от размера БД.

3) удаление записи

В реляционной БД при удалении записи не происходит её физического удаления из БД. В этом случае, удаляемая запись удаляется из файла индекса, а в файле данных помечается как удалённая и далее становится недоступной для обработки. Физическое удаление помеченных как «удалённые» записей происходит либо по команде от пользователя, либо по накоплению какого-то порогового значения удалённых записей (т.е. во время переиндексации). Тогда файл БД переписывается в порядке, обратном порядку добавления записи.

4) изменение записи

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

5) индексация

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

16.Реляционные базы данных. Основы реляционной алгебры. Отношения. Фундаментальные свойства отношений. Операции над отношениями. Общая интерпретация реляционных операций. Реляционная модель данных. Основные понятия реляционных баз данных. Нормализация и денормализация реляционной модели данных. Основные характеристики 1, 2, 3, нормальных форм. Реляционные системы управления базами данных. Реляционные базы данных

Реляционная модель впервые была предложена Э.Ф.Коддом (E.F.Codd) в 1970. Цели создания реляционной модели формулировались следующим образом:

• обеспечение более высокой степени независимости от данных.

• создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

• расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. В настоящее время существует несколько сотен ти­пов различных РСУБД как для мейнфреймов, так и для микрокомпью­теров, хотя многие из них не полностью удовлетворяют точному определению реля­ционной модели данных. Примерами РСУБД для персональных компьютеров являются СУБД Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim.

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