NAME OF INSTITUTION

Under
Ethiopian TVET-System
DATABASE ADMINISTRATION LEVEL III

LEARNING GUIDE # 25

Unit of Competence: Test Physical Database Implementation

Module Title: Testing Physical Database Implementation
LG Code: ICT DBA3 M06 Lo1 25
TTLM Code: ICT DBA3 TTLM06 0817

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 1 of 25
III
TVET/Tigray
 INTRODUCTION Learning Guide
This learning guide is developed to provide you the necessary information regarding the
following content coverage and topics –
 Undertake database management system modeling
 Test Database Performance
 Seek client feedback and signoff
This guide will also assist you to attain the learning outcome stated in the cover page.
Specifically, upon completion of this Learning Guide, you will be able to –
 They will list down the properties of relational databases
 They will differentiate Entity types, entity sets, attributes, and sets
 They will refine ER designing
They will understand about Naming conventions Learning Activities
1. Read the specific objectives of this Learning Guide.
2. Read the information written in the “Information Sheets 1”
3. Accomplish the “Self-check”
4. If you earned a satisfactory evaluation proceed to “Information Sheet 2”. However, if
your rating is unsatisfactory, see your teacher for further instructions or go back to
Learning Activity # 1.
5. Submit your accomplished Self-check. This will form part of your training portfolio.
6. Read the information written in the “Information Sheet 2”
7. Accomplish the “Self-check”
8. Read the “Operation Sheet” and try to understand the procedures discussed.
Your teacher will evaluate your output either satisfactory or unsatisfactory. If unsatisfactory,
your teacher shall advice you on additional work. But if satisfactory you can proceed.
 Your teacher will evaluate your output either satisfactory or unsatisfactory. If
unsatisfactory, your teacher shall advice you on additional work. But if satisfactory
you can proceed to the next topic.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 2 of 25
III
TVET/Tigray
 Information sheet
LO 1 : Undertake database management system modeling
1.1 Using Entity relationship Modeling
Entity-Relationship(ER) Model
 The ER model is a high-level conceptual data model. It has not been implemented in any
commercial DBMS (?), but is a powerful short hand often used in database design for a first
rendition of the miniworld.
Conceptual data model
This is the highest level ER model in that it contains the least granular detail but establishes the
overall scope of what is to be included within the model set. The conceptual ER model normally
defines master reference data entities that are commonly used by the organization. Developing an
enterprise-wide conceptual ER model is useful to support documenting the data architecture for
an organization.
A conceptual ER model may be used as the foundation for one or more logical data models. The
purpose of the conceptual ER model is then to establish structural metadata commonality for
the master data entities between the set of logical ER models. The conceptual data model may be
used to form commonality relationships between ER models as a basis for data model
integration.
Logical data model
A logical ER model does not require a conceptual ER model, especially if the scope of the
logical ER model includes only the development of a distinct information system. The logical
ER model contains more detail than the conceptual ER model. In addition to master data entities,
operational and transactional data entities are now defined. The details of each data entity are
developed and the entity relationships between these data entities are established. The logical ER
model is however developed independent of technology into which it will be implemented.
Physical data model
One or more physical ER models may be developed from each logical ER model. The physical
ER model is normally developed to be instantiated as a database. Therefore, each physical ER
model must contain enough detail to produce a database and each physical ER model is
technology dependent since each database management system is somewhat different.
The physical model is normally forward engineered to instantiate the structural metadata into a
database management system as relational database objects such as database tables, database
indexes such as unique key indexes, and database constraints such as a foreign key constraint or
a commonality constraint. The ER model is also normally used to design modifications to the
relational database objects and to maintain the structural metadata of the database.
English grammar structure ER structure
Common noun Entity type
Proper noun Entity
Transitive verb Relationship type
Intransitive verb Attribute type
Adjective Attribute for entity
Adverb Attribute for relationship
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 3 of 25
III
TVET/Tigray
  High level coding data Model
Using High-Level Conceptual Data Models
Logical design or data model mapping
Result is a database schema in implementation data model of DBMS

Physical design phase

Internal storage structures, file organizations, indexes, access paths, and physical
designparameters for the database files specified.
 Entity types, entity sets, attributes, and sets
 An entity is an object in the miniworld.
 An attribute of an entity can have a value from a value set (domain)
 Each entity belongs to some one entity types.t. entities in one entity type have the same
attributes (so each entity type is a set of similar entities).
 A key attribute of an entity type is one whose value uniquely identifies an entity of that type.
 A combination of attributes may form a composite key.
 If there is no applicable value for an attribute that attribute is set to a null value.
