Название: Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Токмаков Г. П.)

Жанр: Информационные системы и технологии

Просмотров: 1420


1.1.3.  п осле д о вательный и ассо ци ати в н ы й доступ в файло в ых  сист емах

На первых ЭВМ данные хранились на ленте и записи извлекались и обра- батывались последовательно. В программах эти данные были организованы точно также как и на физическом носителе когда еще не существовало понятия логической структуры.

Поэтому при этом использовался самый простой способ локализации записи – сканирование файла до выявления требуемой записи. Для реализации данного способа доступа достаточно было знать начальный адрес файла (см. Рис. 1.3. ).

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

в которых содержится информация об одном сотруднике.

 

 

Логическая структура данных

 

Дескриптор файла

Метод доступа к пос- ледовательным данным

Физический файл

 

 

 

1

2

3

4

5

6

7

8

eof

 

 
Программа, использущая последовательный файл

Логика программы,

реализуемая программистом

 

Информационная система .

 

 

Рис. 1.3.          Логическая и физическая структуры файлов с последовательным доступом

 

Каждая логическая запись делится на поля, такие как имя, адрес, иденти-

фикационный номер сотрудника и т. д.

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

Неотъемлемой частью процесса обработки последовательного файла явля-

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

Хотя во многих приложениях требуется идентифицировать записи по клю- чам, которые не являются уникальными (например, Фамилия, Имя, Отчество), но при этом все равно должен существовать один уникальный ключ, используе- мый для идентификации записи в файле (например, в таблице СТУДЕНТЫ  это номер зачетной книжки). Такой ключ называется первичным или идентифика- тором.

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

Ограниченные возможности последовательных файлов не помешали им быть эффективным средством для составления один или два раза в месяц счетов, пла-

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

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

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

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

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

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

Классическим примером использования индексированного файла является обслуживание записей сотрудников. За счет создания индекса можно избежать

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

известен (см. Рис. 1.4. ).

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

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

На основе рассмотренных вариантов информационных систем, построен-

ных на основе файловых систем, можно констатировать следующее:

– типовым программным обеспечением обработки данных в этих информа-

ционных системах являются методы доступа, а не методы управления данными;

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

В качестве аналога индекса можно привести предметный указатель, разме-

щаемый в конце книги. Понятие индекса широко используется в СУБД и пона-

добится нам в дальнейшем.