RELATION

Relational model The relational model represents the database as a collection of relations tables: Tables-relations are saved in the format of Tables A table has rows and columns, where rows represents records and columns represent the attributes. Tuple-A single row of a table, which contains a single record for that relation Relation instance-A finite set of tuples in the relational database system represents relation instance. Relation instances do not have duplicate tuples Relation schema-A relation schema describes the relation name tablename, attributes, and their names

Relation Schema Relation Schema R, denoted by R(A1, A2,…, An), is made up of relation name R and a list of attributes A1, A2,…, An Each attribute Ai is the name of a role played by some domain D in the relation schema R. D is called the domain of Ai and is denoted by dom(Ai) A Domain D is a set of atomic values R is called the name of the relation The degree of a relation is the number of attributes n of its relation schema

Formal Definitions Let R(A1, A2) be a relation schema: Let dom(A1) = {0,1} Let dom(A2) = {a,b,c} Then: dom(A1) X dom(A2) is all possible combinations: {<0,a> , <0,b> , <0,c>, <1,a>, <1,b>, <1,c> } The relation state r(R)  dom(A1) X dom(A2)

Definition Summary Informal Terms Formal Terms Table Relation Column Header Attribute All possible Column Values Domain Row Tuple Table Definition Schema of a Relation Populated Table State of the Relation

Formal definition A scheme is a set of attributes A tuple assigns a value to each attribute in its scheme A relation is a set of tuples with the same scheme

Relation

Relational Integrity Constraints. Key constraints Domain constraints Referential integrity constraints

Key Constraints A set of attributes in the relation, which can identify a tuple uniquely is called a key If there are more than one such a key, these are are called candidate keys A set of attributes in a relation is called a candidate key if, and only if, Every tuple has a unique value for the set of attributes (uniqueness) No proper subset of the set has the uniqueness property (minimality)

Key Constraints Candidate key: {ID}; {First,Last} looks plausible but we may get people with the same name {ID, First}, {ID, Last} and {ID, First, Last} satisfy uniqueness, but are not minimal {First} and {Last} do not give a unique identifier for each row  

Choosing Candidate Keys Important: don’t look just on the data in the table to determine what is a candidate key The table may contain just one tuple, so anything would do! Use knowledge of the real world – what is going to stay unique!

Primary Keys One Candidate Key is usually chosen to be used to identify tuples in a relation This is called the Primary Key Often a special ID attribute is used as the Primary Key

NULLs and Primary Keys Missing information can be represented using NULLs A NULL indicates a missing or unknown value a key attribute can not have NULL values.

Foreign Keys Foreign Keys are used to link data in two relations. A set of attributes in the first (referencing) relation is a Foreign Key if its value always either Matches a Candidate Key value in the second (referenced) relation, or Is wholly NULL This is called Referential Integrity

Foreign Keys - Example {DID} is a Foreign Key in Employee-each Employee’s DID value is either NULL, or matches an entry in the Department relation. This links each Employee to (at most) one Department {DID} is a Candidate Key for Department –Each entry has a unique value for DID

Attributes and Domains A domain is given for each attribute The domain lists the possible values for that attribute Each tuple assigns a value to each attribute from its domain Examples An ‘age’ might have to come from the set of integers between 0 and 150 A ‘department’ might come from a given list of strings A ‘notes’ field might allow any string at all

Referential integrity Constraints work on the concept of Foreign Keys Informally, a tuple that refers to another tuple from another relation should refer to existing tuple In a given relation R1 a set of attributes FK is said to be a foreign key of R1 referencing another relation R2, if the following rules holds: The attributes in FK have the same domain as the primary key of R2 for every tuple in R1 , the attributed in its foreign key FK either reference a tuple in R2 or is null

Referential integrity Constraints When relations are updated, referential integrity can be violated This usually occurs when a referenced tuple is updated or deleted There are a number of options: RESTRICT - stop the user from doing it CASCADE - let the changes flow on NULLIFY – make values NULL

Referential integrity-example What happens if Marketing’s DID is changed to 16 in Department? The entry for Accounts is deleted from Department?

