Название: Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Токмаков Г. П.)

Жанр: Информационные системы и технологии

Просмотров: 1431

1.1.1.  и стория  систе м  управления  д анными

Исторически базы данных развивались как способ интеграции систем хра- нения данных. С развитием компьютерных технологий для них находилось все больше применений в управлении информацией и начали создаваться инфор- мационные системы для автоматизации деятельности бухгалтерий, отделов кадров, отделов закупок и т. д. Каждая такая информационная система инфор- мационная систем имела свой собственный набор данных (см. Рис. 1.1. ). Сна- чала эти данные хранились в последовательных файлах, затем появились фай- лы, основанные на индексировании.

Рис. 1.1.          Файловая информационная система

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

Для решения этой проблемы на первых этапах развития технологии ин- формационных систем для хранения данных создавались файлы коллективного доступа, разрабатываемые в едином центре. Но у файлов коллективного досту- па имелись серьезные недостатки. Структура записей в файлах и наборы отно- шений, реализуемые в прикладных программах, были «жесткими», и их изме- нение означало перестройку отношений в прикладных программах.

Сложные  структуры  данных,  используемые  при  решении  задачи  комп-

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

Стремление выделить и обобщить повторяющиеся фрагменты прикладных программ, ответственные за управление сложно структурированными данными коллективного доступа, явилось первой побудительной причиной создания сис- тем управления базами данных (СУБД). В результате СУБД стали мощным средством интеграции данных, хранимых и обрабатываемых внутри опреде- ленной организации. С их помощью можно было работать внутри одной интег- рированной системы с платежными ведомостями бухгалтерии, записями со- трудников отдела кадров, инвентарными записями отдела закупок и т. д. (см. рРис. 1.2. ).

История систем управления данными во внешней памяти началась с появ-

лением магнитных дисков. Первым попытку расширить возможности работы с дисками путем создания СУБД предпринял еще в 1961 г. Чарльз Бахман. Тогда

он работал в фирме General Electric, а потому разработка велась на машине этой компа- нии, а созданная им «интегри- рованная система хранения» могла работать только на этой машине.

Дальнейшее  развитие  этой идеи предпринял Джон Кулли-

ан. Он был предпринимателем и ему первому пришла в голову оригинальная для того времени

идея: продавать ПО для ком- пьютеров. Он не стремился раз- рабатывать свои программы «с

нуля»; наряду с собственными разработками  он   покупал  от-

Рис. 1.2.          Информационная система с базой данных

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

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

На этом поприще он оказался чрезвычайно успешным, но вскоре столкнул-

ся с тем, что для интеграции приобретенных и разрабатываемых продуктов нужна единая система управления данными. На основании анализа альтерна- тивных решений выбор пал на «интегрированную систему хранения» Бахмана, и это было исключительно верным решением. Система Бахмана, названная Куллианом СУБД, отлично работала на мейнфреймах IBM и совместимых с ними машинах.

Система, созданная на основе «интегрированной системы хранения» Бах-

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

Описание данных Бахмана было представлено в виде иерархической сис-

темы «указателей», помогающих осуществить доступ к конкретной ячейке па-

мяти. Эта незамысловатая работа оказала колоссальное влияние на развитие ПО, за что Бахман получил Тьюринговскую премию, а это аналог Нобелевской в области ВТ.

СУБД Бахмана строились с использованием иерархических и сетевых мо- делей и были названы им навигационными, поскольку для перемещения по за- писям использовались «указатели» или «пути», что отличает их от реляцион-

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

К появлению современных реляционных СУБД привела другая революци- онная идея, предложенная Коддом. Он в 1970 г. опубликовал статью, содержа- щую описание простой модели данных, согласно которой база данных состав- ляется из таблиц. Таблицы эти особенные, и их особенность заключается в том, что в них не должно быть одинаковых строк. Поэтому эти таблицы были назва- ны реляциями, а сама модель  реляционной.

Но основное достоинство реляционных моделей данных заключалось не в их простоте, хотя и это имело большое значение, а в том, что в них были при-

менены принципы нечисловой или ассоциативной обработки данных. В соот-

ветствии с этими принципами данные связываются в соответствии с их внут-

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

При числовой обработке данных содержание данных практически не ис-

пользуется. Допустим, что мы хотим вычислить сумму элементов массива. При этом достаточно указать адрес начального элемента массива, а затем накапли- вать сумму элементов в некотором регистре, индексируя соответствующим об- разом адреса. В ходе этого вычисления нас не интересуют текущие значения суммируемых переменных, мы просто должны проверять некоторые перемен- ные, влияющие на ход выполнения программы (например, достигнут или нет конец массива).

При ассоциативной обработке нас в первую очередь интересуют сведения об объектах и их свойствах. При этом мы можем запросить сведения о студен- те, указав его фамилию, имя или номер зачетной книжки, или узнать имена всех преподавателей моложе 40 лет, чей оклад выше 300 000 руб.

Для пояснения принципов ассоциативной обработки данных приведем сле-

дующий простой пример. Допустим, у нас имеются сведения о студентах и группах, в которых они обучаются, представленные в таблице ГРУППЫ с полями

Код, Наименование, и в таблице СТУДЕНТЫ с полями Номер зачетной книжки, Фами‐ лия, Имя, Отчество, Код_группы. По этим данным, используя принципы ассоциа- тивной обработки, а именно сравнивая значения полей Код таблицы ГРУППЫ и

Код_группы таблицы СТУДЕНТЫ, мы можем определить в какой группе учится ка- ждый студент, сколько студентов учится в каждой группе, вывести список сту- дентов каждой группы и т. д. Как видно из приведенного примера, при ассоциа-

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

Таким образом, пользователи смогут комбинировать данные из разных ис- точников, если логическая информация, необходимая для такого комбинирова- ния, присутствует в исходных данных. Это открыло новые возможности для

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

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

Для сравнения навигационного и реляционного (ассоциативного) подходов реализации СУБД можно использовать классический пример, в котором для

описания пункта назначения применяются различные способы.

– При использовании навигационного подхода путь до объекта можно ука-

зать так: «Едете по шоссе 25 км, поворачиваете направо и продолжаете движение до третьего населенного пункта. Нам нужен 3‐й дом с левой стороны».

– Ассоциативный подход, используемый в рамках реляционной СУБД, по-

зволяет просто указать: «Желтый дом в населенном пункте N».

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

ему нужно подробно описать, как доехать до места назначения.

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

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

данных и может сама отыскать требуемую информацию без приведения под-

робной информации относительно пути доступа.

Хотя реляционная модель одержала решительную победу над навигацион-

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