• Attributes can be
– composite / simple (atomic)
– single-valued / multivalued
– stored / derived
– key / nonkey.
Composite or simple attribute
An attribute that is a single whole is a simple attribute. The value of a simple attribute is
considered as whole, not as comprising
of other attributes or components. For example,attributes stName, stFatherName, stDateOfBorth
of an entity type STUDENT are
example of simple attributes. On the other hand ifan attribute consists
of collection ofother simple or composite attributes then it
is called a composite attributes. For example, stAdres attribute may comprise of
houseNo, streetNo, areaCode, city etc. In this case stAdres will be a composite attribute
Single valued or multi-valued Attributes:
Some attribute have single value at
a time, whereas some others may have multiplevalues. For example, hobby attribute of STUDEN
T or skills attribute of EMPLOYEE,since
a student mayhave multiple hobbies, likewise an employee may have multipleskills so they are m
ulti valued
attributes. On the other hand, name, father name,designation are generally single valued attribute
s
Stored or Derived Attributes:
Normally attributes are stored attributes, that is, their values are stored
and accessed assuch from the database. However, sometimes attributes' values are not stored
as such,rather they are computed or derived based on some other value. This other value may bes
tored
in the database or obtained some other way. For example, we may store the name,father name, ad
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 4 of 25
III
TVET/Tigray
dress of employees, but age can be computed from date of birth. The advantage
of declaring age as derived attribute is that whenever we will access the age, we
will get the accurate, current age of employee since it will be computed right at thetime when it
is being accessed.
How a particular attribute is stored or defined, it
is decided first by the environment andthen it has tobe designer's decision; your decision. Becaus
e, the organization or systemwill not object rather they will not even know the form in which you
have defined anattribute. You have to make
sure that the system works properly, it fulfills therequirement; after that you do it as
per your convenience and in an efficient way.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 5 of 25
III
TVET/Tigray
The Entity
Entity is basic building block of the E-R data model. The term entity is used in threedifferent me
anings or for three different terms and that are:
· Entity type
· Entity instance
· Entity set

Entity Type
The entity type can be defined as a name/label assigned to items/objects that exist in an
environment and that have similar properties. It could be person, place, event or even
concept, that is, an entity type can be defined for physical as well as not-physical things.
An entity type is distinguishable from other entity types on the basis of properties and the
same thing provides the basis for the identification ofan entity type. We analyze thethings existin
g in any environment or place. We
can identify or associate certainproperties with each of the existing in that environment. Now the
things that havecommon or similar properties are candidates of belonging to same group, if
we assign a name to that group then we say that we have identified an entity type.
Generally, the entity types and their distinguishing properties are established
by nature,by very existence of the things. For example, a bulb is an electric accessory,
a cricket bat is a sports item, a computer is an electronic device, a shirt is
a clothing item etc. Soidentification of entity types is guided by very nature of the things and the
n items havingproperties associated with an entity type are considered to
be belonging to that entity typeor instances
of that entity type. However, many times the grouping of things in
anenvironment is dictated by the specific interest of the organization or system that maysupersed
e the natural classificationof entity types.
Naming Entity Types
Following are some recommendations for naming entity types. But they are justrecommendation
s; practices considered good in general. If one, some or all of them areignored in a
design, the design will still be valid if it
satisfies the requirements otherwise,but good designs usuallyfollow these practices:
 Singular noun recommended, but still plurals can also be used
 Organization specific names, like customer, client, gahak anything will work
 Write in capitals, yes, this is something that is generally followed, otherwise willalso wor
k.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 6 of 25
III
TVET/Tigray
  Abbreviations can be used,
be consistent. Avoid using confusing abbreviations, ifthey are confusing for others today,
tomorrow they will confuse you too.
The Keys
Attributes act
as differentiating agents among different entity types, that is, thedifferencesbetween entity
types must be expressed in terms of attributes. An entity typecan have many instances; each insta
nce has got a
certain value against each attributedefined as part of that particularentity type. A key is
a set of attributes that can be used toidentify or access a particular entity instance of
an entity type (or out of an entity set).The concept of key is beautiful and very useful; why
and how. An entity type may havemany instances,from a few to several thousands and even mor
e.

Following are the major types of keys

 Super Key
 Candidate Key
 Primary Key
 Alternate Key
 Secondary Key
 Foreign Key
Super key
A super key is a set of one or more attributes which taken collectively, allow us to
dentify uniquely an entity instance in the entity set. This definition is same as of a key, it means
that the super key is the most general type of key.
Candidate Key
A super key for which no subset is a super key is called a candidate key, or the
minimal super key is the candidate key. It means that there are two conditions for the
candidate key, one, it identifies the entity instances uniquely, as is required in case ofsuper key,
second, it should be minimum, that is, no proper subset of candidate key is a key. So, if
we have a simple super key, that is, that consists of single attribute, it indefinitely a
candidate key, 100%. However, if we have a composite super key and if we
take any attribute out of it and remaining part is not a super key anymore then that
composite super key is also a candidate key since it is minimal super key.

