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

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

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


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

 

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

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

 

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

 

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

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

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

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

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

лучения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

 

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

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

 

 

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

 

                                                            

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

                                                            

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

 

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

                                                

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

                                                

 

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

 

Файл ОТДЕЛЫ

 

 

ОТД_НОМЕР

ОТД_РУК

ОТД_СЛЖ_ЗАРП

ОТД_ЧИСЛ

. . .

. . .

. . .

. . .

 

 

Рис. 1.7.          Структура файлов СЛУЖАЩИЕ и ОТДЕЛЫ

на уровне приложения

 

Введение этих  двух  файлов позволило бы  преодолеть большинство не-

удобств, перечисленных выше. При этом:

– каждый из файлов содержал бы только не дублируемую информацию;

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