История развития СУБД (становление и поколения)

СУБД  выросли  из  файловых  систем.  Примерное  начало  становления СУБД – 60-е  годы 20  века (нет  данных  о  разработках  других  стран (СССР, Европа)):

• для  управления  данными  американского  проекта Apollo  в  начале 60-х создано  программное  обеспечение GUAM (North American Aviation (теперь Rockwell International)),  в  середине 60-х  на  базе GUAM  создана первая коммерческая СУБД IMS (Information Management System) (NAA + IBM) –  носители  магнитная  лента,  иерархическая  структура  данных (подходило  для  управления  иерархией  частей  проекта (компоненты → узлы → детали)); 
• в  середине 60-х  фирма General Electric  создала  систему IDS (Integrated Data Store) –  сетевая  СУБД (более  сложные  взаимосвязи,  чем  у иерархических СУБД, попытка создания стандарта баз данных). Формирование  стандартов  БД –  в 1965  на  конференции CODASYL (Conference on Data System Languages)  создана  группа List Processing Task Force,  переименованная  в 1967  в DBTG (Data Base Task Group) –  предложен стандарт в отчетах 1969, 1971 на сетевые БД (логическая организация данных + язык  управления  данными) –  стандарт  не  одобрен ANSI,  но  на  его  основе разработано большое число систем (CODASYL или DBTG-систем).

DBTG-системы + системы на основе иерархического подхода – СУБД первого поколения (будут рассмотрены при изучении иерархической и сетевой модели данных), имеют ряд недостатков:

• для выполнения простых запросов требуют написания достаточно сложных программ;
• независимость от данных реализована в минимальной степени;
• отсутствие теоретических основ для описания (только технические стандарты).

В 1970 опубликована работа (E.F. Codd, IBM) о реляционной модели данных, устраняющей недостатки иерархической и сетевой моделей. На базе этой модели появилось множество экспериментальных СУБД. Первые коммерческие реляционные СУБД – конец 70-х – начало 80-х (экспериментальная СУБД System R (IBM, Сан-Хосе, Калифорния) – создана для проверки реляционной модели, в ходе проекта создан язык SQL; СУБД DB2 (IBM); Oracle (Oracle Corporation)). Реляционные СУБД относятся к СУБД второго поколения.
Реляционная модель также имеет ряд недостатков, один из них – ограниченные возможности моделирования. Наиболее значимые работы по устранению этого недостатка реляционной модели (в области семантического моделирования данных – исследований о способах представления смыслового значения, о модели более точно описывающей реальный мир):

• 1976, Чен предложил модель «сущность-связь» (ER-модель) – технология проектирования баз данных (будем рассматривать); 
• Кодд предложил расширенные версии реляционной модели (RM/T (1979) и RM/V2 (1990)).

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

СУБД

СУБД (DBMS) – программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать БД, а также осуществлять к ней контролируемый доступ. Фактически – прослойка между БД и пользователем (прикладной программой) для скрытия особенностей хранения и управления данными (абстрагирование).

Независимость от данных

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

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

Трехуровневая архитектура ANSI-SPARC

Основная  цель  СУБД –  показ  пользователям  данных  в  абстрактном представлении,  т.е.  сокрытие  от  пользователей  особенностей  хранения  и управления данными. Попытки  стандартизации  терминологии  и  общей  архитектуры  СУБД предприняты  в 1971  группой DBTG (DataBase Task Group).  Был  предложен двух  уровневый  подход  к  архитектуре  СУБД,  выработанный  на  основе системного  представления):  схема (уровень  администратора)  и  подсхемы (уровень  пользовательских  представлений).  В 1975  комитетом  планирования
стандартов  и  норм SPARC (Standarts Planning and Requeirements Committee) Национального  института  стандартизации  США ANSI (American National Standard Institute)  была  предложена  необходимость  трехуровневого  подхода. Эта  модель  не  является  стандартом,  но  представляет  собой  основу  для понимания функциональных особенностей СУБД.
Цель  трехуровневой  архитектуры –  отделение  пользовательского представления базы данных от ее физического представления по ряду причин:

• каждый пользователь должен иметь  возможность обращаться  к данным, используя  собственное  представление  о  них (независимо  от представлений других пользователей);
• взаимодействие  пользователя  с  базой  не  должно  зависеть  от особенностей  хранения  данных  в  ней (например,  индексирование, хеширование); 
• администратор  базы  данных  должен  иметь  возможность  изменять структуру  хранения  данных  в  базе,  не  оказывая  влияния  на пользовательские представления; 
• внутренняя  структура БД  не  должна  зависеть  от  изменений физических аспектов  хранения  информации (например,  использование  нового устройства хранения).
  Архитектура ANSI-SPARC имеет  три уровня: внешний, концептуальный и внутренний.

