Лекция 19. Основные направления развития технологий баз данных




НазваниеЛекция 19. Основные направления развития технологий баз данных
страница1/3
Дата публикации05.06.2013
Размер0.51 Mb.
ТипЛекция
uchebilka.ru > История > Лекция
  1   2   3

Лекция 19. Основные направления развития технологий баз данных



Краткая аннотация. Данная лекция является заключительной лекцией курса. И вместо подведения итогов курса, предлагается кратко рассмотреть ближайшие перспективы и направления развития технологий баз данных. В данной лекции рассматривается история развития технологии обработки данных, даются характеристики постреляционным, объектно-ориентированные базам данных, базам данных, основанные на правилах. Отдельные перспективные черты, характерные этим направлениям, присущи уже современным серверам баз данных.
^ Список ключевых терминов. Постреляционные базы данных. Объектно-ориентированные базы данных. Базы данных, основанные на правилах. Активная база данных. Дедкутивная база данных.
^ Цель лекции. Познакомить студентов с ближайшими перспективами и направлениями развития технологий баз данных. Рассматривается история развития технологии обработки данных, даются характеристики постреляционным, объектно-ориентированные базам данных, базам данных, основанные на правилах, отдельные черты которых присущи уже современным серверам баз данных.
^ Текст лекции:
В данной лекции, являющейся заключительной лекцией курса, рассматриваются основные направления в области развития технологий баз данных. Это тем настолько многообразна, что ей может быть посвящен отдельный курс. Поэтому выделим лишь наиболее интересные, на наш взгляд, направления и полученные результаты. Более подробно с современным состоянием исследований в области баз данных и систем управления базами данных можно познакомиться в [10], [13], [20-21], [37], [40].

Системы управления данными обычно хранят громадные объемы данных, представляющих исторические записи организации. Размеры этих баз данных бурно растут. Важно то, что старые данные и приложения продолжают работать при добавлении новых данных и приложений. Системы постоянно изменяются. Действительно, большая часть крупных систем баз данных была разработана несколько десятков лет тому назад и развивалась вместе с развитием технологии. Взгляд в историю помогает понять текущие системы.

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

^ 19.1 История развития систем управления данными
Нулевое поколение: менеджеры записей (4000 г.г. до н. э. – 1900 г.г.). В первых известных письменных свидетельствах описывается учет царской казны и налогов в Шумере. Поддержка записей имеет долгую историю. В следующие шесть тысяч лет наблюдается эволюция от глиняных таблиц к папирусу, затем к пергаменту и, наконец, к бумаге. Имелось много новшеств в представлении данных: фонетические алфавиты, сочинения, книги, библиотеки, бумажные и печатные издания. Это были большие достижения, но обработка информации в эту эпоху производилась вручную.

^ Первое поколение: менеджеры записей (1900 – 1955 г.г.). Впервые автоматизированная обработка информации появилась приблизительно в 1800 году, когда Джеквард Лум начал производить раскрой ткани по образцам, представленным перфокартами. Позже аналогичная технология использовалась в механических пианино. В 1890 г. Холлерит использовал технологию перфокарт для выполнения переписи населения Соединенных Штатов. Его система содержала запись для каждой семьи. Каждая запись данных представлялась в виде двоичных структур на перфокарте. Машины сводили подсчеты в таблицы по жилым кварталам, территориальным и административным округам и штатам. Холлерит основал компанию для производства оборудования, для записи данных на карты, сортировки и составления таблиц. Бизнес Холлерита в конце концов привел к возникновению International Business Machines. Эта небольшая компания IBM процветала в период от 1915 до 1960 года как поставщик оборудования регистрации данных для бизнеса и правительственных организаций.

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

^ Второе поколение: программируемое оборудование обработки записей (1955 – 1970 г.г.). Электронные компьютеры с хранимыми программами были разработаны в 1940-х и начале 1950-х годов для выполнения научных и численных вычислений. Примерно в то же время компания Univac разработала аппаратуру магнитных лент, каждая из которых могла хранить столько информации, сколько десять тысяч перфокарт. Поставка в 1951 году UNIVAC1 в Бюро переписей отразилась на разработке устройств с перфокартами. Эти новые компьютеры могли обрабатывать сотни записей в секунду, и их можно было разместить на гораздо меньшей площади, чем предыдущее оборудование.

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

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

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

