Database Systems

LECTURE #:09 M. Shafiq FACULTY OF CS & IT

UNIVERSITY OF GUJRAT

Data Modeling

A detailed model that captures overall structure of organizational data while being independent of any implementation considerations Typically data modelling is carried out parallel with other requirements analysis and structuring steps during the systems analysis phase. Following this, the data model supporting the scope and requirements of the proposed system is developed.

Entity Relationship Diagram Model: A Data Modeling Approach.

Proposed by Peter Chen in 1976 Entity Relationship Diagram is a form of data modelling A logical representation of the data of an organization or business area in graphical form Data modelling involves examining the data objects in a system and identifying the relationship between these objects Top-down approach to database design The primary purpose of an ERD is to document the logical structure of a database

Why ERD ?

Conceptual design: (ER Model is used at this stage.)

What

are the entities and relationships in the enterprise? What information about these entities and relationships should we store in the database? What are the integrity constraints or business rules that hold? A database `schema in the ER Model can be represented pictorially (ER diagrams). An ER diagram can be mapped into a relational schema.
4

Basic Symbols
Components Name
Entity

Symbol

Department

Attribute
Staff No.

Relationship

employs

OR

employs
5

An Entity

An entity is a thing of interest to a system about which information is kept For example in a Hospital Administration System, some likely entities would include: Patient, Doctor, Operation, Ward

Each of these things are of interest to the system and would have data stored about them
6

Choosing Entities

Example A sale always starts with a customer receiving an estimate. The estimate then becomes an order. An order can be for one or more stock items. Each stock item belongs to a certain stock category (e.g. taps, sinks, cupboards etc.)

An Attribute
An attribute is an item of data held about an entity In computer systems an attribute is a field of information Example : Sales System Entity : Customer Attributes : Customer Name, Customer Address, Customer Phone Number

For Example

In a Sales System, customer name and address are attributes of the entity customer.

The primary key is likely to be Customer Code or Customer ID as the unique identifier for each customer in the system.

Basic E-R Notation

Entity symbols

A special entity that is also a relationship

Attribute symbols
Relationship symbols

Associative Entity

The database relational model doesn't offer direct support to many-to-many relationships. The solution to this problem is the creation of another table to hold the necessary information for this relationship. This new table is called an associative entity. An Associative entity becomes an entity and a relationship since it encapsulates properties from both.

11

Multivalued Attribute

Multivalue attribute is the practice of maintaining more than a single value in a database column. If you want to know the hobbies for a client. The proper way to handle this is to maintain the data in a one - to - many child table. Another way is a multivalue field that will contain one or more values, separated by a comma. The eMailAddress field can store a variable number of email address values in the single record. So the list [joe@abc132.info, jdb@gbmail.net, joe_bacde@thisorthat.edu] can be stored and accessed via a single query / disk read when accessing the associated record. phone number = {617-555-1234, 617-333-4321} <-- multi-valued attribute example

12

Derived Attribute
Derived attributes are attributes whose values are generated from other attributes using calculations, algorithms or procedures For Example

Employee Age derived from Date of Birth Account Balance derived from ?? Work Experience derived from ??

13

Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed) Whats wrong with this?

Derived
from date employed and current date

Multivalued:
an employee can have more than one skill

Composite Attribute

A composite attribute consists of a group of values from more than one domain. For example, the Address attribute consists of several domains such as house number, street number, city, country, etc.

15

Strong and Weak Entity

A Weak Entity is an entity that cannot be uniquely identified by its attributes alone; therefore, it must use a foreign key in conjunction with its attributes to create a primary key. The foreign key is typically a primary key of an entity it is related to. A weak entity is part of an ER diagram that relies on other entities (Strong Entities). Without the strong entity, the weak entity wouldn't exist. An entity transaction has attributes transaction-number, date and amount. Different transactions on different accounts could share the same number. These are not sufficient to form a primary key (uniquely identify a transaction). 16 Thus transaction is a weak entity set.

Identifying Relationship and Relationship

An identifying relationship describes a situation in which the existence of a row in the child table depends on a row in the parent table. An example of this that is given is, An author can write many books (1-to-n relationship), but a book cannot exist without an author.

17

Scenario Example of ERD

An Organization wants to run a home appliances service center. Customers call to request a technician and the center Coordinator assigns an employee to sit for the customer from a list of employees available for the particular day requested.

18

Service Center System

Data is used to: Assign employee to job Determine availability Data to be captured in database: Employee data Job data Customer data

19

ERD - Service Center System

Employee

Customer

assigned to
Job

Related to

Service Center System

Employee

Attributes: EmpID, Name, Address, Phone Number, Available Hours, JobNo Attributes: JobNo, JobDate, JobTime, EmpID Attributes: CusNo, Name, Address, Phone Number, JobNo
21

Job

Customer

Entity Instance
An entity instance is a single occurrence of an entity type. An entity type is described just once in a data model while many instances of that data type may be represented by data stored in the system. There is one EMPLOYEE entity type in most organisations but there may be hundred or thousands of instances of this entity type in the company.

Example A sale always starts with a customer receiving an estimate.The estimate then becomes an order. An order can be for one or more stock items. Each stock item belongs to a certain stock category (e.g. taps, sinks, cupboards etc.)

From the narrative we can deduce An Estimate becomes and Order An Estimate is issued to a particular Customer An Estimate refers to a Stock Item(s) An Order is placed by the Customer An Order refers to a Stock Item(s) A Stock Item refers to a particular Stock Category

Order System
Order
Places Becomes

Refers to

Stock Item
Refers to

Issued to

Customer

Estimate
Refers to

Stock Category

Entity
Estimate

Primary Key
Estimate Number

Other Attributes
Date Customer Number Stock Item Code Same as Estimate

Order Customer

Order Number

Stock Item

Stock Category

Customer Number Customer Name Customer Address Credit Limit Stock Item Code Description Number in Stock Supplier Code Category Code Category 26 Description

ERD Relationships
A relationship is an association between two entities that is important to the system. We must also consider the extent to which each entity is related to another. There may be: Unary Relationship Binary Relationship Ternary Relationship

27

The Cardinality of a Relationship

Cardinality defines the minimum and maximum number of occurrences of one entity for a single occurrence of the other

From the previous example we can say that: A customer can place several orders if they wish But an order can only be placed by one customer
28

Cardinality

Cardinality is bi-directional This means that it must be defined for both directions of the entity relationship.

29

One-to-One Relationship (1:1)

A one-to-one relationship occurs where a single occurrence of one entity relates to one occurrence of a second entity.
Estimate

becomes

Order

An estimate can only become one order and an order is derived from one estimate.

30

One-to-Many Relationship(1:N)

One-to-Many relationships occur when a single entity instance is related to many occurences of a second entity.

Customer

is issued with

Estimate

One customer can be issued with many estimates (the relationship is described as one-to-many)

Many-to-Many Relationship (N:M)

Many-to-many relationships occur where many instances of an entity relate to many instances of a second entity Usually N:M relationships are broken into one or more pairs of one-to-many relationships

N:M

Estimate

Refers to

Stock Item

Many estimates refers to many stock items (or many stock items are referred to by many estimates)

Sales ERD
Order
Places Becomes Refers to

Stock Item
Refers to

Issued to

Customer

Estimate
Refers to

Stock Category

Cardinality

Optional Cardinality

Where the analyst considers whether an entity occurrence at one end of the relationship can ever be present in the system without the presence of the corresonding occurrence of the entity at the other end of the relationship

Mandatory Cardinality

When the occurrence of the entity at either end of the relationship must be present in the system

35

Mandatory - Mandatory

Some relationships are mandatory and some are optional

Doctor

Is responsible for Registered with

Patient

A doctor must be responsible for one or more patients and a patient must be registered with one and only one doctor

Optional Mandatory

Doctor

Is responsible for Register ed with

PROJECT

A doctor may be responsible for one or more patients and a patiente must be registered with one and only one doctor

37

Mandatory Optional

A doctor must be responisble for one of more patients and a patient may be registered with one and only one doctor
Is responsible for Registere
d with

Doctor

Patient

Optional Optional

A doctor may be responsible for one or more patients and a patient may be registered with one and only one doctor
Is responsible for Registere
d with

Doctor

Patient

39

Relationship Cardinality
Graphic Cardinality Exactly 1 0 or 1 1 or more 0 or many More than 1
40

Note || denotes 1 and only

EE-R Data Model

Most common feature is representation of supertypes and subtypes A popular feature of Object Oriented paradigm

Super/Subtypes

Also called generalization/ specialization

Supertype is called a General Entity type whereas subtypes are the specializations For Example Wahical is Supertype and Car,Van and Bus are the sub types.

Super/Subtypes
General Entity Types
ST PERSON

ST1

ST2

ST3

EMP

FAC

Specialized Entity Types

Super/Subtypes
EMP

Grade

NoOfHrs

SALARIED
AnalSal

HOURLY
HourlyRate

Super/Subtypes
Id Address Name

PERSON

StId

Qual

STD
CGPA
ClsName

FAC
Grade