Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения, например, с помощью естественного языка на конкретном носителе (например, бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение «Стоимость авиабилета 128». Здесь «128» – данное, а «Стоимость авиабилета» – его семантика.
Нередко данные и интерпретация разделены. Например, «Расписание движения самолетов» может быть представлено в виде таблицы (таблица 1.1), в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).
Таблица 1.1 – Расписание движения самолетов
| Интерпретация | |||||||
| Номер рейса | Дни недели | Пункт отправления | Время вылета | Пункт назначения | Время прибытия | Тип самолета | Стоимость билета |
| Данные | |||||||
| 2_4_7 | Баку | 21.12 | Москва | 0.52 | ИЛ-86 | 115.00 | |
| 3_6 | Ереван | 7.20 | Киев | 9.25 | ТУ-154 | 92.00 | |
| 2_6 | Казань | 22.40 | Баку | 23.50 | ТУ-134 | 73.50 | |
| 1 по 7 | Киев | 14.10 | Москва | 16.15 | ТУ-154 | 57.00 | |
| 2_3_5 | Минск | 10.50 | Сочи | 13.06 | ИЛ-86 | 78.50 | |
| 1_3_6 | Москва | 15.17 | Баку | 18.44 | ИЛ-86 | 115.00 | |
| 1 по 7 | Москва | 9.05 | Киев | 11.05 | ТУ-154 | 57.00 | |
| 1_3_5 | Рига | 21.53 | Таллин | 22.57 | АН-24 | 21.50 | |
| 3_6 | Сочи | 18.25 | Баку | 20.12 | ТУ-134 | 44.00 | |
| 2_4_6 | Таллин | 6.30 | Рига | 7.37 | АН-24 | 21.50 |
Применение ЭВМ для ведения (ведение данных – термин, объединяющий действия по добавлению, удалению или изменению хранимых данных) и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не «знает», является ли «21.50» стоимостью авиабилета или временем вылета).
Существуют по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации:
1. ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных;
2. стоимость памяти ЭВМ была первоначально весьма велика.
Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая «знала», например, что шестое вводимое значение связано со временем прибытия самолета, а четвертое – со временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.
Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими. Нередки случаи, когда пользователи одной и той же ЭВМ создают и используют в своих программах разные наборы данных, содержащие сходную информацию.
Разработчики прикладных программ (написанных, например, на Бейсике, Паскале или С) размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. При этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.). Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех программ, которые используют записи этого файла.
В книге У. Девиса (Операционные системы, М., Мир, 1980) приведен пример:
«Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это, казалось бы, незначительное изменение привело к ужасным последствиям. Добавление к адресу нового поля, содержащего шесть символов, означало необходимость внесения изменений в каждую программу, использующую данные этой задачи в соответствии с изменившейся суммарной длиной полей. Тот факт, что какой-то программе для выполнения ее функций не требуется знания почтового индекса, во внимание не принимался: если в некоторой программе содержалось обращение к новой, более длинной записи, то в такую программу вносились изменения, обеспечивающие дополнительное место в памяти».
Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых «Системы управления базами данных» (СУБД). Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банками данных, а затем базами данных (БД).
Пусть, например, требуется хранить расписание движения самолетов (таблица. 1.1) и ряд других данных, связанных с организацией работы аэропорта (БД «Аэропорт»). Представив, что мы используем для этого «русифицированную» СУБД, можно подготовить следующее описание расписания:
СОЗДАТЬ ТАБЛИЦУ Расписание (Номер_рейса Целое Дни_недели Текст (8) Пункт_отправления Текст (24) Время_вылета Время Пункт_назначения Текст (24) Время_прибытия Время Тип_самолета Текст (8) Стоимость_билета Валюта);и ввести его вместе с данными в БД «Аэропорт».
Язык запросов СУБД позволяет обращаться за выборкой данных как из программ, так и с терминалов). Сформировав запрос
ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылетаИЗ ТАБЛИЦЫ РасписаниеГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Киев' И Время_вылета > 17;получим расписание «Москва-Киев» на вечернее время, а по запросу
ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса)ИЗ ТАБЛИЦЫ РасписаниеГДЕ Пункт_отправления = 'Москва' И Пункт_назначения = 'Минск';получим количество рейсов «Москва-Минск».
Эти запросы не потеряют актуальности и при расширении таблицы:
ДОБАВИТЬ В ТАБЛИЦУ Расписание Длительность_полета Целое;как это было с программами обработки почтовых адресов при введении почтового индекса.
Однако за все надо расплачиваться: на обмен данными через СУБД требуется большее время, чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного приложения.