Системы пакетной обработки транзакций сохраняли транзакции на картах или лентах и собирали их в пакеты для последующей обработки. Раз в день эти пакеты транзакций сортировались. Отсортированные транзакции сливались с хранимой на ленте намного большей по размерам базой данных (основным файлом) для производства нового основного файла. На основе этого основного файла также производился отчет, который использовался как гроссбух на следующий бизнес-день. Пакетная обработка позволяла очень эффективно использовать компьютеры, но обладала двумя серьезными ограничениями. Если в транзакции имелась ошибка, она не распознавалась до вечерней обработки основного файла, и могло потребоваться несколько дней для исправления транзакции. Более важным является то, что бизнес не знал текущего состояния базы данных – поскольку транзакции реально не обрабатывались до следующего утра. Для решения этих двух проблем требовался следующий шаг эволюции – оперативные системы. Этот шаг также существенно облегчил написание приложений.

^ Третье поколение: оперативные сетевые базы данных (1965-1980 г.г.). Для таких приложений, как ведение операций на фондовой бирже или резервирование билетов, требуется знание текущей информации. Эти приложения не могут использовать вчерашнюю информацию, обеспечиваемую системами пакетной обработки транзакций, – им нужен немедленный доступ к текущим данным. С конца 1950-х лидирующие компании из нескольких областей индустрии начали вводить в использование системы баз данных с оперативными транзакциями; транзакции над оперативными базами данных обрабатывались в интерактивном режиме. Оперативный доступ к данным обеспечивался несколькими ключевыми технологиями. Аппаратура для подключения к компьютеру интерактивных компьютерных терминалов прошла путь развития от телетайпов к простым алфавитно-цифровым дисплеям и, наконец, к сегодняшним интеллектуальным терминалам, основанным на технологии персональных компьютеров. Мониторы телеобработки представляли собой специализированное программное обеспечение для мультиплексирования тысяч терминалов со скромными серверными компьютерами того времени. Эти мониторы собирали сообщения-запросы, поступающие с терминалов, быстро назначали программы сервера для обработки каждого сообщения и затем направляли ответ на соответствующий терминал. Оперативная обработка транзакций дополняла возможности пакетной обработки транзакций, за которой оставались задачи фонового формирования отчетов.

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

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


Рисунок 19.1 – Эволюция моделей данных:

(a) Чистая иерархическая модель с записями, сгруппированными под другими записями.

(b) По мере развития приложения разным пользователям желательно иметь разные представления данных, выражаемые в виде разных иерархий.

(c) Диаграмма Бахмана, показывающая типы записей и связи между типами записей.

(d) Та же информация, представленная в реляционной модели, где все данные и все связи явно представляются как записи.
Каждому городу соответствует набор отбывающих рейсов. Каждому заказчику соответствует набор путешествий, а каждое путешествие состоит из набора рейсов. Кроме того, каждому рейсу соответствует набор пассажиров. Как показано на рисунке 19.1.b, эта информация может быть представлена в виде трех иерархий наборов. Каждая из трех иерархий отвечает на отдельный вопрос. Первый – это планирование рейсов в городе. Вторая иерархия дает представление о рейсах заказчика. Третья иерархия говорит, к какому рейсу относится каждый заказчик. Приложение резервирования билетов нуждается во всех трех этих представлениях данных.

Иерархическое представление на рисунке 19.b обладает существенным недостатком. Избыточное хранение данных не только дорого стоит, но также и порождает проблемы обновлений: при создании рейса или изменении его информации необходимо обновить данные во всех трех местах (всех трех иерархиях). Для решения этих проблем информацию можно представлять в сетевой модели данных, что показано на рисунке 19.1.c. На рисунке 19.1.c изображена одна база данных, в которой каждая запись хранится в одном экземпляре и связывается с набором других записей посредством связи. Например, все рейсы, используемые в путешествии конкретного заказчика, связываются с этим путешествием. Программа может попросить систему баз данных перебрать эти рейсы. При потребности между записями могут создаваться новые связи. Рисунок 19.1.c изображает диаграмму Бахмана или диаграмму «сущность-связь». На рисунке 19.1.d представлена реляционная модель.

Управление ассоциативным доступом и обработкой, ориентированной на наборы, было настолько распространено, что в сообществе COBOL выделилась группа Data Base Task Group (DBTG) для определения стандартного способа спецификации таких данных и доступа к ним. Чарльз Бахман (Charles Bachman) в GE (General Electric) построил прототип системы навигации по данным. За руководство работы DBTG, разработавшей стандартный язык определения данных и манипулирования данными, Бахман получил Тьюринговскую премию. В своей Тьюринговской лекции он описал эволюцию моделей плоских файлов к новому миру, где программы могут осуществлять навигацию между записями, следуя связям между записями. Модель Бахмана напоминает систему Memex Ванневара Буша или навигационную модель страниц и ссылок сегодняшнего Internet.

