ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 399
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
произвольных (ad hoc) запросов как к самим данным, так и к сведениям о том, какие типы данных доступны.
В других организациях наблюдалось быстрое увеличение количества файлов и приложений. В конечном счете наступал момент, когда сотрудники отдела по обработке данных были просто не в состоянии справиться со всей этой работой с помощью имеющихся ресурсов. В этом случае программное обеспечение переставало адекватно отвечать запросам пользователей, эффективность его падала, а недостаточность документирования имела следствием дополнительное усложнение сопровождения программ. При этом часто игнорировались меры по обеспечению безопасности или целостности данных; средства восстановления в случае сбоя аппаратного или программного обеспечения были крайне ограничены или вообще отсутствовали. Доступ к файлам часто ограничивался одним пользователем, т.е. не предусматривалось их совместное использование даже сотрудниками одного и того же отдела.
Все перечисленные ограничения файловых систем являются следствием двух факторов.
1. Определение данных содержится внутри приложений, а не хранятся отдельно и независимо от них.
2. Помимо приложений не предусмотрено никаких других инструментов доступа к данным и их обработки.
Приложение 2. Краткая история развития субд
Предшественницами СУБД были файловые системы, обладающие существенными недостатками
(прил.1). Однако появление СУБД не привело к полному исчезновению файловых систем. Для выполнения некоторых специализированных задач подобные файловые системы используются до сих пор. Считается, что развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну. Этот проект был начат по инициативе президента США Дж.Ф. Кеннеди, поставившего задачу высадить человека на Луну к концу десятилетия. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необходимо для реализации этого проекта [7].
В результате специалисты основного подрядчика – фирмы North American Aviation (теперь эта фирма называется Rockwell International) – разработали программное обеспечение под названием GUAM
(Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Эта соответствующая инвертированному дереву структура часто называется иерархической структурой (hierarchical structure). В середине 60-х годов корпорация IBM присоединилась к фирме NAA для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные возможности IMS только управлением иерархиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были основным типом носителя в то время. Спустя некоторое время это ограничение удалось преодолеть. Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов [7].
Следующим заметным достижением середины 60-х годов было появление системы IDS (Integrated
Data Store) фирмы General Electric. Работу над ней возглавлял один из пионеров исследований в области систем управления базами данных – Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа систем управления базами данных – сетевых (network) СУБД, – что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных.
Для создания таких стандартов в 1965 году на конференции организации CODASYL (Conference on Data
Systems Languages), проходившей при участии представителей правительства США и бизнесменов, была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу
Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций ереды, которая допускала бы разработку баз данных и управление данными. Предварительный вариант
120
В других организациях наблюдалось быстрое увеличение количества файлов и приложений. В конечном счете наступал момент, когда сотрудники отдела по обработке данных были просто не в состоянии справиться со всей этой работой с помощью имеющихся ресурсов. В этом случае программное обеспечение переставало адекватно отвечать запросам пользователей, эффективность его падала, а недостаточность документирования имела следствием дополнительное усложнение сопровождения программ. При этом часто игнорировались меры по обеспечению безопасности или целостности данных; средства восстановления в случае сбоя аппаратного или программного обеспечения были крайне ограничены или вообще отсутствовали. Доступ к файлам часто ограничивался одним пользователем, т.е. не предусматривалось их совместное использование даже сотрудниками одного и того же отдела.
Все перечисленные ограничения файловых систем являются следствием двух факторов.
1. Определение данных содержится внутри приложений, а не хранятся отдельно и независимо от них.
2. Помимо приложений не предусмотрено никаких других инструментов доступа к данным и их обработки.
Приложение 2. Краткая история развития субд
Предшественницами СУБД были файловые системы, обладающие существенными недостатками
(прил.1). Однако появление СУБД не привело к полному исчезновению файловых систем. Для выполнения некоторых специализированных задач подобные файловые системы используются до сих пор. Считается, что развитие СУБД началось еще в 60-е годы, когда разрабатывался проект полета корабля Apollo на Луну. Этот проект был начат по инициативе президента США Дж.Ф. Кеннеди, поставившего задачу высадить человека на Луну к концу десятилетия. В то время не существовало никаких систем, способных обрабатывать или как-либо управлять тем огромным количеством данных, которое было необходимо для реализации этого проекта [7].
В результате специалисты основного подрядчика – фирмы North American Aviation (теперь эта фирма называется Rockwell International) – разработали программное обеспечение под названием GUAM
(Generalized Update Access Method). Основная идея GUAM была построена на том, что малые компоненты объединяются вместе как части более крупных компонентов до тех пор, пока не будет собран воедино весь проект. Эта соответствующая инвертированному дереву структура часто называется иерархической структурой (hierarchical structure). В середине 60-х годов корпорация IBM присоединилась к фирме NAA для совместной работы над GUAM, в результате чего была создана система IMS (Information Management System). Причина, по которой корпорация IBM ограничила функциональные возможности IMS только управлением иерархиями записей, заключалась в том, что необходимо было обеспечить работу с устройствами хранения с последовательным доступом, а именно с магнитными лентами, которые были основным типом носителя в то время. Спустя некоторое время это ограничение удалось преодолеть. Несмотря на то, что IMS является самой первой из всех коммерческих СУБД, она до сих пор остается основной иерархической СУБД, используемой на большинстве крупных мейнфреймов [7].
Следующим заметным достижением середины 60-х годов было появление системы IDS (Integrated
Data Store) фирмы General Electric. Работу над ней возглавлял один из пионеров исследований в области систем управления базами данных – Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа систем управления базами данных – сетевых (network) СУБД, – что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных.
Для создания таких стандартов в 1965 году на конференции организации CODASYL (Conference on Data
Systems Languages), проходившей при участии представителей правительства США и бизнесменов, была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу
Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций ереды, которая допускала бы разработку баз данных и управление данными. Предварительный вариант
120
отчета этой группы был опубликован в 1969 году, а первый полный вариант – в 1971 году.
Предложения группы DBTG содержали три компонента [7].
1. Сетевая схема – это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа.
2. Подсхема – это часть базы данных, как она видится пользователям или приложениям.
3. Язык управления данными – инструмент для определения характеристик и структуры данных, а также для управления ими.
Группа DBTG также предложила стандартизировать три различных языка.
1. Язык определения данных (Data Definition Language – DDL) для схемы, который позволит АБД описать ее.
2. Язык определения данных (также DDL) для подсхемы, который позволит определять в приложениях те части базы данных, доступ к которым будет необходим.
3. Язык манипулирования данными (Data Manipulation Language - DML), предназначенный для управления данными.
Несмотря на то, что этот отчет официально не был одобрен Национальным Институтом
Стандартизации США (American National Standards Institute - ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG, Теперь они называются
CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи приведенные ниже недостатки.
• Даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные программы.
• Независимость от данных существует лишь в минимальной степени.
• Отсутствие общепризнанных теоретических основ.
В 1970 году Э.Ф.Кодд (E.F.Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х – начале 80-х годов. Особенно следует отметить проект System R, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.
• Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.
• В 80-х годах были созданы различные коммерческие реляционные СУБД - например, DB2 или
SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.
В настоящее время существует несколько сотен различных реляционных СУБД для мейнфреймов и микрокомпьютеров, хотя для многих из них определение реляционной модели носит несколько преувеличенный характер. В качестве примера многопользовательских СУБД может служить система
CA-Openlngres фирмы Computer Associates и систему Informix фирмы Informix Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft,
Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные СУБД относятся к
СУБД второго поколения.
Однако реляционная модель также обладает некоторыми недостатками – в частности, ограниченными возможностями моделирования сложных предметных областей. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель «сущность-связь» (Entity-Relationship model – ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных.
В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели – RM/T (1979), затем еще одну версию –
RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).
121
Предложения группы DBTG содержали три компонента [7].
1. Сетевая схема – это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа.
2. Подсхема – это часть базы данных, как она видится пользователям или приложениям.
3. Язык управления данными – инструмент для определения характеристик и структуры данных, а также для управления ими.
Группа DBTG также предложила стандартизировать три различных языка.
1. Язык определения данных (Data Definition Language – DDL) для схемы, который позволит АБД описать ее.
2. Язык определения данных (также DDL) для подсхемы, который позволит определять в приложениях те части базы данных, доступ к которым будет необходим.
3. Язык манипулирования данными (Data Manipulation Language - DML), предназначенный для управления данными.
Несмотря на то, что этот отчет официально не был одобрен Национальным Институтом
Стандартизации США (American National Standards Institute - ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG, Теперь они называются
CODASYL-системами, или DBTG-системами. CODASYL-системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи приведенные ниже недостатки.
• Даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные программы.
• Независимость от данных существует лишь в минимальной степени.
• Отсутствие общепризнанных теоретических основ.
В 1970 году Э.Ф.Кодд (E.F.Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х – начале 80-х годов. Особенно следует отметить проект System R, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.
• Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.
• В 80-х годах были созданы различные коммерческие реляционные СУБД - например, DB2 или
SQL/DS корпорации IBM или Oracle корпорации Oracle Corporation.
В настоящее время существует несколько сотен различных реляционных СУБД для мейнфреймов и микрокомпьютеров, хотя для многих из них определение реляционной модели носит несколько преувеличенный характер. В качестве примера многопользовательских СУБД может служить система
CA-Openlngres фирмы Computer Associates и систему Informix фирмы Informix Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft,
Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные СУБД относятся к
СУБД второго поколения.
Однако реляционная модель также обладает некоторыми недостатками – в частности, ограниченными возможностями моделирования сложных предметных областей. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель «сущность-связь» (Entity-Relationship model – ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных.
В 1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели – RM/T (1979), затем еще одну версию –
RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).
121
В ответ на все возрастающую сложность приложений баз данных появились две новые системы:
объектно-ориентированные СУБД, или ООСУБД (Object-Oriented DBMS - OODBMS), и объектно-
реляционные СУБД, или ОРСУБД (Object-Relational DBMS -ORDBMS). Однако, в отличие от предыдущих моделей, действительная структура этих моделей не совсем ясна. Попытки реализации подобных моделей представляют собой СУБД третьего поколения.
Приложение 3. Сравнительная характеристика даталогических моделей
Сетевая модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
Поддержание бинарных связей и связей более высоких степеней типа M:N с помощью декомпозиции.
Поддерживает рекурсивные связи с помощью декомпозиции.
Типы записи непосредственно связаны друг с другом с помощью конструкции «тип набора».
Целостность на уровне ссылок поддерживается за счёт конструкций «тип набора».
Обладает ограниченной гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется путем «перемещения» (навигации) по структуре. В зависимости от конкретного расположения типа записи по отношению к начальной точке в структуре, для доступа к данным могут использоваться различные специальные команды.
Иерархическая модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.
Бинарные связи более высоких степеней типа M:N поддерживаются только с помощью декомпозиции и дублирования данных в разных иерархиях.
Рекурсивные связи поддерживаются только с помощью декомпозиции и дублирования данных.
Типы записей непосредственно связаны между собой с помощью иерархической структуры.
Целостность на уровне ссылок поддерживается в тех случаях, когда зависимый дочерний тип записи полностью участвует в связи со своим родительским типом записи.
Не обладает гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется путем «перемещения» (навигации) от корневого типа записи к типам записи более низкого уровня в данной иерархии при ее прямом или обратном обходе.
1 ... 10 11 12 13 14 15 16 17 ... 20
Реляционная модель данных
Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М, а также рекурсивные связи типа 1:1 и 1:М.
Бинарные связи более высоких степеней типа M:N поддерживаются с помощью декомпозиции.
Рекурсивные связи типа M:N поддерживаются с помощью декомпозиции
Типы записей связанны друг с другом символически с помощью конструкции
«первичный/внешний ключ».
В реляционной модели поддерживается целостность на уровне ссылок.
Обладает гибкостью по отношению к изменению требований к данным и методам доступа.
Доступ к типам записей осуществляется с помощью команд реляционной алгебры или реляционного исчисления. Эти команды могут быть вложенными, что позволяет создавать сложные запросы.
Сводная характеристика систем баз данных
Критерий
CODASYL (сетевая
система)
IMS (иерархическая
система)
Реляционная система
Период создания
1960 – 1970 годы
1960 – 1970 годы
1960 – настоящее время
122
Над чем ведется работа сейчас
Разделение физических и логических концепций
Обеспечение взаимодействия с другими системами и типами СУБД
Повышение производительности, обеспечение совместимости с SQL2, а также добавление объектно- ориентированных компонентов
Реализация
Записи и указатели
Обычно записи и указатели, но могут быть и просто физически смежные записи
Записи со значениями, которые могут использоваться как логические указатели
Базовая физическая структура данных
Сеть, в которой записи связаны друг с другом в один набор с помощью указателей. Могут содержать встроенные в них указатели
Обобщенная древовидная структура, в которой один тип записи образует корень, а все другие типы записей – зависимые от корня узлы
Двумерная таблица
Общая структура файлов и методы доступа к ним
Прямые методы доступа и индексно- последовательные методы доступа (включая метод
VSAM)
Методы доступа HIDAM,
HDAM.HISAM.HSA М.
Варианты прямого доступа и индексно-последователь- ных методов доступа
(включая метод VSAM)
Разные методы доступа от последовательных файлов с индексами и методов прямого доступа вплоть до сложных древовидных поисковых структур
Логическая структура данных
Набор, в котором один тип записи-владельца может быть связан со многими типами записей-членов.
Сложные сети создаются с помощью типов наборов
Обобщенная древовидная структура
Набор двумерных таблиц
Поддерживаемые типы связей
Связи типа 1:1 и 1:М.
Связи типа M:N и рекурсивные связи поддерживаются с помощью декомпозиции. С ними проще всего работать в иерархической системе
Связи типа 1:1 и 1 :М.
Связи типа M:N обычно поддерживаются с помощью логических указателей, которые связывают разные физические структуры данных. Рекурсивные связи поддерживаются с помощью декомпозиции и дублирования
Связи типа 1:1 и 1:М.
Связи типа M:N и рекурсивные поддерживаются с помощью декомпозиции
Поддержка целостности на уровне ссылок для связей типа «родитель-потомок»
Обеспечивается средствами СУБД с использованием правил вставки и сохранения для структуры наборов. Если записи-члены закреплены за записью-владельцем, то удаление записи-владельца приводит к каскадному удалению записей-членов.
Обеспечивается средствами СУБД с использованием зависимостей в древовидной структуре. То есть при удалении корня дерева (или поддерева) будут удалены все зависящие от него узлы, что эквивалентно каскадному удалению.
Поддержка варьируется от разработки процедур, правил или триггеров, используемых непосредственно средствами СУБД, вплоть до процедур, реализуемых в прикладных программах.
123
Если записи-члены не обязательно являются частью набора, то удаление записи-владельца эквивалентно заданию неопределенной связи
(NULL). Можно запрограммировать и другие варианты действий.
Обычно внешние ключи в типах записей не требуются
Обычно в типах записей внешние ключи не нужны.
Сложности могут возникнуть в случаях, когда связи M:N представляются с помощью логических указателей
Стандарт SQL92 требует реализации этой функции механизмами самой СУБД
Логическая независимость от данных
Концептуальная схема моет быть расширена без изменения подсхем. При перестройке или удалении из концептуальной схемы типов записи, поля набора потребуется ввести поправки только в те представления, в которых они используются
Полностью аналогична
CODASYL -системам
Полностью аналогична
CODASYL -системам
Физическая независимость от данных
Концептуальная схема должна быть изменена в соответствии с изменениями структуры хранения в тех местах схемы, в которых описаны детали физического хранения. Это может вызвать необходимость изменения прикладных программ. Следовательно, реализация макета базы данных может значительно усложниться
При изменении структуры хранения может потребоваться изменить концептуальную схему
(ОБД) и внести поправку в логику обработки данных в приложениях. Для упрощения процесса изменения структур хранения предусмотрены специальные утилиты
В тех случаях когда не допускается выбор из нескольких возможных физических структур данных, некоторые СУБД при необходимости позволяют определять различные структуры файлов и вторичных индексов
Гибкость при изменении приложений
Новые или изменённые приложения могут не обладать достаточной производительностью, потому что база данных структурирована для существовавших ранее приложений.
Новые или изменённые приложения могут быть неэффективны, потому что базовые структуры подогнаны под исходные приложения.
Настройка для работы с новыми или изменёнными приложениями может быть выполнена без особых затруднений.
Поэтому может оказаться не возможным эффектно поддерживать все требуемые приложения
Изменить базовую структуру так, чтобы обеспечить удовлетворительную работу базы данных со всеми требуемыми приложениями, достаточно сложно или даже вообще не возможно. Вероятно, для этого потребуется создать дополнительные структуры
В СУБД, поддерживающей выбор структуры файлов, для разных таблиц могут быть выбраны самые подходящие структуры данных
124