In mathematical terms, the relation itself can be expressed simply in terms of the attributes it contains:

The Relational Model The relational data model organises data as 2-dimensional tables or relations. An example of one such relation would be STUDENT shown below. As we have seen in the wine list example, tables (relations) hold information in rows that can be updated, added to or deleted. RELATION: STUDENT ID Surname Sex Birth_Place Date_of_Birth P1 Smith Male Dublin 030382 P2 Jones Female Galway 040281 P3 Malone Male Mayo 020381 Terminology In everyday terms, the table STUDENT contains five columns and three rows (or entries). However, in relational theory, the terminology has been formalised and is based on the relation s mathematical structure. Therefore, the rows of a relation are known as tuples while the columns are the attributes of the relation. Each tuple of a relation holds individual pieces of information for each of the attributes specified. For example, the value of the Surname attribute in the first tuple is Smith. In mathematical terms, the relation itself can be expressed simply in terms of the attributes it contains: STUDENT (ID, Surname, Sex, Birth_Place, Date_of_Birth) We call a relation with specific sample data, for example the table above, an instance of the relation. Note that different terminology can be used in books for attributes, tuples and relations (as table below). We will use the mathematical terminology in these notes. Mathematical terminology In database manuals In some books Relation Table Table Attribute Field Column Tuple Record Row Database Systems (EE221) - Page 10

A database can be made up of more than one relation. In order to be able to locate information in the database, each relation must have a unique name (to differentiate between relations); as must each attribute of a relation (no two attributes may have the same name within one relation but there is no restriction on having the same attribute name in two different relations). Domains Let us now consider the characteristics of an attribute s values. Such values come from domains, and the domain for an attribute defines the valid values of that attribute. Domains are a more abstract concept than types or sorts in programming languages - two sets of values can be of the same type but of a different domain. For example, in the STUDENT relation, Surname and Birth_Place are both character strings, but they come from different domains, because they signify different things - Surname is from the domain of all valid surnames, while Birth_Place comes from the domain of all valid locations. Note that, it is permitted for multiple attributes within a relation to hold values from the same domain. For example, if we wished to add an attribute to STUDENT with the name of the next-of-kin, this attribute could also come from the NAME domain. It is also possible for attribute values themselves to be relations, in which case, the attribute domains are instances of that relation. In the relation LIVED-IN, the attribute Residence is in itself, a relation. The attributes of Residence are City and Date-Moved-In. The domain of the attribute Residence is a combination of the domains of its attributes. However, we will see later that using such multi-valued attributes is considered bad practice, and in fact disallowed in most relational theories. RELATION: LIVED-IN Person Residence Martha City Date-Moved-In New York 030303 Boston 070705 Jack City Date-Moved-In Boston 040593 Philadelphia 070699 Database Systems (EE221) - Page 11

Summary of Properties of Relational Tables Relational tables have the following properties: 1. Different relations (tables) must have unique names 2. Each tuple (row) in a relation is unique 3. Each attribute (column) in a relation must have a unique name 4. The order of attributes in a relation is not significant 5. The order of tuples in a relational table is not significant 6. All values of an attribute are from the same domain 7. Values of attributes are atomic (for most relational theories) Keys of Relations The notion of a key is fundamental to relational theory. A key of a relation is a set of one or more attributes that uniquely identify tuples in the relation. That is, given any possible value of the key, at most there will be one tuple in the relation with a matching value of the key attributes. This property is called the uniqueness property of relation keys. For example, in the STUDENT relation, ID is a key to the relation. STUDENT (ID, Surname, Sex, Birth_Place, Date_of_Birth) Note that a relation can (and normally does) have more than one key. Some more terminology A key, as we have defined it above, is normally termed a superkey defined as: a set of attributes whose values identify a unique tuple in a relation. A superkey can include any subset of the relation s attributes that possesses this uniqueness property. For example, in the relation STUDENT, the ID attribute is a superkey, as it uniquely defines a tuple of the relation. Taken together, the attributes ID and SURNAME is also a superkey, because again only one tuple in the relation can have a given value of these attributes. In fact, all the attributes of a relation taken together also form a superkey! This is implied by property 2 above. Note also that a key can never have a null (blank) value. Database Systems (EE221) - Page 12

Relational theory also calls for a more restricted type of key where the number of attributes in a superkey to a minimum (excludes any unnecessary ones). Such keys are called relation keys. A relation key may be formally defined as a set of one or more attributes of a relation such that the following two properties hold for all time for any instance of the relation: Uniqueness: the set of attributes has a unique value for each tuple in the relation. Nonredundancy: if an attribute is removed from the set of attributes in the relation key, then the remaining attributes will not possess the uniqueness property. A relation may also have more than one relation key. If a relation has more than one, it is a good idea to choose one relation key to be the primary key of the relation. This is the key which will be principally used to retrieve a particular tuple (row) from a relation. Note that whether or not a set of attributes forms a relation key is a matter of interpretation for the database designer when creating a data model. Consider the following relation: LECTURER (ID, Name, Telephone_Number, Office_Number) All DCU employees have a unique ID number and these numbers are never reused or changed so the attribute ID will form a relation key. It is possible that two lecturers share an office or telephone, and that lectures can move rooms or phone numbers, so neither of these attributes will form a relation key. However, in an institute where every lecturer always has their own office then Office_Number will also be a relation key. It requires analysis of the particular application to determine these facts and to ensure the database schema correctly mirrors the real world being modelled. Analysis and data modelling is an important part of database design which will be touched on in the next section. Database Systems (EE221) - Page 13

