Lecture On Database Analysis and Design

ByJesmin Akhter Lecturer, IIT, Jahangirnagar University

MODELING THE RULES OF THE ORGANIZATION

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Overview of Business Rules

Business rules are important in data modeling because they govern how data are handled and stored. Basic business rules are data names and definitions. Thoroughly capturing and structuring business rules, then enforcing them through database technologies, helps to ensure that information systems work right and that users of the information understand what they enter and see.

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Data Names and Definitions

Fundamental to understanding and modeling data are naming and defining data objects. In the entity-relationship notation , entities, relationships, and attributes are defined with clear and distinct names and definitions. there are some general guidelines about naming any data object. Data names should Relate to Business, not Technical (Hardware or Software) Characteristics; so, Customer is a good name, but File10, Bit7 are not good names. . Be Meaningful almost to the point of being self-documenting.

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Data Names
Be Unique from the name used for every other distinct data object; words should be included in a data name if they distinguish the data object from other similar data objects (e.g., HomeAddress versus CampusAddress). Be Readable, so that the name is structured as the concept would most naturally be said (e.g., GradePointAverage is a good name. Be Composed of Words; each organization often chooses a vocabulary from which significant words in data names must be chosen. Alternative, or alias names, also can be used as can approved abbreviations (e,g CUST for Customer), and you may be encouraged to use abbreviations so that data names are short enough to meet maximum length limits of database technology. Be Repeatable, meaning that different people or the same person at different times should develop exactly or almost the same name; this often means that there is a standard hierarchy or pattern for names (e,g., the birth date of a student would be StudentBirthDate and the birth date of an employee would be EmployeeBirthDate).

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Data Modeling using the Entity Relationship Model

Prepared by Jesmin Akhter, Lecturer, IIT,JU

ER Model Concepts
Entities and Attributes
Entities are specific objects or things in the mini-world that are represented in the database. For example EMPLOYEE , DEPARTMENT, PERSON, COMPANY. Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have a Name, Id, Address, Sex, BirthDate. A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', Id='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55 Each attribute has a value set (or data type) associated with it e.g. integer, float string, date-type, enumerated type,

Types of Attributes
Simple Each entity has a single atomic value for the attribute. Attribute that are not divisible are called simple or atomic attributes. For example, id or Sex. Composite The attribute may be composed of several components. For example, Address (Apt#, House#, Street, City, State, ZipCode, Country) or Name (FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite. Multi-valued An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.

Entity Type Versus Entity Instance

An entity instance is a single occurrence of an entity type. Figure below illustrates the distinction between an entity type and two of its instances. An entity type is described just once (using metadata) in a database, whereas many instances of that entity type may be represented by data stored in the database. For example, there is one EMPLOYEE entity type in most organizations, but there may be hundreds (or even thousands) of instances of this entity type stored in the database.

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Strong Versus Weak Entity Types

Most of the basic entity types to identify in an organization are classified as strong entity types. A strong entity type is one that exists independently of other entity types. Examples include STUDENT, EMPLOYEE, AUTOMOBILE, and COURSE. Instances of a strong entity type always have a unique characteristic (called an identifier)-that is, an attribute or combination of attributes that uniquely distinguish each occurrence of that entity. A weak entity type is an entity type whose existence depends on some other entity type. A weak entity type has no business meaning in an E-R diagram without the entity on which it depends. The entity type on which the weak entity type depends is called the identifying owner (or simply owner for short). A weak entity type does not have its own identifier. Generally, on an E-R diagram, a weak entity type has an attribute that serves as a partial identifier A full identifier will be formed for the weak entity by combining the partial identifier with the identifier of its owner.
Prepared by Jesmin Akhter, Lecturer, IIT,JU

Simple Versus Composite Attributes

A composite attribute is an attribute, such as Address, that has meaningful component parts. Figure shows the notation that we use for composite attributes applied to this example. EMPLOYEE Employee_Address (StreeCAddress, City, State, PostaLCode)

Simple (or atomic) attribute: An attribute that cannot be broken down into smaller components that are meaningful to the organization. For example, all of the attributes associated with AUTOMOBILE are simple: Vehicle_ID, Color, Weight and Horsepower.
Prepared by Jesmin Akhter, Lecturer, IIT,JU

Single Valued Versus Multivalued Attributes

Single valued attribute: An attribute that may take on only one value for a
given entity (or relationship) instance. Ex. Age is a single valued attribute of a person. Multivalued attribute: An attribute that may take on more than one value for a given entity (or relationship) instance Ex. Colors attribute for a car , Cars with one color have a single valued, where as two tone cars have two values for colors. Ex. College degree

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Stored Versus Derived Attributes

Some attribute values can be calculated or derived from other related attribute values that are stored in the database. For example, suppose that for an organization, the EMPLOYEE entity type has a Date_Employed attribute. If users need to know how many years a person has been employed, that value can be calculated using Date_Employed and today's date. Ex. Date_Employed , BirthDate. A derived attribute is an attribute whose values can be calculated from related attribute values (plus possibly data not in the data base, such as today's date, the current time, or a security code provided by a system user). EMPLOYEE
Ex. Age attribute of a person.

Employee_Name( ... ) PayroILAddress( ... ) Date_Employed {Skill} (Years_Employed)

Prepared by Jesmin Akhter, Lecturer, IIT,JU

Entity Types and Key Attributes

An entity type defines a collection (or sets)of entities that have the same attributes but each entity has its own value. For example, the EMPLOYEE entity type or the PROJECT entity type. An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, Id_no of EMPLOYEE. A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity type with components (Number, State). An entity type may have more than one key. For example, the CAR entity type may have two keys: VehicleIdentificationNumber (popularly called VIN) and VehicleTagNumber (Number, State), also known as license_plate number.

ENTITY SET corresponding to the ENTITY TYPE CAR

The collection of all entities of a particular entity type in the database at any point in time is called an entity set. Use the same name as entity type. CAR indicate entity type and current set of all CAR entities in the database.

CAR Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, {Color} car1 ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1999, {red, black}) car2 ((ABC 123, NEW YORK), WP9872, Nissan 300ZX, 2-door, 2002, {blue}) car3 ((VSY 720, TEXAS), TD729, Buick LeSabre, 4-door, 2003, {white, blue}) . . .

