- Database Structure
- Relational Database Management System (RDBMS)
- Database Concepts
- Summary
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Relational Database Management System (RDBMS)
The SAP database contains literally thousands of tables that store information. Some products like ECC and R/3 have more than 30,000 tables in fact, whereas other products like CRM might have fewer than 10,000. Regardless of the number, these tables are tied to each other through established relationships. This connection of multiple tables through relationships creates what is known as a Relational Database Management System (RDBMS).
An important benefit in the design of an RDBMS is that it eliminates redundancy. To understand this better, look at the concept of an RDBMS using the phonebook example. In this example, the phonebook represents a table that stores the names, addresses, and phone numbers for everyone in your city. Say that you obtain a different phone book for your same city, one that includes email and website addresses along with the other data. Now you have two separate tables that store much of the same information, although the second source includes data not available in the first.
Say that you wanted to create a report listing all the Names and Phone numbers from the first table, and include the email addresses in this report by pulling data from the second book. This data is stored in two different tables, and hence problematic. If you updated the first phonebook table with all the information from the second directory, the same information would be stored in two different tables.
Besides being redundant and therefore a waste of resources, this is more cumbersome from a maintenance perspective too. Say that someone’s physical home address changes, as they often do: You would then be required to change this data in both tables. Using an RDBMS database design, these problems are no longer a concern, because the tables and therefore their discrete data are associated with one another through relationships specified within the database. In the example, both the tables contain a column (or field) containing the person’s name. In an RDBMS, these two tables could therefore be linked by the name field, or any other field they have in common (see Figure 3.2).
Primary Key
Database tables in an RDBMS are required to contain a unique field that individually distinguishes one particular record from all others in the database. This unique field is called a primary key and is composed of one or more fields that make every record in a database unique.
)
Figure 3.2 The phonebook example using an RDBMS to link tables.
I’ll use the SAP R/3 Human Resources functional area as an example of a primary key. The Human Resources module stores all your company’s employee data. Some of your employees will have the same department number, some will have the same job title, and some will even have the same salary. Thus, none of these are good primary key candidates. In order to uniquely distinguish each employee of a U.S.-based company, a primary key could be used based on the employee’s Social Security number, though. Because a person’s Social Security number is truly unique, it would be a good candidate for a primary key in your employee’s table. Figure 3.3 gives a sound example of two different tables and their unique primary keys.
)
Figure 3.3 Primary keys in an Employee table and a Department table.
Foreign Key
You use the primary key field in one table to link it to another. The common link field in the other table is usually not the primary key in the other table: It is called a foreign key.
Let’s use the Human Resources employee example again. You have an employee table that stores the basic employee data with a primary key defined as the Social Security number, and you have a Department Table that stores all the department numbers and departments for employees with a department number as the primary key (see Figure 3.3). In these two tables, you have the same field, Department Number. In the Employees table, the department number is the foreign key linking it to the department table (see Figure 3.4).
)
Figure 3.4 The department numbers in the Employee Table are checked against the Check table using a foreign key relationship.
The foreign key is used to establish consistency between tables. An example of consistency would be that you do not want an employee entered into the system with a department number that is not currently in the database table in which department numbers are stored. The use of a foreign key relationship is to check that the number entered exists in the department table, as shown in Figure 3.4, and reject any records that do not. This way all the data is consistent in your tables.
Check Table Violation
Your SAP database will not accept data in any fields that contain a foreign key to a Check table in which the data entered does not exist in the Check table (see Figure 3.5).
)
Figure 3.5 On the Employee Personnel Data screen the Mar. status field will only accept an entry from the Check table.
In this example, you need to enter a Marital Status for the employee. The possible values in the Check table are listed in the small window. If you enter a value that is not listed in the Check table as a valid entry, you will receive a check violation error like the one shown in Figure 3.6.
)
Figure 3.6 A Check violation message appears when you enter data into a field that is not in the Check table for that field.
An error message will appear when you enter a value (in this case in SAP) that is not a valid entry in the Check table.