Primary Key
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 7 of 25
III
TVET/Tigray
A candidate key chosen by the database designer to act as key is the primary key. An entity type
may have more than one candidate keys, in that case the database designer has to designate one
of them as primary key, since there is always only a single primary key in an entity type.
If there is just one candidate key then obviously the same will be declared
as primary key. The primary key can also be defined as the successful candidate key.
Alternate Keys
Candidate keys which are not chosen as the primary key are known as alternate keys.
Secondary Key
Many times we need to access certain instances of an entity type using the value(s) of
oneor more attributes other than the PK. The difference in accessing instances using thevalue of
a key or non-key attribute is that the search on the value of PK
will always returna single instance (if it exists), where as uniqueness is not guaranteed
in case of non-keyattribute. Such attributes on which we need to access the instances of
an entity type thatmay not necessarilyreturn unique instance is called the secondary key.
 Relationship type, relationship sets, roles and structural constraints
Relationships
After two or more entities are identified and defined with attributes, the participantsdetermine if
relationship exists between the entities. A relationship is any association,linkage, or connection
betweenthe entities of interest to the business; it is a two-directional, significant association
between two entities, or between an entity and itself.
Each relationship has a name, an optionality (optional or mandatory), and
a degree (howmany). A relationship is described in real terms.
Assigning a name, optionality, and a degree to
a relationship helps confirm the validity ofthat relationship. If you cannot give a relationship all t
hese things, then perhaps therereally is no relationship at all.
Relationship represents an association between two or more entities. An example of
arelationship would be:
·Employees are assigned to projects
·Projects have subtasks
·Departments manage one or more projects
Relationships are the connections and interactions between the entities instances e.g.
DEPT_EMP associates Department and Employee.
 A relationship type is an abstraction of
a relationship i.e. a set of relationshipsinstances sharing common attributes.
 Entities enrolled in a relationship are called its participants.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 8 of 25
III
TVET/Tigray
The participation of an entity in
a relationship is total when all entities of that set mightbe participant in the relationship otherwis
e it is partial e.g. if every Part is supplied by a
Supplier then the SUPP_PART relationship is total. If certain parts are available withouta supplie
r than it is partial.
Naming Relationships:
If there is no proper name of the association in the system then participants' names of
abbreviations are used. STUDENT and CLASS have ENROLL relationship. However, it can
also be named as STD_CLS.
Roles
Entity set of a relationship need not be distinct. For example
Phone City
Name

SSN
Manager
W
Employee fo ork
r s
Worker

The labels "manager" and "worker" are called "roles". They specify how employee
entities interact via the "works-for" relationship set. Roles are indicated in ER diagrams
by labeling the lines that connect diamonds to rectangles. Roles are optional. They clarify
semantics of a relationship.

o Symbol for Relationships:

o Shown as a Diamond
o Diamond is doubled if one of the participants is dependent on the other
o Participants are connected by continuous lines, labeled to indicate cardinality.
o In partial relationships roles (if identifiable) are written on the line connecting thepartially
participating entity rectangle to the relationship diamond.
o Total participation is indicated by double lines

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 9 of 25
III
TVET/Tigray
Types of Relationships

Unary Relationship
An ENTITY TYPE linked with itself, also called recursive relationship. Example
Roommate, where STUDENT is linked with STUDENT
Example 1:

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 10 of 25
III
TVET/Tigray
Binary relationship
A Binary relationship is the one that links two entities sets e.g. STUDENT-CLASS.
Relationships can be formally described in an ordered pair form.
Enroll = {(S1001, ART103A), (S1020, CS201A), (S1002, CSC201A)}
Entire set is relationship set and each ordered pair is an instance of the relationship

Ternary Relationship
A Ternary relationship is the one that involves three entities e.g.
STUDENT-CLASS-FACULTY.
N-ary Relationship
Most relationships in data model are binary or
at most ternary but we could define arelationship set linking any number of entity sets i.e. n-ary r
elationship
Entity sets involved in a relationship set need not be distinct. E.g.
Roommate = {(Student1, Student2) | Student1 ∈ Student Entity Set, Student2 ∈ Student
Entity Set and Student 1 is the Roommate of Student2}
Relationship Cardinalities
The cardinality of a relationship is the number of entities to which another entity can map
under that relationship. Symbols for maximum and minimum cardinalities are:

One-to-One mapping:
A mapping R from X to Y is one-to-one if each entity in X is associated with at most
one entity in Y and vice versa.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 11 of 25
III
TVET/Tigray
Many-to-One mapping:
A mapping R from X to Y is many-to-one if each entity in X is associated with at
most one entity in Y but each entity in Y is associated with many entities in X.

One-to-Many mapping:
A mapping R from X to Y is one-to-many if each entity in X is associated with many entities in
Y but each entity in Y is associated with one entity in X.

Many-to-Many mapping:
A mapping R from X to Y is many-to-many if each entity from X is associated with
many entities in Y and one entity in Y is associated with many entities in X.

Constraints on Relationship Types

o Relationship types have certain constraints that limit the possible combination of entities that
may participate in relationship.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 12 of 25
III
TVET/Tigray
o An example of a constraint is that if we have the entities Doctor and Patient, the organization
may have a rule that a patient cannot be seen by more than one doctor. This constraint needs
to be described in the schema.
o There are two main types of relationship constraints, cardinality ratio, and participation.

Cardinality for Binary Relationship

