Название: Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Токмаков Г. П.) Жанр: Информационные системы и технологии Просмотров: 1448 |
1.2.1. с труктуры данн ых
С целью выделить из прикладной логики общие правила обработки данных в ранних информационных системах производились необходимые надстройки над файловыми системами в виде библиотеки программ, подобно тому, как это делается в компиляторах (см. Рис. 1.5. ). Но очень скоро стало понятно, что с помощью общей библиотеки программ невозможно реализовать более сложные методы хранения данных. Поясним это на примере. Предположим, что требуется реализовать простую информацион- ную систему, поддерживающую учет служащих некоторой организации.
Система должна выполнять следующие действия: – выдавать списки служащих по отделам; – поддерживать возможность перевода служащего из одного отдела в другой; – обеспечивать средства поддержки приема на работу новых служащих и увольнения работающих служащих, т. е. ввод и удаление данных о служащих. Кроме того, для каждого отдела должна поддерживаться возможность по- лучения: – имени руководителя отдела; – общей численности отдела; – общей суммы зарплаты служащих отдела, среднего размера зарплаты и т. д. Для каждого служащего должна поддерживаться возможность получения: – номера удостоверения по полному имени служащего (для простоты допус- тим, что имена всех служащих различны); – полного имени по номеру удостоверения; – информации о соответствии служащего занимаемой должности и размере его зарплаты. Предположим, что мы решили создать эту информационную систему на файловой системе и пользоваться одним файлом СЛУЖАЩИЕ, расширив базовые возможности файловой системы за счет специальной библиотеки функций (см. Рис. 1.6. ). Поскольку минимальной информационной единицей в нашем случае является служащий, в этом файле должна содержаться одна запись для каждого служащего. Чтобы можно было удовлетворить указанные выше требования, за- пись о служащем должна иметь следующие поля: – полное имя служащего (СЛЖ_ИМЯ); – номер его удостоверения (СЛЖ_НОМЕР); – данные о соответствии служащего занимаемой должности (СЛЖ_СТАТ = {«да», «нет»}); – размер зарплаты (СЛЖ_ЗАРП); – номер отдела (СЛЖ_ОТД_НОМЕР). Поскольку мы решили ограничиться одним файлом СЛУЖАЩИЕ, та же запись должна содержать имя руководителя отдела (СЛЖ_ОТД_РУК). Если мы этого поля не введем, то невозможно будет, например, получить имя руководителя отдела в котором работает служащий.
Неуникальный ключ Файл СЛУЖАЩИЕ
СЛЖ_ИМЯ СЛЖ_НОМЕР СЛЖ_СТАТ СЛЖ_ЗАРП СЛЖ_ОТД_НОМЕР СЛЖ_ОТД_РУК
. . . . . . . . . . . . . . . . . .
Рис. 1.6. Структура файла СЛУЖАЩИЕ на уровне приложения
Чтобы информационная система могла эффективно выполнять свои базо- вые функции, необходимо обеспечить многоключевой доступ к файлу СЛУЖАЩИЕ по уникальным ключам СЛЖ_ИМЯ и СЛЖ_НОМЕР. Ключ называется уникальным, ес- ли его значения гарантированно различны во всех записях файла. Если мы не сможем обеспечить многоключевой доступ к файлу СЛУЖАЩИЕ, то для выполне- ния наиболее часто используемых операций получения данных о конкретном служащем понадобится последовательный просмотр в среднем половины запи- сей файла. Кроме того, система должна обеспечить возможность эффективного выбо- ра всех записей с общим значением СЛЖ_ОТД_НОМЕР, т. е. доступ по неуникаль- ному ключу. Если не поддерживать данный механизм доступа, то для получе- ния данных об отделе в целом, в общем случае потребуется полный просмотр файла. Но даже в этом случае, чтобы получить численность отдела или общий размер зарплаты, система должна будет выбрать все записи о служащих ука- занного отдела и посчитать соответствующие общие значения. Таким образом, мы видим, что при реализации даже такой простой инфор- мационной системы на базе файловой системы возникают следующие затруд- нения: – требуется создание сложной надстройки для многоключевого доступа к файлам; – возникает существенная избыточность данных (для каждого служащего по- вторяется номер и имя руководителя его отдела); – требуется выполнение массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы потребуется, например, обес- печить операцию выдачи списков служащих, получающих указанную зарплату, то для этого либо придется полностью просматривать файл, либо нужно будет рест- руктурировать файл СЛУЖАЩИЕ, объявляя ключевым и поле СЛЖ_ЗАРП. Для улучшения ситуации можно было бы поддерживать два многоключевых файла: СЛУЖАЩИЕ и ОТДЕЛЫ. Первый файл должен был бы содержать поля СЛЖ_ИМЯ, СЛЖ_НОМЕР, СЛЖ_СТАТ, СЛЖ_ЗАРП и СЛЖ_ОТД_НОМЕР, а второй – ОТД_НОМЕР, ОТД_РУК (номер удостоверения служащего, являющегося руководителем отдела), ОТД_СЛЖ_ ЗАРП (общий размер зарплаты служащих данного отдела) и ОТД_ЧИСЛ (общее число служащих в отделе). Структура этих файлов показана на Рис. 1.7. .
Файл СЛУЖАЩИЕ
СЛЖ_ИМЯ СЛЖ_НОМЕР СЛЖ_СТАТ СЛЖ_ЗАРП СЛЖ_ОТД_НОМЕР . . . . . . . . . . . . . . .
Рис. 1.7. Структура файлов СЛУЖАЩИЕ и ОТДЕЛЫ на уровне приложения
Введение этих двух файлов позволило бы преодолеть большинство не- удобств, перечисленных выше. При этом: – каждый из файлов содержал бы только не дублируемую информацию; – не возникала бы необходимость в динамических вычислениях суммарной информации по отделам.
|
|