ADO и XML простыми словами


Оглавление (нажмите, чтобы открыть):

Применение технологии ADO для работы с XML-файлами

В силу обстоятельств пришлось столкнуться и с ADO и с .NET чуть ближе чем хотелось бы.
Прошу помочь решить задачу/ответить на вопрос:
У меня есть табличка на форме и все данные с нее я сохраняю в xml файл, и выгражаю данные в таблицу из xml файла. Мне не нужно иметь базу данных, все данные я храню в xml документе. Можно ли как-то работать по технологии ADO с xml файлами? Т.е. пользоваться всеми плюшками технологии, но работать не с бд, а с xml. Подскажите и направьте, пожалуйста. Если можно с примером.

Добавлено через 5 часов 53 минуты
Ок, решил работать с DataGridView при помощи ADO и сериализовывать полученные данные в xml объекты. Не подскажите как можно сделать Dictionary источником данных DataGridView?
Подскажите, пожалуйста! Единственное место где не могу разобраться.
Заранее спасибо.

09.03.2012, 00:01

Организация работы с XML файлами через DataAdapter
Здравствуйте! Не хотелось просить помощи, но время проведенное за чтением книг и поиск в интернете.

Какие технологии использовать для работы с XML
Здравствуйте. Подскажите какие технологии использовать в проекте? Программа должна выполнять.

Что нужно для работы с xml-файлами на perl?
что нужно для работы с xml-файлами на perl? (под виндоус, на апаче и активперле) от xml.

Основы работы с XML файлами
Здравствуйте пользователи форума. Хотел спросить как, считывать и записывать из XML файла. Что.

Основы XML для начинающих пользователей

Введение в правильную разметку

XML означает Extensible Markup Language, с акцентом на markup (разметка). Вы можете создавать текст и размечать его при помощи обрамляющих тегов, превращая каждое слово, предложение или фрагмент в идентифицируемую, сортируемую информацию. Создаваемые вами файлы, или экземпляры документа, состоят из элементов (тегов) и текста, причем элементы помогают правильно понимать документ при чтении на бумаге или даже обрабатывать его в электронном виде. Чем больше описательных элементов, тем больше частей документа можно идентифицировать. С первых дней существования разметки одно из ее преимуществ заключается в том, что в случае потери компьютерной системы распечатанные данные все равно остаются читабельными благодаря тегам.

Языки разметки прошли путь от первых форм, создаваашихся компаниями и госучреждениями, до Стандартного языка обобщенной разметки (Standard Generalized Markup Language — SGML), Гипертекстового языка разметки (Hypertext Markup Language — HTML) и в конечном итоге до XML. SGML может показаться сложным, а HTML (который, по сути, сначала был просто набором элементов) оказался недостаточно мощным для идентификации информации. XML разрабатывался как простой в применении и удобный для расширения язык разметки.

В XML можно создавать свои собственные элементы, что позволяет точно представлять фрагменты данных. Документы можно не просто разделять на абзацы и заголовки, но и выделять любые фрагменты внутри документа. Чтобы это было эффективно, нужно определить конечный перечень своих элементов и придерживаться его. Элементы можно определять в Описании типа документа (Document Type Definition — DTD) или в схеме, что будет кратко обсуждено ниже. Когда вы освоите и начнете использовать XML, не бойтесь экспериментировать с именами элементов, создавая реальные файлы.

Построение документа XML

Как уже упоминалось, файлы XML состоят из текста и разметки. Большая часть текста помещается в элементы, в которых текст окружен тегами. Например, допустим, нужно создать поваренную книгу в формате XML. У нас есть рецепт под названием Ice Cream Sundae, который нужно преобразовать в XML. Чтобы разметить название рецепта, заключим его текст в элемент, который начинается и заканчивается тегами. Этот элемент можно назвать recipename . Чтобы отметить начальный тег элемента, поместим его имя в угловые скобки <> ), вот так: . Затем введем текст Ice Cream Sundae . После текста поставим замыкающий тег, который представляет собой имя элемента в угловых скобках, плюс косая черта завершения элемента ( / ) перед именем элемента, вот так: . Эти теги образуют элемент, в который можно вводить текст и даже другие элементы.

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

Начало создания файла XML

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

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

Создание корневого элемента

Начальный и замыкающий теги корневого элемента окружают весь текст XML-документа. В файле должен присутствовать только один корневой элемент, и это необходимая «обложка» для него. В листинге 1 показан фрагмент примера, который я здесь использую, с корневым элементом (рецепт). (Полный файл XML приведен в Загрузках.)

Листинг 1. Корневой элемент

По мере создания своего документа вы будете размещать текст и дополнительные теги между и .

Наименования элементов

Соблюдение регистра в тегах

При создании XML регистры начального и конечного тегов должны совпадать. В противном случае можно получить сообщение об ошибке при использовании или просмотре XML. Например, Internet Explorer не отображает текст в случае несовпадения регистров. Вместо этого он выводит сообщения о несовпадении начального и конечного тегов.

Итак, у нас есть корневой элемент . В XML сначала выбираются имена элементов, а затем на основе этих имен определяется соответствующее описание DTD или схема. Имена могут содержать буквы, цифры и специальные знаки, такие как знак подчеркивания ( _ ). Вот несколько правил об именах, которые нужно помнить:

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

В предыдущем примере, если мы добавили элемент с именем , то его начальным тегом должен быть , а соответствующим замыкающим тегом — .

Листинг 2. Другие элементы

XML-документ может содержать пустые теги, внутри которых ничего нет и которые могут выражаться одним тегом, а не парой из открывающего и замыкающего тегов. Например, это может быть самостоятельный тег в стиле HTML . Он не содержит никаких дочерних элементов или текста, так что это пустой элемент, и его можно записать как (с пробелом и знакомой замыкающей косой чертой в конце).

Вложение элементов

Вложение— это размещение элементов внутри других элементов. Эти новые элементы называются дочерними элементами, а элементы, которые их окружают, — их родительскими элементами. В листинге 3 в корневой элемент вложено несколько элементов. Это вложенные дочерние элементы , и

Добавление атрибутов

К элементам иногда добавляются Атрибуты. Атрибуты состоят из пары имя-значение, где значение берется в двойные кавычки ( » ), вот так: type=»dessert» . Атрибуты позволяют сохранять вместе с элементом дополнительные параметры, меняя значения этих параметров от элемента к элементу в одном и том же документе.

Атрибут —или даже несколько атрибутов —указывается внутри начального тега элемента: . При добавлении нескольких атрибутов они разделяются пробелами: . В листинге 4 показан файл XML, как он выглядит теперь.

Листинг 4. Наш файл XML с элементами и атрибутами

Можно использовать любое количество атрибутов. Подумайте, какие подробности можно добавить в ваш документ. Атрибуты особенно полезны, если документы будут храниться —например, по типу рецептов. Имена атрибутов могут содержать такие же символы, что и имена элементов, с теми же правилами исключения пробелов и начала имени с буквы.

Правильно и неправильно построенный XML

Если вы следуете правилам, определенным в вашей структуре, вы сможете легко создавать правильно построенный код XML. Правильный XML— это код XML, составленный с соблюдением всех правил XML: правильное именование элементов, вложение, именование атрибутов и т.п.

В зависимости от того, что именно вы делаете с XML, вам может понадобиться работа с правильно построенным XML. Рассмотрим приведенный выше пример сортировки по типу рецептов. Нужно, чтобы элементы содержали атрибут type . Очень важно иметь возможность успешно проверить код и гарантировать постоянное присутствие значения этого атрибута.

Под проверкой (validation) понимается проверка структуры документа на соответствие установленным для нее правилам и определению дочерних элементов для каждого родительского элемента. Эти правила определяются в Описании типа документа (DTD) или в схеме. Для такой проверки требуется создать DTD или схему, а затем давать ссылку на файл DTD или схемы в своих XML-файлах.

Чтобы разрешить проверку, нужно ближе к началу своих XML-документов поместить декларацию типа документа ( DOCTYPE ). Эта строка содержит ссылку на DTD или схему (перечень элементов и правил), которая будет использоваться для проверки данного документа. Строка DOCTYPE может быть примерно такой, как в листинге 5.

Листинг 5. DOCTYPE

Этот пример означает, что ваш файл списка элементов с именем filename.dtd находится в вашем компьютере (то есть в каталоге SYSTEM , а не в общем каталоге PUBLIC ).

Использование сущностей

Сущности (entity)могут представлять собой фрагменты текста или специальные символы. Они могут указываться внутри документа или вне его. Во избежание ошибок и для правильности отображения сущности должны быть надлежащим образом объявлены и выражены.

Нельзя вводить специальные символы прямо в текст. Для использования в тексте специальных символов их нужно сделать сущностями и использовать коды этих символов. В качестве сущностей можно определить фразы, такие как название компании, а затем использовать их по всему тексту. Чтобы создать сущность, назначьте ей имя и вставляйте это имя и вставляйте это имя в текст после знака амперсанда ( & ) и заканчивая точкой с запятой — например, &coname; (или другое имя). Затем укажите этот код в своей строке DOCTYPE в квадратных скобках( [] ), как в листинге 6. Этот код определяет текст, который подставляется вместо сущности.

Листинг 6. Сущность

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

Как избежать ошибок

Пока вы учитесь создавать XML-файлы, открывайте их в редакторе XML, чтобы удостовериться в их формальной правильности и убедиться, что правила XML соблюдены. Например, если у вас Windows® Internet Explorer®, вы можете просто открыть свой файл XML в браузере. Если ваши элементы, атрибуты и текст отображаются, значит файл XML составлен правильно. Если же присутствуют ошибки, вероятно, вы что-то напутали в синтаксисе, и вам нужно тщательно проверить свой документ на опечатки или пропуски тегов и знаков пунктуации.


Как упоминалось в разделе Вложение элементов, элемент, содержащий другой элемент, называетя родителем этого вложенного элемента. В приведенном ниже примере является корневым элементом и содержит весь текст файла. В этот родительский элемент вложены дочерние элементы , , и другие. Такая структура делает , и дочерними элементами. Не забывайте правильно вкладывать эти дочерние элементы. В листинге 7 приведен пример правильно построенного XML-документа с правильным вложением элементов.

Листинг 7. Правильно построенный документ XML

Примечание: Разрывы строк облегчают чтение кода, не влияют на сам XML.

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

Проверка XML

На рисунке 1 показан XML-документ, элементы которого отображаются без сбоев в Internet Explorer. Текст обрамляют открывающий и замыкающий теги. Рядом с родительскими элементами расположены значки плюс ( + ) и минус( — ), которые позволяют убрать внутрь элементов все вложенные в них элементы (их потомков).

Рисунок 1. Пример файла XML со свернутыми потомками

Заключение

Усвоив несколько простых правил, вы можете гибко разрабатывать собственные элементы XML и их атрибуты. Правила XML не сложны. Набирать XML-документ тоже несложно. Главное — понять, что вы хотите от документов в смысле возможностей сортировки и поиска, а затем разработать элементы и атрибуты для удовлетворения этих требований.

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

Ресурсы для скачивания

  • этот контент в PDF
  • Пример исходного кода (example.zip | 2KБ)

Похожие темы

  • Оригинал статьи (EN).
  • Статьи на тему XML в Wikipedia: подробнее об XML.
  • Руководства по XML на сайте W3 Schools: от основ XML — к JavaScript и другим, более сложным предметам.
  • Спецификация XML от World W >

Комментарии

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

XML: пример, функции и возможности, плюсы и минусы формата

XML — код, принятый в качестве рекомендации Консорциума World Wide Web (W3C), аналогичен языку HTML. Он является менее сложным и удобным в применении, принадлежит к подмножеству языка разметки стандарта SGML, используемого для создания структуры документа. Основным строительным блоком XML является элемент, определяемый начальными и конечными тегами. Все данные в документе XML содержатся во внешнем элементе, известном как корневой. Имена описывают его содержимое. А структура описывает отношения между элементами в примере XML. Он поддерживает вложенные или внутренние элементы с иерархической структурой.

История

XML появился как способ преодолеть недостатки двух своих предшественников — SGML и HTML. В конце 1980-х до появления Интернета издатели цифровых СМИ реализовали различные преимущества SGML для динамического отображения информации. Язык был чрезвычайно мощным и расширяемым инструментом для семантической разметки и особенно полезен для каталогизации и индексации данных. SGML и сегодня можно использовать для создания бесконечного количества языков разметки.

Однако SGML остается довольно сложным и дорогим, особенно для повседневного использования в интернете. Добавление возможности SGML к текстовому процессору удваивает или даже утраивает его цену. Наконец, коммерческие браузеры ясно дали понять, что они не намерены когда-либо поддерживать SGML.

Одним из самых популярных приложений SGML стало развитие языка разметки гипертекста HTML, созданного Тимом Бернерсом Ли в конце 1980-х. С момента своего развития HTML стал жертвой собственной популярности, так как он был быстро принят и расширен многими способами, выходящими за рамки его первоначального видения.

