Relational Model Characteristics

Logical view of data

What is key?
Integrity rules
Relationship
Data dictionary

> CHANGE, EVERYDAY

View of Data in a DBMS
View of data in a DBMS indicates how the data is visualized
at each level of data abstraction.
Data abstraction allow developers to keep complex data
structures away from the users.
The developers achieve this by hiding the complex data
structures through levels of abstraction.

> CHANGE, EVERYDAY

Three-Schema Architecture
The main objective of this architecture is to have an effective
separation between the user interface and the physical
database. So, the user never has to be concerned regarding
the internal storage of the database and it has a simplified
interaction with the database system.
The three-schema architecture defines the view of data at
three levels:
Physical level (internal level)
Logical level (conceptual level)
View level (external level)

> CHANGE, EVERYDAY

Physical Level/ Internal Level
The physical or the internal level schema describes how the
data is stored in the hardware.
It also describes how the data can be accessed.
The physical level shows the data abstraction at the lowest
level and it has complex data structures.
Only the database administrator operates at this level.

> CHANGE, EVERYDAY

Logical Level/ Conceptual Level
It is a level above the physical level.
Here, the data is stored in the form of the entity set, entities,
their data types, the relationship among the entity sets, user
operations performed to retrieve or modify the data and
certain constraints on the data.
Well adding constraints to the view of data adds the security.
As users are restricted to access some particular parts of the
database.
It is the developer and database administrator who operates
at the logical or the conceptual level.

> CHANGE, EVERYDAY

View Level/ User level/ External level
It is the highest level of data abstraction and exhibits only a
part of the whole database.
It exhibits the data in which the user is interested.
The view level can describe many views of the same data.
Here, the user retrieves the information using different
application from the database.

> CHANGE, EVERYDAY

The figure below describes the three-schema architecture of
the database:

> CHANGE, EVERYDAY

What are Keys in DBMS?
Keys in DBMS is an attribute or set of attributes which helps you to
identify a row(tuple) in a relation(table). They allow you to find the
relation between two tables.
Keys help you uniquely identify a row in a table by a combination of one
or more columns in that table. Key is also helpful for finding unique
record or row from the table. Database key is also helpful for finding
unique record or row from the table.
Employee ID FirstName LastName
11 Andrew Johnson
22 Tom Wood
33 Alex Hale

In the above-given example, employee ID is a primary key because it uniquely identifies an

employee record.
In this table, no other employee can have the same >employee ID.
CHANGE, EVERYDAY
What is a Primary Key?
A Primary Key is a column or group of columns in a table that
uniquely identify every row in that table. The Primary Key can't be a
duplicate meaning the same value can't appear more than once in
the table. A table cannot have more than one primary key.
Rules for defining Primary key:
Two rows can't have the same primary key value
It must for every row to have a primary key value.
The primary key field cannot be null.
The value in a primary key column can never be modified or
updated if any foreign key refers to that primary key.

> CHANGE, EVERYDAY

What is the Alternate key?
Alternate Keys is a column or group of columns in a table that
uniquely identify every row in that table.
A table can have multiple choices for a primary key but only one
can be set as the primary key. All the keys which are not primary
key are called an Alternate Key.
In example, StudID, Roll No, Email are qualified to become a
primary key. But since StudID is the primary key, Roll No, Email
becomes the alternative key.
StudID Roll No First Name LastName Email
1 11 Tom Price [email protected]
2 12 Nick Wright [email protected]
3 13 Dana Natan [email protected]

> CHANGE, EVERYDAY

What is a Candidate Key?
A Candidate Key is a set of attributes that uniquely identify
tuples in a table. Candidate Key is a super key with no repeated
attributes.
The Primary key should be selected from the candidate keys.
Every table must have at least a single candidate key. A table
can have multiple candidate keys but only a single primary key.
Properties of Candidate key:
It must contain unique values
Candidate key may have multiple attributes
Must not contain null values
It should contain minimum fields to ensure uniqueness
Uniquely identify each record in a table > CHANGE, EVERYDAY
Example: In the given table Stud ID, Roll No, and email are candidate keys
which help us to uniquely identify the student record in the table.
StudID Roll No First Name LastName Email
1 11 Tom Price [email protected]
2 12 Nick Wright [email protected]
3 13 Dana Natan [email protected]

