E/R Model: Type of Attributes
EDIT
SHARE
AFSOMAALI KUBARO
Contents
[show]
Edit
Optional attributes Edit
A required attribute is an attribute that must have a value in it, while an optional attribute may not have a value
in it and can be left blank. The reasoning for making an attribute required is to ensure that data are collected
for that particular characteristic.
Example: Consider the entity Student abovestud_LastName and studFirstName would be required attributes
as it uniquely defines that table and we assume all students have a first and last name. Optional attributes in the
table Student could be stu_MiddleName, stu_Email, and stu_Phone since some students may not have a
middle name, a phone number, or an email address
Keys and non-keys Attributes Edit
In every entity an attribute or grouped attributes uniquely identify that entity. These attributes are the key
attributes and range from Primary key (single attribute identifier) to a Composite Key (Multi attribute
Identifier). The rest of the attributes after the identifier are considered the non-key attributes or descriptors,
which just describe the entity.
Example: Above in the table Student there is only one unique identifier, stu_LastName, which is the primary
key of the table. The rest of the attributes are descriptors.
Simple and Composite Attributes Edit
Attributes can be classified as having many parts to them or just a single unbreakable attribute. The
composite attribute is an attribute that can be subdivided into other single attributes with meanings of their
own. A simple attribute is just an attribute that cannot be subdivided into parts.
Example: Imagine from the entity Student that instead of having the three attributes: stu_LastName,
stu_MiddleName, stu_FirstName it had one attribute called stu_Name. The attribute stu_Name would be
considered a composite attribute since it can be subdivied into the other three attributes: stu_LastName,
stu_MiddleName, stu_FirstName. The rest of attributes would be consider single attributes since they can't be
subdivided into parts.
Single-valued and multi-valued Attributes Edit
Attributes can be classified as single or multi-value. The single-value attribute can only have one value, while
the multi-valued attributes usually can store multiple data in them.
Example: In the entity Student, stu_Address could be considered a multi-value attribute since a student could
have multiple addresses where he lives at. An example of a single-value attribute would
be stu_LastName since a student usually has josiose last name that uniquely identifies him/her.
Derived Attributes Edit
The last category that attributes can be defined is called a derived attribute, where one attribute is calculated
from another attribute. The derived attribute may not be stored in the database but rather calculated using
algorithm.
Example: In the entity Student, stu_Age would be considered a derived attribute since it could be calculated
using the student's date of birth with the current date to find their age.
Categories:
The table below illustrates how and by what means one can establish these
relationships:
Relationship Mandatory/ Optional Composite Primary Key Mandatory Check box
Identifying - Yes Checked
Non-Identifying Mandatory No Checked
Non-Identifying Optional No Un-checked
I have made Book_id as part of the primary key in the Chapter table. It defines an
Identifying relationship between Book and Chapter tables.
To establish Non-Identifying relationship (mandatory) between Book and Owner tables, I
added Book_id as a foreign key in the Owner table, and keep its Mandatory flag
“Checked”. It means the system will never allow null values in the Book_id column in
the Owner table.
