Приложение

ПРИЛОЖЕНИЯ

Приложение 1. НЕДОСТАТКИ ФАЙЛОВЫХ СИСТЕМ

Ограничения файловых систем, закрывающие перспективы их использования при обработке значительных объемов информации большим количеством конкурирующих пользователей следующие [7, 1Ц.

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

2.Дублирование данных.

3.Зависимость данных.

4.Несовместимость форматов файлов.

5.Фиксированный набор запросов, быстрое увеличение количества приложений.

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

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

2. Дублирование данных

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

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

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

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

3. Зависимость данных

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

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

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

4. Несовместимость форматов файлов

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

5. Фиксированный набор запросов, быстрое увеличение количества приложений

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

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

Все перечисленные ограничения файловых систем являются следствием двух факторов.

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-х годов было появление системы ПЭ8 (Integrated Data Store) фирмы General Electric. Работу над ней воз-

главлял один из пионеров исследований в области систем управления базами данных – Чарльз Бачман (Charles Bachmann). Развитие этой системы привело к созданию нового типа систем управления базами данных – сетевых (network) СУБД, – что оказало существенное влияние на информационные системы того поколения. Сетевая СУБД создавалась для представления более сложных взаимосвязей между данными, чем те, которые можно было моделировать с помощью иерархических структур, а также для формирования стандарта баз данных. Для создания таких стандартов в 1965 году на конференции организации

CODASYL (Conference on ВаФа Systems Languages), проходившей при участии представителей правительства США и бизнесменов, была сформирована рабочая группа List Processing Task Force, переименованная в 1967 году в группу Data Base Task Group (DBTG). В компетенцию группы DBTG входило определение спецификаций среды, которая допускала бы разработку баз данных и управление данными. Предварительный вариант отчета этой группы был

опубликован в 1969 году, а первый полный вариант – в 1971 году. Предложения группы DBTG содержали три компонента [7].

1.Сетевая схема – это логическая организация всей базы данных в целом (с точки зрения АДБ), которая включает определение имени базы данных, типа каждой записи и компонентов записей каждого типа.

2.Подсхема – это часть базы данных, как она видится пользователям или приложениям.

3.Язык управления данными – инструмент для определения характеристик и структуры данных, а также для управления ими.

Группа DBTG также предложила стандартизировать три различных языка.

1.Язык определения данных (Data Definition Language – DDL) для схемы, который позволит АБД описать ее.

2.Язык определения данных (также ИН ) для подсхемы, который позволит определять в приложениях те части базы данных, доступ к которым будет необходим.

3.Язык манипулирования данными (Data Manipulation Language – DML), пред-

назначенный для управления данными.

Несмотря на то, что этот отчет официально не был одобрен Национальным Институтом Стандартизации США (American National Standards Institute – ANSI), большое количество систем было разработано в полном соответствии с этими предложениями группы DBTG. Теперь они называются CODASYLсистемами, или DBTG-системами. СОРА8'Л -системы и системы на основе иерархических подходов представляют собой СУБД первого поколения. Однако этим двум моделям присущи приведенные ниже недостатки.

–Даже для выполнения простых запросов с использованием переходов и доступом к определенным записям необходимо создавать достаточно сложные программы.

–Независимость от данных существует лишь в минимальной степени.

–Отсутствие общепризнанных теоретических основ.

В1970 году Э.Ф.Кодд (Е.F.Codd), работавший в исследовательской лаборатории корпорации IBM, опубликовал очень важную и весьма своевременную статью о реляционной модели данных, позволявшей устранить недостатки прежних моделей. Вслед за этим появилось множество экспериментальных реляционных СУБД, а первые коммерческие продукты появились в конце 70-х - начале 80-х годов. Особенно следует отметить проект System В, разработанный в исследовательской лаборатории корпорации IBM, расположенной в городе Сан-Хосе, штат Калифорния, созданный в конце 70-х годов (Astrahan et al., 1976). Этот проект был задуман с целью доказать практичность реляционной модели, что достигалось посредством реализации предусмотренных ею структур данных и требуемых функциональных возможностей. На основе этого проекта были получены важнейшие результаты.

–Был разработан структурированный язык запросов SQL, который с тех пор стал стандартным языком любых реляционных СУБД.

–В 80-х годах были созданы различные коммерческие реляционные СУБД – например, DB2 или SQL/DS корпорации IBM или Oracle корпорации Oracle

Corporation.

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

OpenIngres фирмы Computer Associates и систему Informix фирмы Informix

Software, Inc. Примерами реляционных СУБД для персональных компьютеров являются Access и FoxPro фирмы Microsoft, Paradox и Visual dBase фирмы Borland, а также R:Base фирмы Microrim. Реляционные СУБД относятся к СУБД второго поколения. Однако реляционная модель также обладает некоторыми недостатками – в частности, ограниченными возможностями моделирования сложных предметных областей. Для решения этой проблемы был выполнен большой объем исследовательской работы. В 1976 году Чен предложил модель <сущность-связь» (Entity-Relationship model – ER-модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных.

В1979 году Кодд сделал попытку устранить недостатки собственной основополагающей работы и опубликовал расширенную версию реляционной модели – RM/Т (1979), затем еще одну версию – RM/V2 (1990). Попытки создания модели данных, позволяющей более точно описывать реальный мир, нестрого называют семантическим моделированием данных (semantic data modeling).

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

Приложение 3. СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА ДАТАЛОГИЧЕСКИХ МОДЕЛЕЙ

Сетевая модель данных

–Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.

–Поддержание бинарных связей и связей более высоких степеней типа М:N с помощью декомпозиции.

–Поддерживает рекурсивные связи с помощью декомпозиции.

–Типы записи непосредственно связаны друг с другом с помощью конструкции «тип набора».

–Целостность на уровне ссылок поддерживается за счёт конструкций «тип набора».

–Обладает ограниченной гибкостью по отношению к изменению требований к данным и методам доступа.

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

Иерархическая модель данных

–Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М.

–Бинарные связи более высоких степеней типа М:N поддерживаются только с помощью декомпозиции и дублирования данных в разных иерархиях.

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

–Типы записей непосредственно связаны между собой с помощью иерархической структуры.

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

–Не обладает гибкостью по отношению к изменению требований к данным и методам доступа.

–Доступ к типам записей осуществляется путем «перемещения» (навигации) от корневого типа записи к типам записи более низкого уровня в данной иерархии при ее прямом или обратном обходе.

Реляционная модель данных

–Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М, а также рекурсивные связи типа 1:1 и 1:М.

–Бинарные связи более высоких степеней типа М:N поддерживаются с помощью декомпозиции.

–Рекурсивные связи типа М:N поддерживаются с помощью декомпозиции и Типы записей связанны друг с другом символически с помощью конструкции «первичный/внешний ключ».

–В реляционной модели поддерживается целостность на уровне ссылок.

–Обладает гибкостью по отношению к изменению требований к данным и методам доступа

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

Сводная характеристика систем баз данных

Критерий		CODASYL	IMS (иерархическая система)		Реляционная система
		(сетевая система)
Период создания		1960-1970 годы	1960-1970 годы		1960-настоящее время
Над чем ведется		Разделение физических и ло-	Обеспечение взаимодействия с		Повышение	производительности,
работа сейчас		гических концепций	другими системами и типами		обеспечение совместимости с SQL2, а
			СУБД		также	добавление	объектно-
					ориентированных компонентов
Реализация		Записи и указатели	Обычно записи и указатели, но		Записи со значениями, которые могут
			могут быть и просто физиче-		использоваться как логические указа-
			ски смежные записи		тели
Базовая	физиче-	Сеть, в которой записи связа-	Обобщенная	древовидная	Двумерная таблица
ская	структура	ны друг с другом в один	структура, в которой один тип
данных		набор с помощью указателей.	записи образует корень, а все
		Могут содержать встроенные	другие типы записей - зависи-
		в них указатели	мые от корня узлы
Общая структура		Прямые методы доступа и	Методы доступа HIDAM,		Разные методы доступа от последова-
файлов и методы		индексно-последовательные	HDAM, HISAM, HSA М. Ва-		тельных файлов с индексами и методов
доступа к ним		методы доступа (включая ме-	рианты прямого доступа и ин-		прямого доступа вплоть до сложных
		тод VSAM)	дексно-последователь-ных ме-		древовидных поисковых структур
			тодов доступа (включая метод
			VSAM)
Логическая		Набор, в котором один тип	Обобщенная	древовидная	Набор двумерных таблиц
структура данных		записи-владельца может быть	структура
		связан со многими типами
		записей-членов. Сложные се-
		ти создаются с помощью ти-

пов наборов

Поддерживаемые

Связи типа 1:1 и 1:М.Связи

Связи типа 1:1и 1:М. Связи

Связи типа 1:1 и 1:М.Связи типа M:N и

типы связей

типа M:N и рекурсивные свя-

типа M:N обычно поддержи-

рекурсивные поддерживаются с помо-

зи поддерживаются с помо-

ваются с помощью логических

щью декомпозиции

щью декомпозиции. С ними

указателей, которые связыва-

проще

всего

работать в

ют разные физические струк-

иерархической системе

туры данных.

Рекурсивные

связи поддерживаются с по-

мощью декомпозиции и дуб-

лирования

Поддержка

це-

Обеспечивается

средствами

Обеспечивается

средствами

Поддержка варьируется от разработки

лостности

на

СУБД с использованием пра-

СУБД с использованием зави-

процедур, правил или триггеров, ис-

уровне

ссылок

вил вставки и сохранения для

симостей

в

древовидной

пользуемых

непосредственно

сред-

для связей

типа

структуры наборов. Если за-

структуре. То есть при удале-

ствами СУБД, вплоть до процедур, ре-

«родитель-

писи-члены закреплены за

нии корня дерева (или подде-

ализуемых в прикладных программах.

потомок»

записью-владельцем, то уда-

рева)будут удалены все зави-

Стандарт SQL92 требует реализации

ление записи-владельца при-

сящие от него узлы, что экви-

этой функции механизмами

самой

водит к каскадному удалению

валентно каскадному удале-

СУБД

записей-членов. Если записи-

нию. Обычно в типах записей

члены не обязательно явля-

внешние ключи не нужны.

ются частью набора, то уда-

Сложности могут возникнуть в

ление записи-владельца экви-

случаях,когда связи M:N пред-

валентно

заданию неопреде-

ставляются с помощью логи-

ленной связи (NULL). Можно

ческих указателей

запрограммировать и

другие

варианты действий.

Обычно

внешние ключи в типах запи-

сей не требуются

Логическая

неза-

Концептуальная

схема моет

Полностью

аналогична CO-

Полностью

аналогична CODASYL-

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