СУБД.ppt

технологий. Сегодня они во многом ассоциируются с банковскими транзакциями, хотя

так было не всегда. История баз данных начинается с одного из самых значительных инженерных подвигов прошлого столетия: полета на Луну. Североамериканская компания Rockwell заключила контракт с правительством США на участие в проекте Apollo. Построение космического корабля включает в себя сборку нескольких миллионов деталей, поэтому была создана система управления файлами, отслеживавшая информацию о каждой детали. Однако в ходе последующей проверки обнаружилась огромная избыточность. Выяснилось, что почти все данные повторяются в двух и более файлах.

в сотрудничестве с IBM в 1968 г. разработала автоматизированную систему

заказов. Названная IMS (Information Management System — система управления информацией), она заложила основу концепции СУБД.
Ключевым новшеством IMS было разделение данных и функций деловой логики. Прикладные программисты получили возможность работать с информацией на логическом уровне, а база данных брала на себя задачу физического хранения.
Подобное разделение труда привело к резкому скачку производительности. Еще одним изобретением стал язык DL/I(Data Language I). Это был специализированный язык составления нерегламентированных запросов к базе данных. Его появление сделало ненужным дорогостоящее программирование на таких языках, как COBOL и FORTRAN, популярных в то время.

данных, в которой существует путь от корня иерархии к каждой

записи. Такая модель стала основой для систем управления данными, она же дала толчок к следующим изобретениям из-за своей ограниченности. Полная история IMS была опубликована в 1998 г. В 1971 г. состоялась конференция по языкам обработки данных (Conference on Data Systems Languages, CODASYL), в задачу которой входила разработка стандартов баз данных. Ранее эта конференция уже стандартизировала язык COBOL. Новый стандарт был расширен на иерархическую модель данных, применяемую в IMS. Результатом стало появление сетевой модели данных.
В сетевой модели любая запись может участвовать в нескольких отношениях предок/потомок. Это позволяло обходить целый ряд ограничений иерархической модели. Разработкой сетевой модели занимался Чарльз Бейчман, в то время руководитель проекта IDS (Integrated Data System — интегрированная система обработки данных) в компании General Electric. Он же изобрел «диаграммы Бейчмана», описывающие сетевые базы данных. За свой труд в 1973 г. Бейчман получил награду Тьюринга.

над эпохальным документом для Ассоциации производителей вычислительной техники (Association for

Computing Machinery, ACM). В июне 1970 г. этот документ был опубликован под названием "Реляционная модель для больших банков совместно используемых данных" ("A Relational Model of Data for Large Shared Data Banks"). Этот документ в корне изменил теорию баз данных.
Доктор Кодд придумал реляционную модель, в которой данные можно было свободно описывать в их естественном виде без каких либо ограничений, накладываемых средой физического хранения. Следовательно, это позволяло создать язык высокого уровня, способный работать с данными независимо от того, как они хранятся в компьютере.
В результате появились две СУБД: System R компании IBM и Ingres Калифорнийского университета в Беркли. В обеих был реализован реляционный модуль и язык запросов. Последний в СУБД System R первоначально назывался SEQUEL (Structured English Query структурированный английский язык запросов). Позднее появилось название SQL (Structured Query Language). Организация ANSI опубликовала официальный стандарт языка SQL.

собой совокупность информации, организованной в виде множеств. Каждое множество содержит

записи унифицированного вида. Сами записи состоят из полей. Обычно множества называют таблицами, а записи — строками таблиц. Такова логическая модель данных.
На жестком диске вся база данных может находиться в одном файле. В MySQL для каждой базы данных создается отдельный каталог, а каждой таблице соответствуют три файла. В других СУБД могут использоваться иные принципы физического хранения данных.

трех способов:

Простейшее отношение — "один к одному". В этом случае

строка первой таблицы соответствует одной единственной строке второй таблицы. На диаграммах такое отношение выражается записью 1:1.

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

Наконец, при отношении "многие ко многим" строки первой таблицы могут быть связаны с произвольным числом строк во второй таблице. Такое отношение записывается как N:M.

эти данные хранятся, и приложения, взаимодействующие с СУБД, не знают

о способе записи данных на диск.
"Снаружи" виден лишь логический образ данных, и это позволяет менять код СУБД, не затрагивая код самих приложений.

Подобная обработка данных осуществляется посредством языка четвертого поколения (4GL), который поддерживает запросы, записываемые и исполняемые немедленно. Данные быстро утрачивают свою актуальность, поэтому скорость доступа к ним важна. Кроме того, программист должен иметь возможность формулировать новые запросы. Они называются нерегламентированными (ad hoc), поскольку не хранятся в самой базе данных и служат узкоспециализированным целям.

отношений между ними. Схема хранится как часть базы Данных и

