3.2-3.3

3.2-3.3 - In this section we will discuss about the most...

This preview shows pages 1–5. Sign up to view the full content.

* In this section we will discuss about the most important characteristic of the relational model: KEYS. A key is one or more attributes that determine other attributes, in other words if two entity instances have the same value for the key, they will have also the same value for the determined attributes. We already discussed about an important type of key that is named PRIMARY KEY and determines uniquely each entity instance in the table. * A key may have one attribute or more attributes. * If a key consists of two or more attributes, it is called COMPOSITE KEY. * Let us consider the STUDENT table, from the previous section. * The primary key in that example is the student identification number: STU_NUM. * However, let us assume we do not have such a number for the students. Which will be another available PRIMARY KEY? * Let us consider the name (which will be a composite key: STU_LNAME, STU_FNAME and STU_INIT). However, there are many instances when you have 2 persons with the same name in a big school. Therefore, it would not be a good PRIMARY KEY because is likely to have duplications. Another idea is to consider also the date of birth which will reduce significantly the chances for duplication (but still such a situation may appear). A policy to solve such a situation will be needed (For instance adding a suffix to the first name).

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
As described in the previous slide at the basis of keys is the principle of determination. Intuitively this principle means that knowing the value of an attribute A you can determine the value of an attribute B. More formally, if two entity instances (rows) have the same value for attribute A they must have the same value for the attribute B. * In our example the student identification number will determine the other attributes of a student, for instance the student last name. However the reverse is not true. If you have the student last name this will not determine other attributes. For instance the last name “Smith”, correspond with two entity instances that are having different values for most of the attributes.
Another notion if that of functional dependence: Attribute B is functionally dependent on A if A determines B, which means that each value in column A determines one and only one value in column B. In our example the student last name is functionally dependent on student identification number.

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
Let us consider the following problem. For the STUDENT table we have the following rules defining how the student classification (Freshman, sophomore, junior and senior) is obtained. It is a simple rule based on the numbers of hours completed, as
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 01/22/2011 for the course IT 214 taught by Professor Staff during the Spring '08 term at George Mason.

Page1 / 11

3.2-3.3 - In this section we will discuss about the most...

This preview shows document pages 1 - 5. Sign up to view the full document.

View Full Document
Ask a homework question - tutors are online