o Binary relationships are relationships between exactly two entities.
o The cardinality ratio specifies the maximum number of relationship instances that an entity
can participate in.
o The possible cardinality ratios for binary relationship types are: 1:1, 1:N, N:1, M:N.
o Cardinality ratios are shown on ER diagrams by displaying 1, M and N on the diamonds.
o The ratio shown closest to an entity, represents the ratio the other entity has to that entity.

Participation Constraints and Existence Dependencies

o The participation constraint specifies whether the existence of an entity depends on its being
related to another entity via the relationship type.
o The constraint specifies the minimum number of relationship instances that each entity can
participate in.
o There are two types of participation constraints:
o Total:
 If an entity can exist, only if it participates in at least one relationship instance,
then that is called total participation, meaning that every entity in one set, must be
related to at least one entity in a designated entity set.
 An example would be the Employee and Department relationship. If company
policy states that every employee must work for a department, then an employee
can exist only if it participates in at lest one relationship instance (i.e. an
employee can’t exist without a department)
 It is also sometimes called an existence dependency.
 Total participation is represented by a double line, going from the relationship to
the dependent entity.
o Partial:
 If only a part of the set of entities participate in a relationship, then it is called
partial participation.
 Using the Company example, every employee will not be a manager of a
department, so the participation of an employee in the “Manages” relationship is
partial.
 Partial participation is represented by a single line.

Attributes of Relationship Types

o Relationships can have attributes similar to entity types.
o For example, in the relationship Works_On, between the Employee entity and the
Department entity we would like to keep track of the number of hours an employee works on
a project. Therefore we can include Number of Hours as an attribute of the relationship.
o Another example is for the “manages” relationship between employee and department, we
can add Start Date as an attribute of the Manages relationship.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 13 of 25
III
TVET/Tigray
o For some relationships (1:1, or 1:N), the attribute can be placed on one of the participating
entity types. For example the “Manages” relationship is 1:1,StartDate can either be migrated
to Employee or Department.
 Weak entity types
o Entity types that do not have key attributes are called weak entity types.
o Entities that belong to a weak entity type are identified by being related to specific entities
from another entity type in combination with one of their attribute values.
o This entity type is called an identifying or owner entity type.
o The relationship that relates the identifying entity type with the weak entity type is called an
identifying relationship.
o A weak entity type always has a total participation constraint with respect to the identifying
relationship, because a weak entity cannot exist without its owner.
o Not all existence dependencies result in a weak entity type; if an entity has a key attribute
then it is not a weak entity.
o A weak entity type usually has a partial key, which is the set of attributes that can uniquely
identify weak entities that are related to the same owner entity.

Weak Entity Example

o For example, lets assume in a library database, we have an entity type Book. For each book,
we keep track of the author, ISBN, and title. The library may own several copies of the same
book, and for each copy, it keeps track of the copy number (a different copy number for each
copy of a given book) and price of each copy.

Book Copy
Has

o Because the copy number is only unique for each book (meaning Book 123 may have copy 1,
copy 2, copy 3, and book 456 may also have copy 1, copy 2 and copy 3) and not for all
copies of all books, it cannot be considered unique for each copy.
o Therefore because the Copy entity does not have a key attribute, it is considered a weak
entity type, an is identified by being related to the Book entity. The book entity is the
identifying entity, and the relationship is the identifying relationship.
o Because a copy cannot exist without the owner (Book) the Copy entity type has a total
participation constraint with respect to the identifying relationship.
o The partial key of the Copy entity is Copy Number, for each owner entity Book, the Copy
Number uniquely identifies the copy.
 Refining ER designing
