Глава 1. Что такое базы данных и
СУБД
1.1. Данные и ЭВМ
Восприятие реального мира можно
соотнести с последовательностью
разных, хотя иногда и
взаимосвязанных, явлений. С давних
времен люди пытались описать эти
явления (даже тогда, когда не могли
их понять). Такое описание называют данными.
Традиционно фиксация данных
осуществляется с помощью
конкретного средства общения
(например, с помощью естественного
языка или изображений) на
конкретном носителе (например,
камне или бумаге). Обычно данные
(факты, явления, события, идеи или
предметы) и их интерпретация
(семантика) фиксируются совместно,
так как естественный язык
достаточно гибок для представления
того и другого. Примером может
служить утверждение "Стоимость
авиабилета 128". Здесь "128" –
данное, а "Стоимость
авиабилета" – его семантика.
Нередко данные и интерпретация
разделены. Например, "Расписание
движения самолетов" может быть
представлено в виде таблицы (рис.
1.1), в верхней части которой
(отдельно от данных) приводится их
интерпретация. Такое разделение
затрудняет работу с данными
(попробуйте быстро получить
сведения из нижней части таблицы).
| Интерпретация |
| Номер рейса |
Дни недели |
Пункт отправления |
Время вылета |
Пункт назначения |
Время прибытия |
Тип самолета |
Стоимость билета |
| Данные |
| 138 |
2_4_7 |
Баку |
21.12 |
Москва |
0.52 |
ИЛ-86 |
115.00 |
| 57 |
3_6 |
Ереван |
7.20 |
Киев |
9.25 |
ТУ-154 |
92.00 |
| 1234 |
2_6 |
Казань |
22.40 |
Баку |
23.50 |
ТУ-134 |
73.50 |
| 242 |
1 по 7 |
Киев |
14.10 |
Москва |
16.15 |
ТУ-154 |
57.00 |
| 86 |
2_3_5 |
Минск |
10.50 |
Сочи |
13.06 |
ИЛ-86 |
78.50 |
| 137 |
1_3_6 |
Москва |
15.17 |
Баку |
18.44 |
ИЛ-86 |
115.00 |
| 241 |
1 по 7 |
Москва |
9.05 |
Киев |
11.05 |
ТУ-154 |
57.00 |
| 577 |
1_3_5 |
Рига |
21.53 |
Таллин |
22.57 |
АН-24 |
21.50 |
| 78 |
3_6 |
Сочи |
18.25 |
Баку |
20.12 |
ТУ-134 |
44.00 |
| 578 |
2_4_6 |
Таллин |
6.30 |
Рига |
7.37 |
АН-24 |
21.50 Рис. 1.1.
К разделению данных и их
интерпретации
|
Применение ЭВМ для ведения* и обработки данных
обычно приводит к еще большему
разделению данных и интерпретации.
ЭВМ имеет дело главным образом с
данными как таковыми. Большая часть
интерпретирующей информации
вообще не фиксируется в явной форме
(ЭВМ не "знает", является ли
"21.50" стоимостью авиабилета
или временем вылета). Почему же это
произошло?
Существует по крайней мере две
исторические причины, по которым
применение ЭВМ привело к отделению
данных от интерпретации. Во-первых,
ЭВМ не обладали достаточными
возможностями для обработки
текстов на естественном языке –
основном языке интерпретации
данных. Во-вторых, стоимость памяти
ЭВМ была первоначально весьма
велика. Память использовалась для
хранения самих данных, а
интерпретация традиционно
возлагалась на пользователя.
Пользователь закладывал
интерпретацию данных в свою
программу, которая "знала",
например, что шестое вводимое
значение связано с временем
прибытия самолета, а четвертое – с
временем его вылета. Это
существенно повышало роль
программы, так как вне
интерпретации данные представляют
собой не более чем совокупность
битов на запоминающем устройстве.
Жесткая зависимость между
данными и использующими их
программами создает серьезные
проблемы в ведении данных и делает
использования их менее гибкими.
Нередки случаи, когда
пользователи одной и той же ЭВМ
создают и используют в своих
программах разные наборы данных,
содержащие сходную информацию.
Иногда это связано с тем, что
пользователь не знает (либо не
захотел узнать), что в соседней
комнате или за соседним столом
сидит сотрудник, который уже давно
ввел в ЭВМ нужные данные. Чаще
потому, что при совместном
использовании одних и тех же данных
возникает масса проблем.
Разработчики прикладных программ
(написанных, например, на Бейсике,
Паскале или Си) размещают нужные им
данные в файлах, организуя их
наиболее удобным для себя образом.
При этом одни и те же данные могут
иметь в разных приложениях
совершенно разную организацию
(разную последовательность
размещения в записи, разные форматы
одних и тех же полей и т.п.).
Обобществить такие данные
чрезвычайно трудно: например, любое
изменение структуры записи файла,
производимое одним из
разработчиков, приводит к
необходимости изменения другими
разработчиками тех программ,
которые используют записи этого
файла.
Для иллюстрации обратимся к
примеру, приведенному в книге:
У.Девис, Операционные системы, М.,
Мир, 1980:
"Несколько лет назад
почтовое ведомство (из лучших
побуждений) пришло к решению, что
все адреса должны обязательно
включать почтовый индекс. Во многих
вычислительных центрах это,
казалось бы, незначительное
изменение привело к ужасным
последствиям. Добавление к адресу
нового поля, содержащего шесть
символов, означало необходимость
внесения изменений в каждую
программу, использующую данные
этой задачи в соответствии с
изменившейся суммарной длиной
полей. Тот факт, что какой-то
программе для выполнения ее
функций не требуется знания
почтового индекса, во внимание не
принимался: если в некоторой
программе содержалось обращение к
новой, более длинной записи, то в
такую программу вносились
изменения, обеспечивающие
дополнительное место в памяти.
В условиях
автоматизированного управления
централизованной базой данных все
такие изменения связаны с
функциями управляющей программы
базы данных. Программы, не
использующие значения почтового
индекса, не нуждаются в модификации
- в них, как и прежде, в соответствии
с запросами посылаются те же
элементы данных. В таких случаях
внесенное изменение неощутимо.
Модифицировать необходимо только
те программы, которые пользуются
новым элементом данных.".
* Ведение
(сопровождение, поддержка) данных –
термин объединяющий действия по
добавлению, удалению или изменению
храни-мых данных.
[Содержание] [Вперед]
|