Defining Relationships and Associations Flashcards
What is cardinality, and why is it important in data models?
Cardinality, also known as multiplicity, describes how many instances of one entity relate to one instance of another entity. It is important because it defines the constraints and the nature of the relationships between entities, ensuring the integrity and accuracy of the data model.
How does UML notation express cardinality?
UML notation expresses cardinality with a range, using a minimum and maximum value. An asterisk (*) is used to indicate an unrestricted maximum. For example:
1..1 means exactly one instance.
0..* means zero or more instances.
What are the cardinalities for the relationship where every employee is assigned to a department?
In this relationship:
Every employee must be assigned to exactly one department: 1..1.
A department can have any number of employees, including zero: 0..*.
Describe the cardinality for the relationship where each department is led by one employee.
For this relationship:
Each department is led by exactly one employee: 1..1.
Not every employee is a leader, and an employee can lead only one department: 0..1.
What are the two ways relationships are expressed in ABAP Dictionary and ABAP CDS?
Relationships in ABAP Dictionary and ABAP CDS are expressed through:
- Associations in ABAP CDS, which define relationships between CDS view entities. Usually, this involves two associations pointing in opposite directions for a single relationship.
- Foreign Keys in ABAP Dictionary, which establish dependencies for table fields to relate to another database table. One foreign key dependency corresponds to one relationship.
Explain the difference between cardinality and multiplicity.
Strictly speaking, cardinality refers to the actual number of instances of an entity, whereas multiplicity specifies the range of allowed values for these instances. In practice, especially in ABAP Dictionary and ABAP CDS, these terms are used synonymously to describe the constraints on entity relationships.
How are foreign key dependencies used in ABAP Dictionary to define relationships?
In ABAP Dictionary, foreign key dependencies are used to establish relationships by defining dependencies between table fields. This ensures that data in one table (the foreign key table) corresponds correctly to data in another table (the primary key table), thereby maintaining referential integrity.
What is the primary purpose of foreign key dependencies in modern ABAP programming?
In modern ABAP programming, the primary purpose of foreign key dependencies is for documentation. In classical ABAP development, they also influenced the user interface by enabling implicit input checks and generating value helps.
How do foreign key definitions in the ABAP Dictionary affect database consistency checks?
Foreign key definitions in the ABAP Dictionary do not affect database consistency checks because they remain on the ABAP layer and are not passed on to the database. Therefore, they do not lead to implicit consistency checks on the database.
What is a foreign key dependency, and what are its components?
A foreign key dependency defines a relationship between two dictionary database tables: the foreign key table and the check table. It links each primary key field of the check table to a corresponding field in the foreign key table. The fields in the foreign key table that form the foreign key must match the primary key fields of the check table.
What are semantic attributes of foreign keys, and how are they used?
Semantic attributes of foreign keys provide additional information to describe the relationship and influence its usage. They include:
Short Description: An explanatory text for the relationship.
Foreign Key Field Type: Indicates whether the foreign key fields are key fields of the foreign key table (#KEY), not key fields (#NON_KEY), or if the foreign key table contains translatable text (#TEXT_KEY).
Value Check for Classical UI: Controls if classical user dialogues perform value checks based on the foreign key relationship.
How is cardinality specified for foreign key relationships in the ABAP Dictionary?
Cardinality is specified with [n, m] immediately after the keyword KEY:
Left side (n): Number of foreign key table records per check table record (values: 1, 0..1, 1.., 0..).
Right side (m): Number of check table records per foreign key table record (values: 1, 0..1).
In the employee and department example, what cardinality should be used if it is mandatory for an employee to be assigned to a department?
If it is mandatory for an employee to be assigned to a department, the cardinality should have m = 1.
What does the left-hand side of the cardinality represent, and what are the possible values?
The left-hand side (n) represents the number of dependent records (foreign key table records) per check table record:
n = 1: Exactly one dependent record.
n = 0..1: At most one dependent record.
n = 1..: At least one dependent record.
n = 0..: Any number of dependent records, including none.
Given the requirement that each department can have multiple employees, but an employee can belong to exactly one department, what is the appropriate cardinality?
The appropriate cardinality for this requirement is (0..*, 1), indicating that:
A department can have any number of employees (0..*).
Each employee must belong to exactly one department (1).
What is the main difference between foreign key dependencies and associations in CDS views?
The main difference is that foreign key dependencies link a foreign key table to a check table, while associations in CDS views are more flexible and can link any association source to any association target. Associations can also be bi-directional, unlike foreign key dependencies.
How many associations can a single CDS view definition contain?
A single CDS view definition can contain any number of associations. For instance, some views in the SAP S/4HANA data model contain over one hundred associations.
What are the components of an association definition in a CDS view?
An association definition in a CDS view consists of the following parts:
- Association Target: Defined using the association to keyword followed by the name of the association target, which should be a CDS entity.
- Association Name: An identifier for the association defined using the AS addition. It’s recommended to start with an underscore (_).
- Association Condition: Defined using the ON keyword, usually comparing view elements of the association source to those of the association target.
Why is it recommended to define an association name?
Defining an association name is recommended because:
It improves code readability.
It allows for having more than one association to the same target.
It avoids confusion by providing a clear identifier for each association.
How do you format the association condition in a CDS view?
The association condition is formatted as follows:
It starts with the ON keyword.
The view elements of the association source are on the left, prefixed with $projection..
The view elements of the association target are on the right, prefixed with the association name.
Can database tables be used as targets in CDS view associations?
While it is possible to use database tables as targets in CDS view associations, it is not recommended. It is better to use CDS entities as targets.
In the example provided, what are the names of the CDS views for the EMPLOYEE and DEPARTMENT tables?
In the example, the CDS views for the EMPLOYEE and DEPARTMENT tables are named R_Employee and R_Department, respectively.
Provide an example of defining an association in the CDS view R_Employee linking it to R_Department.
define view R_Employee as select from Employee
association to R_Department as _Department
on $projection.DEPARTMENT_ID = _Department.DEPARTMENT_ID
{
key EMPLOYEE_ID,
FIRST_NAME,
LAST_NAME,
DEPARTMENT_ID,
_Department
}
In this example:
R_Department is the association target.
_Department is the association name.
The association condition links EMPLOYEE.DEPARTMENT_ID to DEPARTMENT.DEPARTMENT_ID.