Relational Database Management Systems What is a RDBMS?

Simply put, an RDBMS is a type of DBMS that organizes data into a series of records held in linked tables. While there are other types of database management approaches, the relational approach is the most common in many applications, including GIS. The organization around linked tables aids in data access and transformation because the linkages based on record values are very flexible. That is, to say, the rules for linkages are established and the actual association of records is based on values. There are several fundamental definitions to consider when thinking about RDBMS.

Domain a pool of values from which specific attributes of specific relations draw their actual values Tuple an ordered list of values Primary key a unique identifier for a table; any column or combination of columns with the property that no two rows of the table have the same value in that column or columns

The Suppliers Relation an example of a relation

When viewing the graphic above, consider the following. The named attributes draw their values from defined domains, which are represented as the star bursts at the top. The entire collection of tuples and attributes is called a relation, which many of us view as tables. The number of attributes in a relation is sometimes referred to as the degree of the relation. Since relational terminology can be expressed in common terms the following figure provides a crosswalk between relational terms and their equivalents.

Common Types of Modeling Errors When using the relation approach for modeling data, there are a variety of mistakes that can be made that result in database errors. At a basic level, the incomplete data model error results from a situation in which an analyst is asked to build a model that is limited in scope. This occurs when the analyst does not have full information about the total requirements for a particular data model. Another class of errors results from a situation in which the there is an incomplete understanding of the problem domain. This is referred to as the mis-modeled problem domain. Among the problems in this class of errors is the mis-modeling of the connectivity between entity sets (or, more properly, relations). Another common error of this type is termed the multi-valued attributes. This

occurs when a set of data that has been modeled as attribute can actually have multiple values and should be modeled as a separate relation. Perhaps the best way to explain this further is through an example. Data Modeling Scenario Consider a requirement to develop a relational database for a small college. The specific application area is tracking student enrollment in classes. Consider the semantic model below: Students enroll in sections This simple expression encapsulates the relationship between two discrete entity sets, students and sections. Obviously, students is a collection of things that have unique properties, with respect to another set of things, sections, which have their own properties. Using the E-R modeling framework, the semantic relationship can be expressed in a convenient graphical form.

In the diagram relations are shown in rectangles, attributes in ovals, and relationships in diamonds. This type of notation is very commonly used in E-R diagrams. Before the database is constructed, analysts convert the content of the E-R diagram in a series of relational schemas. These schemas identify the names of the derived relations and their attributes, as in the example below.

Lets say that some of the students at this college are motivated to have two majors. The typical modeling response to this situation might be to add an additional attribute called major2. However there is a fundamental relational problem with that approach. First, is that not all students may have a second major leading to many blank values for the attribute major2. A further problem arises when some very motivated students decide to triple major. This is a classic mis-modeled domain error known as a multi-valued domain.

A common solution to this problem is to remove the multi-valued attribute (major in this case) to another relation of its own. Note that a new relation, Student_majors has been added to this portion of the diagram. Note further that its association with Students is established in the relationship called Majors_in. This relationship can be expressed in the relational scheme below. Note that relationship manifests itself in the posting of the primary key, ID, from the Student relation as a foreign key in the Student_majors relation.