БД по локальной библиотеке

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

 

 

 

 

 

2 ТЕОРИЯ ПО БАЗАМ ДАННЫХ

 

2.1 Создание общей таблицы

 

     Целостность  сущностей и ссылок. Существуют требования к обеспечению целостности отношения.

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

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

     Каждой записи родительского  отношения может соответствовать  одна или несколько записей  дочернего отношения. Зависимость  между записями в первом случае  называется «один – к - одному», а во втором случае – «один  – ко - многом».

      Существует три механизма обеспечения ссылочной целостности.

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

       Каскадное  удаление:  

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

        

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

 

2.2  Типы данных

Типы полей формата Paradox

Alpha	строка длиной 1-255 байт, содержащая любые печатаемые символы
Number	числовое поле длиной 8 байт, значение которого может быть положительным и отрицательным. Диапазон чисел - от 10-308 до 10308 с 15 значащими цифрами
$ (Money)	числовое поле, значение которого может быть положительным и отрицательным. По умолчанию, является форматированным для отображения десятичной точки и денежного знака
Short	числовое поле длиной 2 байта, которое может содержать только целые числа в диапазоне от -32768 до 32767
Long Integer	числовое поле длиной 4 байта, которое может содержать целые числа в диапазоне от -2147483648 до 2147483648
# (BCD)	числовое поле, содержащее данные в формате BCD (Binary Coded Decimal). Скорость вычислений немного меньше, чем в других числовых форматах, однако точность - гораздо выше. Может иметь 0-32 цифр после десятичной точки
Date	поле даты длиной 4 байта, которое может содержать дату от 1 января 9999 г. до нашей эры - до 31 декабря 9999 г. нашей эры. Корректно обрабатывает високосные года и имеет встроенный механизм проверки правильности даты
Time	поле времени длиной 4 байта, содержит время в миллисекундах от полуночи и ограничено 24 часами
@ (Timestamp)	обобщенное поле даты длиной 8 байт - содержит и дату и время
Memo	поле для хранения символов, суммарная длина которых более 255 байт. Может иметь любую длину. При этом размер, указываемый при создании таблицы, означает количество символов, сохраняемых в таблице (1-240) - остальные символы сохраняются в отдельном файле с расширением .MB
Formatted Memo	поле, аналогичное Memo, с добавлением возможности задавать шрифт текста. Также может иметь любую длину. При этом размер, указываемый при создании таблицы, означает количество символов, сохраняемых в таблице (0-240) - остальные символы сохраняются в отдельном файле с расширением .MB. Однако, Delphi в стандартной поставке не обладает возможностью работать с полями типа Formatted Memo
Graphic	поле, содержащее графическую информацию. Может иметь любую длину. Смысл размера - такой же, как и в Formatted Memo. Database Desktop “умеет” создавать поля типа Graphic, однако наполнять их можно только в приложении
OLE	поле, содержащее OLE-данные (Object Linking and Embedding) - образы, звук, видео, документы - которые для своей обработки вызывают создавшее их приложение. Может иметь любую длину. Смысл размера - такой же, как и в Formatted Memo. Database Desktop “умеет” создавать поля типа OLE, однако наполнять их можно только в приложении. Delphi “напрямую” не умеет работать с OLE-полями, но это легко обходится путем использования потоков
Logical	поле длиной 1 байт, которое может содержать только два значения - T (true, истина) или F (false, ложь). Допускаются строчные и прописные буквы
+ (Autoincrement)	поле длиной 4 байта, содержащее нередактируемое (read-only) значение типа long integer. Значение этого поля автоматически увеличивается (начиная с 1) с шагом 1 - это очень удобно для создания уникального идентификатора записи (физический номер записи не может служить ее идентификатором, поскольку в Парадоксе таковой отсутствует. В InterBase также отсутствуют физические номера записей, но отсутствует и поле Autoincrement. Его с успехом заменяет встроенная функция Gen_id, которую удобней всего применять в триггерах)
Binary	поле, содержащее любую двоичную информацию. Может иметь любую длину. При этом размер, указываемый при создании таблицы, означает количество символов, сохраняемых в таблице (0-240) - остальные символы сохраняются в отдельном файле с расширением .MB. Это полнейший аналог поля BLOb в InterBase
Bytes	строка цифр длиной 1-255 байт, содержащая любые данные

 

2.3  Реляционная база данных. Типы связей

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

Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.

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

В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию. Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода.

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

Домен представляет собой множество всех возможных значений определенного атрибута отношения. Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 – номера всех отделов фирмы, домен 3 -  названия всех должностей, домен 4  - даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, например, числовые или символьные.

Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4-х элементов, каждый их которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы (рис. 3.1).

Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Д_рождения). Множество собственно кортежей отношения часто называют содержимым (телом) отношения.

Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Д. рождения) ключевым является атрибут «ФИО». Ключ может быть составным (сложным), т.е. состоять из нескольких атрибутов.

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

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

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

Ключи обычно используют для достижения следующих целей:

1. Исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);
2. Упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним  - возрастание, а по другим – убывание);
3. Ускорения работы к кортежами отношения (подраздел 3.2);
4. Организации связывания таблиц  (подраздел 3.3).

Пусть в отношении R1 имеется не ключевой атрибут. А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ.

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

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

1.Все строки таблицы должны  быть уникальны, т.е. не может быть  строк с одинаковыми первичными  ключами.

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

3.Все строки одной таблицы  должны иметь одну структуру, соответствующую именам и типам  столбцов.

4.Порядок размещения строк в  таблице может быть произвольным.

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

В общем случае можно считать, что БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access  в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули.

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

Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ и ее называют ключевой или таблицей с ключевыми полями.

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

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

Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).

 

Индексирование.

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

Термин «индекс» тесно связан с понятием «ключ», хотя между ними есть и некоторое отличие.

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

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

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

• Вида содержимого в поле ключа записей индексного файла;
• Типа используемых ссылок (указателей) на запись основной таблицы;
• Метода поиска нужных записей.

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

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

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

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

При одноуровневой схеме в индексном файле хранятся короткие записи, имеющие два поля: поле содержимого старшего ключа (хеш-кода ключа) адресуемого блока и поле адреса начала этого блока (рис. 3.3). В каждом блоке записи располагаются в порядке возрастания значения ключа или свертки. Старшим ключом каждого блока является ключ его последней записи.

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

1.Образование свертки значения  ключевого поля искомой записи.

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

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

Основным  недостатком одноуровневой схемы является то, что ключи (свертки) записей хранятся вместе с записями. Это приводит к увеличению времени поиска записей из-за большой длины просмотра (значения данных в записях приходится пропускать).

 

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

 

		Блок ключей - 1
				Запись
		. . .
				Запись
		Блок ключей - 2
				Запись
				Запись
		Блок ключей - N
Главный индекс				запись
		. . .
				запись