Datasets
A dataset is a collection of data managed and offered as a whole. It brings together business meaning, responsible teams, delivery methods and service commitments, helping consumers understand what it solves, what it provides and which changes matter to them.
Supplier 360, for example, can offer supplier profiles, qualifications and scores for procurement analysis and risk management.
Understand the parts of a dataset
| Part | Purpose |
|---|---|
| Dataset record | Describe its name, code, purpose, ownership and lifecycle |
| Business objects | Identify the information offered, including primary and supporting objects |
| Output port | Give consumers a stable delivery entry point |
| Data contract | Describe a port's structure, meaning and operating commitments in a particular version |
| Environment implementation | Show which actual data fulfills contract objects in development, test or production |
| Input port | Declare dependencies on upstream datasets' outputs |
| Version | Record a published set of consumer commitments and its changes |
Projects organize the work of building datasets; datasets support ongoing use and operation. A dataset can have several output ports and combine data from multiple sources.
Establish ownership and business content
In Centralized mode, central teams operate enterprise datasets. In Federated mode, each dataset belongs to one responsibility domain and is operated by its teams, with central teams able to maintain it across domains.
Business object relationships describe the offering. Supplier can be the primary object and Supplier Qualification a supporting object. The primary object establishes the main subject, while supporting objects describe broader coverage.
The catalog displays business descriptions, responsible teams and publication information. Drafts remain with responsible teams for preparation; published datasets are discoverable by enterprise users with the appropriate permissions.
Deliver through output ports
An output port gives consumers a stable entry point. It identifies a delivery method, with a contract describing what a particular version offers. Tables, files, APIs, event streams and semantic models describe different delivery forms.
A port can contain several objects consumed together. A Supplier Analytics port, for example, can offer a supplier dimension and a scoring fact table. Data serving a separate consumption need can have its own port.
Whether a version offers a port is determined by that version's contract. Downstream dependencies can continue referencing the same port while tracking what the current version provides.
Describe commitments in a contract
Contracts explain the offering to consumers:
- Objects and fields: the objects provided, with field names, types, nullability and descriptions;
- Grain: what one row represents, such as a supplier or a supplier assessment;
- Time semantics: conventions for event time, processing time and time zones;
- Units: conventions for money, quantities, weights and other measures;
- Refresh commitments: batch, continuous or on-demand updates and their expected cadence.
A supplier-scoring contract might say that each row represents one supplier's score for a calendar month, measured in points and refreshed daily. Consumers can assess whether that meets their analytical needs.
Choose a starting point
Start from existing tables
Select collected tables in a project to create a dataset and output port. Use their structures as the starting point for a contract, then add business descriptions, the primary business object and refresh commitments. Selecting an environment can also associate those tables as its implementation.
Start from a contract
Define the objects, fields and meanings that consumers need, then associate actual implementations. This supports agreeing on the offering before organizing its construction.
Both paths lead to team review and publication. A contract created from existing tables still needs its business meaning confirmed.
Manage implementations across environments
Select an output port, version and environment to map contract objects to collected physical tables and inspect corresponding fields.
| Scenario | How to organize it |
|---|---|
| Staged rollout | Run a new version in test while production continues serving the previous version |
| Parallel versions | Keep two versions implemented in production while consumers migrate |
| Multiple sources | Implement different objects in one port using different sources |
| Implementation changes | Update table and field mappings, then check them again |
Implementation checks help users compare the contract with actual data:
| Result | Meaning |
|---|---|
| Not bound | No implementation is associated with this version in the environment |
| Not mapped | A contract object has no associated physical table |
| Not checked | A mapping exists and needs checking |
| Matched | The checked structure conforms to the contract |
| Not matched | Objects, fields or structural requirements are missing or inconsistent |
Checks compare the contract with the most recently collected structure. When a source table changes, refresh collection before checking its implementation. Results help teams decide whether to correct the data or update the contract and publish a new version.
Publish and manage versions
The working copy prepares the next consumer commitment. Publication records a version number, change type and summary so consumers can distinguish compatible improvements from changes requiring migration.
Prepare working copy → check publication requirements → publish → prepare the next update
Publication checks cover responsible teams, the primary business object and port contracts, while reporting implementation readiness in each environment. A contract can be published before its implementation is ready; consumers use environment check results to determine where it is usable.
Published contracts remain the commitment for that version. Contract changes are prepared in the working copy for a new release. Team membership, descriptive labels and environment mappings can be maintained separately.
The version list distinguishes the working copy, current version and historical versions, showing associated environments. Historical versions can keep their implementations while consumers upgrade gradually.
Manage upstream and downstream dependencies
Input ports declare which upstream output is used, for what purpose and whether it is required. Port relationships let teams share data across domains and inspect dependencies and consumers.
If an upstream version stops offering a port, its dependencies show the change in supply so downstream teams can respond. Using upstream data does not mean every upstream business object is part of the dataset's own offering.
Deprecate and retire
Teams can deprecate the current version and communicate a planned sunset date. Retirement preserves dataset records and history for reference. Lifecycle, version records and environment checks together describe the state of the offering.