может быть изменена без ущерба для данных.
Схема предназначена для контроля целостности данных. Если, к примеру, объявлено, что поле содержит целочисленные значения, то СУБД откажется записывать в него числа с плавающей запятой или строки. Отношения между записями тоже четко контролируются, и несогласованные данные не допускаются. Операции можно группировать в транзакции, выполняемые по принципу "все или ничего".
СУБД обеспечивает безопасность данных. Пользователям предоставляются определенные права доступа к информации. Некоторым пользователям разрешено лишь просматривать данные, тогда как другие пользователи могут менять содержимое таблиц.
СУБД поддерживает параллельный доступ к базе данных. Приложения могут обращаться к базе данных одновременно, что повышает общую производительность системы. Кроме того, отдельные операции могут "распараллеливаться" для еще большего улучшения производительности.
Наконец, СУБД помогает восстанавливать информацию в случае непредвиденного сбоя, незаметно для пользователей создавая резервные копии данных. Все изменения, вносимые в базу данных, регистрируются, поэтому многие операции можно от менять и выполнять повторно.

между записями выражаются в виде отношений предок/потомок, а у каждой

записи есть ровно одна родительская запись. Это помогает поддерживать ссылочную целостность. Когда запись удаляется из дерева, все ее потомки также должны быть удалены.
На рисунке изображена простая иерархическая база данных, в которой фиксируется деятельность независимого подрядчика. Корень дерева представляет собой запись о клиенте. Ее потомками являются две записи о счет-фактурах и три записи об оплатах счетов. Структура счета номер 17 уточняется в трех дочерних записях, у счета номер 23 одна такая запись.

контролировать. К сожалению, определенные знания о физическом порядке хранения записей

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

между записями в множества. С логической точки зрения связь —

это не сама запись. Связи лишь выражают отношения между записями. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но на этот раз поддерживается множественное наследование.
Следуя спецификации CODASYL, сетевая модель поддерживает DDL (Data Defini tion Language— язык определения данных) и DML (Data Manipulation Language — язык обработки данных). Это специальные языки, предназначенные для определения структуры базы данных и составления запросов. Несмотря на их наличие программист по прежнему должен знать структуру базы данных.

требует от СУБД гораздо более высокого уровня сложности. В ней

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

обеспечивающее безопасный одновременный доступ к информации со стороны многих пользователей.

В строках таблиц часть полей содержит данные, относящиеся непосредственно к записи, а часть — ссылки на записи других таблиц. Таким образом, связи между записями являются неотъемлемым свойством реляционной модели. Каждая запись таблицы имеет одинаковую структуру. Например, в таблице, содержащей описания автомобилей, у всех записей будет один и тот же набор полей: производитель, модель, год выпуска, пробег и т.д. Такие таблицы легко изображать в графическом виде.
В реляционной модели достигается информационная и структурная независимость. Записи не связаны между собой настолько, чтобы изменение одной из них затронуло остальные, а изменение структуры базы данных не обязательно приводит к перекомпиляции работающих с ней приложений.

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

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

хотя это и не проблема реляционной модели. Каждая реляционная СУБД

реализует какое-то подмножество стандарта SQL плюс набор уникальных команд, что усложняет задачу программистам, пытающимся перейти от одной СУБД к другой. Приходится делать нелегкий выбор между максимальной переносимостью и максимальной производительностью. В первом случае нужно придерживаться минимального общего набора команд, поддерживаемых в каждой СУБД. Во втором случае программист просто сосредоточивается на работе в данной конкретной СУБД, используя преимущества ее уникальных команд и функций.
MySQL — это реляционная СУБД. Но теория баз данных не стоит на месте. Появляются новые технологии, которые расширяют реляционную модель.

с языками третьего поколения, интерпретировать все свои информационные сущности как

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

объектной моделей. Их возникновение объясняется тем, что реляционные базы данных

хорошо работают со встроенными типами данных и гораздо хуже — с пользовательскими, нестандартными. Когда появляется новый важный тип данных, приходится либо включать его поддержку в СУБД, либо заставлять программиста самостоятельно управлять данными в приложении.
Не всякую информацию имеет смысл интерпретировать в виде цепочек символов или цифр. Представим себе музыкальную базу данных. Песню, закодированную в виде аудиофайла, можно поместить в текстовое поле большого размера, но как в таком случае будет осуществляться текстовый поиск?
Перестройка СУБД с целью включения в нее поддержки нового типа данных — не лучший выход из положения. Вместо этого объектно-реляционная СУБД позволяет загружать код, предназначенный для обработки "нетипичных" данных. Таким образом, база данных сохраняет свою табличную структуру, но способ обработки некоторых полей таблиц определяется извне, т.е. программистом.