A Frakture Warehouse holds many types of objects that have been mapped from various source systems into a normalized schema. The most common object types in a Frakture Warehouse are:
This page expands on the typical naming and structure of these main tables. You do not need to know these to make use of Frakture's core features: this information will be of most value to analysts, data engineers, or SQL users executing their own queries or building their own reports in the Frakture warehouse.
Most users will want to use the summary tables, which are views that incorporate data from multiple useful core data tables. These summaries are optimized for use by third party reporting suites, as well as Frakture's native reporting.
Frakture data loaded from one of your systems is usually stored in tables with this naming convention:
<platform>_<bot_id>_<data_type>
where the platform is a prefix for the platform (e.g. google_ads, luminate, renxt etc), the bot_id is a unique identifier for the specific bot on your account, and the data_type depends on the type of data.
For example, if we're loading people and gift history out of your Engaging Networks instance, plus a separate stream of other transactions obtained from ActBlue, you might see these tables:
actblue_abc_transaction
engaging_abd_person
engaging_abd_transaction
Note that we've got two tables called _transaction because this type of data is entering the warehouse from two different systems, and we've got two tables beginning with engaging_abd because both tables are built by the same bot.
Occasionally, especially in shared hosting environments such as an agency-managed warehouse for multiple end-user customers, we'll prepend a custom phrase to more specifically distinguish which client's data lives in the table, for example:
humanfund_engaging_abd_transaction