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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4. Индекс

Для ускорения процесса выполнения поиска данных, сортировки данных в таблице, используют индексы. Можно сделать индексированным любое поле таблицы.

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

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

Длинные текстовые поля неудобны для индексирования.

Дата добавления: 2014-07-19; просмотров: 467; Нарушение авторских прав

Мы поможем в написании ваших работ!