Задача представляющая истинный научный интерес заключается в разработке системы управления данными, которая была бы независима от формата данных и от среды программирования,
Скачать 311.93 Kb.
|
Организация данных на внешних носителях.Нечисловая обработка данных потребовала уделить больше внимания структурированию хранимой информации. Эволюция структурирования данных выглядела примерно следующим образом.
Простейшим способом хранения информации являются плоские файлы. Практически любая из ныне используемых операционных систем (ОС) поддерживает плоские файлы, за исключением некоторых специализированных для встраиваемых контроллеров. Плоский файл — это именованный набор данных на внешнем носителе. Сама ОС никакой структурой плоский файл не наделяет и трактует его просто как набор байт. Задача разделения последовательности байт на записи и выделения полей в них ложится целиком на прикладную программу. Основные операции доступа к плоским файлам – открытие на чтение/запись, закрытие, позиционирование на начало файла/конец файла/заданный байт, чтение/запись заданного количества байт с текущей позиции. Операционные системы , например, семейства UNIX или MS Windows, предоставляют намного более развитые средства для доступа к файлам. Тем не менее, все они имеют общие недостатки: Для ОС плоский файл – всего лишь последовательность байт. Поэтому все предположения о структуре записей файла делает прикладная программа. Ошибка в коде или ошибочное обращение не к тому файлу приведет к непредсказуемым последствиям. Как следствие – невозможность заблокировать на чтение/модификацию отдельную запись файла средствами ОС, так, как само понятие записи как таковое отсутствует. Для поиска нужной записи по условию на значение полей придется считывать все записи последовательно с начала файла до тех пор, пока поиск не увенчается успехом, либо наступит конец файла. Поэтому о произвольной выборке данных в этом случае можно говорить с большой натяжкой. Эти недостатки попытались преодолеть поддержкой индексно-последовательных файлов.
При создании И-П файла создается так называемый индекс, который служит для быстрого доступа к записям по значению ключевого поля. Следует обратить внимание на то, что делит файл на записи и поддерживает индекс сама ОС, а не исполняющая система, скомпонованная с прикладной программой Как следует из самого названия, с И-П файлами можно работать двояко. Во-первых, можно считывать записи последовательно, одну за другой. Во-вторых, можно сразу находить нужную запись по значению ключевого поля, при этом ОС использует индекс для ускорения поиска. И-П файлы – большой шаг вперед по сравнению с плоскими файлами. Тем не менее, и они не лишены недостатков. В одном файле могут храниться только сущности одного вида. Создание сложной модели данных приведет к нагромождению большого количества ничем не связанных между собой файлов. В операционной системе отсутствуют средства для описания взаимосвязей между сущностями, хранящимися в различных файлах. Об этих взаимосвязях «знает» только прикладная программа, обрабатывающая данные.
Недостатки, присущие традиционным файлам, сдерживали дальнейшее развитие информационных систем. Возникла потребность в инструментальных средствах, более адекватных решаемым задачам. Такими средствами явились СУБД. В создании СУБД участвовало много фирм, известных и не очень. Каждый производитель имел собственную точку зрения на то, каким должен быть идеальный продукт. В результате возникло множество СУБД, ничего общего не имевших друг с другом. По мере использования СУБД одни идеи получали развитие, заимствовались , другие, наоборот, отмирали. Довольно быстро оказалось, что, несмотря на внешние различия между системами, подавляющее большинство из них можно отнести к трем видам: иерархическим, сетевым и реляционным СУБД. * * * * В основе иерархических СУБД лежит довольно простая модель данных, которую можно представить в виде дерева — ациклического ориентированного графа особого вида. Дерево состоит из вершин, каждая из которых, кроме одной, имеет единственную родительскую вершину и несколько (в том числе ни одной) дочерних. Вершина, не имеющая родительской, называется корнем дерева. Вершины, не имеющие дочерних, называются листьями. Остальные вершины являются ветвями. Иерархические базы данных наиболее пригодны для моделирования структур, по своей природе являющихся иерархическими. В качестве примеров можно привести воинские подразделения или сложные механизмы, состоящие из более простых узлов, которые в свою очередь тоже можно подвергнуть декомпозиции. Вместе с тем существует значительное количество структур, не сводящихся к простой иерархии. Например, всем известное генеалогическое дерево, которое на самом деле не является деревом в строгом смысле, поскольку у людей по два родителя. О более сложных структурах и говорить не приходится. Иерархические СУБД быстро прошли пик популярности, которая обусловливалась их простотой в использовании и ранним появлением на рынке, когда основные конкуренты еще не дозрели для коммерческого использования. Многочисленные недостатки сделали их неконкурентоспособными, и в настоящее время иерархическая модель представляет только исторический интерес. * * * * Сетевые СУБД, подобно иерархическим, также можно представить себе в виде ориентированного графа. Но в этом случае граф может содержать циклы, то есть вершина может иметь несколько родительских. Такая структура значительно выразительнее и пригодна для моделирования гораздо более широкого класса задач. В этой модели вершины представляют собой сущности, а соединяющие их ребра – отношения между ними. Сетевые СУБД имели гораздо больший успех и долго господствовали на рынке. В немалой степени их успеху способствовала энергичная деятельность Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL). Эта организация тщательно проработала спецификации сетевой модели и ее архитектуру, что позволило создать ряд успешных коммерческих продуктов, не последнее место среди которых занимал некогда весьма популярный COBOL. 70-е годы XX века фактически стали эпохой расцвета сетевой модели. Сетевые СУБД весьма прочно укрепились на рынке, и реляционной модели пришлось с боем завоевывать свое место под солнцем. В истории информатики навечно останется «Великий Спор»1, который на самом деле явился решающим сражением сетевой и реляционной моделей. В рядах сторонников сетевой архитектуры был сам великий Чарльз Бахман, и только гений Эдгара Кодда позволил реляционной модели одержать победу. * * * * Реляционные СУБД являются в настоящее время самыми распространенными. Их реализации существуют на всех мало-мальски пригодных для этого платформах (от персональных компьютеров до мэйнфреймов), для всех операционных систем и для всех применений – от простейших продуктов, предназначенных для ведения картотек индивидуального пользования, до сложнейших распределенных многопользовательских систем. Несмотря на такое пестрое разнообразие, все СУБД имеют общую основу – реляционную модель данных, разработанную Коддом в 70-х годах XX столетия. С виду эта модель довольно проста: база данных выглядит как простой набор взаимосвязанных таблиц. Но за внешней простотой кроется мощный и вместе с тем изящный математический аппарат реляционной алгебры, которая в свою очередь базируется на целом ряде математических дисциплин, среди которых – логика, исчисление предикатов, теория множеств… Немалую роль в успехе реляционных СУБД играет также язык SQL???, разработанный специально для запросов к реляционным БД. Это достаточно простой и в то же время выразительный язык, при помощи которого можно выполнять достаточно изощренные запросы к базе. Разумеется, предшествующие СУБД также имели языки описания данных (ЯОД) и языки манипулирования данными (ЯМД). SQL объединил в себе обе эти функции. Но самой привлекательной его особенностью для пользователей-непрофессионалов в программировании, является то, что можно строить запросы на основе непроцедурного подмножества SQL. Это означает, что в формулировке запроса указывается, что должно содержаться в результате, а не как его получить. Имеются и процедурные элементы языка, например, операторы организации ветвления и циклов, но их применения зачастую удается избежать. При работе же с сетевыми БД программист был вынужден использовать навигационные процедуры, отвлекаясь при этом от решения самой задачи. Любой разработчик хранилища данных сталкивается с проблемой построения Базы Данных (БД) для хранения информации, а также создания форм для доступа и пополнения данными своего хранилища. 2. Эра Интернет. С появлением сети Интернет, появились новые возможности представления данных. Новые реализации реляционных СУБД (MySQL, PostgreSQL, и т.д.). А также появились новые языки описания содержания документов: HTML (HyperText Markup Language) - гипертекстовый язык разметки документов (является упрощенной веткой языка SGML), принятый в World Wide Web для создания и публикации Веб-страниц. HTML предоставляет авторам средства для: - включения в Веб-документы заголовков, текста, таблиц, списков, фотографий и т.п.; - перехода к другим Веб-страницам посредством щелчка кнопки мыши по гипертекстовой ссылке; - создания и заполнения форм для транзакций с удаленными службами, например, для поиска информации, бронирования билетов, оформления заказов на товары и др. - непосредственного включения в Веб-документы видеоклипов, звука и других внешних объектов. Но при всех положительных сторонах, имеются отрицательные: HTML не выражает смысла документов. Язык HTML был создан для описания структуры документов (название, заголовки, списки, абзацы и т. п.) и, в некоторой степени, правил их отображения (полужирный шрифт, курсивный шрифт и т. п.). Он ни в коей мере не предназначен для описания смысла написанных на нем документов, а во многих случаях именно данные составляют существо документа, будь-то биржевая сводка или научная публикация. Поэтому появилась необходимость в языке описания данных, причем данных, организованных в иерархические структуры. HTML громоздок и негибок. За последние годы HTML превратился в нагромождение тегов, которые часто дублируют друг друга и отнюдь не вносят ясности в текст документа. Если добавить сюда еще и нестандартные расширения HTML, которыми грешат все разработчики обозревателей, то создание мало-мальски сложных HTML-документов становится серьезной задачей. С другой стороны, раз и навсегда зафиксированный набор тегов часто оказывается недостаточно гибким для выражения нужного нам содержания. Концепция Веб-обозревателя слишком ограничена. С появлением Java-аплетов, сценарных языков и элементов ActiveX Веб-обозреватели перестали быть простыми "отображателями" HTML-документов; сегодня скорее они выглядят как программы, запускающие конкретные приложения. Тем не менее, сама концепция обозревателя накладывает излишние ограничения на пользователя; во многих случаях нужны Веб-ориентированные приложения, т. е. программы, способные читать специализированную информацию с Веб-узлов и выдавать ее в привычном виде, например, в виде электронных таблиц. Поиск документов возвращает слишком много ссылок. Все мы постоянно пользуемся поисковыми системами и постоянно клянем их за неудобство работы. Допустим, что мне нужны все тексты книг Филипа Дика, имеющиеся в Сети. Попытка поиска по имени автора приведет к тому, что я получу список всех ссылок с этим именем, включая воспоминания о Дике, рецензии на его книги и т. д. Намного удобнее было бы воспользоваться специальным тегом Невозможно найти взаимосвязанные ресурсы. Допустим теперь, что я все же нашел несколько рассказов Дика, которые явно составляют единый сборник. Хорошо, если они содержат ссылку на оглавление, но часто это не так. Поэтому необходим способ указания того, что данная группа страниц составляет единый ресурс и должна обрабатываться соответственно. Для этого необходима стандартизованная и развитая система метаописателей Веб-страниц. Поэтому рассмотрим другие возможности: XML (eXtensible Markup Language) – расширяемый язык разметки данных, открытый формат представления именно структуры данных, при работе необходимо учитывать. XML — это упрощенный диалект языка SGML, предназначенный для описания иерархических структур данных в World Wide Web. Он разрабатывается рабочей группой W3C с 1996 г.; в настоящее время принятой рекомендацией является вторая редакция языка XML 1.0 (октябрь 2000 г.), на которую и ориентируется дальнейшее изложение. XML, несомненно, входит в обойму наиболее перспективных технологий WWW, чем объясняется интерес, который уделяется ему и корпорациями-разработчиками, и пользователями. Прежде чем перейти к его описанию, представляется уместным обсудить причины его появления и последующего бурного развития. Попытаемся для этого взглянуть на те проблемы WWW, которые должны быть решены средствами нового поколения Веб-технологий. XML — это попытка решить перечисленные проблемы путем создания простого языка разметки, описывающего произвольные структурированные данные. Точнее говоря, это метаязык, на котором пишутся специализированные языки, описывающие данные определенной структуры. Такие языки называются XML-словарями. В отличие от HTML, XML не содержит никаких указаний на то, как описанные в XML-документе данные должны отображаться. Способ отображения данных для различных устройств задается языком описания стилей XSL, который играет для XML примерно ту же роль, что CSS для HTML. Другое принципиальное его отличие от HTML состоит в том, что XML может содержать любые теги, которые сочтут нужным использовать создатели XML-словаря. Приведем список лишь нескольких специализированных языков на базе XML, которые сегодня находятся в разных стадиях разработки рабочими группами W3C:
Процесс обработки XML-документа состоит в следующем. Его текст анализируется специальной программой, которая называется XML-процессором. XML-процессор ничего не знает о семантике данных в документе; он только производит синтаксический разбор (parsing) текста документа и проверяет его правильность с точки зрения правил XML. Если документ правильно оформлен (well-formed), то результаты разбора текста передаются XML-процессором прикладной программе, которая выполняет их содержательную обработку; если же документ оформлен неверно, то есть содержит синтаксические ошибки, то XML-процессор должен сообщить о них пользователю. Но при рассмотрении работы с XML необходимо помнить следующее: 1. Является семейством, под которым подразумевается множество функциональных разветвлений (Рисунок 1. Семейство XML.);  Рисунок 1. Семейство XML. 2. XML – является языком, самоописывающихся данных; 3. Легок для переноса между платформами; 4. Возможностью ввода специальных символов (математических и химических) за счет поддержки семейств. Но при переходе к работе с этим семейством необходимо помнить парадоксы, описанные в статье Дона Петерсона, «Является ли XML панацеей?»2. Таблица 1. Сравнительная таблица xml и Баз Данных.
Исходя из Таблицы 1 выбираем, как инструмент для работы XML и его семейства. |
Похожие:
 | Что же такое база данных (БД) и система управления базами данных (субд)? В этом направлении информационных технологий не существует... | | Модуль предназначен для обмена данными между базами данных «инфин-управления». Кроме того, возможен обмен данными и с «чужими» программными... |
 | Усовершенствование методической работы в доу как одно из условий повышения качества дошкольного образования | | Анализ системы управления состоянием окружающей среды в Юго-Западном районе г. Москва |
| Обучающая: создать условия для усвоения содержания теоретического материала по данной теме на уровне закрепления, научить учащихся... | | Интерфейс среды matlab (окно команд, окно рабочего пространства, окно истории команд, окно «текущая папка», окно Details, меню Start,... |
| При разработке данной программы учтен интерес обучающихся к вопросам цивилизации и культуры страны изучаемого языка, их интерес к... | | Проектирование системы управления базами данных-независимого концептуального представления данных 7 |
| Краевая информационно-аналитическая система управления образованием (далее – киасуо) предназначена для сбора, хранения и обработки... | | В результате стали появляться и совершенствоваться системы управления базами данных. Одна из самых удобных, до недавнего времени,... |