Внешний уровень – представление БД с точки зрения пользователей (для каждой группы пользователей – описываются только необходимая часть БД). Т.е. каждый пользователь имеет свое представление о «реальном мире», и не видит лишние (с его точки зрения) данные. Кроме того, разные представления могут по-разному отображать одни и те же данные (например, дату). Также часть данных при этом может не храниться в БД (так называемые производные
и вычисляемые данные), а получаться по мере надобности (например, возраст сотрудников), что не потребует лишних обновлений БД и уменьшит ее объем. Концептуальный уровень – обобщающее представление БД (описывает, какие данные хранятся в БД, а также связи между ними). Это промежуточный уровень в архитектуре. Он содержит логическую структуру всей БД (с точки зрения администратора базы данных), а именно: все сущности, их атрибуты и связи; накладываемые на данные ограничения; семантическая информация о данных; информация о мерах безопасности и поддержки целостности данных. Все внешние представления получаются из данных этого уровня, но этот уровень не содержит никаких сведений о методах хранения данных (например, может  быть  информация  о  длине  полей  их  типе,  названии,  но  нет  данных  об объеме в байтах и т.п.).
Внутренний  уровень –  физическое  представление  базы  данных  в компьютере (описывает,  как  информация  хранится  в  БД).  Описывает физическую  реализацию,  и  предназначен  для  достижения  оптимальной производительности  и  обеспечения  экономного  распределения  дискового пространства (содержит  описание  структур  данных  и  описание  организации
файлов).  На  этом  уровне  осуществляется  взаимодействие  СУБД  с  методами доступа  операционной  системы  для  работы  с  данными.  Уровень  содержит информацию о распределении дискового пространства, описание подробностей хранимых  записей (реальная  длина -  байты),  сведения  о  размещении  записей, сжатии и шифровании данных. Ниже  внутреннего  уровня  находится  физический  уровень,  который контролируется  операционной  системой (под  руководством  СУБД,  причем разделение  функций  ОС  и  СУБД  варьируется  от  системы  к  системе). Физический  уровень  использует  только  известные  операционной  системе элементы (например, указатели).
Общее описание БД принято называть схемой базы данных. Для каждого уровня архитектуры ANSI-SPARC существуют свои схемы. На внешнем уровне имеется несколько  внешних  схем или подсхем (для  различных представлений данных  пользователей).  Для  концептуального  и  внешнего  уровня  имеются соответственно концептуальная и внешняя схемы (для каждой БД существуют в  единственном  экземпляре).  Концептуальная  схема  описывает  все  элементы
данных, связи между ними, ограничения целостности и т.п. Внутренняя схема описывает  определения  хранимых  записей , методов представления,  описания полей данных, индексов и т.п.
СУБД  отвечает  за  установление  соответствия  между  этими  схемами (проверка  их  непротиворечивости –  например,  чтобы  можно  было  каждую внешнюю  схему вывести на основе концептуальной  схемы (на основе данных внутренней схемы), проверить соответствие имен и т.п.). Концептуальная схема связана  с  внутренней  посредством  концептуально-внутреннего  отображения (для поиска фактической  записи на физическом устройстве хранения,  которая соответствует  логической  записи  в  концептуальной  схеме  с  учетом ограничений).  Каждая  внешняя  схема  связана  с  концептуальной  схемой  с помощью  внешне-концептуального  отображения (отображение  имен пользовательского  представления  на  соответствующую  часть  концептуальной схемы). Например,  пользователь  хочет  получить  данные  из  БД,  при  этом  его запрос  преобразуется  к  виду  принятому  на  концептуальном  уровне (отображение внешний-концептуальный, например, изменение имен полей для получения логического описания), затем логическое описание отображается на
внутренний уровень (отображение концептуальный-внутренний) для доступа к реальным данным, затем производится обратный процесс.
Следует различать описание БД и саму БД (описание БД (содержание БД) – схема базы данных, создается в процессе проектирования (редко), а сама БД (детализация) – информация содержащаяся в таблицах может меняться часто). Совокупность  данных,  хранящихся  в  БД  на  определенный  момент  времени – состояние БД (состояний может быть различное множество).
Основное  назначение  трехуровневой  архитектуры –  обеспечение независимости от данных (т.е. чтобы изменения на различных уровнях никак не влияли на другие уровни).
Принятое  в  архитектуре ANSI-SPARC  двух  уровневое  отображение  на практике  снижает  производительность  системы,  но  при  этом  поддерживает более высокую независимость от данных (для повышения эффективности есть возможность  прямого  отображения  внешних  схем  на  внутреннюю,  но  при изменениях  внутренней  схемы  необходимо  будет  вносить  изменения  во внешние схемы и прикладные программы).

Системы баз данных (СБД).

Система  баз  данных (СБД) –  компьютеризированная  система  для хранения информации в БД.
Компоненты СБД:
I) Пользователи – делятся на четыре группы:
1) Администраторы:

• администраторы  данных –  отвечают  за  управление  данными,  включая планирование  БД,  разработку  и  сопровождение  стандартов,  бизнес правил (описывают  основные  характеристики  данных  с  точки  зрения организации) и деловых процедур, а также концептуальное и логическое проектирование БД; 
• администраторы  баз  данных –  отвечают  за физическую  реализацию БД, включая  физическое  проектирование,  обеспечение  безопасности  и целостности  данных,  а  также  обеспечение  максимальной производительности  приложений  и  пользователей (более  технический характер по сравнению с администратором данных);2) Разработчики баз данных:

