Create a Logical Data Model and a Detailed Data Model

The preceding figure presents a visualization option for relationships between business entities.

An entity-relationship model is a diagram containing entities or "items", relationships among them, and attributes of the entities and the relationships.

To create a simple entity-relationship model, look at the database table design or analyze the existing data in the source. You can then find out which characteristics or combinations are the most basic key characteristics, and which are high-level characteristics.

High-level characteristics with values that are (at a specific point in time) determined by lower-level key characteristics are called attributes. They represent properties of the key characteristics. For example, for each product, there is only one category. But the same category can have several products. This relationship is described as a 1:N relationship ("N" = many).

In the simple entity-relationship model that is proposed here, a 1:N relationship is visualized by an arrow, or branch.

Other characteristics are in fact independent from the key characteristics. As an example, consider product and color. For each product, there can be several colors. For each color, there can be several products. The relationship color:product is described as an N:M relationship.

In the simple entity-relationship model that is proposed here, an N:M relationship is visualized by a double branch. If there is a key figure for such a combination, it can be assigned on the line. If different attributes of independent characteristics are relevant in one project, or if attributes of attributes exist, a chain of entities can be combined into one picture. To keep it simple, do not draw relations that are obvious.

These models allow you to discuss requirements at a high level and facilitate consultation with users and departments.

As an alternative to the simple entity-relationship model, you can create a bubble diagram. The bubble diagram, like the entity-relationship model, identifies your main business subjects, such as customer, product, and color, and describes them according to their key properties.

The process for generating bubble diagrams involves the following steps for each object (InfoProvider) as detailed in the figure, Bubble Diagram:

1. List key figures in a central rectangle.
2. Characteristics are displayed as bubbles. If there are more values for one characteristic, the bubble is larger.
3. Consider the business subjects which are the main reporting perspectives. These business subjects are described by attributes, which often group and categorize main business subjects. They usually have a 1:N relationship, which means that the main business subject has the more detailed information than its attribute.
4. For the business subjects which are in an N:M relationship, do not draw an arrow.
5. Remember the time perspective. Add the most detailed required level.

Finally, the list of key figures points to different business subjects that have an N:M relationship. For example, one customer can buy several products, or several customers can buy one product. Products are sold in several business units.

From the logical model, you know the required fields (business subjects) and their relations.

The preceding figure displays which cases are best suited to SAP BW/4HANA models (physical or virtual), and which cases are more suited to SAP HANA models (virtual). In either case, you can reduce the modeling task and speed up implementation by checking whether the standard objects provided by SAP suit your needs.

Checking BI content for SAP BW/4HANA models is an ongoing process that lasts until you finish creating a model. If you want to work with BI content, we recommend that you proceed as follows:

1. Define the tasks and roles of your employees. Determine the necessary key figures or information that your employees require to fulfill their tasks. For this, you can use the role-based BI content.

2. Compare the results from your requirement analysis and your data model with the BI content. Usually, you perform a top-down comparison, that is, you search for key figures, reports, and DataStore Objects (advanced) in the BI content that are required.

3. Determine the differences between your own data model and the BI content.

4. Depending on the object type, you can extend or modify the BI content. You can use the content as a copy template for your own objects, or create your own objects in your namespace, regardless of the BI content.

Your last task is to convert the logical data model into a detailed SAP HANA or SAP BW/4HANA data model (depending on the data target). This is the fine-grain version of the model, which contains all the information needed to create the objects as SAP HANA content or SAP BW/4HANA objects.

In this phase, you turn a requirement into a technical realization choice. For instance, if the business users want to see up-to-date values, you can use a logical model, such as SAP BW/4HANA Open ODS Views, or SAP HANA Calculation Views. However, if they need a preserved snapshot, use a data persisting model, such as SAP BW/4HANA Datastore Objects (advanced). By defining the key fields of an object, you define the level of granularity.

If you decide to model an SAP BW/4HANA InfoProvider, decide on a field-based or InfoObject-based approach. Use a field-based approach if you do not need a domain for master data. Decide whether a category will be modeled as attribute or hierarchy level in separate master data models, or saved together with each record. This is a good starting point for a documentation.

If you decide to use an SAP BW/4HANA model, you can focus on views, or persist with values in a Datastore Object (advanced). If you decide to use views, you define different types of Open ODS Views and their relations as a virtual star schema.

For Datastore Objects (advanced), the most important question is the type of Datastore Object (advanced) you need.

If all records are only aggregated, never overwritten, and the key consists of all characteristics of the Datastore Objects (advanced), then use a Data Mart DataStore Object.

The main advantages of a Data Mart DataStore Object are as follows:

• It is easy to administrate. If new characteristics are added or removed from the list of fields, there is no need to adapt the key manually.

• New records are immediately available for reporting.

• It can contain more than 3000 characteristics.

The main drawback is that only corrections of transactional data can only be implemented by adding a Storno record.

If you need an overwrite functionality for changing characteristics or InfoObjects, use other types of Datastore Objects (advanced) with specified key, for example, a Standard DataStore Object.

For characteristics, define if they are integrated as InfoObject or as a field. Use InfoObjects to load a value domain, attributes, texts, and hierarchies, and make them available in Queries. If neither is required, simply use a field with a specified data format. The preceding figure lists the differences between these methods.

Attributes and hierarchies are stored separately in master data tables, reducing the redundancy. Values are derived at reporting time. Use this modeling option with not time-dependent attributes or hierarchies for the tracking history scenario B (current view). With time-dependent attributes or hierarchies, tracking history scenario C (key date based) is modeled.

Attributes can also be represented as characteristics of the fact (transactional) data table, therefore, they are stored redundantly in each transactional record. The values are already determined during data load. This modeling option is used for the tracking history scenario A (historical truth).

The process for deriving an SAP BW/4HANA model for master data involves the following steps:

1. List all areas of business and identify which characteristics are relevant for them.

2. Collect and combine requirements from all relevant models.

The preceding figure displays how you can gather the attributes and properties needed for an InfoObject.

In the first step for each InfoObject, list the areas of business for which it is relevant. For example, the product characteristic is relevant for a production model and a sales model, but not for HR.

In the second step, you must include all properties for the InfoObject that are necessary for at least one model. The following are some examples:

• Assume that for the production model, product texts are only needed in English. However, for the sales model, product texts are needed in English and French. Then, because of the sales model, product texts must be specified as language-dependent.

• Assume that for the production model, attributes weight, and category are required, and for the sales model, price and category are needed. Then altogether, the product InfoObject needs weight, category, and price.

• Assume that for the production model, the category attribute, does not need to be time-dependent, but for the sales model, it must be time-dependent. Then altogether, the category attribute must be time-dependent.