Steps in Database Design
• Requirements Analysis
– user needs; what must database do?
Conceptual Design
high level descr (often done w/ER model)
• What are the entities and relationships in the enterprise?
• What information about these entities and relationships should we store in the database?
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 14 of 25
III
TVET/Tigray
• What are the integrity constraints or business rules that hold?
• A database `schema’ in the ER Model can be represented pictorially (ER diagrams).
• Can map an ER diagram into a relational
schema.
• Logical Design
– translate ER into DBMS data model
• Schema Refinement
– consistency, normalization
• Physical Design - indexes, disk layout
• Security Design - who accesses what, and how

ER Model Basics
• Entity: Real-world object, distinguishable from other objects. An entity is described using a set
of attributes.
• Entity Set: A collection of similar entities. E.g., all employees.
– All entities in an entity set have the same set of attributes. (Until we consider hierarchies,
anyway!)
– Each entity set has a key (underlined).
– Each attribute has a domain.
Relationship: Association among two or more entities.
E.g., Attishoo works in Pharmacy department.
– relationships can have their own attributes.
• Relationship Set: Collection of similar relationships.
– An n-ary relationship set R relates n entity sets E1 ... En ;each relationship in R involves
entities e1 ∈ E1, ..., en ∈ En
Same entity set can participate in different relationship sets, or in different “roles” in the same
set.
ER modeling can get tricky!
• Design choices:
– Should a concept be modeled as an entity or an attribute?
– Should a concept be modeled as an entity or a relationship?
– Identifying relationships: Binary or ternary? Aggregation?
Note constraints of the ER Model:
– A lot of data semantics can (and should) be captured.
– But some constraints cannot be captured in ER diagrams.
We’ll refine things in our logical (relational) design
 ERD naming, conventions, and design issues
What you are doing is very important, and it will affect the ease of use and understanding at every
level. So it is good to get as much understanding as possible at the outset. The relevance of most of
this will not be clear, until you start coding in SQL.

1. Maintain a data focus, not an application or usage focus. It is, after all 2011, and databases are
supposed to be independent of the apps that use them. That way, as they grow, and more than
the one app uses them, the naming will remain meaningful, and need no correction. (Databases
that are completely embedded in a single app are not databases.) Name the data elements as
data, only.
2. Be very considerate, and name tables and columns very accurately. Do not use UpdatedDate if
it is a DATETIME datatype, or _description if it contains dosage.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 15 of 25
III
TVET/Tigray
3. It is important to be consistent across the database. Do not use NumProduct in one place to
indicate number of Products and ItemNo or ItemNumin another place to indicate number of
Items. Use NumSomething for numbers-of, and SomethingNo for identifiers, consistently.
4. Do not prefix the column name with a table name or short code, such as user_first_name.
SQL already provides for the tablename as a qualifier: user.first_name.
 the first exception is for PKs. Always use user_id, never id.
 and always use the exact same name wherever a PK is carried as an FK.
Thereforeuser_product will have an user_id as a component of its PK.
 the relevance of this will be clear when you start coding.
 the second exception is where there is more than one FK referencing the same parent
table table, carried in the child. Use Role Names to differentiate the meaning or usage,
egAssemblyId and ComponentId instead of ProductId. And in that case, do not use the
undifferentiated ProductId for one of them. Be precise.
5. Prefix Where you have more than say 100 tables, prefix the table names with a Subject
Area:REF_ for Reference; OE_ for Order Entry, etc. Only at the physical level, not the logical (it
clutters the model).
6. Suffix. I do not use suffixes on tables, and I always use suffixes on everything else. With an
underscore. That means in the logical normal use of the database, there are no underscores;
but on the administrative side, underscores are used as a separator:
_V View (with the main TableName in front, of course)
_fk Foreign Key (the constraint name, not the column name) simple form
_cac Cache
_seg Segment
Etc
This is really important because when the server gives you an error message:

Foreign key violation on Customer_SalesOrder_fk

you know exactly which FK was violated. The Parent_Child_fk vs Child_Parent_fk is
because (a) it shows up in the correct sort order when you are looking for them and (b) we
always know the child involved, what we are guessing at is, which Parent.
7. Foreign Keys (the constraint, not the column). The minimum is identified above. The best
naming for a FK is to use the VerbPhrase, which eliminates the need for a suffix. But that is only
for high end relational databases, where the tables are mature, and the VerbPhrases have been
identified:
Customer_Initiates_SalesOrder
Vendor_Offers_PartVendor
The error message is just a delightful:

Foreign key violation on Vendor_Offers_PartVendor.

8. Indices are special, so they have a naming convention of their very own, made up of, in order:
U Unique
C Clustered
_ separator
If one column or a very few columns, then the
ColumnNames
If more than a few columns, then
PK Primary Key (as per model)
AK Alternate Key (IDEF1X term)
Etc
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 16 of 25
III
TVET/Tigray
 – date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 17 of 25
III
TVET/Tigray
  Notation for UML class diagrams
The class diagram is the main building block of object oriented modeling. It is used both for
general conceptual modeling of the systematic of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data
modeling.The classes in a class diagram represent both the main objects, interactions in the
application and the classes to be programmed.

A class with three sections.

In the diagram, classes are represented with boxes which contain three parts:

 The top part contains the name of the class

 The middle part contains the attributes of the class
 The bottom part gives the methods or operations the class can take or undertake
In the design of a system, a number of classes are identified and grouped together in a class
diagram which helps to determine the static relations between those objects. With detailed
modeling, the classes of the conceptual design are often split into a number of subclasses.
In order to further describe the behavior of systems, these class diagrams can be complemented
by state diagram or UML state machine.
UML provides mechanisms to represent class members, such as attributes and methods, and
additional information about them.

The UML specifies two types of scope for members: instance and classifier.

o Classifier members are commonly recognized as “static” in many programming languages.

The scope is the class itself.
 Attribute values are equal for all instances
 Method invocation does not affect the instance’s state
o Instance members are scoped to a specific instance.
 Attribute values may vary between instances
 Method invocation may affect the instance’s state (i.e., change instance’s attributes)
To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance
scope is assumed by default.

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 18 of 25
III
TVET/Tigray
 1.2 Enhanced ER diagram and UML modeling
The enhanced entity–relationship (EER) model (or extended entity-relationship model)
in computer science is a high-level or conceptual data model incorporating extensions to the
original entity–relationship (ER) model, used in the design of databases.
 Sub classes, super classes and inheritance
Sub classes and Super classes
o In some cases, and entity type has numerous sub-groupings of its entities that are meaningful,
and need to be explicitly represented, because of their importance.
o For example, members of entity Employee can be grouped further into Secretary, Engineer,
Manager, Technician, Salaried_Employee.
o The set listed is a subset of the entities that belong to the Employee entity, which means that
every entity that belongs to one of the sub sets is also an Employee.
o Each of these sub-groupings is called a subclass, and the Employee entity is called the super-
class.

o An entity cannot only be a member of a subclass; it must also be a member of the super-
class.
o An entity can be included as a member of a number of sub classes, for example, a Secretary
may also be a salaried employee, however not every member of the super class must be a
member of a sub class.
Superclass
– An entity type that includes one or more distinct subgroupingsof its occurrences.
Subclass
– A distinct subgrouping of occurrences of an entity type.
• Superclass/subclass relationship is one-to-one.
• Superclass may contain overlapping or distinctsubclasses.
• Not all members of a superclass need be amember of a subclass.
o The subset relationship between the set and its subset is called ISA, meaning “is a”
o In general, ISA could be
» Disjoint: no entity could be in more than one subclass
» Overlapping: an entity could be in more than one subclass
» Total: every entity has to be in at least one subclass
» Partial: an entity does not have to be in any subclass
o
 Specialization and generalization

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 19 of 25
III
TVET/Tigray
Specialization
 The process of defining a set of subclasses of a super class.
 Specialization is the top-down refinement into (super) classes andsubclasses
 The set of sub classes is based on some distinguishing characteristic of the super class.
 For example, the set of sub classes for Employee, Secretary, Engineer, Technician,
differentiates among employee based on job type.
 There may be several specializations of an entity type based on different distinguishing
characteristics.Another example is the specialization, Salaried_Employee and
Hourly_Employee, which distinguish employees based on their method of pay.
 Is the process of defining a set of subclasses of a super-class
 The set of subclasses is based upon some distinguishing characteristics of the entities in the
super-class.
Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE
basedupon job type.
 May have several specializations of the same super-class
Example: Another specialization of EMPLOYEE based in method of pay is
{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
 Super-class/subclass relationships and specialization can be diagrammatically represented in
EER diagrams
 Attributes of a subclass are called specific attributes. For example, TypingSpeed of
SECRETARY
 The subclass can participate in specific relationship types. For example, BELONGS_TO of
HOURLY_EMPLOYEE

Notation for Specialization

o To represent a specialization, the subclasses that define a specialization are attached by lines
to a circle that represents the specialization, and is connected to the super class.
o The subset symbol (half-circle) is shown on each line connecting a subclass to a super class,
indicates the direction of the super class/subclass relationship.
o Attributes that only apply to the sub class are attached to the rectangle representing the
subclass. They are called specific attributes.
o A sub class can also participate in specific relationship types. See Example.

Reasons for Specialization

Certain attributes may apply to some but not all entities of a super class. A subclass is defined in
order to group the entities to which the attributes apply.
The second reason for using subclasses is that some relationship types may be participated in
only by entities that are members of the subclass.

Summary of Specialization
Allows for:
 Defining set of subclasses of entity type
 Create additional specific attributes for each sub class
 Create additional specific relationship types between each sub class and other entity types or
other subclasses.
Generalization
 The reverse of the specialization process

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 20 of 25
III
TVET/Tigray
  Several classes with common features are generalized into a super-class; originalclasses
become its subclasses
• Example: CAR, TRUCK generalized into VEHICLE; both CAR, TRUCK
becomesubclasses of the super-class VEHICLE.We can view {CAR, TRUCK} as a
specialization of VEHICLEAlternatively, we can view VEHICLE as a generalization of
CAR and TRUCK
Types of Specializations
Predicate-defined or Condition-defined specialization
 Occurs in cases where we can determine exactly the entities of each sub class by placing a
condition of the value of an attribute in the super class.
 An example is where the Employee entity has an attribute, Job Type. We can specify the
condition of membership in the Secretary subclass by the condition, JobType=”Secretary”
Another Example:

 The condition is called the defining predicate of the sub class.

 The condition is a constraint specifying exactly those entities of the Employee entity type
whose attribute value for Job Type is Secretary belong to the subclass.
 Predicate defined subclasses are displayed by writing the predicate condition next to the line
that connects the subclass to the specialization circle.
Attribute-defined specialization
 If all subclasses in a specialization have their membership condition on the same attribute of
the super class, the specialization is called an attribute-defined specialization, and the
attribute is called the defining attribute.
 Attribute-defined specializations are displayed by placing the defining attribute name next to
the arc from the circle to the super class.
User-defined specialization
 When we do not have a condition for determining membership in a subclass the subclass is
called user-defined.
 Membership to a subclass is determined by the database users when they add an entity to the
subclass.
 Constraints and characteristics of specialization and generalization
Constraints on Specialization and Generalization
 Several specializations can be defined on an entity type.
 Entities may belong to subclasses in each of the specializations.
 The specialization may also consist of a single subclass, such as the manager specialization,
in this case we don’t use the circle notation.
Disjointness Constraint:
• Specifies that the subclasses of the specialization must be disjointed (an entity can be a
member of at most one of the subclasses of the specialization)
 Specified by d in EER diagram
• If not disjointed, overlap; that is the same entity may be a member of more than one
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 21 of 25
III
TVET/Tigray
subclass of the specialization
 Specified by o in EER diagram
Completeness Constraint:
• Total specifies that every entity in the superclass must be a member of some subclass in
the specialization/ generalization
 Shown in EER diagrams by a double line
• Partial allows an entity not to belong to any of the subclasses
 Shown in EER diagrams by a single line
There are four categories of constraints of specialization and generalization:
– mandatory and disjoint;
– optional and disjoint;
– mandatory and nondisjoint;
– optional and nondisjoint.

 Modeling of union types using categories

 Represent specialization/Generalization and inheritance in UML class

diagrams
Generalization is the process of extracting shared characteristics from two or more classes,
and combining them into a generalized superclass. Shared characteristics can be attributes,
associations, or methods.
In contrast to generalization, specialization means creating new subclasses from an existing
class. If it turns out that certain attributes, associations, or methods only apply to some of the
objects of the class, a subclass can be created. The most inclusive class in a
generalization/specialization is called the superclass and is generally located at the top of the
diagram. The more specific classes are called subclasses and are generally placed below the
superclass.

 Relationship types of degree higher than two

Some database design tools are based on variations of the ER model that permit only binary
relationships. In this case, a ternary relationship such as SUPPLY must be represented as a
weak entity type, with no partial key and with three identifying relationships. The three
participating entity types SUPPLIER, PART, and PROJECT are together the owner entity
types.

 Data Abstraction knowledge Representation and Ontology

The ER and EER models used both in conceptual data modeling and in artificial intelligence
literature when discussing knowledge representation (abbreviated as KR). The goal of KR
techniques is to develop concepts for accurately modeling some domain of knowledge by
creating an ontology that describes the concepts of the domain. This is then used to store and
manipulate knowledge for drawing inferences, making decisions, or just answering questions.
The goals of KR are similar to those of semantic data models, but there are some important
similarities and differences between the two disciplines:
• Both disciplines use an abstraction process to identify common properties and important
aspects of objects in the miniworld (domain of discourse) while suppressing insignificant
differences and unimportant details.
• Both disciplines provide concepts, constraints, operations, and languages for defining data and
representing knowledge.
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 22 of 25
III
TVET/Tigray
• KR is generally broader in scope than semantic data models. Different forms of knowledge,
such as rules (used in inference, deduction, and search), incomplete and default knowledge, and
temporal and spatial knowledge, are represented in KR schemes. Database models are being
expanded to include some of these concepts.
• KR schemes include reasoning mechanisms that deduce additional facts from the facts stored
in a database. Hence, whereas most current database systems are limited to answering direct
queries, knowledge-based systems using KR schemes can answer queries that involve inferences
over the stored data. Database technology is being extended with inference mechanisms.
• Whereas most data models concentrate on the representation of database schemas, or meta-
knowledge, KR schemes often mix up the schemas with the instances themselves in order to
provide flexibility in representing exceptions. This often results in inefficiencies when these KR
schemes are implemented, especially when compared with databases and when a large amount of
data (or facts) needs to be stored.
In this section we discuss four abstraction concepts that are used in both semantic data models,
such as the EER model, and KR schemes:
(1) classification and instantiation,
(2) identification,
(3) specialization and generalization, and
(4) aggregation and association.
The paired concepts of classification and instantiation are inverses of one another, as are
generalization and specialization. The concepts of aggregation and association are also related.
We discuss these abstract concepts and their relation to the concrete representations used in the
EER model to clarify the data abstraction process. An ontology is somewhat similar to a
conceptual schema, but with more knowledge, rules, and exceptions.
1. Classification and Instantiation
The process of classification involves systematically assigning similar objects/entities to object
classes/entity types. We can now describe (in DB) or reason about (in KR) the classes rather than
the individual objects. Collections of objects share the same types of attributes, relationships, and
constraints, and by classifying objects we simplify the process
of discovering their properties. Instantiation is the inverse of classification and refers to the
generation and specific examination of distinct objects of a class. Hence, an object instance is
related to its object class by the IS-AN-INSTANCE-OF OR IS-AN-MEMBER-OFrelationship.
Although UML diagrams do not display instances, the UML diagrams allow a
form of instantiation by permitting the display of individual objects. We did not describe this
feature in our introduction to UML. In general, the objects of a class should have a similar type
structure. However, some objects may display properties that differ in some respects from the
other objects of the class; these exception objects also need to be modeled, and KR schemes
allow more varied exceptions than do database models. In addition, certain properties apply to
the class as a whole and not to the individual objects; KR schemes allow such class properties.
UML diagrams also allow specification of class properties. In the EER model, entities are
classified into entity types according to their basic attributes and relationships. Entities are
further classified into subclasses and categories based on additional similarities and differences
(exceptions) among them. Relationship instances are classified into relationship types. Hence,
entity types, subclasses, categories, and relationship types are the different types of classes in the
EER model. The EER model
does not provide explicitly for class properties, but it may be extended to do so. In UML, objects
are classified into classes, and it is possible to display both class properties and individual
objects. Knowledge representation models allow multiple classification schemes in which one
– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 23 of 25
III
TVET/Tigray
class is an instance of another class (called a meta-class). Notice that this cannot be represented
directly in the EER model, because we have only two levels—classes and instances. The only
relationship among classes in the EER model is a superclass/subclass relationship, whereas in
some KR schemes an additional class/instance relationship can be represented directly in a class
hierarchy. An instance may itself be another class, allowing multiple-level classification
schemes.
2. Identification
Identification is the abstraction process whereby classes and objects are made uniquely
identifiable by means of some identifier. For example, a class name uniquely identifies a whole
class. An additional mechanism is necessary for telling distinct object instances apart by means
of object identifiers. Moreover, it is necessary to identify multiple manifestations
in the database of the same real-world object. For example, we may have a tuple <Matthew
Clarke, 610618, 376-9821> in a PERSON relation and another tuple <301-54-0836, CS, 3.8> in
a STUDENT relation that happen to represent the same real-world entity.
There is no way to identify the fact that these two database objects (tuples) represent the same
real-world entity unless we make a provision at design time for appropriate crossreferencing to
supply this identification. Hence, identification is needed at two levels:
• To distinguish among database objects and classes
• To identify database objects and to relate them to their real-world counterparts
In the EER model, identification of schema constructs is based on a system of unique names for
the constructs. For example, every class in an EER schema whether it is an entity type, a
subclass, a category, or a relationship type must have a distinct name. The names of attributes of
a given class must also be distinct. Rules for unambiguously
identifying attribute name references in a specialization or generalization lattice or hierarchy are
needed as well.
At the object level, the values of key attributes are used to distinguish among entities of a
particular entity type. For weak entity types, entities are identified by a combination of their own
partial key values and the entities they are related to in the owner entity type(s). Relationship
instances are identified by some combination of the entities that they relate, depending on the
cardinality ratio specified.
3. Specialization and Generalization
Specialization is the process of classifying a class of objects into more specialized subclasses.
Generalization is the inverse process of generalizing several classes into a higherlevel abstract
class that includes the objects in all these classes. Specialization is conceptual refinement,
whereas generalization is conceptual synthesis. Subclasses are used in the EER model to
represent specialization and generalization. We call the relationship
between a subclass and its superclass an IS-A-SUBCLASS-OF relationship, or simply an IS-A
relationship.
4. Aggregation and Association
Aggregation is an abstraction concept for building composite objects from their component
objects. There are three cases where this concept can be related to the EER model.
The first case is the situation in which we aggregate attribute values of an object to form the
whole object. The second case is when we represent an aggregation relationship as an ordinary
relationship. The third case, which the EER model does not provide for explicitly, involves the
possibility of combining objects that are related by a particular relationship instance into a
higher-level aggregate object. This is sometimes useful when the higher-level aggregate object is
itself to be related to another object. We call the relationship between the primitive objects and

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 24 of 25
III
TVET/Tigray
their aggregate object IS-A-PART-OF; the inverse is called IS-A-COMPONENT-OF. UML
provides for all three types of aggregation.
The abstraction of association is used to associate objects from several independent classes.
Hence, it is somewhat similar to the second use of aggregation. It is represented in the EER
model by relationship types, and in UML by associations. This abstract relationship is called IS-
ASSOCIATED-WITH.
semantic data models do allow it and call the resulting object a composite or molecular object.
Other models treat entity types and relationship types uniformly and hence permit relationships
among relationships.

Self check one

I. Say true or false
______1. The ER model is a high-level conceptual data model.
______2. The logical ER model contains more detail than the conceptual ER model.
______3. An entity is an object in the miniworld.
______4. A relationship is any association, linkage, or connection betweenthe entities .
______5. A weak entity type always has a partial participation constraint with respect to the
identifying relationship.
II. choose the best answer for the following.
______1. __________ is theminimal super key.
A. Candidate key B. primary key C. alternate key D. all
______2. ______ are the keys which are not chosen as the primary key .
A. Alternate keys B. candidate keys C. secondary keys
______3. Entity types that do not have key attributes are___________.
A. Strong entity types B. weak entity types C. none
______4. Which of the following is not true about Classifier members of UML?
A. Attribute values are equal for all instances
B. Method invocation does not affect the instance’s state
C. Method invocation may affect the instance’s state
D. None
______5. no entity could be in more than one subclass this means
A. disjoint
B. overlapping
C. total
D. all

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 25 of 25
III
TVET/Tigray
Answersheet
self check one
I. True /false
1. True
2. False
3. True
4. True
5. false
II. Choose
1. A.
2. A
3. B
4. C
5. A

– date 08-2017
Database administration L-
Copyright Info/Author: Regional Page 26 of 25
III
TVET/Tigray