NOTATION OF ER-DIAGRAM
Symbol Meaning ENTITY WEAK ENTITY RELATIONSHIP IDENTIFYING RELATIONSHIP ATTRIBUTE KEY ATTRIBUTE MULTIVALUED ATTRIBUTE COMPOSITE ATTRIBUTE DERIVED ATTRIBUTE

E1 E1

R R R N (min,max)

E2 E2 E

TOTAL PARTICIPATION OF E2 IN R CARDINALITY RATIO 1:N FOR E1:E2 IN R STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R

ER DIAGRAM Entity Types are:

EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Relationships and Relationship Types

A relationship relates two or more distinct entities with a specific meaning. For example, EMPLOYEE John Smith works on the ProductX PROJECT or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS_ON are binary relationships.

Example relationship instances of the WORKS_FOR relationship between EMPLOYEE and DEPARTMENT
EMPLOYEE WORKS_FOR DEPARTMENT

e1 e2 e3 e4 e5 e6 e7

      

r1 r2

d1 d2 d3

r3 r4 r5 r6 r7


Example relationship instances of the WORKS_ON relationship between EMPLOYEE and PROJECT
EMPLOYEE WORKS_ON PROJECT

r9 e1 e2 e3 e4 e5 e6 e7
      

r1 r2

p1 p2 p3

r3 r4 r5 r6 r8 r7


Relationships and Relationship Types (2)

More than one relationship type can exist with the same participating entity types. For example, MANAGES and WORKS_FOR are distinct relationships between EMPLOYEE and DEPARTMENT, but with different meanings and different relationship instances.

ER DIAGRAM Relationship Types are:

WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

Weak Entity Types

An entity that does not have a key attribute

Example: Suppose that a DEPENDENT entity is identified by the dependents first name and birhtdate, and the specific EMPLOYEE that the dependent is related to. DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity type via the identifying relationship type EPENDENT_OF

Chapter 3-23

Weak Entity Type is: DEPENDENT Identifying Relationship is: DEPENDENTS_OF

Chapter 3-24

Constraints on Relationships

Constraints on Relationship Types ( Also known as ratio constraints ) Maximum Cardinality One-to-one (1:1) One-to-many (1:N) or Many-to-one (N:1) Many-to-many Minimum Cardinality (also called participation constraint or existence dependency constraints) zero (optional participation, not existencedependent) one or more (mandatory, existence-dependent)

Many-to-one (N:1) RELATIONSHIP

EMPLOYEE WORKS_FOR DEPARTMENT

e1 e2 e3 e4 e5 e6 e7

      

r1 r2

d1 d2 d3

r3 r4 r5 r6 r7


Many-to-many (M:N) RELATIONSHIP

EMPLOYEE WORKS_ON PROJECT

r9 e1 e2 e3 e4 e5 e6 e7
      

r1 r2

p1 p2 p3

r3 r4 r5 r6 r8 r7