Модели данных:от систем управления файлами до обьективно-реляционных БД.

Системы управления файлами

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

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

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

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

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

Иерархические базы данных

Иерархическая модель данных является наиболее простой среди всех теоретико-графовых моделей. (Теоретико-графовые модели – это модели, которые отражают совокупность объектов реального мира в виде графа взаимосвязанных информационных объектов). Появление этой модели связано с тем, что в реальном мире очень многие связи соответствуют такому порядку, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов.

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

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

Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповое отношение, база данных.

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

Запись (иногда используется имя сегмент) - именованная совокупность полей. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее элементов. Экземпляр записи - конкретная запись с конкретным набором значений элементов. Разница между типом записи и экземпляром записи такая же, как между типом переменной и самой переменной. Набор элементов данных, однозначно определяющих экземпляр записи, называется ключом.

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

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

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

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

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

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

Операции над данными, определенные в иерархической модели:

· ДОБАВИТЬ в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.

· ИЗМЕНИТЬ значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

· УДАЛИТЬ некоторую запись и все подчиненные ей записи.

· ИЗВЛЕЧЬ:

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

§ извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева).

В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 1000 руб.).

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

Поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка).

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

Преимущества иерархической модели:

- простота идеи. Структура интуитивно понятна. Поэтому достаточно легко можно себе представить всю БД;

- безопасность. Обеспечивается СУБД;

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

- целостность данных. Взаимоотношение предок-потомок всегда предполагает наличие связи между сегментом-предком и его потомками;

- эффективность. Эта модель эффективна, когда в БД содержится большой объем данных со связью 1:М и выполняется большое количество транзакций.

Из-за явного превосходства над системой файлов иерархические БД быстро стали доминировать на рынке 70-х годов. Это стало предпосылкой создания больших БД.

Однако, иерархическая модель имеет свои недостатки:

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

- сложность управления. Любые изменения в структуре БД, например, перемещение сегментов, вызовут необходимость изменений во всех прикладных программах. Хотя иерархическая БД обеспечивает целостность БД, в то же время она дает возможность удалить один сегмент, что приведет к автоматическому удалению всех сегментов-потомков;

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

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

Сетевые базы данных

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

Во многих отношениях сетевая модель схожа с иерархической. БД воспринимается как совокупность записей, между которыми существует связь 1:М. Но в отличие от иерархической модели в сетевой модели записи могут иметь более, чем одного предка.

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

Базовыми объектами модели являются элемент данных, агрегат данных, запись и набор данных.

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

Агрегат данных – это либо линейный набор элементов данных (агрегат типа вектор), либо совокупность таких векторов (агрегат типа повторяющаяся группа).

Запись – совокупность агрегатов или элементов данных, моделирующая некоторый класс объектов реального мира. Понятие записи соответствует понятию сегмент (запись) в иерархической модели. Точно так же, как для записи в иерархической модели, вводятся понятия типа записи и экземпляра записи.

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

Следуя спецификации CODASYL (Conference on Data Systems Languages – конференции по языкам обработки данных) сетевая модель поддерживает DDL (Data Definition Language‑ язык определения данных) и DML (Data Manipulation Language – язык обработки данных).

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

Каждая запись в сетевой модели имеет служебные поля: владелец (master, owner), которая в иерархической модели соответствует предку, следующий (next), которая соответствует потомку в иерархической модели. Запись (member) в сетевой модели может при некоторых условиях появляться более чем в одном наборе, т.е. запись-член может иметь несколько записей-владельцев.

Как и в иерархической модели, в сетевой обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Операции над данными в сетевой модели:

· ДОБАВИТЬ - внести запись в БД и, в зависимости от режима включения, либо включить ее в групповое отношение, где она объявлена подчиненной, либо не включать ни в какое групповое отношение.

· ВКЛЮЧИТЬ В ГРУППОВОЕ ОТНОШЕНИЕ - связать существующую подчиненную запись с записью-владельцем.

· ПЕРЕКЛЮЧИТЬ - связать существующую подчиненную запись с другой записью-владельцем в том же групповом отношении.

· ОБНОВИТЬ - изменить значение элементов предварительно извлеченной записи.

· ИЗВЛЕЧЬ - извлечь записи последовательно по значению ключа, а также используя групповые отношения - от владельца можно перейти к записям - членам, а от подчиненной записи к владельцу набора.

· УДАЛИТЬ - убрать из БД запись. Если эта запись является владельцем группового отношения, то анализируется класс членства подчиненных записей. Обязательные члены должны быть предварительно исключены из группового отношения, фиксированные ‑ удалены вместе с владельцем, необязательные ‑ останутся в БД.

· ИСКЛЮЧИТЬ ИЗ ГРУППОВОГО ОТНОШЕНИЯ - разорвать связь между записью-владельцем и записью-членом.

Преимущества сетевой модели.

В сетевой модели сохранились преимущества иерархической модели данных, но были исправлены многие недостатки:

- концептуальная простота. Абстрактное представление БД достаточно простое;

- поддержка других типов связей. Связь типа m:n в сетевой модели реализуется проще, чем в иерархической за счет того, что в ней допускается наличие нескольких владельцев записи;

- гибкость доступа к данным значительно выше, чем в иерархической и в системах файлов;

- любое приложение может получить доступ к записи-владельцу и всем записям-членам набора без долгого прямого обхода;

- обеспечение целостности данных за счет того, что пользователь должен сначала определить запись-владелец, а потом уже записи-члены (запись-член не может существовать без записи-владельца);

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

- соответствие стандартам. Стандарты DDL и DML значительно улучшили возможности администрирования БД.

Недостатки сетевой модели:

- сложность системы в целом. Так же, как и иерархическая, предоставляет навигационные средства доступа к данным, поэтому администраторы, программисты для получения доступа должны хорошо знать внутреннюю структуру БД. Сетевую модель, как и иерархическую, нельзя считать дружественной системой;

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

Реляционные базы данных

О мере роста объема обрабатываемой информации и повышения требований к БД и приложениям, процессы проектирования, управления и использования БД становились более трудоемкими. Отсутствовала возможность написания нерегламентированных запросов.

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

Реляционная модель была предложена Э.Коддом в 1970 году. Она требует от СУБД гораздо более высокого уровня сложности. В ней делается попытка избавить программиста от выполнения рутинных операций по управлению данными, характерных для иерархической и сетевой моделей. Внешняя концептуальная простота достигается за счет ресурсов компьютера.

Реляционная модель БД реализуется с помощью сложнейшей системы управления реляционной базой данных (РСУБД, RDBMS – Relational Database Management System). РСУБД выполняют те же функции, что и иерархические и сетевые СУБД, но в ее состав входят и дополнительные функции, делающие ее модель простой для понимания и внедрения. РСУБД предоставляет возможность оперировать обычными понятиями человеческой логики. Она берет на себя управление всеми сложными деталями физической реализации БД.