RESTRICT RESTRICT stops any action that violates integrity You cannot update or delete Marketing or Accounts You can change Personnel as it is not referenced

CASCADE CASCADE allows the changes made to flow through If Marketing’s DID is changed to 16 in Department, then the DIDs for John Smith and Mark Jones also change If Accounts is deleted then so is Mary Brown

NULLIFY NULLIFY sets problem values to NULL If Marketing’s DID changes then John Smith’s and Mark Jones’ DIDs are set to NULL If Accounts is deleted, Mary Brown’s DID becomes NULL

Naming Conventions A consistent naming convention can help to remind you of the structure Assign each table a unique prefix, so a student name may be stuName, and a module name modName Naming keys Having a unique number as the primary key can be useful If the table prefix is abc, call this abcID A foreign key to this table is then also called abcID Example

ER – Model to relation mapping Rules for automated translation from ER to relational model help in building “complete” lifecycle tools

Mapping strong entity to Relation Department Dept Name Manager Dept_Id Department(Dept_id, DeptName, Manager) Strong entity type with simple attributes can be mapped into relation in a straight forward manner. Attributes acting as keys in the ER model are retained as keys in a relation model.

Mapping weak entity to Relation Employee EmpNo Insurance Record Insurance Details 1 InsuranceRecord(EmpNo) For weak entity types, include the key of the owner entity type as key attribute(s). These key attributes also form a foreign key into the owner entity type. The CASCADE option is used whenever the owner entity type is updated or deleted.

Mapping 1:1 relationship to relation Department Dept_Id Manager ManagedBy 1 Secretary EmpNo Manager(EmpNo, Dept_Id, Secretary) Manager is strong entity and not weak entity type but still is in total participation This means that manager does not have any existence without being participating in a relationship type of this kind The manager will just be an employee and not manager unless he/she is given department to manage. Department has independent existence

Mapping 1:1 relationship-summery In 1:1 binary relationship between two entities S and T, choose one of them (say S) as the “base” relation If either S or T has a total participation , choose that one as the base. Include primary key of other entity type as a foreign key of the base. Include any relationship attributes as attributes of the base.

Mapping 1:1 relationship to relation Project Proj_Id Consultant Consultation 1 Secretary EmpNo Consultation(Proj_id, EmpNo, Secretary) In case both entities in a 1:1 binary relationship are in total participation, then merge both entity types into one (usually in the name of relationship) Both Project and Consultant are in total participation, this means that: A project has no existence unless is being consulted by a consultant and consultant has not existence unless he/she is associated with a project

Mapping 1:N relationship to relation Employee EmpNo Department WorksIn 1 N Dept_Id Employee(EmpNo, Dept_id,…)

Mapping M:N relationship to relation Empoyee EmpNo Department DeputedTo N M RecordNo Dept_Id Employee(EmpNo,…) Department(Dept_id,…) DeputedTo(EmpNo, Dept_id,RecordNo…)

Mapping M:N relationship to relation In M:N binary relationship, it is not possible to collapse the relationship into any one of the entity type, since the relationship does not identify either entity type uniquely A separate relationship is required to complete the mapping The CASCADE option in referential integrity should be used for the relation created during UPDATE and DELETE. This is because, each instance of the relationship has an existential dependency on the created relation

Mapping M:N relationship to relation Both 1:1 and 1:N relationship can be mapped in the way similar to mapping M:N relationship. This is especially true if number of relationship instances are small and the null-values have to be avoided in the created relation However this is not attractive if there is total participation in 1:N or 1:1 relationship due to the creation of extra unnecessary relations

Mapping multi-valued attributes to relation Bird Species Colour Bird(Species, …) BirdColors(Species, Color, …) For each multi-valued attributes of a given entity type S, create a separate relation that has a primary key of S paired with all value of the multi-valued attribute The CASCADE option should be used for referential integrity of the newly created relation

Mapping n-ary relationship to relation Supplier STRegNo Project Suplies ProjId Part PartId Supplier(STRegNo, …) Project(ProjId, …) Part(PartId, …) Supplies(STRegNo, ProjId, PartId, …)