II этап. Ранние файловые системы
Характерные черты:
1. Файлы организованы простым последовательным способом.
2. Физическая структура данных такая же как и логическая структура файла.
3. Типовое ПО выполняет только операции ввода-вывода.
4. Полностью отсутствует независимость данных. Если менялась организация данных, требовалось модифицировать программу.
5. Высокая степень избыточности в файлах данных. Для того чтобы обновить файл, требовалось записать новый файл; при этом сохранялся старый файл и, возможно, более ранняя версия.
6. Для облегчения программирования (сортировка, анализ, обработка данных) используются первые специализированные языки: COBOL, RPG.
7. Одни и те же данные редко использовались для нескольких приложений.
Рисунок 4 – Файловая система с простым последовательным доступом
III этап. Развитые файловые системы
Характерные черты:
1. Физические данные представлены наборами данных (НД) с последовательной, индексно-последовательной и прямой организацией. В последовательном наборе данных все записи организованы строго последовательным способом; в наборе данных с прямой организацией возможен непосредственный доступ к любой записи по ее ключу; в индексно-последовательном наборе данных существует многоуровневая система индексов, позволяющая прямым образом определить дорожку диска, на которой расположена требуемая запись для ее последующего последовательного поиска.
|
|
|
2. Возможен как последовательный, так и произвольный доступ к записям (но не к полям записей).
3. Логическая и физическая структуры файлов различаются между собой, но связь между ними достаточно простая.
4. Остается значительная избыточность данных.
5. Сохраняется тенденция разрабатывать и оптимизировать данные в основном для одного приложения.
6. Типовым программным обеспечением (ПО) обработки данных являются методы доступа, а не методы управления данными. Операционные системы обеспечивали абстракцию файла для хранения этих записей, язык управления заданиями для выполнения заданий и планировщик заданий для управления потоком работ.
Рисунок 5 – Развитые файловые системы
Поскольку информационные системы требуют сложных структур данных, эти дополнительные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось первой побудительной причиной создания систем управления базами данных (СУБД).
СУБД – программный продукт, решающий задачи управления данными: сортировка, поиск, изменение, добавление, обработка, передача в другие приложения.
|
|
|
IV этап. Ранние СУБД (1965-1980 гг.)
Дальнейшее направление развития было следующим: простые индексно-последовательные организации записей быстро развились в более мощные модели записей, ориентированной на наборы - иерархические модели данных.
Приложениям часто требуется связать две или более записей. Пример некоторых типов записей простой системы резервирования авиационных билетов и их связи (три иерархии наборов) представлен на рис. 6.
Рисунок6 - Иерархическая модель (пример 1)
Каждый рейс связывает некоторые города. Каждому заказчику соответствует набор поездок, а каждая поездка состоит из набора задействованных рейсов (сегментов). Кроме того, каждому рейсу соответствует набор пассажиров. Каждая из трех иерархий отвечает на отдельный вопрос. Первая - это планирование рейсов между городами. Вторая иерархия дает представление о рейсах заказчика. Третья иерархия говорит, к какому рейсу относится каждый заказчик. Приложение резервирования билетов нуждается во всех трех этих представлениях данных.
Иерархическая модель обладает существенным недостатком. Избыточное хранение данных не только дорого стоит, но также и порождает проблемы обновлений: при создании рейса или изменении его информации необходимо обновить данные во всех трех местах (всех трех иерархиях).
|
|
|
Другой случай – на рис. 7 приведен пример графического представления иерархической модели тематических сборников издательств.
Рисунок 7 - Иерархическая модель (пример 2)
Модель позволяет обращаться к элементам напрямую, зная название и, возможно, дополнительное условие. Например, если выбрать один из сборников в предыдущем примере, можно спуститься "вниз" по иерархии и, например, просмотреть одну из статей или несколько статей из выбранного сборника.
Тут можно отметить другой недостаток. - Операции манипулирования данными в иерархических системах ориентированы прежде всего на поиск информации сверху-вниз. Обратный поиск затруднен, а часто и невозможен. Например, запрос «Кто из авторов публиковался в данном сборнике?» работает чрезвычайно быстро, поскольку направление поиска совпадает со схемой иерархии. Однако попытка реализовать запрос типа "В скольких сборниках статей опубликовал свои статьи господин Петров?" может оказаться весьма трудной задачей.
|
|
|
Следующая по уровню развития модель - сетевая модель частично решает эти проблемы.
Каждая запись хранится в одном экземпляре и связывается с набором других записей посредством связи. В процессе работы могут появляться как новые записи, так и связи. Управление ассоциативным доступом и обработкой, ориентированной на наборы, имело систему навигации, напоминающую модель страниц и ссылок нынешнего Internet.
Если вернуться к примеру с изданием тематических сборников и попытаться расширить его, чтобы он более полно соответствовал реальным взаимоотношениям, то схема сетевой модели будет выглядеть следующим образом (рис. 8).
Рисунок 8 - Сетевая модель
Свойства сетевой модели:
1. Различные логические данные могут быть получены из одних и тех же физических данных;
2. Доступ к одним и тем же данным может осуществляться по различным путям, отвечающим этим приложениям;
3. Элементы данных являются общими для разных приложений;
4. Программное обеспечение содержит средства уменьшения избыточности данных;
5. Уменьшение избыточности содействует повышению согласованности (целостности) данных.
Постепенно к концу указанного периода кристаллизовалась понятия схемы и независимости данных. В этих ранних базах данных поддерживались три вида схем данных: 1) логическая схема, которая определяет глобальный логический проект записей базы данных и связей между записями; 2) физическая схема, описывающая физическое размещение записей базы данных на устройствах памяти и в файлах, а также индексы, нужные для поддержки логических связей; 3) предоставляемая каждому приложению подсхема, раскрывающая только часть логической схемы, которую использует программа.
И на самом деле многие программы, написанные в ту эпоху, все еще работают сегодня с использованием той же самой подсхемы, с которой все начиналось, хотя логическая и физическая схемы абсолютно изменились.В результате можно говорить о возникновении эпохи развитых СУБД.
В дополнению к пяти указанным выше свойствам сетевой модели для развитой СУБД можно отметить два дополнительных свойства (6 и 7).
6. База данных содержит не только данные, но и план, или модель данных. При создании БД разработчик описывает ее логическую структуру и способы видения БД пользователем. Такие описания базы данных называются моделью данных, схемой или концептуальной схемой. Модель определяет единицы данных, а также специфицируют связи каждой единицы данных с другими единицами данных. Например, число может появиться и в файле и в базе данных, но в файле это просто обезличенное число, а в базе данных число выполняет роль, назначенную для него моделью данных. Это может быть цена, номер заказа, индексом продукта и т.д.
7. СУБД позволяет различать и поддерживать два независимых взгляда на базу данных, воплощенных соответственно в "логической" и "физической" независимости данных. Логическая независимостьданных означает, что общая структура данных может быть изменена без изменения прикладных программ. Под физической независимостьюданных понимается способность СУБД предоставлять некоторую свободу модификации способов организации базы данных в среде хранения (например, с целью повышения эффективности БД), не вызывая необходимости внесения соответствующих изменений в логическое представление и не затрагивая созданных прикладных программ, использующих БД.
V этап. Современные СУБД (1980гг. - ...)
Несмотря на успех сетевой модели данных, чувствовалось, что навигационный программный интерфейс был интерфейсом слишком низкого уровня. В статье Э.Ф. Кодда 1970 года была обрисована реляционная модель, которая стала альтернативой низкоуровневому навигационному интерфейсу. Идея реляционной модели состоит в том, чтобы единообразно представлять и сущности, и связи посредством плоских таблиц.
Возвращаясь к примеру с системой резервирования билетов, это 5 таблиц для хранения всей массы данных, включая связи
Рисунок 9 - Реляционная модель (пример 1)
В случае с издательством
Рисунок 10 - Реляционная модель (пример 2)
Для реляционных баз данных сохраняются все свойства (свойства 1-7), присущие сетевым моделям. Тем не менее, можно выделить ряд новых свойств (свойства 8-15).
8. Поддержка языков БД.Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. В современных СУБД поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (StructuredQueryLanguage).
9. Поддержка логической целостности (непротиворечивости) базы данных. В развитых СУБД ограничения целостности базы данных объявляются в схеме базы данных, а их проверка осуществляется при каждом обновлении объектов данных или связей между ними.Помимо ввода некорректных данных и неправомерными действиями процедур модификации данных, нарушение логической целостности может быть вызвано следствием несвоевременного прерывания выполнения таких процедур при обработке запроса, выданного другим пользователем, либо внешними причинами (пример некорректного переноса данных с одного счета на другой).
10. Совместное использование базы данных.СУБД должно гарантировать многопользовательское и бесконфликтное выполнение запросов и обновление на основе распределения полномочий.
11. Параллельная обработка базы данных.
12. Развитые СУБД располагают средствами восстановления разрушенной базы данных, основываясь на использовании аппарата контрольной точки и журнализации изменений.
13. Наличие средств защиты данных, обеспечивающих эффективные процедуры управления защитой, секретностью и безопасностью данных.
14. Наличие средств архивирования и перемещения данных.
15. Поддержка современных архитектур.
Традиционный подход к наращиванию возможностей СУБД заключался во встраивании новых типов данных прямо в систему баз данных: символы, числа, дата + время, интервал времени, строки переменной длины. Но это удовлетворяло не всех. Традиционно существовало четкое разделение программ и данных. По мере появления новых приложений разделение программ и данных стало проблематичным. Приложениям требовалось дать данным поведение. Например, если данные представляли сложный объект, то методы поиска, сравнения и манипулирования данными становились специфичными для типов данных "документ", "графический образ", "звук" или "карта". Специалистам различных областей хотелось определять свои типы данных и методы работы с ними: географы - карты, математики - временные ряды.
В последние годы стали появляться объектно-реляционные СУБД. В объектно-реляционной базе данных каждая запись может содержать данные со сложным поведением и это поведение может быть встроено в библиотеках классов, которые поддерживают новые типы, с одной стороны, с другой стороны, полностью сохраняется реляционный характер СУБД, включая язык манипуляции данными SQL.
Дата добавления: 2018-02-28; просмотров: 562; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!