> CHANGE, EVERYDAY

What is the Foreign key?
A Foreign Key is a column that creates a relationship between
two tables. The purpose of Foreign keys is to maintain data
integrity and allow navigation between two different instances
of an entity. It acts as a cross-reference between two tables as
it references the primary key of another table.

> CHANGE, EVERYDAY

In this key in DBMS example, we have two table, teach and
department in a school. However, there is no way to see
which search work in which department.
In this table, adding the foreign key in Deptcode to the
Teacher name, we can create a relationship between the two
tables.

This concept is also known as Referential Integrity.

> CHANGE, EVERYDAY
 What is the Compound key?
A Compound Key has two or more attributes that allow you
to uniquely recognize a specific record. It is possible that each
column may not be unique by itself within the database.
However, when combined with the other column or columns
the combination of composite keys become unique. The
purpose of the compound key in database is to uniquely
identify each record in the table.
OrderNo ProductID Product Name Quantity
B005 JAP102459 Mouse 5
B005 DKT321573 USB 10
B005 OMG446789 LCD Monitor 20
B004 DKT321573 USB 15
B002 OMG446789 Laser Printer 3

> CHANGE, EVERYDAY

In this example, OrderNo and ProductID can't be a primary key
as it does not uniquely identify a record. However, a compound
key of Order ID and Product ID could be used as it uniquely
identified each record.
What is the Composite key?
A Composite Key is a combination of two or more columns
that uniquely identify rows in a table. The combination of
columns guarantees uniqueness, though individually
uniqueness is not guaranteed. Hence, they are combined to
uniquely identify records in a table.
The difference between compound and the composite key is
that any part of the compound key can be a foreign key, but
the composite key may or maybe not a part of the foreign key.

> CHANGE, EVERYDAY

Integrity Rules
Constraints are a very important feature in a relational model.
In fact, the relational model supports the well-defined theory of
constraints on attributes or tables.
Constraints are useful because they allow a designer to specify
the semantics of data in the database.
Constraints are the rules that force DBMSs to check that data
satisfies the semantics.

> CHANGE, EVERYDAY

Domain Integrity
Domain restricts the values of attributes in the relation and is
a constraint of the relational model.
However, there are real-world semantics for data that cannot
be specified if used only with domain constraints.
We need more specific ways to state what data values are or
are not allowed and which format is suitable for an attribute.
For example, the Employee ID (EID) must be unique or the
employee Birthdate is in the range [Jan 1, 1950, Jan 1, 2000].
Such information is provided in logical statements
called integrity constraints.

> CHANGE, EVERYDAY

Entity Integrity
To ensure entity integrity, it is required that every table have a
primary key.
Neither the Primary Key nor any part of it can contain
null values.
This is because null values for the primary key mean we
cannot identify some rows.
For example, in the EMPLOYEE table, Phone cannot be a
primary key since some people may not have a telephone.

> CHANGE, EVERYDAY

Referential integrity
Referential integrity requires that a foreign key must have a
matching primary key or it must be null.
This constraint is specified between two tables (parent and
child); it maintains the correspondence between rows in these
tables. It means the reference from a row in one table to
another table must be valid.
Examples of referential integrity constraint in the
Customer/Order database of the Company:

Customer(CustID, CustName)
Order(OrderID, CustID, OrderDate)
> CHANGE, EVERYDAY
To ensure that there are no orphan records, we need to enforce
referential integrity. An orphan record is one whose foreign key
FK value is not found in the corresponding entity – the entity
where the PK is located.
Recall that a typical join is between a PK and FK.
The referential integrity constraint states that the customer ID
(CustID) in the Order table must match a valid CustID in the
Customer table.
Most relational databases have declarative referential integrity.
In other words, when the tables are created the referential
integrity constraints are set up.

