1. Внешний,

2. Концептуальный и

3. внутренний уровни базы данных, как показано на рис. ниже.

1. Внешний уровень. Это представление бд с точки зрения конечных пользователей.

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

Примером может служить база данных «Студенты техникума», которая хранит и обрабатывает самую разнообразную информацию о студентах.

Так, диспетчер учебной части не интересуется адресом студента, данными о его родителях. Для диспетчера эта часть информации «не видна», она не входит в его представление о базе данных. Его интересует успеваемость студента, название группы.

Куратор группы, наоборот, «видит» все эти данные. Его интересуют и личные данные студента и его успеваемость.

Мед. сестра техникума будет иметь своё представление о базе данных «Студенты техникума», не́сколько отличное от представлений куратора и диспетчера.

У библиотекаря техникума тоже будет своё собственное представление о данных, которые должны храниться в этой базе данных.

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

В общем случае, структура БД определяется набором объектов, входящих в неё и взаимосвязью между ними.

2. Концептуальный уровень

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

• все объекты, их характеристики и связи;

• ограничения, накладываемые на данные;

• информация о мерах обеспечения безопасности и поддержки целостности данных.

Концептуальная схема БД не зависит от СУБД, которая будет использоваться для реализации БД.

3. Внутренний уровень

Внутренний уровень – это физическое представление БД в памяти компьютера.

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

Этот уровень описывает, как информация хранится в БД (конкретные методы хранения данных, распределение дискового пространства и т.д.).

4. Реляционная модель баз данных

4.1.Общая характеристика элементов реляционной модели данных.

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

2. Понятие таблицы. Основные элементы таблицы.

Таблица— основной компонент БД, она рассматривается как непосредственное хранилище данных. В каждой таблице фиксируются данные о каких-либо объектах или процессах, рассматриваемых в конкретной предметной области. Пример имён таблиц: Студент, ПРОДАЖА_ТОВАРА.

Таблица состоит из строк и столбцов.

Столбцы отображают перечень характеристик рассматриваемого объекта или процесса (например, для СТУДЕНТА это ФИО, группа, специальность и т.д.

Для процесса ПРОДАЖА_ТОВАРА это ДатаПродажи, объём_продажи и т.д.).

Есть различные способы обращения к этим элементам таблицы:

Строка	Столбец
Запись	Поле

Любая из приведенных пар терминов может считаться верной.

Будем пользоваться парой терминов Запись-поле.

Каждое поле должно иметь своё уникальное имя (в пределах одной таблицы).

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

Например: «Адрес студента». Более корректным считается имя Адрес_студента.

Каждая запись отображает полный набор данных об одном экземпляре объекта.

Например, первая запись содержит всю информацию о студенте Иванове, вторая – о студенте Петрове и т.д

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

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

Количество полей в таблице значительно меньше. Допускается наличие таблиц всего с двумя полями (нередкое явление).

4.3 Идентификатор. Ключи таблицы.

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

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

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

Таких полей в таблице может быть и несколько. Например, для каждого СТУДЕНТА уникальными будут данные студенческого билета, данные паспорта, идентификационный номер. Для процесса продажи товара уникальными могут быть: номер документа, оформляющего сделку (соответствующее поле может иметь имя ДОГОВОР).

Значение идентификатора для каждого объекта не может отсутствовать! Если паспорт имеют не все студенты, значит, ПАСПОРТ не является в данном случае идентификатором объекта СТУДЕНТ.

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

Первичный ключ – это поле, отображающее один из идентификаторов объекта.

Можно сказать и так:

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

Если идентификаторов в таблице может быть несколько, то первичный ключ всегда только один. Обозначается: PK. Остальные идентификаторы данного объекта называются альтернативными ключами.

СтудБилет	фамилия	имя	отчество	год_рожд	спец	ИД
К-2847	Кравец	Сергей	Владимирович	1993	СОЗ	0120334566
К-2848	Кравец	Сергей	Владимирович	1992	РПЗ	0320434668
К-2849	Кравченко	Антон	Борисович	1993	МЕЕП	0177334587

Здесь идентификаторами являются поля: СтудБилет и ИД. Значения их уникальны и присутствуют только в одной записи. Нами выбрано ключевое поле— СтудБилет.

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

НазваниеГруппы+ ФИО.

Вероятность того, что в одной группе будут учиться полные тёзки, невелика. Не рекомендуется определять ключ по полям «Имя»+«Фамилия», поскольку нельзя исключить повторения этой пары значений для разных людей.

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

Ключ таблицы, состоящий из одного поля, называют простым ключом.

Последовательность полей в составном ключе имеет определённое значение, поэтому нужно внимательно относиться к подбору последовательности полей в ключе.

Группа	фамилия	имя	отчество	телефон
СОЗ-07 1/9	Кравец	Сергей	Владимирович	538752
РПЗ-08 1/9	Кравец	Сергей	Владимирович	954946

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

Использование первичного ключа позволяет:

1. Однозначно определить конкретную запись в таблице,

2. Ускорить процедуру поиска данных в таблице,

3. Установить связь с другими таблицами базы данных,

4. Ограничить ссылочную целостность данных в таблицах БД.