Он остается популярным и сегодня, хотя считается неподходящим в качестве формата хранения данных общего назначения в отличие от других языков. Пример: XML устраняет пробел, будучи удобочитаемым как для человека, так и для компьютера, и в то же время достаточно гибким для поддержки обмена данными, независимого от платформы и архитектуры. В 1998 году W3C одобрил версию 1.0 XML, таким образом, официально был создан новый язык.

Структура элементов

Существует два способа определить структуру XML-документа (определение типа данных (DTD) и схемы XML). Документы DTD были введены SGML. Они соответствуют расширенной форме Backus Naur (EBNF).

Документы схемы XML пишутся с использованием синтаксиса кода. Как DTD, так и XML-схема позволяет задавать правила ограничения. Они применяются к содержимому документов экземпляра этого же кода. Они принимают форму правил для проверки структуры XML.

Все XML-документы имеют один корневой элемент, который содержит подэлементы, их подэлементы и т. д. Это приводит к иерархической древовидной структуре в них.

Благодаря разработке через SGML определения типов документов больше подходят для приложений, ориентированных на документы, таких как HTML. В HTML используется DTD. Хотя он может определять структуру документа, но не может определять правила, которые должны применяться к данным. То есть все данные, содержащиеся в XML-документе, в DTD обрабатываются как строка. Это подходит для языков разметки. Но не подходит, когда приложению необходимо контролировать содержащиеся в нем данные.

Документ XML считается «правильно сформированным», то есть может быть прочитан и понят синтаксическим анализатором, если его формат соответствует спецификации XML и он правильно размечен. А элементы должным образом вложены. Код также поддерживает возможность определения атрибутов для элементов и описания характеристик в начальном теге. Документы могут быть очень простыми для XML, пример текста «Привет, мир!»:

Руководство по безопасности брандмауэра

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

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

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

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

Управление в SOA

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

Пример sitemap XML и нюансы использования демонстрирует возможности языка.

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

Формируя метаданные с использованием XML, а затем, создавая приложения XSLT для передачи их в компоненты SOA и из них, разработчики получают многочисленные преимущества:

  1. Они создают средства для захвата ключевых элементов данных, взаимодействий и семантики. Они облегчают перемещение их между компонентами SOA или между собой. Также документируют основные понятия и предположения относительно данных, которые они используют и необходимых метаданных.
  2. Четкие абстрактные представления потоков информации, которые передаются между компонентами и между собой (а также характер и масштаб этих потоков) дают возможность перенаправлять их по мере появления новых бизнес-потребностей и по мере того как новые производители и потребители объединяются в общей картине.
  3. Протоколы XML и обмена сообщениями, такие как SOAP, действительно упрощают абстрагирование данных и их перемещение. Но они также повышают важность того, где находятся данные, как они получают или сохраняют надлежащий контекст и как связать определенный синтаксис, семантику и проверку точности с реальной информацией, которую они представляют.

Процесс парсера

Одной из целей формата XML было улучшение форматов необработанных данных, таких как простой текст, путем включения подробных описаний значения содержимого. Теперь, чтобы иметь возможность читать XML-файлы, используют синтаксический анализатор. Он (в основном) предоставляет содержимое документа через так называемый API-интерфейс прикладного программирования. Другими словами, клиентское приложение получает доступ к содержимому XML-документа через интерфейс вместо того, чтобы интерпретировать код самостоятельно. Это можно продемонстрировать на примере parser JAVA XML.

Синтаксический анализатор кода анализирует правильно сформированный документ, встроенный в строковое поле и передает проанализированные данные в выходное поле записи.


При настройке анализатора XML пользователь указывает два поля. Первое содержит документ, второе — назначения для проанализированных результатов. Можно определить элемент разделителя. Это делается для того чтобы разделить документ на несколько значений. Если он не определен, XML Parser передает весь документ в целевое поле в виде карты.

При определении этого элемента можно использовать его или упрощенное выражение XPath. Используют элемент, когда он находится непосредственно под корневым узлом и упрощенное выражение XPath (для более глубокого доступа к данным в документе XML).

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

Можно настроить процессор так, чтобы XPath включался в каждый анализируемый элемент и XML в атрибутах полей. Это также помещает каждое пространство имен в атрибут заголовка записи xmlns. Еще можно настроить процессор на включение атрибутов и объявлений пространства имен в запись (как атрибут поля). По умолчанию он уже включает атрибуты XML и объявления пространства имен в виде полей.

При настройке анализатора XML указывают поле для анализа и поле вывода для использования. На панели «Свойства» на вкладке «Общие» настраивают свойства, представленные в таблице ниже.

Интеграция XML с реляционными данными и ADO.NET XML Integration with Relational Data and ADO.NET

Класс XmlDataDocument является производным от класса XmlDocument и содержит XML-данные. The XmlDataDocument class is a derived class of the XmlDocument, and contains XML data. Класс XmlDataDocument полезен тем, что он организует связь между реляционными и иерархическими данными. The advantage of the XmlDataDocument is that it provides a bridge between relational and hierarchical data. Этот класс XmlDocument можно привязать к объекту DataSet, после чего любые изменения их данных будут одновременно отображаться в обоих классах. It is an XmlDocument that can be bound to a DataSet and both classes can synchronize changes made to data contained in the two classes. Класс XmlDocument, привязанный к объекту DataSet, позволяет интегрировать XML-данные с реляционными данными, не преобразуя все данные в формат XML или в реляционный формат. An XmlDocument that is bound to a DataSet allows XML to integrate with relational data, and you do not have to have your data represented as either XML or in a relational format. Можно использовать оба формата, не ограничиваясь единым способом представления данных. You can do both and not be constrained to a single representation of the data.

Доступность двух представлений данных дает следующие преимущества. The benefits of having data available in two views are:

Структурированную часть XML-документа можно сопоставить с набором данных и эффективным образом хранить, индексировать и использовать в поиске. The structured portion of an XML document can be mapped to a dataset, and be efficiently stored, indexed, and searched.

В XML-данных, хранимых в реляционном формате, можно эффективно выполнять преобразования, проверку и навигацию с помощью модели курсора. Transformations, validation, and navigation can be done efficiently through a cursor model over the XML data that is stored relationally. Иногда в реляционных структурах эти операции выполняются более эффективно, чем для XML-данных, хранящихся в модели XmlDocument. At times, it can be done more efficiently against relational structures than if the XML is stored in an XmlDocument model.

Объект DataSet может хранить часть XML-документа. The DataSet can store a portion of the XML. Это значит, что с помощью XPath или XslTransform можно сохранять в объекте DataSet только нужные элементы и атрибуты. That is, you can use XPath or XslTransform to store to a DataSet only those elements and attributes of interest. Это позволяет внести изменения в отфильтрованный набор данных меньшего размера, а затем передать изменения в более крупный набор данных XmlDataDocument. From there, changes can be made to the smaller, filtered subset of data, with the changes propagating to the larger data in the XmlDataDocument.

Также вы можете преобразовать данные, загруженные в объект DataSet из SQL Server. You can also run a transform over data that was loaded into the DataSet from SQL Server. Есть и еще один вариант: привязать элементы управления WinForm и WebForm, управляемые классами платформы .NET Framework, к объекту DataSet, который заполнен из потока входных XML-данных. Another option is to bind .NET Framework classes-style-managed WinForm and WebForm controls to a DataSet that was populated from an XML input stream.

Помимо поддержки класса XslTransform, класс XmlDataDocument предоставляет доступ к реляционным данным для запросов XPath и проверки. In addition to supporting XslTransform, an XmlDataDocument exposes relational data to XPath queries and validation. Для реляционных данных, в основном, доступны все XML-службы, а реляционные средства, такие как привязка элементов управления, CodeGen и т. д., доступны с помощью структурированной проекции XML-данных без нарушения их точности. Basically, all XML services are available over relational data, and relational facilities, such as control binding, codegen, and so on, are available over a structured projection of XML without compromising XML fidelity.

Так как класс XmlDataDocument наследуется от класса XmlDocument, он содержит реализацию модели W3C DOM. Because XmlDataDocument is inherited from an XmlDocument, it provides an implementation of the W3C DOM. Тот факт, что класс XmlDataDocument связан с объектом DataSet и хранит в нем часть своих данных, ни в коей мере не ограничивает и не изменяет его использование в качестве класса XmlDocument. The fact that the XmlDataDocument is associated with, and stores a subset of its data within, a DataSet does not restrict or alter its use as an XmlDocument in any way. Код, написанный для обработки событий класса XmlDocument, работает с классом XmlDataDocument без изменений. Code written to consume an XmlDocument works unaltered against an XmlDataDocument. Объект DataSet обеспечивает реляционное представление тех же данных, определяя таблицы, столбцы, связи и ограничения, и является изолированным хранилищем пользовательских данных в памяти. The DataSet provides the relational view of the same data by defining tables, columns, relations, and constraints, and is a stand-alone, in-memory user data store.

Мастер Йода рекомендует:  Neurodata Lab LLC

На рисунке ниже показаны различные связи между XML-данными, объектом DataSet и классом XmlDataDocument. The following illustration shows the different associations that XML data has with the DataSet and XmlDataDocument:

На рисунке вы видите, что XML-данные можно загрузить непосредственно в объект DataSet, что позволяет использовать реляционные методы для работы с ними. The illustration shows that XML data can be loaded directly into a DataSet, which allows direct manipulation with XML in the relational manner. Также XML-данные можно загрузить в класс XmlDataDocument, производный от модели DOM, а затем загрузить в объект DataSet и синхронизировать. Or, the XML can be loaded into a derived class of the DOM, which is the XmlDataDocument, and subsequently loaded and synchronized with the DataSet. Поскольку объект DataSet и класс XmlDataDocument синхронизируются по одному набору данных, то все изменения в любом из этих хранилищ отражаются и в другом хранилище. Because the DataSet and XmlDataDocument are synchronized over a single set of data, changes made to the data in one store are reflected in the other store.

Класс XmlDataDocument наследует все возможности редактирования и навигации из класса XmlDocument. The XmlDataDocument inherits all the editing and navigational features from the XmlDocument. Бывают случаи, когда использование класса XmlDataDocument с его наследуемыми возможностями и синхронизация с объектом DataSet оказываются более предпочтительным вариантом, чем загрузка XML-данных непосредственно в объект DataSet. There are times when using the XmlDataDocument and its inherited features, synchronized with a DataSet, is a more appropriate option than loading XML directly into the DataSet. В следующей таблице перечислены аспекты, которые нужно учитывать при выборе метода загрузки для объекта DataSet. The following table shows the items to be considered when choosing which method to use to load the DataSet.

Причины для загрузки XML-данных непосредственно в объект DataSet When to load XML directly into a DataSet Причины для синхронизации класса XmlDataDocument с объектом DataSet When to synchronize an XmlDataDocument with a DataSet
Запросы к данным в объекте DataSet проще выполнять через SQL, чем через XPath. Queries of data in the DataSet are easier using SQL than XPath. Необходимо использовать запросы XPath к данным в объекте DataSet. XPath queries are needed over data in the DataSet.
Не обязательно сохранять порядок элементов в исходном XML-коде. Preservation of element ordering in the source XML is not critical. Важно сохранять порядок элементов в исходном XML-коде. Preservation of element ordering in the source XML is critical.
Не нужно сохранять пробелы между элементами и форматированием в исходном XML-коде. White space between elements and formatting does not need to be preserved in the source XML. Важно сохранять пробелы и форматирование в исходном XML-коде. White space and formatting preservation in the source XML is critical.

Если непосредственная загрузка XML-данных в объект и из объекта DataSet соответствует поставленным задачам, изучите документацию о загрузке DataSet из XML и записи DataSet в виде XML. If loading and writing XML directly into and out of a DataSet addresses your needs, see Loading a DataSet from XML and Writing a DataSet as XML Data.

Если нужно загружать данные в объект DataSet из класса XmlDataDocument, переходите к документу о синхронизации объекта DataSet с XML-документом. If loading the DataSet from an XmlDataDocument addresses your needs, see Synchronizing a Dataset with an XML Document.

Формат XML для Smartdevice. Создание и управление объектами ADO.NET

Существуют различные мнения относительно важности XML в разработке программного обеспечения. Компания Microsoft разработала собственную стратегию NET , направленную на использование XML и Web-служб в качестве «прослойки», обеспечивающей такое взаимодействие между компаниями, которое не зависит от использующихся в них операционных систем и механизмов хранения данных. Поскольку XML – это данные, a ADO . NET – механизм работы с данными в . NET , тот факт что ADO . NET поддерживает работу с XML -документами наравне с остальными данными, выглядит вполне естественно. В этом аспекте библиотека ADO . NET является тесно интегрированной с инфраструктурой XML . NET .

ADO . NET -стратегию Microsoft в отношении XML необходимо рассматривать с двух сторон: с одной стороны, Microsoft стремится предоставить те же инструменты для доступа к XML -содержимому, которые используются для доступа к информации, хранящейся в базе данных, с другой – обеспечить в ADO . NET средства преобразования информации базы данных в формат XML . Отметим, что название ADO . NET не совсем корректное, так как ADO . NET не является прямым «наследником» ADO .

