Использование фреймворка, подобного тому, как предлагает @rjrudin, определенно подходит для любой крупной работы или продолжающегося процесса. Тем не менее, это все еще помогает экспериментировать, чтобы понять, что вы запрашиваете у платформы. («GIGO») - Немного человеческой мысли и ручного труда окупится - «денормализация» - это не чисто механический / объективный процесс - это сочетание знаний в предметной области, творческого компромисса и целевого обогащения данных.
Я предлагаю вам начать с того же процесса, который вы использовали бы для разработки схемы СУБД - подумайте о запросах. Полезно получить список «топ-10» от основных пользователей данных / приложения, какие запросы / вопросы будут наиболее необходимы и какие результаты и форматы ожидаются. Денормализация не так полезна вне контекста (крайний пример - просто поместить ВСЕ данные в один «денормализованный» документ »- вероятно, бесполезно).
Упрощенная, но полезная концепция заключается в том, что MarkLogic очень хорошо работает для вопросов и ответов на основе «Документа». «Думай как гугл». Когда вы используете Google, что вы ищете? Вы ищете веб-сайты? или дистиллированные краткие "факты"? Агрегации / статистика? Если ваши запросы в основном имеют вид «Дайте мне все документы, которые содержат информацию о XYZ», то вы, вероятно, захотите денормализовать в документы, которые сосредоточены вокруг тем типа «XYZ». Если на вашем домене имеется естественная группировка информации, ориентированная на документы (например, у фармацевтической компании есть документы, связанные с наркотиками, у туристической компании есть документы, связанные с недвижимостью).
Очень важно помнить, что как поиск, так и создание / обновление документов работают на уровне «документа», а затем позволяют вашим ожидаемым запросам и наборам результатов определять ваше определение «документа», а не создавать документы, основанные исключительно на внешнем ключе.
отношения извлекаются из нормализованных представлений. В классике «Деловые документы»
пример - если ваш бизнес-домен имеет рабочие процессы, сосредоточенные на «Счета-фактуры» и «Заказы на покупку», то имеет смысл сделать каждый Счет-фактуру отдельным документом, возможно, включив в него все детали позиции. Однако, если ваши бизнес-процессы сосредоточены на управлении запасами, возможно, имеет смысл моделировать документы по каждой части запаса, возможно, с подробностями заказа, встроенными в каждую часть, или обоими.
Механизм денормализации довольно прост, если вы определились с моделью документа - он практически идентичен запросу на соединение RDBMS - за исключением того, что вам не нужно создавать фиксированные «строки» и «столбцы». XQuery внутри QConsole - это хорошая платформа для экспериментов с вашей моделью документа. Затем, когда вы его закроете, переход на одну из описанных платформ будет простым.
Грубый пример денормализации документа Order / Item может выглядеть так: (псевдокод)
for $order in /order_recored_csv/order
let $doc := <order> {
$order/*,
for $line_item in /item_record_csv/line_item[ order_id = $order/order_id ]
return
<line>{ $line_item/* except $line_item/order_id }</line>
}
</order>
return xdmp:document-insert( "/orders/{$doc/order_id}" , $doc )
Что создаст набор документов "заказа" со связанными позициями в каждой.
Затем вы можете улучшить, например, добавив информацию о клиентах, обогащение данных (перевод идентификаторов в значения, поиск данных из внешних источников, назначение уникальных идентификаторов, управление версиями, ссылки на источники данных и т. Д.).