Week 4- Entity Relationship

Modeling
By Maria Rahim
Keys
• In the relational model, keys are important because they are used to
ensure that each row in a table is uniquely identifiable. They are also
used to establish relationships among tables and to ensure the
integrity of the data.
• A key consists of one or more attributes that determine other
attributes. For example, an invoice number identifies all of the invoice
attributes, such as the invoice date and the customer name.
• One type of key is primary key which unique as discussed earlier.
Relational Model
Based on these concepts, the relational model has three well-defined
components:
1. A logical data structure represented by relations
2. A set of integrity rules to enforce that the data are and remain
consistent over time
3. A set of operations that define how data are manipulated
Each table must
have a primary The column’s range
key. In general of permissible
terms, the values is known as
primary key (PK) its domain. Because
is an attribute (or the STU_GPA values
a combination of are limited to the
attributes) that range 0–4,
uniquely inclusive, the
identifies any domain is [0,4]
given row. In this
case, STU_NUM
(the student
number) is the
primary key.

Most relational DBMSs allow you to define your own date presentation format. For
instance, Access and Oracle users might specify the “dd-mmm-yyyy” date format to show
the first STU_DOB value in Figure 3.1 as 12-Feb-1975.
Keys
• In the relational model, keys are important because they are used to
ensure that each row in a table is uniquely identifiable. They are also
used to establish relationships among tables and to ensure the
integrity of the data.
• A key consists of one or more attributes that determine other
attributes. For example, an invoice number identifies all of the invoice
attributes, such as the invoice date and the customer name.
• One type of key is primary key which unique as discussed earlier.
Determination
• The key’s role is based on a concept known as determination. In the context of a database
table, the statement “A determines B” indicates that if you know the value of attribute A, you
can look up (determine) the value of attribute B. For example, knowing the STU_NUM in the
STUDENT table (see Figure 3.1) means that you are able to look up (determine) that student’s
last name, grade point average, phone number, and so on.
• The shorthand notation for “A determines B” is A → B. If A determines B, C, and D, you write A
→ B, C, D. Therefore, using the attributes of the STUDENT table in Figure 3.1, you can represent
the statement
• “STU_NUM determines STU_LNAME” by writing: STU_NUM → STU_LNAME
• In fact, the STU_NUM value in the STUDENT table determines all of the student’s attribute values. For
example, you can write:
• STU_NUM → STU_LNAME, STU_FNAME, STU_INIT and
• STU_NUM → STU_LNAME, STU_FNAME, STU_INIT, STU_DOB, STU_TRANSFER
• In contrast, STU_NUM is not determined by STU_LNAME because it is quite possible for several students to
have the last name Smith
Functional Dependence
• The principle of determination is very important because it is used in the definition of a central
relational database concept known as functional dependence. The term functional dependence
can be defined most easily this way:
The attribute B is functionally dependent on A if A determines B. More precisely:
The attribute B is functionally dependent on the attribute A if each value in column
A determines one and only one value in column B.
• Using the contents of the STUDENT table in Figure 3.1, it is appropriate to say that STU_PHONE
is functionally dependent on STU_NUM. For example, the STU_NUM value 321452 determines
the STU_PHONE value 2134. On the other hand, STU_NUM is not functionally dependent on
STU_PHONE because the STU_PHONE value 2267 is associated with two STU_NUM values:
324274 and 324291. (This could happen in a dormitory situation, where students share a
phone.) Similarly, the STU_NUM value 324273 determines the STU_LNAME value Smith. But
the STU_NUM value is not functionally dependent on STU_LNAME because more than one
student may have the last name Smith
Keys
• Composite key is a key that consists of two or more attributes (table
columns) that together uniquely identify an entity occurrence (table
row).
• Super key is any key that uniquely identifies each row. In short, the
super key functionally determines all of a row’s attributes. In the
STUDENT table, the superkey could be any of the following:
• STU_NUM
• STU_NUM, STU_LNAME
• STU_NUM, STU_LNAME, STU_INIT
In fact, STU_NUM, with or without additional attributes, can be a superkey even
when the additional attributes are redundant.
Keys
• A candidate key can be described as a super key without unnecessary
attributes, that is, a minimal super key. Using this distinction, note
that the composite key
• STU_NUM, STU_LNAME is a super key, but it is not a candidate key because
STU_NUM by itself is a candidate key
• The combination STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE might
also be a candidate key, as long as you discount the possibility that two
students share the same last name, first name, initial, and phone number
Keys
• Secondary is defined as a key that is used strictly for data retrieval purposes.
Suppose customer data are stored in a CUSTOMER table in which the customer
number is the primary key. Do you suppose that most customers will remember
their numbers? Data retrieval for a customer can be facilitated when the
customer’s last name and phone number are used. In that case, the primary key
is the customer number; the secondary key is the combination of the customer’s
last name and phone number. Keep in mind that a secondary key does not
necessarily yield a unique outcome. For example, a customer’s last name and
home telephone number could easily yield several matches where one family
lives together and shares a phone line. A less efficient secondary key would be
the combination of the last name and zip code; this could yield dozens of
matches, which could then be combed for a specific match.
Keys
• A foreign key (FK) is an attribute whose values match the primary key
values in the related table. For example, in Figure 3.2, the
VEND_CODE is the primary key in the VENDOR table, and it occurs as
a foreign key in the PRODUCT table.
Example
Create table course( courseid
varchar(5) primary key,
courseName varchar(50));
Create table student(studentid
varchar(20) primary key,firstName
varchar(50),lastName varchar(50),
courseid varchar(5) references
course(courseid));
What is a constraint?
Constraints are used to implement standard and business rules. Data integrity of the database must be
maintained. In order to ensure data has integrity we have to implement certain rules or constraints. As
these constraints are used to maintain integrity they are called as integrity constraints.
• Standard rules
Standard constraints are the rules related to primary key and foreign key. Every table must have a primary
key. Primary key must be unique and not null. Foreign key must derive its values from corresponding
parent key. These rules are universal and are called as standard rules.
• Business rules
These rules are related to a single application. For example, in a payroll application we may have to
implement a rule that prevents any row of an employee if salary of the employee is less than 2000.
Another example is current balance of a bank account Must be greater than or equal to 500. Once the
constraints are created, Oracle server makes sure that the constraints are not violated whenever a row is
inserted, deleted or updated. If constraint is not satisfied then the operation will fail. Constraints are
normally defined at the time of creating table. But it is also possible to add constraints after the table is
created using ALTER TABLE command.
Entity Relationship Modeling
The Relational Database Model, that the ERM forms the basis of an
ERD. The ERD represents the conceptual database as viewed by the end
user. ERDs depict the database’s main components: entities, attributes,
and relationships. Because an entity represents a real-world object, the
words entity and object are often used interchangeably. Thus, the
entities (objects) of the Tiny College database design developed in this
chapter include students, classes, teachers, and classrooms.
UML Notation
There are two popular ERD notation:
• Crow’s Foot Notation
• The Chen notation favors conceptual
modeling
• Chen Notation
• The Crow’s Foot notation favors a more
implementation-oriented approach
Domain
• A domain is the set of possible values for a given attribute. For
example, the domain for the grade point average (GPA) attribute is
written (0,4) because the lowest possible GPA value is 0 and the
highest possible value is 4. The domain for the gender attribute
consists of only two possibilities: M or F (or some other equivalent
code).
Representation in Different Notation
• Primary Key: In Chen’s notation it is underlined whereas pk keyword is
used to identify primary key in crowfoot notation.
• Single-valued vs multivalued attribute: Chen’s notation distinguish
between single and multi value attribute by a double line connecting
the attribute to the entity whereas crow foot notation doesn’t
distinguish them.
Implementing multivalued attribute
Representation in Different Notation
• Derived attribute (A derived attribute is an attribute whose value is
calculated (derived) from other attributes): A derived attribute is
indicated in the Chen notation by a dashed line connecting the
attribute and the entity whereas crow’s foot notation doesn’t
distinguish it
Relationship
• Relationship is association between entities and can be
show by connectivity and cardinality.
• The term connectivity is used to describe the
relationship classification like one to one, one to many,
many to many.
• Cardinality expresses the minimum and maximum
number of entity occurrences associated with one
occurrence of the related entity. In the ERD, cardinality
is indicated by placing the appropriate numbers beside
the entities, using the format (x,y). The first value
represents the minimum number of associated entities,
while the second value represents he maximum
number of associated entities.
Relationship Strength
• Weak (Non-identifying) Relationships: A weak relationship, also
known as a non-identifying relationship, exists if the PK of the related
entity does not contain a PK component of the parent entity and is
represented by --- line.
Relationship Strength
• A strong relationship, also known as an identifying relationship, exists
when the PK of the related entity contains a PK component of the
parent entity.
Relationship participation
• Participation in an entity relationship is either optional or mandatory.
• Optional participation means that one entity occurrence does not
require a corresponding entity occurrence in a particular relationship.
For example, in the “COURSE generates CLASS” relationship, you
noted that at least some courses do not generate a class.
• Mandatory participation means that one entity occurrence requires a
corresponding entity occurrence in a particular relationship.
Relationship Degree
• A relationship degree indicates the number of entities or participants
associated with a relationship. A unary relationship exists when an
association is maintained within a single entity. A binary relationship
exists when two entities are associated. A ternary relationship exists
when three entities are associated. Although higher degrees exist,
they are rare and are not specifically named
Implementing many to many relationship
• If M:N relationships are encountered, you must create a bridge between the entities that display
such relationships.
Steps to develop ERD
• Create a detailed narrative of the organization’s description of
operations.
• Identify the business rules based on the description of operations.
• Identify the main entities and relationships from the business rules.
• Develop the initial ERD.
• Identify the attributes and primary keys that adequately describe the
entities.
• Revise and review the ERD
Scenario 1
1.Create a Crow’s Foot ERD to include the following business rules for
the ProdCo company.
a. Each sales representative writes many invoices
b. Each invoice is written by one sales representative
c. Each sales representative is assigned to one department
d. Each department has many sales representatives
e. Each customer can generate many invoices
f. Each invoice is generated by one customer
Scenario 2
2. During some period of time, a customer can rent many video tapes
from the BigVid store. Each of the BigVid’s videotapes can be rented to
many customers during that period of time
Scenario 3
3. The KwikTite Corporation operates many factories. Each factory is
located in a region. Each region can be “home” to many of KwikTite’s
factories. Each factory employs many employees, but each of those
employees is employed by only one factory.