1. RELATION

2. 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

3. 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

4. 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)

5. 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

6. 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

7. Relation

8. Relational Integrity Constraints.
Key constraints
Domain constraints
Referential integrity constraints

9. 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)

10. 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

11. 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!

12. 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

13. 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.

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

23. 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

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

25. 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.

26. 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.

27. 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

28. 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.

29. 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

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

31. 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…)

32. 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

33. 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

34. 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

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