2) Разработчики баз данных:

• разработчики логической базы данных – занимаются идентификацией данных, связей между данными и устанавливают ограничения, накладываемые на хранимые данные - (ответ на вопрос ЧТО?); 
• разработчики физической базы данных – по готовой логической модели создают физическую реализацию (формирование таблиц, выбор структур хранения, методов доступа, мер защиты) – ответ на вопрос КАК?)

3) Прикладные программисты – создание приложений предоставляющих пользователям необходимые функциональные возможности (действия над базой данных);
4) Пользователи (клиенты БД):

• наивные  пользователи –  осуществляют  доступ  к  БД  через  прикладные программы; 
• опытные  пользователи –  могут  осуществлять  доступ  к  БД  с использованием языков запросов или создавать собственные прикладные программы; 

II)  Прикладные  программы –  обеспечивают  простой  доступ  к  БД  для пользователей,  реализуются  с  использованием  языков  программирования 3-го (процедурные  языки - C, COBOL, Fortran, Ada, Pascal)  или 4-го  поколения (SQL, QBE). 4-е  поколение (“4GL”) -  непроцедурные  языки,  возможно генерирование  прикладного  приложения  по  параметрам,  заданных пользователем, делятся на: языки представления информации (языки  запросов или  генераторы  форм  и  отчетов);  специализированные  языки (электронных таблиц  и  БД);  генераторы  приложений  для  определения,  вставки,  обновления или  извлечения  сведений  из БД;  языки  очень  высокого  уровня  для  генерации кода приложений.
III)  БД –  совокупность  логически  связанных  данных,  хранящихся  в компьютеризованной  системе  и  отражающих  некоторую  предметную  область человеческой  деятельности.  БД –  единое,  большое  хранилище  данных (набор интегрированных записей с самоописанием), содержит данные с минимальной долей  избыточности,  к  которым  может  обращаться  большое  число пользователей.  Описание  данных  называются  системным  каталогом  или
словарем данных, а сами элементы описания – метаданные (данные о данных) (обеспечивают независимость между программами и данными).
IV)  СУБД –  система  управления  базами  данных –  программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать БД, а также осуществлять к ней контролируемый доступ. Главные  преимущества СБД –  преодоление  ограничений файловых  систем (в основном из-за обеспечения централизованного управления данными). 

История развития файловых систем.

Начало  истории  развития  БД  может  характеризоваться  следующими
этапами:  начальное  накопление  данных –  книги;  бумажные  картотеки
(карточки,  папки)  обычно  индексированные  по  какому-либо  признаку  для
ускорения  поиска (например,  картотека  библиотеки) –  ручные  операции,
эффективен только поиск по индексу (по фамилии авторов, названию книги) и
практически  невозможен  по  сложным  критериям (найти  среднее  число  книг
написанных  авторами  с  фамилией  начинающейся  на «А»  и  т.п.).  Рост
требований по поиску разнообразной информации (усложнение запросов, рост
числа данных, требование быстрого ответа на запрос), а также рост мощностей
и  доступности  вычислительной  техники (особенно  появление  магнитных
носителей (ленты, диски)) привело к появлению файловых систем.
Файловая  система -  набор  программ,  которые  выполняют  некоторые
операции  для  пользователей (ввод  данных,  операции  с  файлами,  генерация
фиксированного  набора  специализированных  отчетов),  каждая  программа
определяет жестко  свои  собственные  данные (структура  и методы  доступа)  и
управляет ими, все данные децентрализованы и хранятся в местах их обработки
(например,  по  отделам  предприятия).  Данные  в  этих  системах  хранятся  как
наборы  записей (record)  в  файлах,  каждая  запись  содержит  поля (field)
хранящих определенные характеристики.
Ограничения файловых систем:
•  разделение  и  изоляция  данных –  данные  для  обработки  должны
выбираться из нескольких файлов (сложность одновременной обработки
данных из нескольких файлов);
•  дублирование  данных – (накопление  файлов  с  данными  по  одному
объекту  в  различных  отделах) –  неэкономное  использование  ресурсов
(дисковое пространство) и риск нарушения целостности данных (ошибки,
если данные в разных отделах различаются, требуются проверки данных);
•  зависимость  от  данных – (физическая  структура  и  способы  доступа
различны  для  разных  приложений)  сложно  изменять  файлы (добавить
новое поле), для преобразования данных нужны специальные программы-
конверторы и изменение приложений;
•  несовместимость  форматов  файлов – (если  приложения  создаются  с
использованием  различных  языков  программирования (COBOL, C,
PASCAL)) необходима выработка общего формата (затраты времени)
•  фиксированные запросы (рост количества приложений) – число запросов
~=  числу  приложений,  рост  запросов –  рост  числа  приложений (снятие
документирования  и  поддержки  функциональности  системы -
усложнение сопровождения, снижение мер безопасности по защите).
Все ограничения файловых систем – следствие двух причин:
•  определение  данных  содержится  внутри  приложений,  а  не  отдельно  от
них,
•  кроме приложений нет других инструментов для доступа к данным и их
обработки.
 

О чём этот блог?

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