Управление данными: Прошлое, Настоящее и Будущее
Джим Грей, Системы Управления Базами Данных # 3/1998, Новая редакция: Сергей Кузнецов, 2009 г.
Оригинал: Jim Gray. Data Management: Past, Present, and Future. IEEE Computer 29(10): 38-46 (1996), Vol. 29, # 10, October 1996..
Быстрое развитие технологий хранения данных, коммуникаций и обработки позволяет переместить всю информацию в киберпространство. Программное обеспечение для определения, поиска и визуализации оперативно доступной информации является ключом к созданию такой информации и доступу к ней. Начало систем управления данными связано с решением традиционных задач автоматизации – учета транзакций в бизнесе, науке и коммерции. Эти данные состояли главным образом из чисел и символьных строк. Сегодня эти системы обеспечивают инфраструктуру для большей части общества, предоставляя возможность быстрого, надежного, безопасного и автоматического доступа к данным, распределенным по всему миру. Следующие шаги состоят в автоматизации доступа к более богатым формам данных: изображениям, аудио- и видеоданным, картам и т.д. Другой важной задачей является автоматическое обобщение и абстрагирование данных в соответствии с запросами пользователей. Мультимедийные базы данных и средства доступа к ним будут краеугольным камнем в нашем движении к киберпространству.
Рис. 1. Шесть поколений управления данными, начиная от ручных методов, через несколько стадий автоматизации управления данными.
Системы управления данными обычно хранят громадные объемы данных, представляющих исторические записи организации. Размеры этих баз данных бурно растут. Системы постоянно изменяются. Действительно, большая часть крупных систем баз данных была разработана несколько десятков лет тому назад и развивалась вместе с развитием технологии. Взгляд в историю помогает понять текущие системы.
В управлении данными имелось шесть разных фаз. Вначале данные обрабатывались вручную. На следующем шаге использовались оборудование с перфокартами и электромеханические машины для сортировки и табулирования миллионов записей. На третьей фазе данные хранились на магнитных лентах, и сохраняемые программы выполняли пакетную обработку последовательных файлов. На четвертой фазе было введено понятия схемы базы данных и оперативного навигационного доступа к данным. На пятой фазе был обеспечен автоматический доступ к реляционным базам данным и была внедрена распределенная и клиент-серверная обработка. Теперь мы находимся в начале шестого поколения систем, которые хранят более богатые типы данных, в особенности, документы, изображения, аудио- и видеоданные. Эти системы шестого поколения представляют собой базовые средства хранения для появляющихся приложений Internet и intranet.
2.0 Нулевое поколение: менеджеры записей (4000 г. до н. э. – 1900)
В первых известных письменных свидетельствах описывается учет царской казны и налогов в Шумере. Поддержка записей имеет долгую историю. В следующие шесть тысяч лет наблюдается эволюция от глиняных таблиц к папирусу, затем к пергаменту и, наконец, к бумаге. Имелось много новшеств в представлении данных: фонетические алфавиты, сочинения, книги, библиотеки, бумажные и печатные издания. Это были большие достижения, но обработка информации в эту эпоху производилась вручную.
2.1. Первое поколение: менеджеры записей (1900-1955)
Впервые автоматизированная обработка информации появилась приблизительно в 1800 году, когда Джеквард Лум (Jacquard Loom) начал производить раскрой ткани по образцам, представленным перфокартами. В 1890 г. Холлерит (Herman Hollerith) использовал технологию перфокарт для выполнения переписи населения Соединенных Штатов. Его система содержала запись для каждой семьи. Каждая запись данных представлялась в виде двоичных структур на перфокарте. Бизнес Холлерита в конце концов привел к возникновению International Business Machines. Эта небольшая компания IBM процветала в период от 1915 до 1960 года как поставщик оборудования регистрации данных для бизнеса и правительственных организаций.
К 1955 году у многих компаний имелись целые этажи, предназначенные для хранения перфокарт, на других этажах размещались шеренги перфораторов, сортировщиков и табуляторов. Было ясно, что наступает время, когда новая технология вытеснит перфокарты и электромеханические компьютеры.
2.2. Второе поколение: программируемое оборудование обработки записей (1955-1970)
Электронные компьютеры с хранимыми программами были разработаны в 1940-х и начале 1950-х годов для выполнения научных и численных вычислений. Примерно в то же время компания Univac разработала аппаратуру магнитных лент, каждая из которых могла хранить столько информации, сколько десять тысяч перфокарт.
Ключевым компонентом этой новой технологии было программное обеспечение. Было гораздо проще сортировать, анализировать и обрабатывать данные с применением таких языков, как COBOL и RPG. Начали появляться стандартные пакеты для таких общеупотребительных бизнес-приложений как общая бухгалтерия, расчет заработной платы и пр.
Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Типичные программы последовательно читали несколько входных файлов и производили на выходе новые файлы. Для облегчения определения этих ориентированных на записи последовательных задач были созданы COBOL и несколько других языков программирования. Операционные системы обеспечивали абстракцию файла для хранения этих записей, язык управления заданиями для выполнения заданий и планировщик заданий для управления потоком работ.
Системы пакетной обработки транзакций сохраняли транзакции на картах или лентах и собирали их в пакеты для последующей обработки. Пакетная обработка позволяла очень эффективно использовать компьютеры, но обладала двумя серьезными ограничениями. Если в транзакции имелась ошибка, она не распознавалась до вечерней обработки основного файла, и могло потребоваться несколько дней для исправления транзакции. Более важным является то, что бизнес не знал текущего состояния базы данных – поскольку транзакции реально не обрабатывались до следующего утра. Для решения этих двух проблем требовался следующий шаг эволюции – оперативные системы. Этот шаг также существенно облегчил написание приложений.
2.3. Третье поколение: оперативные сетевые базы данных (1965-1980)
Для таких приложений, как ведение операций на фондовой бирже или резервирование билетов, требуется знание текущей информации. С конца 1950-х лидирующие компании из нескольких областей индустрии начали вводить в использование системы баз данных с оперативными транзакциями. Оперативный доступ к данным обеспечивался несколькими ключевыми технологиями. Аппаратура для подключения к компьютеру интерактивных компьютерных терминалов прошла путь развития от телетайпов к простым алфавитно-цифровым дисплеям и, наконец, к сегодняшним интеллектуальным терминалам, основанным на технологии персональных компьютеров. Мониторы телеобработки представляли собой специализированное программное обеспечение для мультиплексирования тысяч терминалов со скромными серверными компьютерами того времени. Эти мониторы собирали сообщения-запросы, поступающие с терминалов, быстро назначали программы сервера для обработки каждого сообщения и затем направляли ответ на соответствующий терминал. Оперативная обработка транзакций дополняла возможности пакетной обработки транзакций, за которой оставались задачи фонового формирования отчетов.
Оперативные базы данных хранились на магнитных дисках или барабанах, которые обеспечивали доступ к любому элементу данных за доли секунды. Эти устройства и программное обеспечение управления данными давали возможность программам считывать несколько записей, изменять их и затем возвращать новые значения оперативному пользователю. В начале системы обеспечивали простой поиск данных: либо прямой поиск по номеру записи, либо ассоциативный поиск по ключу.
Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы.
На рис. 2.a показаны некоторые типы записей простой системы резервирования авиационных билетов и их связи. Каждому городу соответствует набор отбывающих рейсов. Каждому заказчику соответствует набор путешествий, а каждое путешествие состоит из набора рейсов. Кроме того, каждому рейсу соответствует набор пассажиров. Как показано на рис. 2.b, эта информация может быть представлена в виде трех иерархий наборов. Каждая из трех иерархий отвечает на отдельный вопрос. Первый – это планирование рейсов в городе. Вторая иерархия дает представление о рейсах заказчика. Третья иерархия говорит, к какому рейсу относится каждый заказчик. Приложение резервирования билетов нуждается во всех трех этих представлениях данных.
Рис. 2. Эволюция моделей данных.
(a) Чистая иерархическая модель с записями, сгруппированными под другими записями.
(b) По мере развития приложения разным пользователям желательно иметь разные представления данных, выражаемые в виде разных иерархий.
(c) Диаграмма Бахмана, показывающая типы записей и связи между типами записей.
(d) Та же информация, представленная в реляционной модели, где все данные и все связи явно представляются как записи. Отношения показаны вверху рисунка. Некоторые детали отношения Segment показаны в нижнем правом углу; это отношение содержит запись для каждого рейса (сегмента) маршрута пассажира.
Иерархическое представление на рис. 2.b обладает существенным недостатком. Избыточное хранение данных не только дорого стоит, но также и порождает проблемы обновлений: при создании рейса или изменении его информации необходимо обновить данные во всех трех местах (всех трех иерархиях). Для решения этих проблем информацию можно представлять в сетевой модели данных, что показано на рис. 2.c. На рис. 2.c изображена одна база данных, в которой каждая запись хранится в одном экземпляре и связывается с набором других записей посредством связи. Например, все рейсы, используемые в путешествии конкретного заказчика, связываются с этим путешествием. Программа может попросить систему баз данных перебрать эти рейсы. При потребности между записями могут создаваться новые связи. Рис. 2.c называется по-разному – диаграммой Бахмана или диаграммой «сущность-связь» . Реляционная диаграмма с рис. 2 (рис. 2.d) описывается в следующем разделе.
Управление ассоциативным доступом и обработкой, ориентированной на наборы, было настолько распространено, что в сообществе COBOL выделилась группа Data Base Task Group (DBTG) для определения стандартного способа спецификации таких данных и доступа к ним. Чарльз Бахман (Charles Bachman) в GE (General Electric) построил прототип системы навигации по данным. За руководство работы DBTG, разработавшей стандартный язык определения данных и манипулирования данными, Бахман получил Тьюринговскую премию. В своей Тьюринговской лекции он описал эволюцию моделей плоских файлов к новому миру, где программы могут осуществлять навигацию между записями, следуя связям между записями. Модель Бахмана напоминает навигационную модель страниц и ссылок сегодняшнего Internet.
В сообществе баз данных COBOL кристаллизовалась концепция схем и независимости данных. Они поняли потребность в сокрытии физических деталей расположения записей. Программы должны были видеть только логическую организацию записей и связей, так что программы продолжали работать при изменении и развитии способов хранения данных. Записи, поля и связи, не используемые программой, следовало сокрыть – как по соображениям безопасности, так и для того, чтобы изолировать программу от неизбежных изменений схемы базы данных.
В этих ранних базах данных поддерживались три вида схем данных: 1) логическая схема, которая определяет глобальный логический проект записей базы данных и связей между записями; 2) физическая схема, описывающая физическое размещение записей базы данных на устройствах памяти и в файлах, а также индексы, нужные для поддержки логических связей; 3) предоставляемая каждому приложению подсхема, раскрывающая только часть логической схемы, которую использует программа. Механизм логических, физических и подсхем обеспечивал независимость данных. И на самом деле, многие программы, написанные в ту эпоху, все еще работают сегодня с использованием той же самой подсхемы, с которой все начиналось, хотя логическая и физическая схемы абсолютно изменились.
Эти оперативные системы должны были решить проблему одновременного выполнения многих транзакций над базой данных, совместно используемой многими терминальными пользователями. До этого подход, основанный на однопрограммном режиме и периодическом изменении основного файла, устранял проблемы параллельного доступа и восстановления. Ранние оперативные системы проложили путь понятию транзакций, блокировавших только те записи, к которым производился доступ. Блокировки позволяют конкурирующим транзакциям получать доступ к разным записям. Системы также поддерживали журнал записей, изменявшихся каждой транзакцией. При сбое транзакции журнал использовался для устранения в базе данных воздействий этой транзакции. Журнал транзакций использовался также для восстановления базы данных в случае аварии носителя. При крахе системы для воссоздания текущего состояния базы данных журнал применялся к ее архивной копии.
К 1980 году сетевые (и иерархические) модели данных, ориентированные на наборы записей, стали очень популярны
2.4. Четвертое поколение: реляционные базы данных и архитектура клиент-сервер (1980-1995)
Несмотря на успех сетевой модели данных, многие разработчики программного обеспечения чувствовали, что навигационный программный интерфейс был интерфейсом слишком низкого уровня. Было трудно проектировать и программировать эти базы данных. В статье Э.Ф. (Теда) Кодда (E.F. Codd) 1970 года была обрисована реляционная модель, которая казалась альтернативой низкоуровневому навигационному интерфейсу.
Идея реляционной модели состоит в том, чтобы единообразно представлять и сущности, и связи. Реляционная модель данных обладала унифицированным языком для определения данных, навигации по данным и манипулирования данными, а не отдельными языками для каждой из этих задач. Еще более важно то, что реляционная алгебра имеет дело со множествами записей (отношениями) как единым целым, применяя операции к множествам записей целиком и производя множества записей в результате. Реляционные модель данных и операции дают возможность получения более коротких и более простых программ для решения задач управления записями.
«Найти номера рейсов до Сан-Франциско, которые являются сегментами путешествия любого заказчика с именем Джонс. Для поиска этих рейсов использовать таблицы City, Flight, Segment, Trip и Customer». Эта программа может показаться сложной, но она значительно проще соответствующей навигационной программы.
Получая такой непроцедурный запрос, реляционная система баз данных автоматически находит лучший способ подбора записей в таблицах City, Flight, Segment, Trip и Customer. Запрос не зависит от того, какие определены связи. Он будет продолжать работать даже после логической реорганизации базы данных. Следовательно, запрос обладает гораздо лучшей независимостью от данных, чем навигационный запрос, основанный на сетевой модели данных.
Вдохновляемые идеями Кодда в течение 1970-х исследователи из академии и индустрии экспериментировали с этим новым подходом к структуризации баз данных и обеспечения доступа к ним, обещавшим более простое моделирование данных и прикладное программирование. Многие реляционные прототипы, разработанные в течение этого периода, сошлись на общей модели и языке. Исследования в IBM Research, возглавлявшиеся Тедом Коддом, Реймондом Бойсом (Raymond Boyce) и Доном Чемберлином (Don Chamberlin), и работа в Калифорнийском университете г. Беркли, которой руководил Майкл Стоунбрейкер (Michael Stonebraker), породили язык, названный SQL. Этот язык был впервые стандартизован в 1985 году. Впоследствии были произведены два основных расширения стандарта. Сегодня почти все системы баз данных обеспечивают интерфейс SQL. Кроме того, во всех системах поддерживаются собственные расширения, выходящие за рамки этого стандарта.
Реляционная модель обладает некоторыми неожиданными преимуществами, кроме повышения продуктивности программистов и простоты использования. Реляционная модель оказалась хорошо пригодной к использованию в архитектуре клиент-сервер, к параллельной обработке и графическим пользовательским интерфейсам. Приложение клиент-сервер разбивается на две части. Клиентская часть отвечает за поддержку ввода и представление выводных данных для пользователя или клиентского устройства. Сервер отвечает за хранение базы данных, обработку клиентских запросов к базе данных, возврат клиенту общего ответа. Реляционный интерфейс особенно удобен для использования в архитектуре клиент-сервер, поскольку приводит к обмену высокоуровневыми запросами и ответами. Высокоуровневый интерфейс SQL минимизирует коммуникации между клиентом и сервером. Сегодня многие клиент-серверные средства строятся на основе протокола Open Database Connectivity (ODBC), который обеспечивает для клиента стандартный механизм запросов высокого уровня к серверу. Парадигма клиент-сервер продолжает развиваться.
|
