История развития баз данных появление субд история. История развития программных средств разработки баз данных История развития бд
Базы данных лежат в основе практически всех современных информационных и информационно- телекоммуникационных систем, и это коренным образом изменило характер работы многих организаций. Развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну
В середине 60-х годов корпорация IBM совместно с фирмой NAA (North American Aviation, в настоящее время - Rockwell International) разработали первую СУБД - иерархическую систему IMS (Information Management System). Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов.
Другим заметным достижением середины 60-х годов было появление системы IDS (Integrated Data Store) фирмы General Electric. Развитие этой системы привело к созданию нового типа систем управления базами данных - сетевых СУБД, что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, и послужили основой для разработки первых стандартов БД.
Для создания стандартов структур хранения данных в 1965 году на конференции CODASYL (Conference on Data Systems Languages) была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций среды, которая допускала бы разработку баз данных и управление данными.
Полный вариант отчета этой группы был опубликован в 1971 году и содержал следующие утверждения: cетевая схема - это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа подсхема - это часть базы данных, видимая конкретными пользователями или прикладными программами язык управления данными - инструмент для определения характеристик и структуры данных, а также для управления ими
Группа DBTG также предложила стандартизировать три различных языка: o язык определения данных DDL для схемы, который позволит администратору базы данных (АБД) описать ее o язык определения данных (также DDL) для подсхемы, который позволит определять в прикладных программах те части базы данных, доступ к которым будет необходим o язык манипулирования данными DML, предназначенный для управления данными
Несмотря на то, что отчет CODASYL официально не был одобрен Национальным Институтом Стандартизации США (ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения.
Однако как сетевым, так и иерархическим моделям баз данных присущи приведенные ниже недостатки: o даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные программы o независимость от данных существует лишь в минимальной степени o отсутствуют теоретические основы
В 1970 году Э. Ф. Кодд, работавший в корпорации IBM, опубликовал статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. Известен проект System R, разработанный в корпорации IBM в конце 70-х годов (Astrahan et al., 1976), задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей.
На основе этого проекта были получены важнейшие результаты: o был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД o в 80-х годах были созданы различные коммерческие реляционные СУБД - например, DB2 или SQL/DS корпорации IBM, Oracle корпорации Oracle, др.
Реляционные СУБД относятся к СУБД второго поколения, существует несколько сотен различных реляционных СУБД для мейнфреймов и персональных ЭВМ. Примеры многопользовательских реляционных СУБД: CA-OpenIngres фирмы Computer Associates, Informix фирмы Informix Software, Inc. Примеры реляционных СУБД для персональных компьютеров: Access фирмы Microsoft, FoxPro, R-Base фирмы Microrim и т.д. Реляционная модель обладает некоторыми недостатками: ограниченными возможностями моделирования. Для решения этой проблемы в 1976 году Чен предложил модель "сущность-связь" (Entity-relationship model - ER-модель), которая в настоящее время стала самой распространенной технологией и основой методологии проектирования баз данных.
В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели - RM/T (1979), затем еще одну версию - RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).
В ответ на все возрастающую сложность прикладных программ, работающих с базами данных появились два новых типа систем: объектно-ориентированные СУБД, или ОО СУБД, объектно-реляционные СУБД, или ОР СУБД. Попытки реализации подобных моделей представляют собой СУБД третьего поколения. В СССР в середине 70-х годов была разработана информационно-поисковая система, основу которой составляла универсальная объектно-ориентированная иерархическая СУБД, нашедшая широкое применение при решении задач проектирования и управления и предвосхитившая многие более поздние разработки такого рода.
Предшественницами СУБД были файловые системы. Появление СУБД не привело к файловых систем полному исчезновению: для выполнения некоторых специализированных задач подобные файловые системы используются до сих пор. Кроме того, файловые системы могут использоваться также СУБД для решения задач хранения данных и доступа к ним.
Файловые системы - это набор программ, которые выполняют для пользователей некоторые операции (например, создание отчетов), причем каждая программа определяет свои собственные данные и управляет ими. Ограничения, присущие файловым системам: o разделение и изоляция данных. o дублирование данных. o зависимость от данных. o несовместимость форматов файлов. o фиксированные запросы (быстрое увеличение количества прикладных программ).
Система баз данных – это компьютеризированная система, основное назначение которой – хранить информацию, предоставляя пользователям возможность ее извлечения и модификации. База данных – структурированный организованный набор данных, описывающих характеристики каких-либо физических или виртуальных систем. (Поименованная совокупность структурированных данных предметной области).
База данных хранит не только рабочие данные, но и их описания. По этой причине базу данных еще называют набором интегрированных записей с самоописанием. В совокупности, описание данных называется системным каталогом (system catalog), или словарем данных (data dictionary), а сами элементы описания – метаданными (meta-data), т.е. данными о данных.
Преимущество подхода абстрагирования данных (data abstraction) - возможность изменить внутреннее определение объекта без каких-либо последствий для его пользователей, при условии, что внешнее определение объекта остается неизменным. В подходе с использованием баз данных, структура данных отделена от прикладных программ и хранится в базе данных.
В базах данных используется термин "логически связанные данные", когда при анализе информационных потребностей организации следует выделить: o сущность (entity)- отдельный тип объекта, который нужно представить в базе данных o атрибут (attribute)- свойство, которое описывает некоторую характеристику рассматриваемого объекта o связь (relationship) это то, что объединяет несколько сущностей
СУБД - это программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать базу данных, а также осуществлять к ней контролируемый доступ. Составляющие СУБД: o Подсистема средств проектирования. o Подсистема обработки. o Ядро СУБД
Возможности СУБД: o позволяет определять базу данных с помощью языка определения данных (DDL – Data Definition Language). o позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных с помощью языка управления данными (DML – Data Manipulation Language).
Возможности СУБД: o СУБД предоставляет контролируемый доступ к базе данных с помощью перечисленных ниже средств: - системы обеспечения безопасности - системы поддержки целостности данных - системы управления параллельной работой прикладных программ - системы восстановления - доступного пользователям каталога
Представление виртуальная (логическая) таблица, получающаяся как результат выполнения поименованного запроса. В отличие от обычных таблиц реляционной БД, представление не является самостоятельной частью набора данных, хранящегося в базе. Содержимое представления динамически вычисляется на основании данных, находящихся в реальных таблицах. Изменение данных в реальной таблице БД немедленно отражается в содержимом всех представлений, построенных на основании этой таблицы.
Достоинства представлений: o обеспечивают дополнительный уровень безопасности o предоставляют механизм настройки внешнего интерфейса базы данных. o позволяют сохранять внешний интерфейс базы данных непротиворечивым и неизменным даже при внесении изменений в ее структуру. o представление обеспечивает полную независимость программ от реальной структуры данных
Аппаратное обеспечение Тома вторичной (внешней) памяти (обычно это магнитные диски), используемые для хранения информации, а также соответствующие устройства ввода-вывода и т. д.; Аппаратный процессор (или процессоры) вместе с оперативной (первичной) памятью, предназначенные для поддержки работы программного обеспечения системы баз данных.
Данные База данных содержит: рабочие данные и метаданные. Интеграция данных - возможность представить базу данных как объединение нескольких отдельных файлов данных Разделяемость данных - возможность использования несколькими различными пользователями отдельных элементов, хранимых в базе данных.
Процедуры Процедуры - инструкции и правила, которые должны учитываться при проектировании и использовании базы данных. Пользователи Различают четыре группы: o администраторы данных и баз данных o разработчики баз данных o прикладные программисты o конечные пользователи.
Администратор базы данных (Database Administrator) отвечает за: o физическую реализацию базы данных, включая физическое o проектирование и воплощение проекта o обеспечение безопасности и целостности данных o сопровождение операционной системы o обеспечение максимальной производительности приложений пользователей
Разработчик логической базы данных Занимается идентификацией данных, связей между данными и устанавливает ограничения, накладываемые на хранимые данные. Должен быть всесторонним и в полном объеме понимать структуры данных организации и ее бизнес-правил. Работа разработчика делится на два этапа: o концептуальное проектирование базы данных o логическое проектирование базы данных
Разработчик физической базы данных. Занимается физической реализацией уже готовой логической модели данных, в том числе: o преобразованием логической модели данных в набор таблиц и ограничений целостности данных o выбором конкретных структур хранения и методов доступа к данным, обеспечивающих необходимый уровень производительности при работе с базой данных o проектированием любых требуемых мер защиты данных
Прикладные программисты Выполняют разработку приложений после создания базы данных, предоставляющую пользователям необходимые им функциональные возможности. Конечные пользователи Пользователи являются клиентами базы данных. Она проектируется, создается и поддерживается для того, чтобы обслуживать их информационные потребности.
Пользователь может получать доступ к базе данных, применяя одно из интерактивных прикладных программ или же интерфейс (встроенная прикладная программа). Некомандные интерфейсы основаны на меню и формах, облегчают работу с базами данных для тех, кто не имеет опыта работы с информационными технологиями. Командный интерфейс (язык запросов) требует некоторого профессионального опыта работы с информационными технологиями.
Преимущества: o контроль за избыточностью данных o непротиворечивость данных o больше полезной информации при том же объеме хранимых данных o совместное использование данных o поддержка целостности данных o повышенная безопасность o применение стандартов.
Преимущества: o повышение эффективности с ростом масштабов системы o возможность нахождения компромисса при противоречивых требованиях o повышение доступности данных и их готовности к работе o улучшение показателей производительности o упрощение сопровождения системы за счет независимости от данных o улучшенное управление параллельностью o развитые службы резервного копирования и восстановления.
История развития СУБД насчитывает > 30 лет. В 1968 году была введена в эксплуатацию первая промышленная СУБД – система IMS фирмы IBM.
1-й этап развития СУБД связан с организацией БД на больших машинах типа IBM360/370. БД хранились во внешней памяти центральной ЭВМ. Программы доступа к БД писались на различных языках. Интерактивный доступ обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами, и служили только устройствами ввода- вывода для центральной ЭВМ.
На втором этапе - с появлением ПК начали развиваться настольные СУБД с монопольным доступом. Большинство СУБД имели удобный пользовательский интерфейс. В них был предусмотрен интерактивный режим работы с БД, как для описания БД, так и для проектирования запросов. Многие СУБД имели развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс. Наличие монопольного режима работы, фактически, привело к вырождению функций администрирования БД, и в связи с этим в них отсутствовали инструментальные средства администрирования БД. Яркие представители этого семейства СУБД, – очень широко использовавшиеся до недавнего времени СУБД DBASE(III+,IV),FoxPro, Clipper, Paradox.
Третий этап развития СУБД связан с широким развитием локальных сетей. Работа на изолированном компьютере с небольшой БД в настоящее время становится нехарактерной для большинства приложений. Компьютеры объединяются в сети и необходимость распределения приложений, работающих с единой БД совершенно очевидна.
БД при этом становится доступна одновременно многим пользователям. Поэтому важной является проблема согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически друг с другом связанных. Возникают задачи, связанные с параллельной обработкой транзакций – последовательности операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Успешное решение этих задач приводит к появлению распределенных БД и баз данных с распределенной обработкой, позволяющих организовать параллельную обработку информации и поддержку целостности БД.
Параллельный доступ нескольких пользователей к одной БД, расположенной на одном компьютере, соответствует режиму распределенного доступа к централизованной БД. Такие системы называются системами распределенной обработки данных .
Если БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен параллельный доступ, то мы имеем дело с параллельным доступом к распределенной БД. Такие системы называют системами распределенных БД .
Большинство современных СУБД рассчитаны на многоплатформенную архитектуру. Они могут работать на компьютерах разной архитектуры и под разными ОС. При этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим. Необходимость поддержки многопользовательской работы с БД и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных.
Для того чтобы не потерять клиентов, которые ранее работали, с настольными СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, и средства экспорта данных из форматов настольных СУБД.
К этому же этапу относится разработка ряда стандартов языков описания и манипулирования данными, начиная с SQL 89, SQL92, SQL99 и технологий обмена данными между различными СУБД, к которым можно отнести протокол ODBC, предложенный фирмой Microsoft. В этот же период были начаты работы, связанные с концепцией объектно-ориентированных БД, к числу которых относятся MS Access и все современные серверы БД: Oracle 7.3, Oracle 8.4, MS SQL 7.0, SYSTEM10, SYSTEM11, SQL Base и др.
История развития баз данных уходит корнями в 1960-е годы. В те времена информация собиралась и хранилась в файлах.каждый файл содержал определенные сведения и для охвата всей предметной области требовалось несколько файлов. Например, сведения о товарах хранились в одном файле, а сведения о клиентах - в другом. Информация о приобретении определенных товаров определенными клиентами - в третьем. Такая организация данных вносила свои сложности:
· представление данных в каждом файле было различным;
· необходимо было согласовывать данные в разных файлах для обеспечения непротиворечивости информации;
· необходимо было выбрать какие данные и в каком виде будут фигурировать в таких файлах, как файл приобретений товаров в примере;
· сложность разработки приложений и их обновления при изменении данных.
Ситуация требовала улучшения и множество специалистов усердно работали над созданием чего-то более удобного в использовании. В начале 1970-х годов, спустя примерно 10 лет, ситуация начала улучшаться и появились первые базы данных.
В 1970 году Э. Ф. Кодд опубликовал статью, которая послужила основой для создания реляционной модели данных. Приемущество такой модели хранения данных заключается в минимальном дублировании данных и исключении некоторых типов ошибок, свойственных другим моделям. Согласно этой модели, данные хранятся в виде таблиц со столбцами и строками. Не все виды таблиц приемлемы для реляционной модели и нежелательные таблицы могут быть нормализованы для удовлетворения требованиям реляционной модели. В процессе нормализации таблица как-правило разбиваются на две или несколько более приемлемых таблиц.
В 1979 году небольшая компания Ashton-Tate выпустила продукт для микрокомпьютеров под названием dBase-II, назвав его реляционной СУБД. Благодаря успешной тактике, компании удалось распространить более 100 000 копий продукта среди пользователей компьютеров Osborne. Многие из пользователей компьютеров создавали программы для них и вскоре dBase стала очень популярной СУБД. В последствииAshton-Tate была приобретена фирмой Borland. На самом деле продукт dBase не являлся реляционной СУБД, а представлял из себя язык программирования с расширенными функциями для обработки файлов. Пока развивалась dBase, другие производители начали перенос на микрокомпьютеры своих коммерческих СУБД для больших ЭВМ. Примерами таких СУБД являются Oracle, Ingress и Focus. Перенос СУБД на микрокомпьютеры послужил причиной улучшения пользовательского интерфейса, что повлекло за собой увеличение числа микрокомпьютеров, работающих с базами данных.
В середине 1980-х годов пользователи начали объединять свои компьютеры в локальные сети, что привело к возникновению клиент-серверной модели, а так же модели с совместным использованием файлов. Сеть позволяла совместно использовать дорогие принтеры и дисковые накопители большой емкости. В перспективе же пользователи хотели совместного использования их баз данных, что стимулировало развитие многопользовательских приложений баз данных для локальных сетей. Поскольку многопользовательская обработка данных в локальной сети отличается от многопользовательской обработки данных на мейнфрейме наличием нескольких вычислителей, возникали дополнительные сложности по координации действий вычислителей. Так появилась клиент-серверная архитектура обработки данных. Существует и более простая, но менее надежная архитектура, снованная на совместном использовании файлов.
В наши дни активно развиваются web-приложения баз данных, а так же базы данных с использованием Internet-технологий. Web-приложения баз данных делают данные доступными черезобозреватель пользователя, в то время как базы данных с использованием Internet-технологий просто используют клиентские обозреватели и технологии типа XML и DHTML для работы с базой данных, не публикуя данные через Internet.
Существует еще две технологии баз данных, которые являются возможными, но пока не реализованы. Это объектно-ориентированные базы данных и распределенные базы данных. Распределенные базы данных представляют собой базу данных организации, распределенную по нескольким компьютерам локальной сети организации. Благодаря такой архитектуре возможно более гибкое разделение нагрузки по отделам предприятия, но реализация такой системой связана с радом проблем, некоторые из которых не решены до сих пор. Объектно-ориентированные базы данных позиционируются как средство для хранения структур данных, используемых в объектно-ориентированном программировании. Поскольку объекты на порядок сложнее структур, то и реализация баз данных будет довольно сложной. Плюс ко всему, развитие объектно-ориентированных баз данных сдерживается наличием огромного количества реляционных БД, в которых хранятся огромные массивы информации.
Рост производительности персональных вычислительных машин спровоцировал развитие СУБД, как отдельного класса. К середине 60-х годов прошлого века уже существовало большое количество коммерческих СУБД. Интерес к базам данных увеличивался все больше, так что данная сфера нуждалась в стандартизации. Автор комплексной базы данных Integrated Data Store Чарльз Бахман (Charles Bachman) организовал целевую группу DTG (Data Base Task Group) для утверждения особенностей и организации стандартов БД в рамках CODASYL - группы, которая отвечала за стандартизацию языка программирования COBOL. Уже в 1971 году был представлен свод утверждений и замечаний, который был назван Подход CODASYL, и спустя некоторое время появились первые успешные коммерческие продукты, изготовленные с учетом замечаний вышеупомянутой рабочей группы. В 1968 году отметилась и компания IBM, которая представила собственную СУБД под названием IMS. Фактически данный продукт представлял собой компиляцию утилит, которые использовались с системами System/360 на шаттлах Аполлон. Решение было разработано согласно коцпетам CODASYL, но при этом была применена строгая иерархия для структуризации данных. В свою очередь в варианте CODASYL за базис была взята сетевая СУБД. Оба варианта, меж тем, были приняты сообществом позднее как классические варианты организации работы СУБД, а сам Чарльз Бахман в 1973 году получил премию Тьюринга за работу Программист как навигатор. В 1970 году сотрудник компании IBM Эдгар Кодд, работавший в одном из отделений Сан Хосе (США), в котором занимались разработкой систем хранения, написал ряд статей, касающихся навигационных моделей СУБД. Заинтересовавшись вопросом он разработал и изложил несколько инновационных подходов касательно оптимальной организаци систем управления БД. Работа Кодда внесла значительный вклад в развитие СУБД и является действительным основоположником теории реляционных баз данных. Уже 1981 году Э.Ф.Кодд создал реляционную модель данных и применил к ней операции реляционной алгебры.
Обзор программных продуктов для разработки систем управления базами данных
Пятая нормальная форма
Четвертая нормальная форма
Нормальная форма Бойса – Кодда
Таблица находится в нормальной форме Бойса – Кодда только в том случае, если любая функциональная зависимость между ее полями сводится к полной функциональной зависимости от возможного ключа.
Согласно данному определению в структуре базы данных все таблицы соответствуют требованиям нормальной формы Бойса – Кодда.
Дальнейшая оптимизация таблиц баз данных должна сводиться к полной декомпозиции таблиц.
Полной декомпозицией таблицы называют такую совокупность произвольного числа ее проекций, соединение которых полностью совпадает с содержимым таблицы.
Четвертая нормальная форма является частным случаем пятой нормальной формы, когда полная декомпозиция должна быть соединением двух проекций. Очень трудно найти такую таблицу, чтобы она находилась в четвертой нормальной форме, но не удовлетворяла определению пятой нормальной формы.
Таблица находится в пятой нормальной форме тогда и только тогда, когда в каждой ее полной декомпозиции все проекции содержат возможный ключ. Таблица, не имеющая ни одной полной декомпозиции, также находится в пятой нормальной форме.
На практике оптимизация таблиц базы данных заканчивается третьей нормальной формой. Приведение таблиц к четвертой и пятой нормальным формам представляет чисто теоретический интерес. Практически эта проблема решается разработкой запросов на создание новой таблицы.
На ранних стадиях разработки информационно - поисковых систем разрабатывались специальные языки манипулирования данными (ЯМД) – языки запросов. Они были ориентированы на операции с данными, представленными в виде иерархически связанных файлов, и имели соответствующие алгоритмы поиска информации.
Появление реляционных баз данных создало предпосылки для других, более быстрых алгоритмов поиска информации.
Для обработки информации, структурированной в виде таблиц – двумерных массивов, в конце 70-х гг. ХХ в. фирмой IBM был разработан соответствующий язык, который в дальнейшем получил название Structured Query Language (SQL) – язык структурированных запросов. В настоящее время SQL является международным стандартом языка обработки данных в реляционных СУБД. Язык является ядром всех программных продуктов для разработки СУБД.
Наибольшее распространение среди пользователей и разработчиков СУБД получили следующие программные продукты:
Специальные языки программирования – Visual FoxPro, SQL, MS SQL-Server
Прикладные программные системы – Microsoft Access, Oracle и др.
Рассмотрим некоторые характеристики данных программных средств.
