В результате мы можем составить такую таблицу ребер (убедитесь, что по этой таблице можно восстановить исходный документ).
| ORDER | Источник | Тип ребра | Приемник | Значение |
| 0 | подэлемент | article.1 | статья про XML | |
| 1 | article.1 | атрибут | codename | XML |
| 2 | article.1 | подэлемент | head.2 | |
| 3 | head.2 | подэлемент | filename.3 | |
| 4 | filename.3 | текст | file.rtf | |
| 5 | head.2 | подэлемент | author.4 | |
| 6 | author.4 | текст | Vasia Pupkin |
Может быть несколько способов реберного представления — в зависимости от терминологии и предполагаемого использования. Значение текста, например, можно считать и значением, и «приемником» (поскольку это все-таки узел). У нас не показаны также «сестринские» связи — а это может оказаться полезным, если важно искать соседние подэлементы. Иногда будет выгодно указывать только первый дочерний элемент и потом — связи типа «следующий».
Можно также нумеровать атрибуты и исключить еще один столбец, но поскольку событие «прибыл атрибут» не предусмотрено в SAX, то сам процесс такой нумерации потребует дополнительного кодирования в духе foreach.
Кроме того, не показана алгебра документов — то есть способ учета документов как атомарных величин. Возможно, для этого будет создана отдельная таблица традиционного формата с полями DOC_ID, DOC_NAME, DOC_DESСRIPTION, DOC_LASTMOD и в том же духе.
Как видно, это представление легко укладывается в одну SQL-таблицу и может быть сравнительно прямолинейно восстановлено с использованием SAX. Фактически многие «объектные» базы данных работают именно таким образом, сохраняя документы в виде реберного представления и восстанавливая их в момент загрузки.
Реберное представление позволяет также оптимизировать поиск — особенно если таблица индексирована по искомому полю. Например, очень легко найти элемент (ы) с заданным индексом, именем, значением атрибута, связью и так далее.