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

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

View Full Document Right Arrow Icon
* 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).
Background image of page 1

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

View Full DocumentRight Arrow Icon
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.
Background image of page 2
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.
Background image of page 3

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

View Full DocumentRight Arrow Icon
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
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.

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 Right Arrow Icon
Ask a homework question - tutors are online