В сообществе баз данных COBOL кристаллизовалась концепция схем и независимости данных. Они поняли потребность в сокрытии физических деталей расположения записей [27]. Программы должны были видеть только логическую организацию записей и связей, так что программы продолжали работать при изменении и развитии способов хранения данных. Записи, поля и связи, не используемые программой, следовало сокрыть – как по соображениям безопасности, так и для того, чтобы изолировать программу от неизбежных изменений схемы базы данных. В этих ранних базах данных поддерживались три вида схем данных:

1) логическая схема, которая определяет глобальный логический проект записей базы данных и связей между записями;

2) физическая схема, описывающая физическое размещение записей базы данных на устройствах памяти и в файлах, а также индексы, нужные для поддержки логических связей;

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

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

Эти оперативные системы должны были решить проблему одновременного выполнения многих транзакций над базой данных, совместно используемой многими терминальными пользователями. До этого подход, основанный на однопрограммном режиме и периодическом изменении основного файла, устранял проблемы параллельного доступа и восстановления. Ранние оперативные системы проложили путь понятию транзакций, блокировавших только те записи, к которым производился доступ. Блокировки позволяют конкурирующим транзакциям получать доступ к разным записям. Системы также поддерживали журнал записей, изменявшихся каждой транзакцией. При сбое транзакции журнал использовался для устранения в базе данных воздействий этой транзакции. Журнал транзакций использовался также для восстановления базы данных в случае аварии носителя. При крахе системы для воссоздания текущего состояния базы данных журнал применялся к ее архивной копии.

К 1980 году сетевые (и иерархические) модели данных, ориентированные на наборы записей, стали очень популярны. Основанная Бахманом компания Cullinet была крупнейшей и наиболее быстро растущей софтверной компанией в мире.

^ Четвертое поколение: реляционные базы данных и архитектура клиент-сервер (1980 – 1995 г.г.). Несмотря на успех сетевой модели данных, многие разработчики программного обеспечения чувствовали, что навигационный программный интерфейс был интерфейсом слишком низкого уровня. Было трудно проектировать и программировать эти базы данных. В статье Э.Ф. Кодда 1970 года была обрисована реляционная модель [50], которая казалась альтернативой низкоуровневому навигационному интерфейсу. Идея реляционной модели состоит в том, чтобы единообразно представлять и сущности, и связи. Реляционная модель данных обладает унифицированным языком для определения данных, навигации по данным и манипулирования данными, а не отдельными языками для каждой из этих задач. Еще более важно то, что реляционная алгебра имеет дело со множествами записей (отношениями) как единым целым, применяя операции к множествам записей целиком и производя множества записей в результате. Реляционные модель данных и операции дают возможность получения более коротких и более простых программ для решения задач управления записями. В качестве конкретного примера на рисунке 19.1.d показана база данных авиалиний из предыдущего раздела, представленная в виде пяти таблиц. Вместо неявного хранения связи между рейсами и путешествиями в реляционной системе явно хранится каждая пара рейс-путешествие как запись базы данных. Это таблица Segment на рисунке 19.1.d.

Чтобы найти все сегменты, зарезервированные для заказчика Джонса, направляющегося в Сан-Франциско, можно написать, например, следующий запрос на языке SQL:

Select Flight#

From City, Flight, Segment, Trip, Customer

Where Flight.to = «SF» AND

Flight.flight# = Segment.flight# AND

Segment.trip# = trip.trip# AND

trip.customer# = customer.customer# AND

customer.name = «Jones»

Эквивалентом этого SQL-запроса на естественном языке является «Найти номера рейсов до Сан-Франциско, которые являются сегментами путешествия любого заказчика с именем Джонс. Для поиска этих рейсов использовать таблицы City, Flight, Segment, Trip и Customer». Эта программа может показаться сложной, но она значительно проще соответствующей навигационной программы.

Получая такой непроцедурный запрос, реляционная система баз данных автоматически находит лучший способ подбора записей в таблицах City, Flight, Segment, Trip и Customer. Запрос не зависит от того, какие определены связи. Он будет продолжать работать даже после логической реорганизации базы данных. Следовательно, запрос обладает гораздо лучшей независимостью от данных, чем навигационный запрос, основанный на сетевой модели данных. Вдобавок к улучшенной независимости данных реляционные программы часто в пять – десять раз проще соответствующих навигационных программ.

