SAP Datasphere offers various object types. Let's start with a high level overview of them and explore concepts like naming convention, impact and lineage analysis, versioning, release state and sharing of objects across spaces.
Object Types
Using the Data Builder, you can define the following objects:
Local Table: Table for data persistence.
Remote Table: Table for virtual access of data.
Graphical view: Intuitive GUI for powerful and easy-to-use modeling for master data and transactional data artifacts.
SQL view: Powerful SQL editor for models based on SQL or SQL Script.
Entity relationship model: Import, visualize, edit, and deploy multiple data entities to better manage your modeling concept.
Analytic model: Define multi-dimensional models to provide the data foundation for analytical purposes (including predefined measures, hierarchies, filters, variables and associations).
Data flow: Load data from sources to SAP Datasphere with transformation logic.
Replication flow: Replicate data from sources in a fast and easy way when complex projections are not required.
Transformation flow: Load data from an SAP Datasphere object, apply transformations and output the result in a local table.
Intelligent lookup: Tool to support look ups to merge data from different entities when manual joins are not sufficient.
Task chain: Group multiple tasks and run them manually once, or periodically through a schedule.
Data access control: Set up row level security authorization.
Naming Objects
A naming convention can help to identify and separate the objects in SAP Datasphere or describe their purpose. The technical names are technically unique per space. In case it is required to have a harmonized naming across spaces, this will require some governance next to the system capabilities.
Another main aspect of naming conventions is an evolution of the model over time. People and responsibilities may change over time. Having a naming convention and adhering to that convention helps developers and users in the system, through having a purpose, an area, an origin or even the priority of a model as part of a naming convention. Anyone would as such be able to quickly understand an object and its purpose, if it can be reused or if it is allowed to be altered.
Note
Avoid the Prefix "SAP" for any object, as SAP delivered business content is using this prefix. SAP Datasphere does not provide the functionality to define name spaces.
General recommendations for naming rules in an organization:
- Unambiguous: Use clear, well defined descriptions. If in doubt, talk to your project’s information developer and check SAP terminology. The goal is that users understand immediately what the entity is used for.
- For descriptions and business names use blanks. Do not use underscores or camel case words.
- Avoid abbreviations as much as possible.
Impact and Lineage Analysis
Impact and Lineage Analysis is the go-to tool whenever you need to understand how data objects in SAP Datasphere relate to each other, either to trace where data comes from, or to see what would be affected by a change.
Lineage looks backward (upstream) and shows all the objects that feed the analysed object. This means source tables, remote tables, flows, intermediate views, and source systems.
Impact looks forward (downstream) and shows all the objects that depend on the analysed object. This means views that read from it, analytic models that use it, and SAP Analytics Cloud stories built on top of it.
Data Analysis is the default mode when you open the Impact and Lineage Analysis diagram. It focuses exclusively on the physical flow of data. It shows how data moves and is transformed from its source to its final consumer. By clicking on an object node, you can activate column-level lineage. The diagram then filters to show only the paths for those specific columns.
Dependency Analysis extends Data Analysis by adding two additional categories of relationship that are invisible in Data Analysis mode: associations and data access controls.
Versioning
Each time you deploy your object, a new version is created in the repository. You can review previous versions of an object at any time and choose to restore a previous version.
Object versioning allows you to review the history of changes to your objects and, for certain types of objects, to restore a previous version.
Note
No validation rules are applied and certain features, such as impact and lineage analysis and data preview are not supported.
Release State
To encourage confidence in the stability of your views and to guarantee backward compatibility when they are updated, you can set their Release State to Released. Once a view is released, it must continue to provide the same output columns until it is replaced by a successor, at which point it can be deprecated and, eventually, decommissioned.
There are currently 4 states that an object in SAP Datasphere can be in:
Not released: The default state that a view is in. You can edit the object freely and consumers can you use the object without any guarantee of the object changing in the future.
Released: When a view is in the status "Released" it can only be edited in such a way that it will not break backwards compatibility. In practice, this means that the column output of a view is static, and only columns can be added, not removed.
Deprecated: A view can be set in the state "Deprecated" once a successor of that view is available in SAP Datasphere. While setting this state, the view asks for its successor view, which should be in a released state as well (otherwise you cannot select it).
Decommissioned: A view that is set to the state "Decommissioned" can be deleted from the system. Before you can set the state "Decommissioned", a view needs to be in the deprecated state for at least 1 year (and at least 2 years after it was released).
Note
Release states are an optional feature. By default, all views are set to "Not Released" and there is no obligation to release any view. Test thoughtfully if the entity is in its final state before releasing it.
You can only switch from "Released" to "Deprecated" and then to "Decommissioned". Only an administrator can reset an entity to "Not Released".
Sharing Objects Across Spaces
To see models or data, users must be assigned to a space that contains these models. Therefore a suitable role must exist. By default, all business users, which are assigned to a given space, are able to consume all of its data. Your space is a secure area and its entities and other objects cannot be seen in other spaces unless you choose to share them. When you share an entity to another space, users in that space can use it as a source for their views and other objects.
In SAP Datasphere the following object types can be shared from one space to another:
- Local table
- Graphical view
- SQL view
- Analytic model
- Task chain
- Data access control
You only need access to the source space in order to start sharing. Sharing is a one-way reference. You cannot change the shared object from the target space, but you can create a view on top of it and remove, rename, or join fields in the view.
As a tricky alternative, you can export an object as a CSN (this is based on JSON) file and import it in another space, but then you must export and import all required objects with the same name.
When access to the model or data should no longer be available, you can unshare the object from selected target spaces. To share or unshare, you must work in the Data Builder in the source space. If you try to unshare an object that is used in the target space, you will get an error message with a list of objects that use it directly. For a full overview of dependencies, check the lineage and impact analysis. Only after a manual re-design of the upper-level objects, you then can unshare.