Поскольку ADO . NET — всего лишь механизм работы с данными в . NET , то справедливым представляется утверждение, что XML представляет собой просто еще один формат данных.

Во времена ADO / OLE DB для обработки информации из некоего источника данных (например, базы данных ) необходимо было создать поставщик OLE DB, который довольно сложен и запутан (вспомните синтаксис ConnectionString разных поставщиков, рассмотренный в части 1). В . NET для доступа к информации из источника, отличного от базы данных , можно либо создать управляемый поставщик, либо воспользоваться преимуществами тесной интеграции ADO . NET с XML .

Ядро такой интеграции — класс DataSet . Можно загружать данные и схему из XML -потока или документа в объект DataSet и наоборот, перманентно сохранять или сериализовать данные или схему из объекта DataSet в XML -поток или документ. ADO синхронизирует объект DataSet с объектом XmlDataDocument . Данные можно модифицировать одновременно, используя любой из классов; все изменения, произведенные с помощью одного из классов, моментально отражаются в другом классе.

Эта глава посвящена поддержке XML в ADO . NET для карманных персональных компьютеров. Вынужден сразу оговориться, что также как и для текстовых форматов, так и для XML возможности использования ADO . NET реализованы для КПК не в полной мере по сравнению с настольными системами. Поддержка XML в . NET обеспечивается интегрированными классами в пяти пространствах имен:

  • System.Xml — содержит классы, обеспечивающие стандартизированную поддержку для обработки XML;
  • System.Xml.Schema — содержит классы, обеспечивающие стандартизированную поддержку схем на языке XML Schema Definition Language ( XSD );
  • System.Xml.Serialization — содержит классы, осуществляющие сериализацию объектов в XML-докумснты или потоки;
  • System.Xml. XPath — содержит классы, осуществляющие синтаксический разбор и вычисление XPath ;
  • System.Xml.Xsl — содержит классы, поддерживающие XSL — преобразования.

Чтобы описать модификацию, которые претерпел набор данных, Microsoft предложила XML –формат DiffGram, идентифицирующий текущую и исходную версии данных, позволяя точно воссоздавать содержимое набора данных. Этот формат, благодаря своей XML -сущности, независим от платформы и приложения, однако не имеет широкого употребления или средств интерпретации вне приложений Microsoft . NET [ [ 3 ] ]

Создание и управление объектами ADO.NET

Задача темы: изучить методику и получить навыки в разработке приложений для управления базами данных в гипертекстовом формате XML.

Разработка: Приложение » Привязка данных к элементам управления Windows» для просмотра данных XML в Windows-форме.

Состав выполняемых функций:

  • Файловые операции: открыть, сохранить, закрыть
  • Алгоритмы: просмотр и прокрутка записей базы в текстовых полях, списках и таблицах; просмотр отдельной записи
  • Информационно-справочные: нет

Наращивание функциональности не предусматривается.

Защита данных – нет.

В качестве входных данных используются программно сформированные объекты. Выходные данные программы – графическое отображение результатов в виде текстовых полей, списков и таблиц для SmartDevice.; файл DataSet.xml

Шаг 1. Разработка графического интерфейса

Графический интерфейс строится с использованием одной формы с надписью (label) » Привязка данных к элементам управления Windows-форм»; тремя кнопками: «Выход», «Заполнить» (изначально свойство Visible =True ), «Очистить» (кнопка совмещена с кнопкой «Заполнить и изначально свойство Visible =False , а при загруженных данных в элементы просмотра свойство меняется на Visible =True ), «Сохранить»; TabControl из трех закладок – примерный дизайн показан на рис.9.1, 9.2, 9.3.

Закладка TextBox содержит 4 надписи: «Сумма», «Цель», «Фирма», «Дата»; 5 полей, свойство одно из которых ReadOnly=True ; кнопку прокрутки записей «Next» — рис.9.1.

Закладка ListBox содержит 4 листбокса для вывода записей таблицы и кнопку просмотра идентификационного номера записи «Ключ ID» — рис.9.2

Закладка DataGrid содержит только элемент для просмотра таблиц DataGrid – рис. 9.3


Шаг 2. Расширяем состав библиотек

Добавляем библиотеки работы с файлами и с форматами XML

Формат XML — Что это и как его открыть?!

Файлик с расширением XML (формат XML) — это расширяемый язык разметки. Непонятно? — Вот и меня данное определение вводит в ступор, а обычного новичка (который пытается освоить компьютер) такой ответ не устраивает. В данной заметке я хочу вам рассказать — что же за формат такой XML и как его можно открыть (и для чего он нужен).

На самом деле XML — самый простой текстовый документ, структура которого может состоять из пользовательских тегов или других описаний документа.

Что такое формат XML

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

Если сравнить его с HTML, то в целом, задачи решают одинаковые, только в HTML все эти теги жестко прописаны и жирный будет определяться как , то в случае с XML мы можем сделать жирный как , т.е. разработчики сами определяют эти теги.

Фишка XML в том, что даже если вы не знаете в какой программе он сформирован, то беглым взглядом можно прочитать и осознать информацию, которая в нем содержится.

Как открыть XML файл

Если вы впервые столкнулись с XML… не расстраивайтесь, формат очень распространенный и, раз уже мы знаем что это текст, то и открывается он любым текстовым редактором (только не вздумайте открывать его в MS Office Word)

Способ 1. Лучший текстовый редактор — Notepad++

Если вы достаточно часто сталкиваетесь с XML в своей жизни, то у вас обязательно должен быть установлен Notepad++! Данный текстовый редактор имеет огромный функционал и подсветку синтаксиса, которая так необходима при просмотрел XML. Notepad++ показывает XML формат в максимально удобном и усвояемом обычным человеком виде.

Способ 2. Блокнот Windows

Если XML файл нужно отредактировать максимально быстро, то и самый простой блокнот сгодится. Кликните правой кнопкой мыши на файлике и в контекстном меню «Открыть с помощью…» и выберите в списке «Блокнот».

В обычном блокноте Windows, к сожалению, нет подсветки синтаксиса, что несколько затрудняет восприятие информации… но по быстрому подправить вполне сгодится.

Способ 3. Браузер

Если нет надобности в редактировании, то XML файл можно открыть только для чтения в любом браузере. Я использую браузер Яндекс, но можно использовать даже ненавистный многим Internet Explorer. Для этого кликните правой кнопкой по файлу и выберите пункт «Открыть с помощью», в списке найдите свой веб обозреватель…

Бывают такие ситуации, когда браузер попытается отобразить информацию согласно тегам… что нам совершенно не нужно — просто нажмите CTRL+ U для просмотра исходного кода документа.

Как можете видеть, браузер отображает более вменяемо информацию из XML файла в отличии от стандартного Блокнота.

Заключение

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

Интеграция XML данных — другой путь

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

XML как промежуточный формат обмена данными «оброс» экосистемой технологий и инструментов для работы с ним– специализированные редакторы, DOM-парсеры, XQUERY/XPATH, XSLT, специальные модули ETL и т. д. Все это многообразие и развитость инструментария идеологически приводят к тому, что у нас есть теперь технологии работы не просто с данными, а со специальными XML-данными. Это как отдельно «наука химия» и отдельно «наука химия для веществ, которые хранятся в синих коробках».

Описываемые далее принципы обработки позволили немножко «отмотать назад» условный прогресс технологий и перевести практически всю работу с XML данными на уровень «чистой» СУБД, без специфичного XML-инструментария. Такой подход дал возможность организовать унифицированное хранение любых XML-данных и обеспечить быстрый произвольный доступ к нужным частям информации. Кроме того, появилась возможность реализовывать ETL-функционал универсальным незатратным (практически без кодирования) способом.

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

Хорошим демо-кейсом для этой технологии могут служить открытые данные сервера госзакупок zakupki.gov.ru, доступные на соответствующем FTP: объём ежедневных обновлений – десятки и сотни тысяч XML файлов объемом в гигабайты или десятки гигабайт, в среднем раз в несколько недель выходит новая версия схемы данных.

Структура данных следует за требованиями законодательства, поэтому, например, информация об извещениях о проведении госзакупок представлена более чем десятком типов документов fcsNotification* в зависимости от типа закупки (электронный аукцион fcsNotificationEF, запрос котировок fcsNotificationZK, закупка у единственного поставщика fcsNotificationEP и т. п.)
Все эти документы основаны на одном базовом типе извещения но отличаются в деталях, поэтому для целей анализа все это многообразие при импорте надо в какой-то момент “схлопывать” и приводить к «единому знаменателю».

На данных госзакупок описываемый подход успешно применен и эффективно работает.

Кратко этапы/элементы описываемой технологии:

(1) Импорт всех XML данных в таблицу унифицированной структуры. Речь не идет о сохранении в базу документов целиком, мы импортируем данные поэлементно как пары “имя элемента” – “значение” или “имя атрибута” – “значение”. В результате данного этапа мы избавляемся от XML как формата хранения и получаем быстрый унифицированный доступ к данным всех импортированных XML-документов любой структуры (при этом нам больше не нужен XQUERY/XPATH).

(2) Вторым элементом технологии является создание спецификаций на “вытаскивание” нужных нам данных – выявление результирующих таблиц, в которые мы будем выливать данные, и маппинг полей источника и результата. Этот этап может быть проведен как на основе XSD-схем документов, так и без использования схем, через анализ закачанных на первом этапе образцов документов. Данный этап не требует никакого программирования и специальных навыков, основной инструментарий здесь – электронная таблица.

(3) Завершающие шаги – выборка нужной информации из первичного хранилища импорта (1) с помощью спецификаций (2), преобразование в “колоночное” представление (“пивотирование”) и автоматизированная трансформация в финальный “аналитический” формат – в терминах аналитических хранилищ данных это таблицы фактов структуры “звездочка” (star) со ссылками на справочники измерений (dimensions) и числовыми показателями-мерами (measures).

1. Первичный импорт.

Мы рассматриваем XML-документ как дерево, вершинами которого являются пары “имя”-“значение”. Таким образом, описываемый подход достаточно универсален и может быть применен к любому древовидному представлению данных.

Структура таблицы для загрузки данных из XML:

  • Record_ID: идентификатор элемента специального иерархического вида, позволяющий связывать друг с другом разные уровни документа
  • File_ID: поскольку в таблицу надо будет загружать содержимое множества XML-файлов, надо также хранить идентификатор файла
  • Path: полный путь к данному элементу начиная с корня документа (фактически, это XPATH-путь до данного элемента)
  • Element_Name: название элемента или атрибута
  • Element _Value: значение элемента или атрибута (в виде строки – так же, как оно хранится в XML)
  • Type: тип записи (элемент это или атрибут) – сохраним на всякий случай, вдруг потом надо будет из таблицы восстановить XML

Идея загрузки дерева в таблицу достаточно очевидная. В MS SQL (про другие СУБД не скажу, не смотрел) есть такая встроенная возможность –XML без указания схемы импортируется в так называемую EDGE-таблицу. Это не совсем то что нам нужно, т. к. в EDGE-формате хранятся отдельными записями имя элемента и его значение (то есть имя есть родительская запись для значения) – такой формат попросту неудобно использовать для дальнейших манипуляций. К тому же в EDGE таблице связи в дереве прописаны через указание ParentID.

Короче говоря, сделать нужное представление данных из EDGE таблицы можно, но придется немножко попотеть для “склеивания” названий и значений элементов, воссоздания XPATH до каждого элемента и создания иерархического идентификатора (о том, как мы его будем строить – чуть ниже). При большом объеме данных решение этих задач может оказаться довольно ресурсоемким, но зато можно обойтись единственным инструментом/языком.

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

Давайте посмотрим на конкретный пример. Есть у нас демо XML-файлы deliveries.xml и returns.xml. Файл deliveries.xml (доставки) содержит корневой элемент Deliveries, на верхнем уровне даты начала и окончания периода за который выгружены данные, дальше идут продукты с указанием названия и поставщика, по каждому продукту идет детализация информации доставок – дата, количество, цена.

Файл returns.xml (возвраты) абсолютно аналогичный, только корневой элемент называется Returns и в деталях элемент с датой по-другому называется.

Имена загруженных файлов хранятся в отдельной таблице, коды наших файлов там равны 2006 (deliveries) и 2007 (returns).

В нашей таблице-приемнике образ наших демо-документов будет выглядеть так:

Record_ID File_ID Path Element_Name Element_Value Type
001 2006 Deliveries E
001\001 2006 Deliveries\ PeriodBegin 2020-01-01 E
001\002 2006 Deliveries\ PeriodEnd 2020-01-31 E
001\003 2006 Deliveries\ Products E
001\003\001 2006 Deliveries\Products\ Product E
001\003\001\001 2006 Deliveries\Products\
Product\
Supplier Zaanse Snoepfabriek E
001\003\001\002 2006 Deliveries\Products\
Product\
ProductName Chocolade E
001\003\001\003 2006 Deliveries\Products\
Product\
Details E
001\003\001\003\
001
2006 Deliveries\Products\
Product\Details\
Detail E
001\003\001\003\
001\001
2006 Deliveries\Products\
Product\Details\Detail\
DeliveryDate 2020-01-03 E
001\003\001\003\
001\002
2006 Deliveries\Products\
Product\Details\Detail\
UnitPrice 10.2000 E
001\003\001\003\
001\003
2006 Deliveries\Products\
Product\Details\Detail\
Quantity 70 E