> CHANGE, EVERYDAY

Here is another example from a Course/Class database:
Course(CrsCode, DeptCode, Description)
Class(CrsCode, Section, ClassTime)

The referential integrity constraint states that CrsCode in the

Class table must match a valid CrsCode in the Course table.
In this situation, it’s not enough that the CrsCode and Section
in the Class table make up the PK, we must also enforce
referential integrity.

> CHANGE, EVERYDAY

When setting up referential integrity it is important that the PK
and FK have the same data types and come from the same
domain, otherwise the relational database management
system (RDBMS) will not allow the join.
RDBMS is a popular database system that is based on the
relational model introduced by E. F. Codd of IBM’s San Jose
Research Laboratory.
Relational database systems are easier to use and understand
than other database systems.

> CHANGE, EVERYDAY

What are Relationships?
A relationship in a DBMS, is primarily the way two or more data
sets are linked.
This is so true for Relational Database Management Systems. One
dataset may be then termed as the Foreign key and the ones linked
to it may be termed as the Primary Key.
There may be multiple Foreign and Primary keys linked to each
other.
Relationships allow the datasets to share and store the data in
separate tables. They also help link disparate data with each other.
Relationships are of three types and the next segment talks about
the same.

> CHANGE, EVERYDAY

Types of Relationship in DBMS
There are three types of relationships that can be found in DBMS:
One to One
One to Many
Many to Many

One to One
This relationship tells us that a single record in Table A is related to a single
record in Table B. And vice versa. Now, the moot question that may arise here
is, that why not move both the data into a single table. There may be many
reasons for it. One primary reason usually is security.
Let us look into an example: We have to create a table where details of our
name, age, email, address, telephone number and password needs to be
stored. Now, all of this are sensitive information and we would not want to
have them bundled together in a single table. Hence, to create a greater
security around it, we create a separate table for the password with different
access control, so that only a selected few will have access to it.EVERYDAY
> CHANGE,
One to Many
This type of relationship in a Database Management System
(DBMS) is the most common type of relationship.
This entails one data in Table A to have links to multiple data in
Table B. However, a single data in Table B, will have link to a
single data in Table A.
One good example to showcase such a relationship is through
a bank account. One individual may have multiple bank
accounts, but each bank account will be linked to one specific
owner or account holder only (provided we are not talking
about a joint bank account)

> CHANGE, EVERYDAY

Many to Many
Consider two table A and B. Each data in Table A is linked to all the
data in Table B and vice versa. A great example would be linking a
student table to the courses table. Table A has the name of all the
students while Table B has the name of all the courses. A particular
student may enrol oneself to more than one course whilst a course
may have more than one student. Hence, it becomes a many to many
relationships.
Now, the market is replete with Database management systems like
MySql, Microsoft Access, SQL Server, Oracle. Because of the glut of so
many of them, it becomes imperative that they have to be in
communication with each other. Hence, most Database Management
Systems come in with something called an Open Database
Connectivity (ODBC) driver. What this does is allows a particular
database to integrate with the other database and sync the flow of
information. A food example would be the SQL statements: SELECT
which queries to select the said data and INSERT which queries
> CHANGE, EVERYDAYto
push the selected data into a particular table.
Data Dictionary
A data dictionary is a file or a set of files that contains a database's
metadata. The data dictionary contains records about other objects
in the database, such as data ownership, data relationships to other
objects, and other data.
The data dictionary is a crucial component of any relational
database. It provides additional information about relationships
between different database tables, helps to organize data in a neat
and easily searchable way, and prevents data redundancy issues.
Ironically, because of its importance, it is invisible to most database
users. Typically, only database administrators interact with the data
dictionary.
A data dictionary is also called a metadata repository.

> CHANGE, EVERYDAY

Example

> CHANGE, EVERYDAY