Вдохновляемые идеями Кодда в течение 1970-х исследователи из академии и индустрии экспериментировали с этим новым подходом к структуризации баз данных и обеспечения доступа к ним, обещавшим более простое моделирование данных и прикладное программирование. Многие реляционные прототипы, разработанные в течение этого периода, сошлись на общей модели и языке. Исследования в IBM Research, возглавлявшиеся Тедом Коддом, Реймондом Бойсом (Raymond Boyce) и Доном Чемберлином (Don Chamberlin), и работа в Калифорнийском университете г. Беркли, которой руководил Майкл Стоунбрейкер (Michael Stonebraker), породили язык, названный SQL. Этот язык был впервые стандартизован в 1985 году. Впоследствии были произведены два основных расширения стандарта [9]. Сегодня почти все системы баз данных обеспечивают интерфейс SQL. Кроме того, во всех системах поддерживаются собственные расширения, выходящие за рамки этого стандарта.

Реляционная модель обладает некоторыми неожиданными преимуществами, кроме повышения продуктивности программистов и простоты использования. Реляционная модель оказалась хорошо пригодной к использованию в архитектуре клиент-сервер, к параллельной обработке и графическим пользовательским интерфейсам. Приложение клиент-сервер разбивается на две части. Клиентская часть отвечает за поддержку ввода и представление выводных данных для пользователя или клиентского устройства. Сервер отвечает за хранение базы данных, обработку клиентских запросов к базе данных, возврат клиенту общего ответа. Реляционный интерфейс особенно удобен для использования в архитектуре клиент-сервер, поскольку приводит к обмену высокоуровневыми запросами и ответами. Высокоуровневый интерфейс SQL минимизирует коммуникации между клиентом и сервером. Сегодня многие клиент-серверные средства строятся на основе протокола Open Database Connectivity (ODBC), который обеспечивает для клиента стандартный механизм запросов высокого уровня к серверу. Парадигма клиент-сервер продолжает развиваться. Как разъясняется в следующем разделе, имеется возрастающая тенденция интеграции процедур в серверах баз данных. В частности, такие процедурные языки, как BASIC и Java, были добавлены к серверам, чтобы клиенты могли вызывать прикладные процедуры, выполняемые на сервере.
  1   2   3

Добавить документ в свой блог или на сайт

Похожие:

Лекция 19. Основные направления развития технологий баз данных iconЛекция Введение в теорию баз данных Лекция посвящена рассмотрению...
Цель: выявить основные структурные элементы баз данных и основные принципы, используемые при их разработке

Лекция 19. Основные направления развития технологий баз данных iconЛекция Введение в базы данных
Обсуждается состав пользователей и распределение обязанностей в информационных системах с базами данных. Дается обзор моделей баз...

Лекция 19. Основные направления развития технологий баз данных iconЛекция 1 (2 часа)
Базы данных являются одной из основных составляющих информационных технологий предприятий. В настоящее время без применения баз данных...

Лекция 19. Основные направления развития технологий баз данных icon3. Лекция: Введение в реляционную модель данных Вопросы: Основные понятия реляционных баз данных
Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными...

Лекция 19. Основные направления развития технологий баз данных iconКурс лекций по дисциплине "Организация баз данных"
В настоящем курсе рассматриваются вопросы организации баз данных (БД). Это важная тема, без основательного знакомства с которой,...

Лекция 19. Основные направления развития технологий баз данных iconКурс лекций по дисциплине "Организация баз данных"
В настоящем курсе рассматриваются вопросы организации баз данных (БД). Это важная тема, без основательного знакомства с которой,...

Лекция 19. Основные направления развития технологий баз данных iconЛекция 14 Транзакции и восстановление баз данных
Одним из основных средств восстановления базы данных после сбоев является журнал транзакций. Для восстановления данных с помощью...

Лекция 19. Основные направления развития технологий баз данных icon1. Архитектура баз данных
Архитектура баз данных субд, которые поддерживают реляционную модель данных. Средства субд для создания базы данных и работы с ее...

Лекция 19. Основные направления развития технологий баз данных iconПримерная должностная инструкция главного специалиста администратора...
Администратор баз данных в соответствии с возложенной на него задачей выполняет следующие функции

Лекция 19. Основные направления развития технологий баз данных iconЛекция по основам торговой деятельности Лекция №1 Введение Основные...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
uchebilka.ru
Главная страница


<