По поводу иерархического идентификатора Record_ID: его цель — уникально пронумеровать узлы дерева документа с сохранением информации о связях со всеми предками.

В приведенном примере мы используем простую платформенно-независимую реализацию c последовательной конкатенацией счетчиков элементов на каждом уровне дерева. Мы “добиваем” счетчик каждого уровня нулями до заданной фиксированной глубины, чтобы получить легкое и быстрое выделение идентификаторов предков любого уровня через выделение подстрок фиксированной длины.

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

Во многих случаях этого подхода будет вполне достаточно для эффективного хранения данных и организации доступа к ним, описанные далее “продвинутые” техники могут не понадобиться.

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

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

На следующих этапах мы рассмотрим трансформацию этих XML документов в единую структуру данных, содержащую 3 таблицы: MovementReports (тип движения – доставка или возврат, даты начала и окончания из корня документа), Products (название и поставщик) и MovementDetails (цена, количество, дата – поле даты в результате будет единое для обоих исходных документов, несмотря на то, что в исходных файлах поля по-разному называются)


2. Создание спецификаций трансформации в результирующие таблицы.

Рассмотрим процесс создания спецификаций на маппинг исходных данных и результирующих таблиц. Для создания таких спецификаций нам потребуется еще кое-что.

2.1. Получение таблички со структурой документов.

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

Если у нас нет XSD-схемы или мы не хотим с ней связываться, то нам может быть достаточно загрузить в нашу таблицу какую-то репрезентативную выборку образцов XML-документов и построить с помощью группировки по полям Path и Element_Name нужный нам список.

Однако не забывайте, что мы хотим в итоге загрузить информацию в некие целевые “финальные” таблицы, поэтому нам надо знать где в XML хранятся отношения один-ко-многим. То есть надо понять какие элементы формируют “дочернюю” таблицу, где происходит размножение.

Иногда, если схема документа не очень сложная, нам это сразу понятно эмпирически, “глазками”. Также при группировке данных нашей “репрезентативной выборки” мы можем посчитать количество элементов и увидеть по этой статистике где они начинают “размножаться”. Но в общем случае, если у нас есть нормальная XSD-схема, лучше воспользоваться ей – размножение данных один ко многим мы “поймаем”, выявив XSD конструкцию maxoccurs=unbounded.

Как видим, задача немного усложняется: хочется получить не только простую табличку, содержащую список XPATH-путей для всех элементов наших документов, но еще и с указанием того, где начинается размножение данных. (А при анализе хорошо прописанной XSD-схемы приятном бонусом могли бы получить возможность вытащить описания элементов и их типы.)

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

Во всех этих Oxygen, Altova, Liquid и менее навороченных нужная информация внутри, несомненно, используется – однако отдавать ее в нужном виде никто из них не умеет. Как правило, в продвинутом редакторе есть возможность генерировать Sample XML на основании схемы, но в XSD может быть конструкция choice, когда в документе может присутствовать что-то на выбор из нескольких разных элементов –тогда уж лучше реальные “боевые” образцы документов проанализировать. И еще — по образцу или образцам документов мы момент размножения информации один-ко-многим в явном виде тоже не поймаем.

В итоге пришлось изобретать велосипед и писать генератор такой таблички (фактически, парсер XSD специального вида) самостоятельно. Благо XSD это тоже XML, его можно так же загрузить в наше хранилище и реляционными операциями вытащить нужный вид. Если схема простая, без ссылок на сложные типы элементов и без наследования от базовых типов, то это достаточно просто. В случае, когда все это наследование типов в наличии (как в госзакупках, например), задача посложнее.

Path Element_Name maxoccurs
Deliveries\ PeriodBegin
Deliveries\ PeriodEnd
Deliveries\Products\Product\ ProductName Products\Product
Deliveries\Products\Product\ Supplier Products\Product
Deliveries\Products\Product\Details\Detail\ DeliveryDate Products\Product\Details\Detail
Deliveries\Products\Product\Details\Detail\ Quantity Products\Product\Details\Detail
Deliveries\Products\Product\Details\Detail\ UnitPrice Products\Product\Details\Detail
Returns\ PeriodBegin
Returns\ PeriodEnd
Returns\Products\Product\ ProductName Products\Product
Returns\Products\Product\ Supplier Products\Product
Returns\Products\Product\Details\Detail\ Quantity Products\Product\Details\Detail
Returns\Products\Product\Details\Detail\ ReturnDate Products\Product\Details\Detail
Returns\Products\Product\Details\Detail\ UnitPrice Products\Product\Details\Detail

2.2. Описание трансформации

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

Path Element_
Name
maxoccurs Target
Table
Target
Field
Element
Depth
Additional
Info
Deliveries\ PeriodBegin MovementReports PeriodBegin_Date 1 Deliveries
Deliveries\ PeriodEnd MovementReports PeriodEnd_Date 1 Deliveries
Deliveries\. \Product\ ProductName …\Product Products ProductName_Dim 3
Deliveries\. \Product\ Supplier …\Product Products Supplier_Dim 3
Deliveries\. \. \. \Detail\ DeliveryDate …\Detail MovementDetails MovementDate_Date 5
Deliveries\. \. \. \Detail\ Quantity …\Detail MovementDetails Quantity_Val 5
Deliveries\. \. \. \Detail\ UnitPrice …\Detail MovementDetails UnitPrice_Val 5
Returns\ PeriodBegin MovementReports PeriodBegin_Date 1 Returns
Returns\ PeriodEnd MovementReports PeriodEnd_Date 1 Returns
Returns\. \Product\ ProductName …\Product Products ProductName_Dim 3
Returns\. \Product\ Supplier …\Product Products Supplier_Dim 3
Returns\. \. \. \Detail\ Quantity …\Detail MovementDetails MovementDate_Date 5
Returns\. \. \. \Detail\ ReturnDate …\Detail MovementDetails Quantity_Val 5
Returns\. \. \. \Detail\ UnitPrice …\Detail MovementDetails UnitPrice_Val 5

Вот какие поля мы добавили:

    Имя целевой таблицы TargetTable. Обратите внимание, что мы учитываем информацию о размножении один-ко-многим (столбец maxoccurs) для определения, в какую таблицу какие данные заливать.

Имя поля целевой таблицы TargetField. Мы далее используем подход сonvention over configuration и будем присваивать суффикс _Dim для полей, которые станут справочниками-измерениями (dimensions), суффикс _Date для полей дат и суффикс _Val для числовых полей- мер (measures). На следующих этапах процесса соответствующие утилиты по суффиксу поймут что делать с данным полем – строить и обновлять нужный справочник или преобразовывать значение в соответствующий формат.

