В графовых моделях данных предусматриваются характерные для представимых в них структур данных операции навигации и манипулирования данными. Принципиальное значение при этом имеет то обстоятельство, что модельные операции манипулирования данными обеспечивают одновременную обработку только одиночных объектов данных из базы данных - записей базы данных, сегментов или полей записей.
Аппарат навигации в графовых моделях служит для идентификации и перемещения в структуре данных к тому объекту данных, над которым будет выполняться очередная операция манипулирования данными. Такие объекты называются текущими. Механизмы доступа к данным и навигации по структуре данных в таких моделях достаточно сложны, особенно в сетевой модели данных CODASYL, и существенным образом опираются на концепцию текущего состояния механизмов доступа. Типичные операции в сетевой модели: найти следующую запись данного типа и сделать ее текущей, извлечь текущую запись в буфер прикладной программы для обработки, заменить в извлеченной записи значения указанных элементов данных на заданные новые их значения, запомнить запись из буфера в базе данных. Аналогичный "позаписный" характер имеют операции над данными в иерархической модели данных.
В 70-х годах начали активно проводиться теоретические исследования реляционной модели данных. Были созданы первые поддерживающие ее СУБД. С появлением персональных компьютеров реляционные системы получили широкое распространение, а к концу 80-х годов стали доминировать на рынке программного обеспечения систем баз данных практически для всех серийно выпускаемых аппаратно-программных платформ.
В соответствии с реляционной моделью данных, база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры или реляционного исчисления.
В отличие от иерархических и сетевых моделей данных в реляционной модели операции над объектами базы данных имеют теоретико-множественный характер. Каждая операция манипулирования данными в такой модели обрабатывает множество строк таблицы. Это дает возможность пользователям формулировать их запросы более компактно, в терминах более крупных конструкций данных.
Однако такой подход порождает сложные проблемы, связанные с обеспечением достаточно высокого уровня производительности СУБД этого класса, которые приходится решать их разработчикам. Другая проблема возникает, когда нужно обеспечить интерфейс СУБД, поддерживающей реляционную модель данных, с программами на традиционных языках программирования. Она заключается в несоответствии структур данных модели и языков программирования, ориентированных на "позаписную" обработку. Для ее решения пришлось дополнить модель данных специальной согласующей конструкцией данных, называемой курсором. Курсор – это временная таблица, содержащая результаты обработки запроса. Прикладная программа может последовательно просматривать строки курсора и обрабатывать их индивидуальным образом.
Характерной чертой графовых моделей данных и реляционной модели является подход к данным как к самостоятельно существующим абстрактным объектам. Их содержательный смысл и связь с объектами предметной области информационной системы остаются при этом за пределами базы данных.
При обращении к базе данных, осмысливании ее содержания отображение между реальными объектами и соответствующими им данными в базе данных, между происходящими в предметной области процессами и операциями над данными, не поддерживается средствами таких моделей данных. Оно осуществляется мысленно пользователями системы, которые должны быть хорошо знакомыми как с предметной областью, так и с организацией данных в системе.
Еще в середине 70-х годов начали проводиться исследования и разработки моделей данных нового типа, призванных решить задачу удержания семантики предметной области. Такие модели данных стали называться семантическими. В их создании приняли участие многие крупные научные центры, осуществившие глубокую теоретическую проработку проблемы и проведение многочисленных экспериментов по их практической реалиции. Тем не менее, семантические модели данных не стали основой создания коммерческих СУБД для широкого использования.
В конце 80-х годов успехи объектно-ориентированного программирования стимулировали разработки СУБД, основанных на объектной модели данных. В отличие от реляционных систем в течение значительного времени среди разработчиков объектных СУБД не существовало единодушия относительно функциональности и конкретного воплощения объектной модели данных. Эта проблема была решена благодаря учреждению консорциума Object Database Management Group (ODMG, позднее переименованного в Object Data Management Group), который разработал и в 1993 году одобрил стандарт объектных баз данных, который он продолжал развивать в дальнейшем. Объектные СУБД стали использоваться значительно шире благодаря интенсивному развитию общей объектной инфраструктуры, в среде которой должны функционировать объектные СУБД во многих крупных проектах информационных систем. Эта среда включает объектные технологии Java, платформу CORBA для создания интероперабельных неоднородных распределенных объектных сред, компонентные объектные технологии J2EE компании Sun Microsystems и COM компании Microsoft, способности Веб интегрировать в свою среду объектные технологии.
В настоящее время в большинстве коммерческих СУБД используются реляционные, объектные и объектно-реляционные модели данных. Объектно-реляционный подход в технологиях баз данных получил основательную поддержку благодаря принятому в 1999 году новому международному стандарту языка SQL. В этом стандарте, получившем название SQL:1999, воплощен некоторый вариант объектно-реляционной модели данных, обеспечивающий преемственность для реляционной модели, поддерживаемой ранними версиями языка SQL.
Рассмотрим теперь краткие характеристики наиболее распространенных моделей данных. Хотя СУБД, основанные на графовых моделях, относят в настоящее время к так называемым унаследованным системам (системам, базирующимся на морально устаревших технологиях), эти модели здесь также рассматриваются, поскольку число установок таких систем пока еще довольно велико. Кроме того, при их разработке были заложены концептуальные основы современного понимания концепции модели данных.
Основные "строительные блоки" структуры сетевой базы данных CODASYL - тип записи и тип набора. Тип записи определяет множество записей базы данных (экземпляров записей), обладающих структурой и другими свойствами, специфицированными в описании данного типа записей в схеме.
Тип набора CODASYL представляет собой множество наборов (экземпляров наборов), обладающих структурой и другими свойствами, специфицированными в схеме базы данных для этого типа набора. Каждый экземпляр набора (для краткости "набор") состоит из одного экземпляра записи, называемой владельцем набора, и в общем случае динамически изменяющегося при обновлениях базы данных множества записей, называемых членами набора. Наборы CODASYL служат для представления связей вида 1:N между записями-владельцами и записями-членами одного или нескольких типов.
Помещенная в базу данных запись может существовать в ней не только самостоятельно, но и являться одновременно членом или владельцем каких-либо наборов в зависимости от того, описан ли ее тип записи в схеме базы данных как тип записи-владельца или записи-члена каких-либо типов наборов. Каждый экземпляр типа записи-владельца набора, появляясь в базе данных, порождает экземпляр набора этого типа. Экземпляр типа записи может принадлежать многим наборам, но только не нескольким экземплярам наборов одного типа, или не принадлежать никакому набору.
Значения производных элементов данных в записи базы данных могут зависеть от значений других элементов данных той же записи, от значения элемента данных в записи-владельце какого-либо набора, членом которого является данная запись. Они могут являться также значением некоторой указанной процедуры. Значения производных элементов записи СУБД вычисляет при обращении к таким элементам.
Предусматриваются также средства управления доступом и так называемые процедуры базы данных. Процедуры базы данных – это программы, которые могут использоваться в различных целях. В частности, они могут инициироваться при наступлении определенного в схеме события, например, при выполнении операции обновления какого-либо элемента данных в записях данного типа и т. д. Такие процедуры являются прообразом триггера в языке SQL.
Для практической реализации рассматриваемой модели данных CODASYL разработал комплекс воплощающих ее языков. К их числу относятся, прежде всего, языки, описывающие организацию базы данных на различных уровнях ее представления, – язык определения данных схемы, язык описания хранимых данных и язык определения данных подсхемы. Первый из них позволяет описать единое «логическое» представление базы данных для всего комплекса ее приложений. Второй указанный язык описывает организацию базы данных в среде хранения. Язык подсхемы описывает взгляд на базу данных с позиций приложения. Для одной и той же базы данных может быть определено средствами этого языка несколько подсхем. Каждая из них описывает подмножество базы данных, с которым оперирует данное приложение или некоторая группа приложений.
На уровне схемы базы данных определяются операционные возможности сетевой модели данных CODASYL, называемые базисными функциями манипулирования данными. Однако они имеют чисто концептуальный характер и используются только для определения схемы базы данных. Реально манипулирование данными базы данных осуществляется в терминах подсхемы. В спецификациях CODASYL были представлены языки определения данных подсхемы и языки манипулирования данными для языков программирования Кобол и Фортран.
Начальная версия этой модели данных была конструктивно описана Рабочей группой по базам данных CODASYL в ее отчете, выпущенном 1969 г., где был представлен полный комплекс языковых средств описания данных и манипулирования данными для языка Кобол, связанных со всеми архитектурными уровнями СУБД. В дальнейшем предложенные языковые спецификации получили серьезное развитие в работах образованного для этой цели Комитета по языку описания данных CODASYL, а также ряда других комитетов, действующих в рамках этой организации.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 |