Foreign Keys Another important concept in relational theory is that of a foreign key. A foreign key in the relation R2 is a set of one or more attributes of R2 (not necessarily a part of a relation key of R2) which form a relation key in another relation R1. The foreign key in R2 must come from the same domain as the relation key in R1. As an example, suppose we have two relations in a database used to keep track of which student has been assigned which final year project: STUDENT PROJECT (ID, Surname, Forename, Programme, Date_of_Birth) (Proj-ID, Project-Title, Student-ID, Year) STUDENT just has one relation key, {ID}. Each year the project numbers are reused but the database will store project information over many years, so the relation key of PROJECT is: {Proj-ID, Year} In our example, the attribute Student-ID of PROJECT is designated a foreign key, as it reflects the attribute ID which is the relation key of STUDENT. This example illustrates that the foreign key does not necessarily have to have the same name as the primary key it reflects; however, they must both have the same domain. Foreign keys are important concepts which model the relationships between different entities. For example the existence of the foreign key Student-ID indicates that there is a relationship between the entities STUDENT and PROJECT, that is, each project is assigned to a student. This relationship allows us to navigate between tables when retrieving data and helps to enforce integrity rules in a database. We will see in the next section that these relationships between entities can be expressed graphically using Entity-Relationship (E-R) diagrams. Foreign key ownership Note that it is considered that a foreign key in a relation R1 is owned by the relation who s relation key it reflects. For example, because Student-ID in PROJECT is a foreign key it may only take on an existing value of ID in STUDENT. Otherwise we could loose referential integrity e.g. we could assign a project to a non-existent student (bad). This is why the term foreign is used the attribute or attributes in the foreign key are really just visiting from another relation the value of the foreign key is determined by their home relation. Database Systems (EE221) - Page 14

Prime and Non-Prime Attributes The final piece of terminology to be introduced refers to prime and nonprime attributes. A prime attribute is an attribute which is part of at least one relation key. A non-prime attribute is an attribute that is not part of any relation key. Examples of prime attributes in PROJECT are Proj-ID and Year, while nonprime attributes are Project-Title and Student-ID. Database Integrity Rules There are two rules relating to database integrity which must be obeyed at all times to ensure that data can be maintained and retrieved successfully. To understand their significance, imagine what would happen if one of the attributes of a primary key were left blank when a tuple was inserted into a relation it would be impossible to ever retrieve that tuple. Similarly, a problem will exist if a foreign key of a relation contains a value which is not reflected in the relation where this attribute is a primary key. For example, if a particular Student-ID in the PROJECT relation did not have a corresponding value of ID in the STUDENT relation, then there would be confusion in the logic of the database, i.e. the project would be assigned to a non-existent student. The two database integrity rules are: 1. Entity Integrity: No attribute participating in the primary key of a relation is allowed to accept null values. The primary key is the unique identifier in a relation - lack of information in the primary key would result in tuples which have no identity. This cannot be permitted. 2. Referential Integrity: If a relation R2 contains a foreign key (i.e. one or more attributes which form a primary key in another relation R1), then every value of the foreign key must either correspond to values in R1, or be wholly null. This ensures that if some tuple t2 references another tuple tl, then tl must exist, therefore ensuring no conflicting information in the data. Database Systems (EE221) - Page 15

Exercise 1 Given the group of four relations and the additional information listed below: (1) Identify all relation keys for each relation. (2) Identify a suitable primary key for each relation. (3) Identify any foreign keys in the set of relations. (4) Identify the non-prime attributes in each relation. In each case, state any assumptions you make about your interpretation of the relationships between the attributes. STUDENT (Student_ID, First_Name, Last_Name, Address, E-mail) REGISTER (Student_ID, Module_ID, Semester) LECTURER (Lecturer_ID, First_Name, Last_Name, E-mail, Office_Number) MODULE (Module_ID, Module_Name, Faculty, Lecturer_ID) The following information is also known: Each student and lecturer has their own unique e-mail address. More than one student may live at the same address. A student may register for a module more than once (e.g. to repeat it), but only once in any given semester. (Note: the values of Semester include a year code e.g. 2-07 is Semester 2 in 2007, etc.). Lecturers may share an office but, if they do, they will not have the same last name. Two faculties may happen to use the same module name for two distinct modules. Exercise 2 In each of the following groups of relations, identify the relation keys, stating any assumptions. Are there any likely foreign keys? Qualify your answer. List the prime and the non-prime attributes in each relation. (i) RESIDENCE (House-Number, Street-Name, City, Country, Date-moved-in) LIVED-IN (Person-ID, Residence-ID) (ii) CITIES (Map-Reference, City-Name, Population) ROADS (Road-Name, Start-City-Name, End-City-Name) Database Systems (EE221) - Page 16