Эффективная глубина вложенности элементов ElementDepth. Нам надо будет для последующих трансформаций сохранить единый код записи целевой таблицы на базе содержимого полей Record_ID и File_ID. В XML глубина элементов может быть разной, но попадать они должны будут в одну целевую таблицу, поэтому мы указываем, какую часть иерархического кода Record_ID нам надо сохранить, отбросив ненужный нам остаток. Благодаря фиксированной длине каждого сегмента иерархического кода, это будет достаточно “дешевая” операция выделения подстрок длины [Количество символов на сегмент кода]* ElementDepth.

  • Дополнительная информация AdditionalInfo. В результате нашей трансформации мы перегрузим исходные данные в разбивке по целевым таблицам в похожую структуру с новыми названиями полей, однако в некоторых местах нам надо будет сохранить важную информацию о том, из какого именно XPATH-пути мы брали исходные данные.
  • Эта техника открывает несколько интересных возможностей манипуляции трансформацией данных. Не углубляясь в детали, просто перечислим что мы можем сделать:

      Если у нас есть несколько исходных схем кодирования XML-данных (например, “старая” схема госзакупок по 95 ФЗ и “новая” по 44 ФЗ), мы можем на этапе описания трансформации привести их к единой структуре данных через унификацию названий полей.

    Можем, как упоминалось ранее, “схлопнуть” разные разделы в рамках одной или нескольких схем документов в единую, более компактную структуру хранения, как мы это делаем в нашем примере.

  • Можно также “схлопнуть” в единообразное представление данные разной глубины. Например, если брать схемы извещений о проведении госзакупок, то в разных схемах информация о лотах закупки может лежать “по адресу” \lot для однолотовых закупок (единственный элемент) и \lots\lot для многолотовых закупок (размножение). С помощью данного подхода можно достаточно просто весь этот зоопарк замаппить в единую таблицу информации о лотах.
  • После того, как наша табличка со спецификацией трансформации готова, мы загружаем ее в базу данных и джойним с нашим первичным хранилищем по полям Path и Element_Name.

    Конкатенацией File_ID, “обрезанного” в соответствии с ElementDepth значения поля Record_ID и значения AdditionalInfo формируем композитный ключ нашей целевой таблицы.

    Результат джойна выливаем для каждой целевой таблицы в отдельную “временную” таблицу (в зависимости от объема данных можно попробовать использовать результат запроса “ на лету ”), на следующем этапе с этими таблицами будут работать завершающие утилиты нашего “конвейера”.

    • До выливки мы имеем набор данных на уровне отдельных полей (элементов). Для того, чтобы соединить поля в записи результирующей таблицы, нам нужно иметь какой-то ключ, который будет однозначно идентифицировать запись целевой таблицы, в которую попадут соответствующие поля.
    • Иерархический идентификатор Record_ID может быть разной длины, в зависимости от “глубины залегания” отдельных элементов в схеме документа. Однако, если углубление уровня не сопровождается размножением элементов один-ко-многим, мы обрезаем наш Record_ID до минимальной достаточной глубины, определенной параметром ElementDepth, что обеспечит нам одинаковость идентификатора для всех полей нашей целевой таблицы. В наших демо-документах такой ситуации нет, но представьте, к примеру, что наш UnitPrice “разветвлялся” бы на 2 значения – оптовую и розничную цены UnitPrice\Retail и UnitPrice\Wholesale.
    • Поскольку в нашем базовом хранилище лежит содержимое множества файлов, в нашем ключе без значения File_ID не обойтись.
    • Следующие этапы преобразования данных работают только с полученными на данном шаге “трансформированными” таблицами, никакой сквозной системы настроек у нас нет. Тип поля (dimension/measure) мы передаем через суффиксы названий, но иногда нам надо передать “по цепочке” еще и информацию о том, в каком именно разделе документа мы брали информацию (помним, что мы можем трансформировать в одинаковый вид документы, закодированные разными схемами). Для передачи на следующий этап преобразования этой информации мы используем необязательный параметр нашей трансформации AdditionalInfo, “подцепив” его к нашему композитному ключу так, чтобы не нарушилась нужная нам идентификация целевых записей.

    Посмотрим, что получилось на выходе в нашем примере:

    MovementReports:

    KEY TargetField Element_Value
    001;2006@Deliveries PeriodBegin_Date 2020-01-01
    001;2006@Deliveries PeriodEnd_Date 2020-01-31
    001;2007@Returns PeriodBegin_Date 2020-02-01
    001;2007@Returns PeriodEnd_Date 2020-02-28

    Products:

    KEY TargetField Element_Value
    001\003\001;2006 Supplier_Dim Zaanse Snoepfabriek
    001\003\001;2006 ProductName_Dim Chocolade
    001\003\002;2006 Supplier_Dim Mayumis
    001\003\002;2006 ProductName_Dim Tofu
    001\003\001;2007 Supplier_Dim Pavlova, Ltd.
    001\003\001;2007 ProductName_Dim Pavlova
    001\003\002;2007 Supplier_Dim Formaggi Fortini s.r.l.
    001\003\002;2007 ProductName_Dim Mozzarella di Giovanni

    MovementDetails:

    KEY TargetField Element_Value
    001\003\001\003\001;2006 MovementDate_Date 2020-01-03
    001\003\001\003\001;2006 UnitPrice_Val 10.2000
    001\003\001\003\001;2006 Quantity_Val 70
    001\003\002\003\001;2006 MovementDate_Date 2020-01-09
    001\003\002\003\001;2006 UnitPrice_Val 18.6000
    001\003\002\003\001;2006 Quantity_Val 12
    001\003\002\003\002;2006 MovementDate_Date 2020-01-13
    001\003\002\003\002;2006 UnitPrice_Val 18.7000
    001\003\002\003\002;2006 Quantity_Val 20
    001\003\001\003\001;2007 MovementDate_Date 2020-02-21
    001\003\001\003\001;2007 UnitPrice_Val 13.9000
    001\003\001\003\001;2007 Quantity_Val 2
    001\003\002\003\001;2007 MovementDate_Date 2020-02-27
    001\003\002\003\001;2007 UnitPrice_Val 27.8000
    001\003\002\003\001;2007 Quantity_Val 4

    Обратите внимание – полученный ключ одинаков для всех полей, которые войдут в соответствующие записи наших целевых таблиц.

    3. Финальная обработка.

    3.1. Пивотирование

    Получив в результате предыдущей трансформации “заготовку” целевой таблицы с исходными данными, разбитыми на тройки — — , мы должны перевести ее в более привычный вид таблицы со множеством полей. Алгоритм этого преобразования очевиден – сначала группировкой значений нашего композитного ключа получаем “скелет” таблицы, потом осуществляем джойны этого “скелета” с таблицей-результатом трансформации по значению композитного ключа. (“Наращиваем мясо”, так сказать.)

    То есть получится N соединений “скелета” с подмножествами таблицы- результата трансформации, выделенными по именам полей, где N- количество названий полей в целевой таблице-результате трансформации.

    Мы благополучно “донесли” поле AdditionalInfo до данной стадии, закодировав его внутри композитного ключа. Теперь надо освободить наш ключ от этой “обузы” и отрезать AdditionalInfo-часть в новое поле AdditionalInfo_Dim.

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

    В итоге получатся такие вот

    MovementReports:

    Record_ID File_ID AdditionalInfo_Dim PeriodBegin_Date PeriodEnd_Date
    001 2006 Deliveries 2020-01-01 2020-01-31
    001 2007 Returns 2020-02-01 2020-02-28

    Products:

    Record_ID File_ID Supplier_Dim ProductName_Dim
    001\003\001 2006 Zaanse Snoepfabriek Chocolade
    001\003\002 2006 Mayumis Tofu
    001\003\001 2007 Pavlova, Ltd. Pavlova
    001\003\002 2007 Formaggi Fortini s.r.l. Mozzarella di Giovanni

    MovementDetails:

    Record_ID File_ID MovementDate_Date UnitPrice_Val Quantity_Val
    001\003\001\003\001 2006 2020-01-03 10.2000 70
    001\003\001\003\001 2007 2020-02-21 13.9000 2
    001\003\002\003\001 2006 2020-01-09 18.6000 12
    001\003\002\003\001 2007 2020-02-27 27.8000 4
    001\003\002\003\002 2006 2020-01-13 18.7000 20


    3.2. Нормализация

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

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

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

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

    В заключение описания процесса

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

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

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

    Вся информация у нас сохранена и доступна в нашем “первичном” табличном хранилище, поэтому заново парсить исходники не придется.

    Можно прописать маппинг полей для «маленькой» трансформации данных – только для нужного нам пропущенного фрагмента. После того как мы “вытащим” недостающий кусок данных, мы сможем достаточно легко “подцепить” его к основному обработанному массиву через связку по иерархическому идентификатору.

    Выводы

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

    В процессе дальнейшей обработки ни одно животное не пострадало не возникло необходимости в создании или модификации каких-либо скриптов или объектов типа ETL task, специфичных для структуры исходных XML-файлов.

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

    Синтаксис и основные понятия языка XML, создание валидных документов

    Понятие о языке XML

    XML — это расширяемый язык разметки (Extensible Markup Language), разработанный специально для размещения информации в World Wide Web, наряду с HTML, который давно стал стандартным языком создания Web-страниц. В отличие от HTML, вместо использования ограниченного набора определённых элементов вы имеете возможность создавать ваши собственные элементы и присваивать им любые имена по вашему выбору. Примечание: подразумевается, что читатель данной статьи хотя бы очень поверхностно знаком с языком HTML.

    XML решает ряд проблем, которые не решает HTML, например:

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

    В зависимости от уровня соответствия стандартам документ может быть «верно сформированным» («well-formed»), либо «валидным» («valid»). Вот несколько основных правил создания верно сформированного документа:

    • Каждый элемент XML должен содержать начальный и конечный тэг (либо пустой тэг типа , который может нести информацию посредством своих атрибутов).
    • Любой вложенный элемент должен быть полностью определён внутри элемента, в состав которого он входит.
    • Документ должен иметь только один элемент верхнего уровня.
    • Имена элементов чувствительны к регистру.

    Есть три основных способа сообщить браузеру, как отображать каждый из созданных вами XML-элементов:

    • Каскадная таблица стилей (Cascading Style Sheet — CSS) или расширяемая таблица в формате языка стилевых таблиц (Extensible Stylesheet Language — XSL).
    • Связывание данных. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и установления взаимодействий HTML-элементов с элементами XML. В дальнейшем HTML-элементы автоматически отображают информацию из связанных с ними XML-элементов.
    • Написание сценария. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и получение доступа к XML-элементам с помощью кода сценария JavaScript или VBScript.

    Индивидуальный пользователь, компания или комитет по стандартам может определить необходимый набор элементов XML и структуру документа, которые будут применяться для особого класса документов. Подобный набор элементов и описание структуры документа называют XML-приложением или XML-словарём.

    XML-приложение обычно определяется созданием описателя типа документа (DTD), который является допустимым компонентом XML-документа. DTD устанавливает и определяет имена элементов, которые могут быть использованы в документе, порядок, в котором элементы могут появляться, и доступные к применению атрибуты элементов. DTD обычно включается в XML-документ и ограничивает круг элементов и структур, которые будут использоваться. Примечание: приложение XML Schema позволяет разрабатывать подробные схемы для ваших XML-документов с использованием стандартного синтаксиса XML и является альтернативой DTD.

    Простейший XML-документ

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

    • Объявление типа документа.
    • Одну или несколько инструкций по обработке.

    XML-документ может содержать комментарии, начинающиеся с символов » «. Комментарий может содержать любой текст, за исключением символов «—«. Тексты комментариев доступны для написанного внутри HTML-страницы кода сценария.

    XML-документ можно набрать в любом текстовом редакторе, сохранив документ как текстовый файл с расширением .xml. В дальнейшем такой документ будет открываться двойным щелчком в Internet Explorer. Вот пример простейшего XML-документа:

    Технология Клиент-Сервер 2001’2
    Home Поиск Издания Контакты k-press.ru

    ADO.NET (ActiveX Data Object.NET) – набор классов, используемый для доступа к источникам данных в платформе .NET. Название ADO.NET означает, что данный набор классов – это логическое развитие предыдущей объектной модели доступа к данным – ADO. Но ADO.NET не просто следующая версия ADO. ADO.NET представляет собой новую объектную модель, которая использует стандарт XML для передачи данных. ADO.Net развивает идею использования отсоединенных массивов данных, переводя ее из разряда дополнительных возможностей в разряд реально используемых, более того – основных способов работы. По сравнению с ADO, ADO.NET обещает более легкое программирование, лучшую производительность и масштабирование, меньшую зависимость от особенностей источников данных и большую способность взаимодействовать с другими платформами.

    В этой статье будет рассмотрено применение ADO.NET для доступа к данным из сценариев ASP.NET. Сначала будет рассмотрена объектная модель ADO.NET, затем наиболее часто употребляемые объекты DataSet и DataReader и поставщики данных, которые применяются для связи с источниками данных. И в конце статьи будут приведены несколько интересных примеров применения ADO.NET в ASP.NET-приложениях.

    Объектная модель ADO.NET

    Примерную объектную модель ADO.NET можно представить следующей диаграммой:

    В предыдущих версиях ADO основным объектом для работы с данными был объект Recordset, хранящий результат выполнения запроса – набор строк и колонок. Хотя ADO и позволял создавать отсоединенные наборы данных, это не было его основной задачей. Он был предназначен для работы с данными, использующей постоянное соединение с источником данных.

    В ADO.NET все изменилось. Теперь ключевой объект, который хранит данные в ADO.NET – DataSet. Это экземпляр CLR-класса System.Data.DataSet, представляющий моментальный снимок части базы данных, размещенный в памяти.

    В ADO объект Recordset использует другие объекты ADO для соединения с источником данных. DataSet – независимый от источника данных объект, который не имеет собственных средств для работы с источниками данных. Связующую роль между DataSet и источником данных в ADO.NET выполняют управляемые (managed) провайдеры. Каждый управляемый провайдер представляет набор объектов, с помощью которых можно подключиться к источнику данных, считать данные и заполнить ими DataSet. Это позволяет DataSet не знать ничего про соединения с источниками данных.

    Преимущества ADO.NET

    ADO.NET создан для использования в управляемых (managed) проектах. Старый ADO основан на технологии COM и при использовании из управляемых приложений требует дополнительных затрат на выполнение прокси-кода. К тому же ADO имеет меньшие возможности при работе с отключенными наборами данных и XML. Например, в ADO было непросто сохранить изменения, произведенные в отключенном курсоре. Вот некоторые преимущества ADO.NET в сравнении с ADO:

    Масштабируемость

    При использовании DataSet работа происходит с отсоединенными наборами данных. Это означает, что вы используете соединение с источником данных очень короткое время. Во многих системах количество подключений к базам данных является самым узким местом в плане масштабируемости. И для этих систем ADO.NET является очень хорошим решением, резко повышающим их масштабируемость. Отключенный набор данных может использоваться несколькими частями программы (или пользователями) одновременно.

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

    В ADO возможности объекта Recordset сильно зависели от используемого источника данных. Хотя теоретически ADO обеспечивал доступ к данным независимо от источника данных, на практике всегда необходимо было иметь хорошее представление о возможностях провайдера. В ADO.NET DataSet действительно независим от источника данных, и изменение провайдера, с помощью которого заполняется DataSet, не влияет на функциональность DataSet-а. А то, что данные читаются целиком или последовательно, снижает планку требований, предъявляемых к провайдеру. Так что в большинстве случаев изменение кода будет состоять в изменении используемого управляемого провайдера данных и строки подключения.

    Способность к взаимодействию

    Так как ADO.NET использует XML как стандартный формат передачи данных, программа, которой необходимо получить данные из компонента ADO.NET, не обязана сама быть компонентом ADO.NET. В общем случае она вообще может не быть Windows-программой. Единственное требование – эта программа должна понимать XML. И это позволяет ADO.NET-компонентам при использовании других компонентов и сервисов, входящих в VS.Net, легко взаимодействовать с любой программой на любой платформе.

    Последние версии ADO также могли представлять данные в виде XML, но это представление было основано на специально разработанной схеме данных, применяемой только для представления объектов Recordset. В ADO.NET поддержка XML более гибка.

    Типизированные поля

    В ADO из-за того, что нужно было обеспечить работу и в скриптовых языках, работа со значениями ячейки шла через тип Variant. И это вызывало некоторое количество проблем – компилятор не имел возможности выполнения проверки на совместимость типов, переменная типа Variant занимала лишнюю память и медленнее обрабатывалась. В последних версиях ADO был добавлен интерфейс IADORecordBinding, позволявший решить эту проблему, но доступен он был только для C++-разработчиков. ADO.NET снимает это ограничение. Теперь данные колонки можно без конвертаций считать в переменную необходимого типа. Стало возможным также создавать классы, производные от DataSet. Такие классы реализуют свойства, сходные с колонками DataSet-а и позволяют осуществлять строго типизированный доступ к полям DataSet-а. При этом можно пользоваться такими функциями среды, как CompleteWord. Генерацию строго типизированных DataSet-ов можно возложить на IDE.

    Брандмауэры

    Так как ADO.NET передает данные с помощью XML – есть возможность передавать эти данные через основную массу брандмауэров. При работе с ADO брандмауэры являлись большой проблемой, так как основная их масса не настроена на пропуск COM пакетов.


    Название свойства

    Описание свойства

    Тип элемента коллекции

    Описание свойства

    Возвращает коллекцию строк таблицы

    DataRow

    Содержит все значения одной строки таблицы

    Columns

    Возвращает коллекцию колонок таблицы

    DataColumn

    Содержит информацию о столбце таблицы (имя, тип данных, и т.д.)

    Constraints

    Возвращает коллекцию описаний ограничений таблицы

    Constraint

    Содержит информацию об ограничении таблицы

    ParentRelations

    Возвращает коллекцию связей таблицы

    DataRelation

    Содержит информацию о связи с другой таблицей

    ChildRelations

    Объекты для работы с данными

    DataSet

    DataSet хранит в себе набор таблиц (считанных полностью или частично из БД) с дополнительной информацией об их структуре и отношениях между ними. Такой подход позволяет более компактно представлять выбранные из источника данные. DataSet предоставляет объектную модель, которая позволяет получить доступ к его внутренним таблицам, их строкам, ячейкам и отношениям между таблицами. С помощью объектов ADO.Net, относящихся к провайдеру, можно выполнять запросы к БД и заполнять таблицы объекта DataSet.

    Основную нагрузку по хранению и обработке данных в DataSet несет на себе коллекция DataTableCollection Tables, содержащая объекты типа DataTable. В объекте DataTable хранятся данные одной таблицы DataSet-а. DataTable в свою очередь содержит несколько коллекций, описывающих хранимую таблицу. В таблице 1 приведено описание свойств, позволяющих получить доступ к этим коллекциям.

    Управляемые провайдеры (managed providers)

    Раньше, до появления ADO.NET, ADO был надстройкой над OLE DB. Это означало, что при подключении к источнику данных с помощью ADO на самом деле вся работа выполнялась OLE DB. COM-природа OLE DB приводит к тому, что управляемое приложение вынуждено использовать прокси для взаимодействия с провайдером. По всей видимости, чтобы избежать неоправданных накладных расходов, разработчики Microsoft решили кроме поддержки OLE DB-провайдеров ввести прямые, так называемые (managed) управляемые провайдеры. Управляемый провайдер может использовать более низкоуровневые API, нежели OLE DB, специфичные для конкретного источника данных. Это позволяет производить необходимую обработку данных сразу в управляемом коде, не тратя времени на прокси-вызовы.

    Управляемый провайдер данных – это набор объектов ADO.NET, разработанных для соединения с определенным источником данных. Все провайдеры обеспечивают одинаковый набор базовых методов и свойств, скрывая в своей реализации всю работу с API доступа к источнику данных. Необходимо только знать, какой управляемый провайдер должен использоваться в конкретном случае.

    Текущая доступная версия .NET Framework (beta 2) представляет два управляемых провайдера:

    • Управляемый провайдер SQL для доступа к данным, расположенным на серверах баз данных Microsoft SQL Server 7 и выше (SqlConnection)
    • Управляемый провайдер для доступа к данным через OLE DB (OleDbConnection). Его можно использовать для доступа к базам данных Access и Oracle, Active Directory, каталогам LDAP и другим источникам, поддерживающим OLE DB или ODBC.

    При использовании SQL провайдера используются объекты SqlConnection, SqlCommand, SqlDataReader и SqlDataAdapter (эти объекты находятся в пространстве имен System.Data.SqlClient). Если же вы работаете с провайдером для OLE DB, то соответственно необходимо использовать объекты OleDbConnection, OleDbCommand, OleDbDataReader и OleDbDataAdapter (пространство имен System.Data.OleDb).

    Почему Microsoft вообще не отказалась от использования OLE DB? Все очень просто – провайдеры тяжелы в реализации, а для OLE DB и ODBC создано много провайдеров и драйверов.

    DataReader

    Использование DataSet оправдано, если необходимо передать данные в формате XML на другой компьютер, например, для их отображения и редактирования или дополнительной обработки. Использование DataSet также оправдано, если необходимо вывести данные в гриде или подключить к полям формы. Если же необходимые данные используются непосредственно там, где они запрашивались, и нужно всего лишь перебрать их по очереди, лучше воспользоваться объектом типа DataReader (SqlDataReader или OleDbDataReader).

    Объект DataReader очень похож на forward-only read-only Recordset в ADO. Данный объект считывает одну запись из источника данных (с помощью метода Read()) за одно обращение и позволяет получить доступ к содержимому записи. Его имеет смысл применять в случае, если надо просто прочитать данные из источника данных и выполнить с ними какие-либо действия (например, вывести на ASP-страницу).

    Примеры работы с ADO.NET

    Теперь посмотрим на применение ADO.NET на практике. Мы рассмотрим примеры нескольких способов чтения данных из базы данных и их изменения. В качестве базы данных будет использоваться Pubs – демонстрационная база данных, входящая в состав поставки MS SQL. В примерах будут использоваться управляемый провайдер SQL. Полученный результат будет отображаться с помощью элемента управления asp:DataGrid. Новая версия ASP – ASP.Net позволяет работать с элементами Web-страницы как с элементами пользовательского интерфейса, размещенными на форме VB. asp:DataGrid – это один из новых компонентов, позволяющих упростить разработку Web-страниц.

    Чтение данных в DataSet

    Итак, первое ADO.NET приложение. В первом примере мы выведем на страницу содержимое таблицы Authors. Код страницы, выполняющий данное действие, приведен ниже:

    Если запустить эту страницу под отладчиком или открыть в броузере, мы получим результат, подобный изображенному на рисунке 2.

    Обратите внимание на функцию Page_Load, в которой и выполняется весь наш код. В ней создается экземпляр объекта SqlConnection, представляющий собой подключение к источнику данных. В конструкторе этого объекта передается строка подключения к нужной базе данных. Затем создается экземпляр объекта SqlDataAdapter, играющий роль связующего звена между провайдером источника данных и объектом DataSet. В конструкторе этого объекта передаются SQL-запрос к базе данных и ранее созданный объект SqlConnection. Затем создается экземпляр DataSet, и с помощью метода Fill объекта SqldataAdapter заполняется необходимыми данными. Полученный DataSet связывается с элементом управления DataGrid. На этом создание простейшей страницы для вывода данных с помощью объекта DataSet закончено. Первая ADO.NET-страница готова. (Работа с DataGrid будет рассмотрена далее в этой статье в разделе «Связывание данных с элементами web-формы»).

    Чтение данных. DataReader.

    Теперь рассмотрим вопрос о доступе к данным с помощью объекта DataReader. Как уже говорилось ранее, DataReader создает forward-only read-only курсор, хорошо знакомый всем программистам, когда-либо использовавшим ADO. DataReader читает одну запись из источника данных за раз.

    В примере будет показан способ чтения данных из таблицы jobs из базы Pubs и вывода прочитанных данных в ListBox. Код страницы, выполняющей это действие, приведен ниже:

    Примерный результат выполнения этой страницы вы можете увидеть здесь:

    Рисунок 3. Вывод результатов запроса с помощью DataReader.

    Весь код опять-таки выполняется в методе Page_Load. Как и в предыдущем примере, создается экземпляр объекта SqlConnection со строкой подключения к базе. Затем создается экземпляр объекта SqlCommand (а не SqlDataSetCommand, как в прошлом примере). Открывается соединение с базой данных (myConn.Open()) и вызывается метод ExecuteReader объекта SqlCommand, который возвращает экземпляр объекта SqlDataReader. После этого в цикле осуществляется проход по полученному myReader, и в ListBox добавляются значения, полученные из базы данных. В конце соединение с базой данных закрывается.

    Код для отображения текста/значения выбранного элемента ListBox добавлен только для проверки.

    Этот код приведен только для примера применения объекта DataReader. Намного эффективнее было бы, конечно же, заполнить DataSet и связать его с ListBox. Как уже упоминалось ранее, вопрос связывания данных с элементами управления на web-странице мы рассмотрим позже.

    Чтение данных. Получение результатов выполнения хранимых процедур

    В предыдущих примерах было описано получение результатов запросов select и их вывод на web-страницу. Но это не единственный способ получения каких-либо результатов от источника данных. Сейчас мы обратимся к работе с хранимыми процедурами – вызову хранимых процедур, передаче и возврату параметров в хранимых процедурах, а также возврату наборов записей из хранимых процедур с помощью ADO.NET.

    Для начала рассмотрим вызов хранимой процедуры с передачей в нее параметров, и получение значения, возвращаемого хранимой процедурой с помощью оператора return. Для этого в базу pubs необходимо добавить следующую хранимую процедуру:


    Эта процедура возвращает количество авторов с активным контрактом, проживающих в указанном штате.

    Теперь напишем ASP.NET-страницу, которая позволит нам вызвать эту процедуру. Ее код приведен ниже:

    Результат выполнения хранимой процедуры при введенном в поле «Штат» значении “CA” (без кавычек) вы можете увидеть здесь (Рисунок 4):

    Весь полезный код выполняется в методе SubmitBtn_Click. В нем вызывается хранимая процедура, ей передаются параметры, и возвращаемое значение выводится на страницу. Итак, как обычно создается экземпляр объекта SqlConnection для подключения к базе данных. Затем создается экземпляр объекта SqlCommand, и ему передается имя вызываемой хранимой процедуры. Для передачи параметров используется свойство Parameters объекта SqlCommand, представляющее собой коллекцию объектов SqlParameter. Эта коллекция предназначена для определения всех параметров хранимой процедуры (входных, выходных и возвращаемого значения). С помощью метода Add этой коллекции в хранимую процедуру добавляются 2 параметра – @state (входной параметр) и RETURN_VALUE (параметр, через который будет возвращаться результат выполнения хранимой процедуры). Для параметра @state устанавливается значение, введенное в поле ввода, а для RETURN_VALUE устанавливается Direction в ParameterDirection.ReturnValue. Также необходимо установить CommandType у объекта SqlCommand в CommandType.StoredProcedure. Затем для реального вызова хранимой процедуры открывается соединение с источником данных, исполняется запрос (с помощью метода ExecuteNonQuery()), вернувшееся значение записывается в Label и соединение закрывается. Создание страницы для вызова хранимой процедуры завершено.

    Чтение данных. Получение набора записей из хранимой процедуры

    Последним примером, связанным с получением данных из источника, будет вызов хранимой процедуры, возвращающей набор данных. Для этого будет вызываться хранимая процедура reptg4 – немного измененный вариант хранимой процедуры reptg3 из базы pubs. Для отображения данных будет использоваться уже знакомая связка объектов SqlDataAdapter-DataSet.

    Страница из примера будет искать книги с ценой, лежащей в пределах MinPrice – MaxPrice и входящих в категорию Type или в категорию, название которой содержит в себе слово “cook».

    Вначале представлен текст хранимой процедуры, которую необходимо добавить в базу pubs:

    Рассмотрим нашу страницу. Во-первых, мы должны были обеспечить возможность передачи параметров в хранимую процедуру. Для этой цели мы разместили на странице текстовые поля tbMinPrice и tbMaxPrice и выпадающий список ccType, предназначенные соответственно для ввода значений минимальной и максимальной цены, и выбора типа книги. Мы также поместили элемент DataGrid для вывода полученных результатов.

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

    Объект SqlDataAdapter имеет свойства SelectCommand, InsertCommand, UpdateCommand и DeleteCommand, имеющие тип SqlCommand. Пример работы с объектом SqlCommand уже был рассмотрен ранее. Более подробно работу с этими свойствами мы рассмотрим немного позднее, а сейчас только посмотрим, каким образом мы можем вызвать хранимую процедуру и передать ей параметры.

    Итак, после создания объекта SqlDataAdapter необходимо изменить тип SelectCommand на CommandType.StoredProcedure и потом, как и в предыдущем примере, заполнить коллекцию Parameters этого объекта для передачи параметров в хранимую процедуру. После передачи всех параметров необходимо (как и в первом примере с использованием DataSet) вызвать метод Fill для заполнения DataSet результатами выполнения хранимой процедуры. Связывание DataSet с DataGrid выводит полученный результат на страницу.

    Изменение данных. Простые примеры

    Мы рассмотрели вопрос вызова SELECT запросов с помощью объекта SqlCommand. Очень часто вы будете применять этот объект и для изменения данных – для выполнения одиночных SQL команд INSERT, UPDATE или DELETE, или вызова хранимых процедур, производящих изменения в базе данных. Далее будет кратко рассмотрен пример страницы, производящей такие изменения в таблице jobs базы pubs. Вначале в таблицу будет добавлена новая запись, потом эта запись будет изменена и затем удалена. Добавление будет сделано с помощью конструируемого запроса INSERT, обновление — с помощью параметризированного запроса, а удалена запись будет вызовом хранимой процедуры без параметров. После каждой операции в DataGrid на страницу будут выводиться текущие данные таблицы jobs.

    Код процедуры удаления:

    Весь код, выполняющий обработку данных, находится в методе Page_OnLoad. При первом запуске данной страницы выполняется вызов хранимой процедуры delJobs, которая удаляет все ранее введенные нами jobs. Затем, в зависимости от значения ViewState[«currStep”] (переменной, в которой сохраняется текущий шаг страницы – добавление, изменение или удаление) выполняются соответствующие действия. Рассмотрим их более подробно.

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

    Обновление данных. Для обновления используется команда UPDATE с параметрами. Затем, как и при работе с хранимыми процедурами, требующими параметров, заполняется коллекция Parameters объекта SqlCommand и выполняется запрос.

    Удаление данных. Для удаления записей просто вызывается приведенная выше хранимая процедура.

    Изменение данных. Работа связки DataSet + DataAdapter.

    .NET Framework предоставляет очень мощную возможность редактирования данных с помощью объектов DataSet и SqlDataAdapter (AdoDataAdapter). После заполнения DataSet с помощью DataAdapter вы можете без проблем редактировать данные в DataSet. А когда придет время сохранить изменения в данных, это легко можно будет сделать с помощью метода Update объекта DataAdapter.

    Рассмотрим работу данного алгоритма на примере. Заполним DataSet данными из таблицы jobs. Затем изменим данные в одной строке и добавим еще одну строку, после чего запишем данные обратно в базу и заново их прочтем для того, чтобы вывести на страницу результат и проконтролировать выполнение операций изменения и добавления.

    Первоначальный вид страницы:

    Страница после нажатия кнопки (изменена строка с job_ >

    Возможность использования связки DataSet + DataAdapter состоит в том, что объект SqlDataAdapter кроме свойства SelectCommand (команда, с помощью которой происходит выборка данных из источника данных) использует также команды для изменения данных (DeleteCommand, InsertCommand и UpdateCommand). Вся сложность при этом заключается в правильном присвоении значений (команд SQL) этим свойствам для корректного обновления данных в базе данных. Большую помощь в этом оказывает объект SqlCommandBuilder, предназначенный для автоматической генерации команд, использующихся для обновления данных. Ну а дальше все просто. Создается объект SqlDataAdapter, заполняется DataSet, и производятся манипуляции с данными. Затем в нужный момент с помощью SqlCommandBuilder генерируются команды для обновления данных, и вызывается метод SqlDataAdapter.Update для записи изменений данных в базу. ..

    Заключение

    В данной статье мы только начали разговор о работе с новой версией ADO – ADO.NET. В следующем номере журнала мы продолжим рассказ как о работе с ней из приложений ASP.NET, так и о работе с ADO.NET из Windows-приложений и построении многоуровневых приложений.

    ** Полностью статью можно найти в печатной версии журнала

    Copyright © 1994-2020 ООО «К-Пресс»

    Что такое XML

    При создании и разработке XML ставилась цель сохранения возможностей SGML (Standard Generalized Markup Language), стандартного обобщенного языка разметки, и обеспечения Web-авторов возможностью подготовки необходимой им компоновки страниц.

    XML также, как и HTML создан для создания документов Web. Авторы, пользующиеся XML также как и в HTML открывают и закрывают тэги , но главный плюс XML заключается в том , что он позволяет включать свои собственные элементы и структурные образования в ваши документы.

    Как уже было сказано выше, при создании документов с использованием XML, вы можете использовать ваши собственные элементы и структуры для разметки содержания ваших документов. Возможно указать DTD (a Document Type Definition), то есть определение типа документа. DTD определяет то, что можно назвать «грамматикой» документа-это список различных элементов и их образований для использования в определенных документах, в чем-то это напоминает исользование CSS, то есть вы можете сделать ссылку на DTD, находящееся где-либо в паутине или написать его непосредственно в вашем документе.

    При использовании программных приложений, например Web-браузера для просмотра ваших XML-документов, элементы DTD интерпретируются и отображаются согласно поведению синтаксического анализатора и программного обеспечения пользователя. Используя таблицы стилей вы можете определить как ваш документ должен отображаться ПО пользователя. Таким образом, содержание документа, его структура, типы используемых в нем элементов и его вид определятся отдельно, то есть независимо друг от друга.

    Новости

    Вы могли бы удивиться: «А для чего нужен XML, если он является всего лишь разновидностью, а точнее производной от SGML?». Вероятно, это правильный вопрос, и мне бы хотелось сразу на него ответить. Не секрет, что XML-это производный от SGML язык, но SGML-язык, использующий огромное множество различных элементов, которые затрудняют и усложняют работу при создании Web-документов (именно поэтому на ранних этапах развития Web, из-за своей сложности в освоении, SGML был заменен более простым HTML, который стал базовым для бурно развивающейся Web. XML — гораздо более проще, чем SGML, но при этом он предоставляет ни чуть не меньше возможностей разработчикам.

    Нужно сказать, что XML полезен для автоматизированных программных средств, ищущих в Web. Несовершенство HTML привело к тому, что сеть превратилась в мешанину текста, полную различных элементов и тэгов, часто используемых, что называется Pro Forma и ничего не значащих.

    XML обладает огромным потенциалом для усовершенствования гипертекста. Например в HTML для создания связи использется элемент A, XML же позволяет создать не просто ссылку, а к примеру, двунаправленную связь.

    Таблицы стилей, используемые с XML могут быть, в конце-концов, определены как Семантика стиля документа и язык спецификации, то есть как международный стандарт для StyleSheet программирования. Результат будет следующий: мы получим более значимую, осознанную и красивую Web-сеть.

    Кто использует XML?

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

    Перспектива XML заключается в том, что он будет использоваться для описания других языков разметки, например, JavaScript, используемого в HTML-документах. Также XML, вероятно, будет весьма полезен для промышленности, которая создавая свои DTD, смогут создавать документы соответствующие области или отрасли промышленности и отражать ее специфические черты.

    С помощью этой статьи, вы быстро погрузитесь в XML. Я буду брать предметы из повседневной жизни, и пытаться описывать их, используя XML. Затем я загружу файл XML в объектную модель документов XML. После этого я продемонстрирую, как запрашивать XML документы с помощью XPath и проделывать некоторые основные манипуляции над ними. Все эти действия будут продемонстрированы с использованием простого приложения на Visual Basic и Microsoft Parser версии 3.0. Заключительной целью этой статьи будет разработка элемента управления ActiveX , который будет запрашивать данные из базы данных pubs на SQL Server и возвращать список наименований книг в формате XML.

    Если кто-либо из вас когда-нибудь пытался изучить XML своими силами, Вы возможно встречались со многими сбивающими с толку понятиями, обрушившимися и на меня в свое время. DTD, XML Schema, пространства имен (namespaces), XPath, XPointers, XSL, XSLT, DOM, SAX, SOAP, Все, я сдаюсь. Добавлю лишь, что большинство из этих материалов основано на реализациях, код которых может содержать ошибки. Наверняка существуют миллионы способов реализации и использования XML, но они все могут быть достаточно сложны. А знаете, XML может быть и очень простым. Если мы забудем про DTD, XML Schemas, пространства имен (namespaces), и т.п.

    Стараясь быстрее обучить вас работе с XML, я буду по возможности игнорировать приличную долю информации, которую вы и так сможете прочитать в соответствующей литературе. И первое что я собираюсь проигнорировать, это пространства имен (namespaces) и схемы (schemas). Вам это может показаться странным, так как большинство книг начинаются именно с объяснения этих понятий, но постарайтесь думать об XML как о средстве решить конкретную задачу, как, например, о молотке. Для того чтобы пользоваться молотком, разве обязательно знать, как построить дом? Что если все что мне нужно, это просто вбить гвоздь чтобы повесить на него картину? То же самое и с XML, он может быть и очень сложным, достаточно универсальным для использования в сотнях, если не в тысячах приложений, и очень простым, если не обращать внимания на некоторые вещи. В этой статье, я буду концентрироваться на решении конкретных проблем с помощью XML.

    Так в чем же собственно проблема? Давайте предположим, что я хочу описать простой объект, например стакан, используя XML. Зачем я собираюсь использовать XML для этого? Ну, во-первых, это как раз то, для чего и предназначен XML. XML описывает данные. В моем примере, стакан, это и есть данные. В жизни, данными могут быть документы Word, листы электронных таблиц, изображения, книга, запись базы данных, или даже классы C++ или Visual Basic. Во вторых, XML расширяем. XML позволяет мне создавать столько признаков, сколько необходимо для описания данных и эти признаки будут такими, какими я захочу. И, наконец, потому что XML быстро становится стандартом. Если на Марсе есть жизнь, то можете не сомневаться, что они там смогут понять мой XML файл.

    Какие основные свойства позволяют описать стакан?

    Как бы то же самое выглядело в формате XML?

    Заметьте, что первая строка файла (?xml version=»1.0″?) имеет специальный вид, пока, просто запомните, что она должна быть тут. Прелесть формата XML в том, что любой может понять, о чем в нем говориться, просто внимательней взглянув на него. Понятно также, что это не единственное из возможных XML описаний стакана. Если я попрошу 10 человек разработать XML описание стакана с одинаковыми свойствами, возможно, все они создадут разные, но верные описания. Вот тут как раз и кроется проблема. Возможно не для нас, людей, но когда компьютер читает XML файл, то было бы отличной идеей, дать ему знать, о чем этот файл. Вот тут и всплывает пространство имен (namespaces) и схемы (schemes). Проще говоря, схемы используются для определения адекватной структуры для XML файла.

    Теперь настало время поговорить о нескольких простых правилах XML, которым необходимо придерживаться:

    Правило XML #1: Адекватный XML файл должен в точности соответствовать своей схеме. Но для простоты понимания материала, ни один из моих примеров не будет использовать схемы. Таким образом, строго говоря, ни один из моих примеров не «адекватный». Но, честно говоря, мне все равно. Я не собираюсь строить дом, мне нужно всего лишь повесить картину. Я подробней расскажу об этом позже, когда будем обсуждать объектную модель документов XML.

    Правило XML #2: Если вы программируете на VB, запомните: XML чувствителен к регистру. XML чувствителен к регистру. XML чувствителен к регистру. XML чувствителен к регистру. Напишите это предложение 1000 раз и никогда не забудете.

    Правило XML #3: Тэги принято называть элементами и каждый открывающийся тэг, должен иметь соответствующий ему закрывающийся тэг. Следуя этому правилу, у вас получится правильный XML файл. Это очень важно, потому что до тех пор, пока XML файл не будет правильно оформлен, он не будет проанализирован и не загрузится в объектную модель документов. Заметьте, если элемент не содержит значений и не содержит других (вложенных) элементов, закрывающий тэг может иметь вид вместо более громоздкой конструкции . Можете увидеть такой подход в предыдущем примере ( ).


    Правило XML #4: Элементы могут содержать атрибуты, а значения атрибутов должны быть заключены в кавычки (одинарные или двойные).

    Правило XML #5: Можно несколько раз использовать имена атрибутов, но имена элементов должны быть уникальны для всего файла. В предыдущем примере, атрибут qty имел различное значение в зависимости от того, в каком элементе он используется ,
    , или . Значение атрибута зависит от контекста его использования. Тогда как значение элемента всегда означает одно и то же, независимо от того, в каком месте файла атрибут находится. В предыдущем примере, элемент и всегда имеет одно и то же значение во всем нашем документе. например, всегда используется для описания высоты стакана.

    Правило XML #6: В XML есть несколько специальных символов, которые не могут быть использованы напрямую, потому что являются зарезервированными в синтаксисе XML. Поэтому, для использования таких символов, придется использовать зарезервированную конструкцию, начинающуюся с символа & и специального кода, (символ & должен писаться как &) (символ » должен писаться как «) (символ должен писаться как >) и (символ ‘ должен писаться как ‘). Вместо этого, также можно использовать инструкцию , где на месте «. » может быть любая последовательность символов, кроме «]]>». Такая конструкция может встречаться в любом месте, но она не может быть вложенной.

    Объектная модель документов XML позволяет программистам загружать содержимое XML файла в память. Как только XML файл загружен таким образом, с ним можно работать, используя свойства, методы и события объектной модели документов. Вот где как раз и проявляется польза XML. Объектная модель документов значительно облегчает выборку и обработку информации XML файла. Я не буду тут рассказывать обо всех возможностях объектной модели документов, расскажу лишь о некоторых основных возможностях, которые помогут в достижении цели этой статьи. Я возьму только что созданный XML файл с описанием стакана, загружу его в объектную модель документов и проделаю несколько действий с ним. Остальные особенности и возможности объектной модели документов я приберегу для следующей статьи, рассказывающей о клиентском XML. Заметьте, не смотря на то, что объектная модель документов очень хороша и удобна для разработчиков, она требует довольно значительного объема системных ресурсов. Поэтому существует еще один метод анализа XML файлов, известный как SAX. Моя статья не претендует на исчерпывающий источник информации по этому вопросу, поэтому было бы полезно также воспользоваться XML SDK.

    Давайте посмотрим на пример, используя анализатор Microsoft’s XML версии 3.0 (Microsoft’s XML parser version 3.0 (msxml3.dll)) чтобы разобраться, как же это все работает. Если у вас нет анализатора, то последнюю версию можно скачать с сайта Microsoft.

    Предположим, я сохранил пример описания стакана в формате XML в файл «» (локальный путь C:\inetpub\wwwroot\xml\cup.xml) и теперь хочу загрузить его в объектную модель документов. Следующий код предполагает, что анализатор уже загружен и работает.

    Пояснение приведённого кода — пройдемся по коду на VB6

    Строка 1:Dim xmlDoc as MSXML2.DOMDocument30

    В этой первой строке определяем ссылку на «Microsoft XML, v3.0». В этой строке я определил переменную xmlDoc как ссылку на XML документ. MSXML2 это библиотека (используйте это название, не пытайтесь написать MSXML3, это не будет работать). DOMDocument30 определяет объект XML документа соответствующий версии 3.0. Вы также можете встретить такой код: dim xmlDoc as MSXML2.DOMDocument. Такой конструкцией обычно пользуются, когда не хотят указывать конкретную версию XML документа. В этом случае будет использоваться зарегистрированный по умолчанию в системе анализатор. Проблема может быть только в том, что версия анализатора, зарегистрированная по умолчанию, может отличаться на разных компьютерах. Если вы хотите быть уверенными в том, что написанный вами код будет работать с любой версией анализатора, то не используйте в нем специфических для конкретных версий анализатора конструкций. Потому, что нет никакой гарантии, что у пользователя, который будет пользоваться вашим кодом, установлена имена та версия анализатора, под которую вы писали свой код. Еще одно преимущество разработки кода, независимого от версии анализатора в том, что когда выходит более новая версия анализатора, у нее обязательно будет обратная совместимость с предыдущими версиями, и вам не придется перекомпилировать ваш код.

    Строка 2:Set xmlDoc = new DOMDocument30

    В этой строке происходит инициализация переменной xmlDoc как нового экземпляра объекта XML документа версии 3.0.

    Строка 3:xmlDoc.async = False

    Файлы XML могут быть загружены либо в синхронном, либо в асинхронном режиме. Если xmlDoc.async = False, то значит, что содержимое XML фала будет загружено, и только после этого управление будет передано вызывающему процессу. Если xmlDoc.async = True, то значит, что управление будет передано вызывающему процессу сразу, не дожидаясь, пока содержимое XML файла будет полностью загружено.

    Строка 4:xmlDoc.val >Этот код сообщает о том, что анализатор не должен проверять загружаемый XML файл на соответствие своей схеме (val >Строка 5:xmlDoc.load ("C:\inetpub\wwwroot\xml\cup.xml")

    В этой строке вызывается метод загрузки указанного XML файла. Существует два вида метода загрузки. Первый, который написан в строке 5, загружает файл в объектную модель документов, и при этом нужно обязательно передавать полный путь до XML файла. Второй вариант загрузки предусматривает передачу в качестве параметра xml строку. Такой вид загрузки мог бы быть вызван, например, так: xmlDoc.loadXML("корректная xml строка"). Я покажу, как пользоваться этим способом позже.

    Строка 6:MsgBox xmlDoc.xml

    Эта строка отображает содержимое загруженного XML файла. В результате мы должны получить тот исходный XML файл, который создали ранее.

    Создайте в Visual Basic новый проект и назовите его standard.exe. Вставьте приведенный выше код в метод загрузки главного окна вашего проекта. Убедитесь, что вы объявили ссылку именно на "Microsoft XML v3.0". Для того, чтобы это сделать, нажмите ProjectReferences, затем пролистайте появившийся список вниз и найдите в нем нужную ссылку. Заметьте, анализатор версии 3.0 должен быть установлен на вашем компьютере, иначе в списке его не будет. Установите точки остановки на последней строке кода (msgbox xmlDoc.xml). Запустите приложение в режиме отладки. Когда процесс выполнения дойдет до точки остановки, вызовите окно "Locals" и посмотрите объектную модель документов. Можно многое узнать, просматривая то, что отображено в этом окне. Окно "Locals" должно быть похоже на то, что изображено на рисунке ниже. Вот некоторые интересные свойства объектной модели документов.

    Объектная модель документов XML всегда содержит два узла верхнего уровня:

    • Item1 это корень ветви элементов документа (не обращайте на нее внимания)
    • Item2 на самом деле первый элемент документа (запомните это)

    nodeName или baseName - могут быть использованы при поиске имени элемента или атрибута.

    nodeType - используйте для того, чтобы получить тип текущего узла.

    nodeValue - используете для того, чтобы узнать значение данных узла.

    childNodes - это коллекция узлов-потомков. Они могут быть узлами элементов, текстовыми узлами и узлами CDATA. Могут быть и другие типы узлов, про которые я сейчас рассказывать не стану, но вы сможете узнать все про них в XML SDK.

    attributes - это коллекция узлов атрибутов текущего элемента.

    length - используется для определения количества узлов в дереве непосредственно принадлежащих текущему.

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

    Узел элементов может содержать узлы потомки элементов, атрибутов, текста или CDATA. Из рисунка ниже видна следующая информация об узле "SOLID":

    nodeType - Тип текущего узла = NODE_ELEMENT - т.е. текущий узел является элементом.

    nodeName или baseName или tagName - Название текущего узла (элемента) = SOLID.

    Его родительский элемент CONTENTS имеет 4 потомков.

    Это можно увидеть на следующем рисунке, но SOLID имеет одного потомка, который имеет текстовый тип данных.

    text - "ice cube" это сокращенный метод, позволяющий получить значение текущего узла без перемещения к текстовому узлу потомка.

    Узлы атрибутов могут состоять только из текстовых или CDATA узлов-потомков. На следующем рисунке показано, какая информация может быть получена об узле "qty":

    nodeType - Тип текущего узла = NODE_ATTRIBUTE - текущий узел является атрибутом.

    nodeName или baseName - Имя текущего узла (Атрибутов) = qty

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

    text или value - "2" это сокращенный метод, позволяющий получить значение текущего узла без перемещения к текстовому узлу потомка.

    Текстовые или CDATA узлы не содержат потомков. Текстовые узлы содержат обработанные текстовые данные своего родительского узла. CDATA содержат необработанные текстовые данные своего родительского узла. CDATA узлы создаются, когда данные в XML файле специальным образом обрамлены. Метка CDATA говорит анализатору не разбирать данные и принимать символы внутри этой метки как данные. Секция CDATA особенно полезна, когда нужно вставить код внутрь XML файла. На следующем рисунке показано, какая информация может быть получена из текущего текстового узла:

    nodeType - Тип текущего узла = NODE_TEXT - текущий узел содержит текстовые данные.

    nodeName - Имя текущего узла (текстового) = #text - все текстовые узлы называются #text

    data или text или value - "2" - это текущие данные узла.

    Секция parseError объектной модели документов может оказаться полезно при выявлении проблем, возникающих при загрузке XML документа. Если я удалю закрывающий тег от OTHER в файле нашего примера и попытаюсь запустить программу еще раз, то получу следующий результат. Первая часть полезной информации, это то, что наш nextSibling теперь содержит значение Nothing. Теперь, если вы посмотрите на childNodes, вы можете увидеть, что поле length теперь равно 0. Оба этих признака говорят о том, что наш XML документ не был загружен. Чтобы разобраться почему, я открываю узел parseError и получаю всю информацию об ошибках.

    Итак, я показал вам, как загрузить XML файл в объектную модель документов, но что с ним там делать? Одна из основных возможностей, которой вы сможете пользоваться это выполнять различные запросы к XML документу. Для этого вы конечно можете просматривать весь документ до тех пор, пока не найдете информацию которую ищите. Но наиболее предпочтительный способ, это использование одного из двух методов класса DOMDocument. Два метода используемые для поиска узлов в нашем предыдущем примере могли бы выглядеть как xmlDoc.SelectSingleNode(patternString) - для получения искомого узла, или xmlDoc.SelectNodes(patternString) - для получения списка искомых узлов. Параметр patternString как раз и является запросом. Он может быть сформирован одним из двух способов. Либо как XSL запрос, либо как XPath запрос. Более новый и предпочтительный способ создавать запросы к XML документу, это XPath. Формат patternString должен быть установлен заранее, перед первым вызовом любого из двух методов запроса данных, иначе по умолчанию будет использоваться XSL способ формирования запросов. Для установки типа формирования patternString используйте setProperty("SelectionLanguage", "format"). Для того, чтобы изменить запросы в нашем примере таким образом, чтобы использовался способ XPath, я добавлю следующую команду: setProperty("SelectionLanguage","XPath"). По-моему, XPath это самая важная технология в XML которую следует изучить. Я приведу несколько простых XPath запросов. Хорошим началом для изучения этой технологии может служить Microsoft XML SDK. Еще одним способом для объяснения этого, могло бы быть написание простого приложения на Visual Basic, которое позволяет вводить запросы и выводить результат. Вы, возможно, найдете какие-нибудь бесплатные приложения, которые делают то же самое, но XPath довольно новый и может не вполне поддерживаться этими приложениями.

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

    Запустите программу и посмотрите, что получится. Вы должны получить четыре сообщения, в которых говориться о содержимом стакана. Последнее сообщение должно быть пустым, потому, что элемент "OTHER" не содержит никакого текста. Давайте составим запрос, который возвращает все содержимое стакана, где qty>0. следующая строка кода делает именно это:

    ОТЛИЧНО! Давайте теперь добавим еще один запрос, который позволит нам определить, есть ли у стакана крышка или нет. Добавьте следующий код в конец предыдущего:

    Пройдемся по коду строка за строкой:

    Строка 1: Dim objNode As IXMLDOMNode

    В этой строке определяется переменная objNode типа узел XML документа. Важно понимать, что узел XML документа это тоже объект. Это не значение. Он состоит сам из себя, также как и его атрибуты и потомку (childNodes). Этим способом вы можете отсекать ненужные ветви дерева, выбирая только нужные.

    Строка 2: Dim objListOfNodes As IXMLDOMNodeList

    В этой строке определяется переменная objListOfNodes имеющая тип списка узлов XML документа (группы узлов).

    Строка 3: xmlDoc.setProperty "SelectionLanguage", "XPath"

    Эта строка устанавливает способ формирования patternString как XPath.

    Строка 4: MsgBox "Your cup contains the following items:"

    Строка 5: Set objListOfNodes = xmlDoc.selectNodes("//CONTENTS/*[@qty>0]")

    Эта строка выполняет XPath запрос, который вернет группу узлов и сохранит их в переменной objListOfNodes. Запрос разбит на следующие части:

    • //CONTENTS - взять все элементы CONTENTS в XML документе. Заметьте: // - это краткое обозначение для всего содержимого XML документа.
    • /* - из списка элементов CONTENTS взять все (* - используется для указания всех) элементы-потомки. Это сокращает полученный результат до четырех узлов элементов (
    • ). Эти четыре узла попадают напрямую под узел CONTENTS.
    • [@qty>0] - проверить каждый элемент-потомок на то, чтобы его атрибут qty (@ - означает атрибут) был больше 0. Если это условие не выполняется, узел отбрасывается. Все, что внутри [ ] в XPath запросе может принимать значения True или False. Если результат True, то узел сохраняется. Если результат False, то узел отбрасывается. После этого наш результат сокращается до трех узлов (
    • ).

    Строка 6-8: For Each objNode In objListOfNodes / MsgBox objNode.Text / Next

    Эти строки отображают значения каждого узла элемента, которые соответствуют запросу. ("ice cube" , "straw" , "water").

    Строка 9: Set objNode = xmlDoc.selectSingleNode("/CUP/LID")

    Эта строка возвращает все элементы LID, которые принадлежат элементу CUP, который, в свою очередь, порожден от корня дерева (когда запрос начинается с /, то это означает что начинать нужно с корня). Это очень похоже на путь к файлу или папке. В нашем примере, этот запрос вернет элемент LID, который содержит значение "yes". Важно тут то, что я указал запросу начинать с корневого элемента XML документа. Запросы не всегда начинают выполняться с корневых элементов, обычно они начинаются с текущего узла. В нашем примере это не имеет значения, поскольку текущим узлом (xmlDoc) и является корневой элемент XML документа (но не во всех случаях это так).

    Строка 10-15: if objNode.text="yes" then / MsgBox "We have a lid" /

    else / MsgBox "No lid on this cup" /end if

    Эта строка отображает сообщение "We have a lid" потому, что текстовое свойство элемента LID "yes".

    Теперь, когда вы поняли основы XML, давайте создадим элемент управления ActiveX, который будет конвертировать набор данных ADO в XML формат. Цель в том, чтобы получить наименования книг из таблицы Titles базы данных Pubs и вернуть их в формате XML. Результат, который получится я буду использовать в своей следующей статье. Вы можете сказать, ADO имеет свои собственные методы для сохранения результата в формате XML, правильно? Да, но если доверить это ADO, то в итоге я получу XML файл в таком ужасном формате, что с ним невозможно будет работать. ADO создаст XML файл с использованием пространства имен, а мне сейчас это совсем не нужно. Во-вторых, ADO создаст XML файл, который будет представлен в форме атрибутов. Иными словами, каждая запись станет элементом и каждое поле - атрибутом:

    А мне бы хотелось получить XML файл в форме элементов, где каждая запись, содержалась бы в теге , и каждое поле было бы элементом внутри тега . Синтаксис моей XML строки был бы таким:

    Кстати, то, что я только что сделал, это создал схему для моей XML строки. Теперь, если мне нужно сверить структуру XML документа со схемой, все что мне останется сделать, это преобразовать схему в правильный формат. То есть в синтаксис DTD или XDR. Заметьте, что я добавил некоторые атрибуты к каждому элементу . Одна из причин этого в том, что эта информация может быть использована клиентом. Prettyname могут быть использованы как метки данных. Атрибут datatype мог бы быть использован для проверки данных на стороне клиента. Но чтобы быть честным, истина причина того, что появились эти атрибуты в том, что они имеют особое назначение в шаблоне XSL фала, который я часто использую для построения секции where SQL запросов. Может быть, я скоро опубликую статью, демонстрирующую этот подход. Шаблон на самом деле очень полезный. Когда XML структура применяется к данным из таблицы Titles, результат будет выглядеть следующим образом:

    Теперь я получил что-то, с чем можно работать!

    Листинг 1 - CUP.XML

    Листинг 2 - Загрузка Cup.xml в объектную модель документов

    Листинг 3 - Элемент управления ActiveX: ADO в XML (WebClass.dll)(xmlControl.cls)

    Листинг 4 - Тестовое приложение на VB для проверки WebClass

    Мастер Йода рекомендует:  Курс «Создание чат-бота для Telegram»
    Добавить комментарий