data modelling1
•Download as PPT, PDF•
0 likes•742 views
A data modeling training document outlines objectives like explaining data modeling, its uses, and components. Data modeling involves creating a graphical representation of information to be stored in a system. It has basic components like entities, attributes, and entity types. Relationships between entities have cardinality, and SAP comes with its own data model called the Enterprise Data Model.
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (17)
Similar to data modelling1
Similar to data modelling1 (20)
More from Kranthi Kumar
More from Kranthi Kumar (20)
data modelling1
- 1. Data Modeling March-2005 Data Modeling | 2.15.02
- 2. Objectives • The participants will be able to : – Explain Data Modeling – Know uses of Data Modeling – Describe the Basic Components of a Data Model – Know Data Modeler/ABAP Dictionary Terminology – Know about Optionality and Cardinality – Use SAP Graphic Notation and SAP Text Notation – Explain Data Model Hierarchies and the SAP EDM – Link a data model to dictionary objects March-2005 Data Modeling | 2.15.02 2
- 3. What is Data Modeling? March-2005 Data Modeling | 2.15.02 3 Data Dictionary Real World DataData DictionaryDictionary Data Model
- 4. Uses of a Data Model March-2005 Data Modeling | 2.15.02 4
- 5. Basic Components of a Data Model March-2005 Data Modeling | 2.15.02 5 EntityEntity Customer AttributeAttribute 30 S. 17th St. Entity TypeEntity Type Order
- 6. Entity March-2005 Data Modeling | 2.15.02 6 Customer Order Product
- 7. Attribute March-2005 Data Modeling | 2.15.02 7 J. ElkinsJ. Elkins Customer 30 S. 17th St.30 S. 17th St.30 S. 17th St.30 S. 17th St. 215-555-8000215-555-8000215-555-8000215-555-8000
- 8. Entity Type March-2005 Data Modeling | 2.15.02 8 Order Customer Product
- 9. Data Modeler / ABAP Dictionary Terminology Data Modeler ABAP Dictionary Customer: entity record Customer address: attribute field Customers: entity type table March-2005 Data Modeling | 2.15.02 9
- 10. Relationships between Entities March-2005 Data Modeling | 2.15.02 10 Customer Order
- 11. Cardinality March-2005 Data Modeling | 2.15.02 11 One - to - Many Many - to - Many One - to - One
- 12. Many-to-Many Relationships March-2005 Data Modeling | 2.15.02 12 Order Order Lines 1 1 A26 Order # Qty Part # 1 3 C589 2 1 A26 Primary Key: Order Number Primary Key: Product Number Primary Keys: Order Number Product Number
- 13. Optionality March-2005 Data Modeling | 2.15.02 13 ? Customer Order ?Customer
- 14. Referenced and Dependent Entity Types March-2005 Data Modeling | 2.15.02 14 Dependent Entity Type Referenced Entity Type Customer ID Name Address . . . Order ID Date of Order Customer ID . . . Customer Order Referenced Dependent
- 15. SAP Graphic Notation March-2005 Data Modeling | 2.15.02 15
- 16. Example Using Graphic Notation March-2005 Data Modeling | 2.15.02 16 Customers Orders
- 17. Practice Using Graphic Notation I March-2005 Data Modeling | 2.15.02 17 Professors Students
- 18. Practice Using Graphic Notation II March-2005 Data Modeling | 2.15.02 18 Professors Students
- 19. Practice Using Graphic Notation III March-2005 Data Modeling | 2.15.02 19 Students Enrolment Records Courses
- 20. SAP Graphic Notation with Text Notation March-2005 Data Modeling | 2.15.02 20 1 C N CN
- 21. SAP Text Notation March-2005 Data Modeling | 2.15.02 21 1 C N CN 1 C N CN 1 C 1 C nn :: mmnn :: mm
- 22. Example Using Text Notation March-2005 Data Modeling | 2.15.02 22 Customers Orders 1 CN:
- 23. Practice Using Text Notation I March-2005 Data Modeling | 2.15.02 23 Students Professors :
- 24. Practice Using Text Notation II March-2005 Data Modeling | 2.15.02 24 Students Professors :
- 25. Practice Using Text Notation III March-2005 Data Modeling | 2.15.02 25 Students Enrolment Records Courses :
- 26. Category March-2005 Data Modeling | 2.15.02 26 Referential Hierarchical Aggregating ? Conditional-Referential Specialisation
- 27. Relationship Category: Hierarchical March-2005 Data Modeling | 2.15.02 27 Department Key: Department Number Course Key: Department Number Course Number
- 28. Relationship Category: Aggregating March-2005 Data Modeling | 2.15.02 28 Student Key: Student ID Number Enrollment Record Key: Student ID Number Course NumberCourse Key: Course Number
- 29. Relationship Category: Referential March-2005 Data Modeling | 2.15.02 29 Department Key: Department Number Professor Key: Professor Number
- 30. Relationship Category: Conditional- Referential March-2005 Data Modeling | 2.15.02 30 Department Key: Department Number Professor Key: Professor Number
- 31. Relationship Category: Specialization March-2005 Data Modeling | 2.15.02 31 Business Customer Key: ID Number Customer Key: ID Number
- 32. Data Model Hierarchies and the SAP EDM March-2005 Data Modeling | 2.15.02 32 General Accounting Chart of Accounts Currency FI . . . . . . . . .
- 33. Linking a Data Model to ABAP Dictionary Objects March-2005 Data Modeling | 2.15.02 33 DataData DictionaryDictionary Data Model
- 34. Summary •A data model is a graphical representation of the information that is to be stored and processed by a system. •SAP comes with its own data model, called the Enterprise Data Model (EDM), that describes the data design of the SAP system. •The basic components of a data model are Entities, Attributes & Entity types. •The cardinality of a relationship describes the number of entities of one type that relate toMarch-2005 Data Modeling | 2.15.02 34
- 35. Questions •What is a data model ? •What is SAP's data model called ? •What are the basic components of a data model ? March-2005 Data Modeling | 2.15.02 35
Editor's Notes
- A data model is a graphical representation of the information that is to be stored and processed by a system. It is composed of the entities about which you will store information (e.g., customers) and the relationships among those entities. It serves as a road map that documents information stored in the data dictionary. Data modeling is the process of analysing a real-world activity, determining the information necessary for performing that activity, and documenting that information in a data model. Any process that involves data transfer (such as the placing of an order) is a strong candidate for data modeling.
- A data model can be used: As a basis for application design (this is an example of “top-down”data modeling) As a road map when creating objects in the data dictionary (this is also “top-down” data modeling) As documentation for an existing system (this is called “bottom-up”data modeling) It is good practice to create and maintain a data model for a system. However, in most systems (and in SAP), it is not necessary to create a data model in order to create objects in the dictionary. SAP comes with its own data model, called the Enterprise Data Model (EDM), that describes the data design of the SAP system. SAP also comes with its own data modeling tool, the SAP Data Modeler, with which you can view the EDM or create your own data models. SAP calls the EDM the “commercially-oriented model of the real world”. We will learn more about data modeling in general, and the SAP Data Modeler in particular, throughout the remainder of this chapter.
- The basic components of a data model are: Entities Attributes Entity types
- An entity is a uniquely identifiable object for which information is to be collected. Examples of entities might be customers, products and orders.
- An attribute is a characteristic of an entity. Examples of attributes might be a customer’s name, address and telephone number.
- An entity type is a set of entities with common attributes. Examples of entity types might be the sets of all customers, all products and all orders.
- The above slide demonstrates how data modeling and data dictionaryterminology coincide. An additional term that is important to learn is primary key: A primary key is that attribute or combination of attributes that uniquely identifies an entity of a particular type. A customer ID number might serve as the primary key of the customers entity type. Although the concept of a primary key is important to understanding the SAP Data Modeler, you can’t actually specify which attributes make up the primary key when building a data model. When building tables in the dictionary, however, you can and must specify a primary key.
- In addition to representing information about entities, data models also represent the relationships between entities. For example, a business is not only interested in customers, orders and products, but also which customers place which orders and which orders are for which products. These relationships represent the business rules that indicate how data is to be stored and processed (such as whether customers can place a second order before paying for the first one). Relationships between entities can be classified in several ways: In terms of cardinality In terms of optionality In terms of category
- The cardinality of a relationship describes the number of entities of one type that relate to entities of other types. For example: There is likely to be a one-to-many relationship between customers and orders. In other words, a customer may place several orders, but each order belongs to a single customer. There is likely to be a many-to-many relationship between orders and products. In other words, an order may consist of several products, and each product may be referenced in more than one order. There is likely to be a one-to-one relationship between consultants and laptop computers. In other words, a consultant possesses one laptop computer, and a laptop computer belongs to a single consultant.
- There is a problem with many-to-many relationships. It is not possible to directly represent those relationships in a normalised relational database. A discussion of normalisation is beyond the scope of this course, but what you need to know is that many-to-many relationships are represented in normalised relational databases by being “broken apart” into two one-to-many relationships with an intermediate entity type. Let’s take the example of orders and products. In order to represent this many-to-many relationship, we would first create an intermediate entity type, such as “order lines”. There would be a separate order line for each product. Next, we would create a one-to-many relationship between orders and order lines (an order can have many lines, but each line belongs to exactly one order). Finally, we would create a one-to-many relationship between products and order lines (a product can be referenced by many lines, but each line refers to exactly one product). This has the same effect as creating a many-to-many relationship between orders and products. You can see what this would look like in a data model in the above slide.
- The optionality of a relationship describes whether or not entities of one type must refer to entities of another type. For example, an order must belong to a customer. It does not make sense to have an order on file that was not placed by a customer. A customer, however, does not have to have an order. Every business wants to keep a record of its customers, whether or not they currently have orders outstanding. In this example, the relationship from orders to customers would be mandatory, but the relationship from customers to orders would be optional.
- When representing entity relationships, it is necessary to give one entity type additional attributes that refer back to the primary key of the other entity type. Only one entity type in the relationship contains the additional attributes. For example, the orders entity type would have an attribute for customer ID, indicating which customer had placed the order. Since a customer could place many orders, however, the customer entity would not contain an attribute for order ID. The entity type that contains the additional attributes is the “child”, or dependent, entity type. The other entity type is the “parent”, or referenced, entity type. In one-to-many relationships, the entity type that is on the “many” side of the relationship is always the dependent entity type. In one-to-one relationships, you may choose which entity type you would like to make as the dependent entity type. The concept of referenced and dependent entity types is necessary to fully understand the notation SAP uses to represent cardinality and optionality.
- SAP groups the terms cardinality and optionality together and calls them both cardinality. The above slide indicates the graphical notation that SAP uses torepresent cardinality. In the SAP Data Modeler, the graphical notation is only shown for one direction (from the referenced entity type to the dependent entity type). For practice and clarity, however, we will do some examples and exercises using the notation in both directions.
- A customer may have zero, one or many orders. An order must refer to exactly one customer.
- Fill in the appropriate graphical notation on the above slide: A professor may advise multiple students. A student must have exactly one professor as an adviser.
- Fill in the appropriate graphical notation on the above slide: A professor may advise multiple students. A student may have a professor assigned as an adviser.
- Fill in the appropriate graphical notation on the above slide: Students may enroll in many courses. A course may have many students enrolled. Enrolment records must refer to valid students and valid courses.
- The above slide indicates the text notation that SAP uses to represent cardinality. When specifying the cardinality of a relationship in the Data Modeler or in the ABAP Dictionary, you must use the text notation listed above, in the format: n : m The left-hand side of the colon refers to the relationship (the arrow) from the dependent entity type to the referenced entity type. This is called the n side of the relationship. The right-hand side of the colon refers to the relationship from the referenced entity type to the dependent entity type. This is called the m side ofthe relationship. You may find the text notation easier to understand if you first draw the relationship using graphical notation and then use the above slide to “translate” the graphical notation to text notation.
- Here are the possible values for each side of the n:m notation. For the left side: n = 1Each dependent entity refers to exactly onereferenced entity. n = CEach dependent entity refers to zero or onereferenced entities. For the right side: m = 1Each referenced entity has exactly onedependent entity. m = CEach referenced entity has zero or onedependent entities. m = NEach referenced entity has at least onedependent entity. m = CNEach referenced entity has zero, one or many dependent entities.
- A customer may have zero, one or many orders. An order must refer to exactly one customer.
- Fill in the appropriate text notation on the above slide: A professor may advise multiple students. A student must have exactly one professor as an adviser.
- Fill in the appropriate text notation on the above slide: A professor may advise multiple students. A student may have a professor assigned as an adviser.
- Fill in the appropriate text notation on the above slide: Students may enroll in many courses. A course may have many students enrolled. Enrolment records must refer to valid students and valid courses.
- Relationships are also identified by their category. A relationship’s category provides information about whether one entity is identified by its relationship to another entity. There are five relationship categories specified in SAP: Hierarchical Aggregating Referential Conditional-Referential Specialization
- In a hierarchical relationship, a dependent entity is identified by its relationship to exactly one other entity of a referenced entity type. The full primary key of the referenced entity type becomes part of the primary key of the dependent entity type. Primary key for department (academic department): Department number Primary key for courses: Department number, course number For example, the course Biology 101 is identified by its number (101) and its department (Biology). Remember that you don’t actually specify an entity type’s primary key in the data modeler.
- In an aggregating relationship, a dependent entity is identified by its relationships with multiple entities of other entity types. The full primary keys of the referenced entity types become part of the primary key of the dependent entity type. Primary key for student: Student ID number Primary key for course: Course number Primary key for enrolment record: Student ID number, course number For example, the enrolment record indicating that student 1224 is taking Biology 101 is identified by its student (1224) as well as its course (Biology 101). Aggregating relationships are what are used to handle many-to-many relationships.
- In a referential relationship, the dependent entity is not identified by its relationship to the referenced entity, and the relationship is non-optional. The primary key of the dependent entity types is not affected by the relationship. Primary key for professor: Professor number Primary key for department: Department number For example, the department Biology is not identified by its chairperson. In other words, the chairperson can be changed without changing the identity of the department itself. However, in this example, since the relationship is a referential relationship, a department must always have a chairperson.
- A conditional-referential relationship is the same as a referential relationship except that the relationship is optional. The primary key of the dependent entity types is not affected by the relationship. Primary key for professor: Professor number Primary key for department: Department number For example, the department Biology is not identified by its chairperson. In other words, the chairperson can be changed without changing the identity of the department itself. However, in this example, since the relationship is a conditional-referential relationship, a department need not have a chairperson. It is possible for the position to be vacant.
- In a specialising relationship, one entity type represents a subset of another entity type. In this case the dependent entity type is known as the specialisation, and the referenced entity type is known as the generalisation. The primary key of the specialisation is the same as the primary key of the generalisation. Specialisations are a special kind of hierarchical relationship. Generalisations and specialisations store different information in non-key attributes. For example, a telephone company might store general information about all customers (such as name and address) in a customer entity type, while more specific information might be stored in a specialisation that only applied to business customers (such as the appropriate contact person at the business, or whether the business was a corporation, partnership, or sole proprietorship).
- Data models in SAP can be organised hierarchically. In other words, it is possible to create small data models that represent a portion of a system. These data models can then be linked together to form a larger, more complete data model. For example, in the Enterprise Data Model (EDM) that comes delivered with SAP, there are “small” data models representing the Chart of Accounts and Currency types. These data models are in turn parts of the larger data model for General Accounting, which together with other data models form the overall data model for the FI module. When data models are organised hierarchically, it is possible to display the hierarchy and then “drill down” to the level of detail you desire. Some or all of the hierarchy may then be displayed graphically. To access the EDM, go to the main screen for the Data Modeler. From there, click one of the buttons: SAP Applications SAP Architecture
- The SAP Data Modeler is integrated with the ABAP Dictionary. In the Data Modeler, it is possible to specify the dictionary table that a particular entity type represents. This permits easy navigation between the Data Modeler and the ABAP Dictionary. Additionally, when you assign an entity type to a table, the system automatically enters the entity type’s attributes for you (they are taken from the table’s field structure). If you change the table’s structure, the entity type’s attribute list will automatically be updated. However, if you change the entity type’s attributes, the dictionary table is not changed.