An order history records product quantities at particular dates. Those records can support volume analysis, a query application and a forecasting model. A five-year aggregate takes a different processing path from a targeted order lookup. Forecasting also requires the information available at each prediction date to be reconstructed.
A data platform connects these uses through shared models. It combines source integration with stable identifiers and retained history. Computation and publication remain suited to each application, which can reuse prepared data through an interface designed for its particular workload.
Orders provide the running example here. The design choices apply to other kinds of data too; the example assumes no particular organisation and does not describe a client deployment.
From sources to shared models
The business application records the order header, lines, products, prices and statuses in a transactional model. The warehouse reconstructs those relationships for analysis at an explicit level of detail. An order line, a status change and a product are distinct objects, even when an export combines them.
Incoming data retains its source identifiers and collection time. Transformations then match references across systems and produce fact and dimension tables. A product dimension can hold successive classifications, while facts record the quantities ordered on a given date. This separation supports different interpretations of the same history.
An implementation on Google Cloud can retain files in Cloud Storage, load raw data into BigQuery and run SQL transformations with dbt. Airflow schedules execution and manages dependencies. The diagram separates this shared preparation from the three delivery paths.
These boundaries separate source transformation from publication to applications. Shared models preserve a common product catalogue and its keys between these stages, while individual applications use representations suited to their workloads.
History for analysis and prediction
Suppose a product moves to a different category in September. An analysis could apply its current classification to every order, or preserve the classification in effect at each sale. These interpretations answer different questions. Version validity periods make the distinction explicit in the data model. dbt snapshots provide one way to retain changes to source rows; their capture frequency determines which changes are actually observed.
Predictive training distinguishes the date of an event from the date its information became available. A correction received in October might concern a July order. Using it to simulate a forecast made in August would introduce knowledge from the future. Training datasets therefore account for availability times as well as business dates. The Feast documentation on point-in-time joins illustrates the distinction and the handling of late corrections.
Each dataset is published under a version that identifies its coverage period and the transformations used. Schema, uniqueness and relationship checks precede publication. dbt data tests can express some of these rules. The tests cover the assertions implemented. Checking completeness also requires comparison with the expected periods, records or source totals.
The flowchart describes dataset publication. Training, evaluation and deployment of a predictive model have their own subsequent lifecycle. Updating the historical data does not automatically replace the model running in production.
Interfaces for applications and AI
Shared models become accessible through several interfaces. The dashboard queries facts and their dimensions to calculate aggregates. The predictive workload receives features calculated over a defined period. The application queries an indexed read model, published to PostgreSQL and exposed through a .NET API in the illustrated example.
A semantic layer adds value when several tools share the same measures. It describes entities, their relationships and calculation rules. The dbt Semantic Layer exposes these definitions to analytical tools and applications; its MCP integration also makes them accessible to AI assistants. A question about ordered quantities can then use a defined measure, including its date rules and exclusions.
That interface supplies a controlled calculation definition. The assistant still has to interpret the request and select the appropriate measure, filters and period. Showing those choices alongside the data refresh time makes the answer easier to assess. The data service enforces permissions independently of instructions given to the model.
Predictive results follow the same publication principle. A stored forecast includes its value, horizon, calculation time and model version. The application can compare it with observed quantities while keeping observations and estimates distinct. The platform connects historical data with the software that uses the result.
Processing suited to each workload
A five-year aggregate, an order lookup and a forecast calculation have different execution profiles. The warehouse supports extensive analytical queries. A dedicated read database can serve targeted application requests with its own indexes and capacity. Separating read and write models describes this principle and the synchronisation work it introduces.
In the illustrated architecture, the API publishes prepared data and forecasts. Operations that create or change orders stay in the transactional system responsible for their rules. The read copy has its own refresh delay; the application displays the state and timestamp of the data it retrieves.
The choice between scheduled batches and event streams follows the required publication delay. A daily summary can use an overnight job. A frequently refreshed view calls for a different ingestion path. Both can share identifiers, definitions and reference transformations while using separate execution resources.
Separating ingestion, models and publishing interfaces provides defined integration points for another source, forecasting model, mobile interface or analytical measure. Each extension has identifiable models and interfaces to build on. The warehouse supplies shared historical data to the analytical queries and software services that use it.