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

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

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

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

1.2.1. с труктуры данн ых

С целью выделить из прикладной логики общие правила обработки данных в ранних информационных системах производились необходимые надстройки над файловыми системами в виде библиотеки программ, подобно тому, как это делается в компиляторах (см. Рис. 1.5. ).

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

Рис. 1.5. Примитивная схема структуризации данных в информационной системе

Система должна выполнять следующие действия:

– выдавать списки служащих по отделам;

– поддерживать возможность перевода служащего из одного отдела в другой;

– обеспечивать средства поддержки приема на работу новых служащих и увольнения работающих служащих, т. е. ввод и удаление данных о служащих.

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

лучения:

– имени руководителя отдела;

– общей численности отдела;

– общей суммы зарплаты служащих отдела, среднего размера зарплаты и т. д.

Для каждого служащего должна поддерживаться возможность получения:

– номера удостоверения по полному имени служащего (для простоты допус-

тим, что имена всех служащих различны);

– полного имени по номеру удостоверения;

– информации о соответствии служащего занимаемой должности и размере его зарплаты.

Предположим, что мы решили создать эту информационную систему на

файловой системе и пользоваться одним файлом СЛУЖАЩИЕ, расширив базовые возможности файловой системы за счет специальной библиотеки функций (см. Рис. 1.6. ). Поскольку минимальной информационной единицей в нашем случае является служащий, в этом файле должна содержаться одна запись для каждого служащего. Чтобы можно было удовлетворить указанные выше требования, за- пись о служащем должна иметь следующие поля:

– полное имя служащего (СЛЖ_ИМЯ);

– номер его удостоверения (СЛЖ_НОМЕР);

– данные о соответствии служащего занимаемой должности (СЛЖ_СТАТ =

{«да», «нет»});

– размер зарплаты (СЛЖ_ЗАРП);

– номер отдела (СЛЖ_ОТД_НОМЕР).

Поскольку мы решили ограничиться одним файлом СЛУЖАЩИЕ, та же запись должна содержать имя руководителя отдела (СЛЖ_ОТД_РУК). Если мы этого поля не введем, то невозможно будет, например, получить имя руководителя отдела в котором работает служащий.

Уникальные ключи

Неуникальный ключ

Файл СЛУЖАЩИЕ

СЛЖ_ИМЯ СЛЖ_НОМЕР СЛЖ_СТАТ СЛЖ_ЗАРП СЛЖ_ОТД_НОМЕР СЛЖ_ОТД_РУК

     

. . . . . . . . . . . . . . . . . .

     

Рис. 1.6. Структура файла СЛУЖАЩИЕ на уровне приложения

Чтобы информационная система могла эффективно выполнять свои базо- вые функции, необходимо обеспечить многоключевой доступ к файлу СЛУЖАЩИЕ по уникальным ключам СЛЖ_ИМЯ и СЛЖ_НОМЕР. Ключ называется уникальным, ес- ли его значения гарантированно различны во всех записях файла. Если мы не сможем обеспечить многоключевой доступ к файлу СЛУЖАЩИЕ, то для выполне- ния наиболее часто используемых операций получения данных о конкретном служащем понадобится последовательный просмотр в среднем половины запи- сей файла.

Кроме того, система должна обеспечить возможность эффективного выбо-

ра всех записей с общим значением СЛЖ_ОТД_НОМЕР, т. е. доступ по неуникаль- ному ключу. Если не поддерживать данный механизм доступа, то для получе- ния данных об отделе в целом, в общем случае потребуется полный просмотр файла.

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

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

– требуется создание сложной надстройки для многоключевого доступа к файлам;

– возникает существенная избыточность данных (для каждого служащего по-

вторяется номер и имя руководителя его отдела);

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

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

руктурировать файл СЛУЖАЩИЕ, объявляя ключевым и поле СЛЖ_ЗАРП.

Для улучшения ситуации можно было бы поддерживать два многоключевых файла: СЛУЖАЩИЕ и ОТДЕЛЫ. Первый файл должен был бы содержать поля СЛЖ_ИМЯ,

СЛЖ_НОМЕР, СЛЖ_СТАТ, СЛЖ_ЗАРП и СЛЖ_ОТД_НОМЕР, а второй – ОТД_НОМЕР, ОТД_РУК (номер удостоверения служащего, являющегося руководителем отдела), ОТД_СЛЖ_ ЗАРП (общий размер зарплаты служащих данного отдела) и ОТД_ЧИСЛ (общее число служащих в отделе). Структура этих файлов показана на Рис. 1.7. .

Уникальные ключи Неуникальный ключ