Relational model attributes and domain, tuples

Domain :

• Data is modeled by using atomic values as the basis for the domain. In the relational
model, atomic values refer to the number of values in a domain that are indivisible.
First Name is a set of character strings that represent the names of people in the domain.

• In a database, a domain is a column that contains a data type. Data types can be built-
in (such as integers or strings) or custom types that define constraints on the data
themselves.

• A SQL Domain is a set of valid values that can be named by the user. Name of the
Domain’s set of values that must belong to (for character string types). This is the name
of the domain’s default Collation.

Example :
In a table, a domain is a set of values that can be used to attribute an attribute. The domain of
a month can accept January, February, etc. A domain of integers can accept whole numbers that
are negative, positive, and zero in December.

Tuple :

Tuples are one of the most used items in Database Management Systems (or DBMS). A Tuple
in DBMS is just a row having inter-related data about a particular entity(it can be any object).

• This data is spread across some columns having various attributes such as name, age,
gender, marks, etc. It should be noted that Tuples are mostly seen in Relational
Databases Management Systems(RDBMS) as RDBMS works on the relational model
(Tabular format).

What Is Tuple In DBMS?

In Database Management System (DBMS), most of the time we need to store the data in tabular
format . This kind of data storage model is also called a Relational model and the system which
leverages the relational model is called Relational Database Management System (RDBMS).
These relations (or tables) consist of rows and columns. But in DBMS, we call these rows
“Tuples” and a row “Tuple”.

Let us see Tuple in DBMS in detail. Let us understand this with the help of a real-life example.
Example Of Single Record Or Tuple

Consider the table given below. We have data of some students like their id, name, age, etc.
here, each row has almost all the information of the respective student. Like the first row has
all the information about a student named “Sufiyan”, similarly, all other rows contain
information about other students. Hence, a single row is also termed a “record” as it contains
all the information of a student. This row or record is termed as Tuple in DBMS. Hence Tuple
in DBMS is just a row representing some inter-related data of a particular entity such as student,
employee, user, etc.

Table for reference:

A Tuple from the above-given table

In the above-given image, you can see that a Tuple is just a row having attributes of a particular
entity like name, age, marks, etc.

Attributes :

• Any real-world object is considered to be an entity that has self-existence and these
entities in DBMS have their own characteristics and properties known as attributes.
Attributes give us additional information about entities and help us to study their
relationship within the specified system.

• Attributes in an ER (Entity Relationship) model are always represented in an elliptical

• An entity may contain any number of attributes while one of the attributes is considered
to be a primary key attribute.

• An attribute can take its values from a set of possible values for each entity instance in
an ER model in DBMS.
We always represent attributes in DBMS in an elliptical shape. We can refer to the above image
where we have an ER model diagram and the student represented in rectangle shape is our
entity object. Student entity has different attributes: Roll_No, Name, DOB, Phone_No, Age,
Address, Country, State, City, and Street.

Degree :

• The degree of a relationship is the number of entity types that participate(associate) in

• By seeing an E-R diagram, we can simply tell the degree of a relationship i.e the number
of an entity type that is connected to a relationship is the degree of that relationship.

Example

If we have two entity type ‘Customer’ and ‘Account’ and they are linked using the primary key
and foreign key. We can say that the degree of relationship is 2 because here two entities are
taking part in the relationship.
Based on the number of entity types that are connected we have the following degree of
relationships:

• Unary

• Binary

• Ternary

• N-ary

Unary (degree 1)
A unary relationship exists when both the participating entity type are the same. When such a
relationship is present we say that the degree of relationship is 1.

Binary (degree 2)

A binary relationship exists when exactly two entity type participates. When such a relationship
is present we say that the degree is 2. This is the most common degree of relationship. It is easy
to deal with such relationship as these can be easily converted into relational tables.

Ternary(degree 3)

A ternary relationship exists when exactly three entity type participates. When such a
relationship is present we say that the degree is 3. As the number of entity increases in the
relationship, it becomes complex to convert them into relational tables.
N-ary (n degree)

An N-ary relationship exists when ’n’ number of entities are participating. So, any number of
entities can participate in a relationship. There is no limitation to the maximum number of
entities that can participate. But, relations with a higher degree are not common. This is because
the conversion of higher degree relations to relational tables gets complex. We are making an
E-R model because it can be easily be converted into any other model for implementing the
database. But, this benefit is not available if we use higher degree relations. So, binary relations
are more popular and widely used. Though we can make a relationship with any number of
entity types but we don’t do that.

We represent an N-ary relationship as follows:

In the view of databases, cardinality refers to the uniqueness of data values that are contained
in a column. High cardinality is nothing but the column contains a large percentage of totally
unique values. Low cardinality is nothing but the column which has a lot of “repeats” in its
data range.

Cardinality between the tables can be of type one-to-one, many-to-one or many-to-many.

Mapping Cardinality

It is expressed as the number of entities to which another entity can be associated via a
relationship set.

For binary relationship set there are entity set A and B then the mapping cardinality can be one
of the following −

• One-to-one

• One-to-many

• Many-to-one

• Many-to-many

One-to-one relationship
One entity of A is associated with one entity of B.

Example

Given below is an example of the one-to-one relationship in the mapping cardinality. Here, one
department has one head of the department (HOD).

One-to-many relationship
An entity set A is associated with any number of entities in B with a possibility of zero and
entity in B is associated with at most one entity in A

Example

Given below is an example of the one-to-many relationship in the mapping cardinality. Here,
one department has many faculties.

Many-to-one relationship

An entity set A is associated with at most one entity in B and an entity set in B can be associated
with any number of entities in A with a possibility of zero.

Example

Given below is an example of the many-to-one relationship in the mapping cardinality. Here,
many faculties work in one department.
Many-to-many relationship

Many entities of A are associated with many entities of B.

An entity in A is associated with many entities of B and an entity in B is associated with many
entities of A.

Many to many=many to one + one to many

Example

Given below is an example of the many-to-many relationship in the mapping cardinality. Here,
many employees work on many projects.