Others reading this thread, might also be interested in the thread…
…that i discovered now, where several people (like @pablo, @ian.mcnicoll, @birger.haarbrandt and @thomas.beale) respond to good questions (from @Jelte and @joostholslag ) in several ways explain things that I often try to (but sometimes fail to) explain in BI contexts:
- The sematically rich tree-shaped (or rather “directed graph”) models of openEHR (and many other object oriented data sources/storages) often need to be turned into “flat” table-like-structures in order to make “normal” table-focused BI tools (and BI experts) work the way they usually do, and
- when creating those table-like-structures (e.g. using openEHR AQL queries) it really helps if you already know the purpose of the BI-tables/operations you want, so that you can make purposeful tables. Creating a general openEHR-tree to openEHR-table conversion would likely be hard to do in a way that easy to work with in tabular BI tools in a way that fits all general purposes.
Working with the Object–relational impedance mismatch - Wikipedia in the BI world, I assume must be a general problem and not openEHR specific.
Questions:
- Is anybody aware of BI tools (query layers/tools, data dictionaries etc) that are good at working with source data that is directed graphs and trees (like RDF, OWL, Object oriented models or rich/deep XML and JSON structures)?
- Have those tools been used for openEHR-based data?
- How easily can “normal” BI-people, more used to tables, learn/understand such tools?
We did in the paper IOS Press Ebooks - Querying Archetype-Based Electronic Health Records Using Hadoop and Dewey Encoding of openEHR Models of course turn openEHR trees/graphs into tables suitable for efficient relational algebra operations to retrieve data, but I doubt that the structure used there would make “classic” BI-tools and BI-experts happy since the purpose was very different.