Pemrograman

Terstruktur
Kelas 2A-2K
Tim Dosen
Yunarso Anang, Sihar Lumban Tobing, I.R. Tandjung,

Ria Sitanggang, Waris Marsisno, Budi Yuniarto,

Aisyah Fitri Yuniasih

CONCEPT & IMPLEMENTATION OF

THE ENTITY-RELATIONSHIP MODEL
OF A DATABASE
2

What is a Database
A database may be dened as a collecFon of persistent data
Persistent means the data has a more-or-less independent
existence or that is semipermanent
E.g. Data stored in ling cabinet, magneFcally or opFcally
stored on a hard disk or CD-ROM is persistent
The purpose is to store informaFon about certain types of
objects, which is called en)ty(ies) in database languange
E.g. books, authors, publishers, students, lecturers, courses

EnDDes, EnDty Class, & EnDty Set

EnFFes are books

EnFty class is the set of all possible books
EnFty set (at this moment) is the specic set of 14 books in the table

AHributes
EnFFes possess certain properFes, which are called aSributes
The enFty class may has the same, all aSributes of the
enFFes (depend on the database designer)
Purpose of an aSribute
To include informaFon in the database
E.g. we want to know what Ftle of each book, so we
include the Title aSribute
To help uniquely idenFfy individual enFFes within an enFty
class
E.g. we may wish to include publisher's ID-number
aSribute for the Publishers enFty class
Are used to describe relaFonships between the enFFes in
dierent enFty classes
We will discuss later..

The AHributes of LIBRARY database

Books aSributes:
Title: Holds the informaFon about the Ftle of a book
ISBN: Used to uniquely idenFfy the book within the Books enFty class
Price: Holds the informaFon about the price of a book
Authors aSributes:
AuName: Holds the informaFon about the name of an author
AuPhone: Holds the informaFon about the phone number of an
author
AuID: Used to uniquely idenFfy the author within the Authors enFty
class
Publishers aSributes:
PubName: Holds the informaFon about the name of a publisher
PubPhone: Holds the informaFon about the phone number of a
publisher
PubID: Used to uniquely idenFfy the publisher within the Publishers
enFty class

Remarks about these aHributes

There is no direct way to tell who is the author of a given book

The Title aSribute does not uniquely idenFfy the book (too
many books have the same Ftle). The ISBN here is a
quintessenFal idenFfying aSribute
We may reasonably assume that no way two publishers in the
world have the same name and the same phone number. Hence
these two aSributes together uniquely idenFfy the publisher
Nevertheless, we have included the publisher's ID aSribute
to make the idenFcaFon more convenient (more ecient)

Keys and Superkeys

Superkeys are set of aSributes that uniquely idenFes any enFty

from among all possible enFFes in the enFty class

Superkeys applies to enFty classes, and not to enFty sets.

E.g. The set of {ISBN} in the Books enFty class, the set of {PubID} and
{PubName, PubPhone} are both superkeys for the Publishers enFty class
E.g. See the set of {Titles} in the sample BOOKS

A Key is a minimal superkey

E.g. ISBN, AuID, and PubID in sample LIBRARY database

Keys are someFmes called candidate keys, since it is usually the case
that we use as an idenFers
A key may contain more than one aSribute

E.g. {SocialSecurityNumbers} and {FullName, FullAddress, DateOfBirth} are

keys for US Ci)zens enFty class

RelaDonships Between EnDDes

EnFty RelaFonship Diagram or E/R Diagram

An entityrelationship
diagram
E/R diagram

RelaDonship Between EnDDes

Types of RelaFonships

Many-to-many relaFonship

One-to-many relaFonship

E.g. In relaFonship between Books and Authors, a book may have many
authors and an author may write many books
E.g. In relaFonship between Publishers and Books, one publisher may
publish many books, but a book may only be published by at most one
publisher (assumed)

One-to-one relaFonship

DeniFon: Each enFty on each side is related to at most one enFty on

the other side of the relaFonship
E.g. In relaFonship between Authors and Contributors
Might be combined into one enFty class if they share the same
aSributes

ImplemenDng E-R Models

RelaFonal Databases

An E/R model of a database is an abstract model, visualized

through an E/R diagram
To implement the E/R model, we need to implement several
things:

The enFFes
The enFty classes
The enFty sets
The relaFonships between the enFty classes

ImplemenFng the relaFonships usually involves some changes

to the enFty classes, e.g. by adding some aSributes
The result of this implementaFon is a relaFonal database

ImplemenDng EnDDes

ImplementaFon of a Books enFty:

Title = Gone With a Wind

ISBN = 0-12-345678-9
Price = $24.00

EnFty Classes: Table Schemes

Books enFty class aSributes: {ISBN, Title, Price}

or we can write this as Books (ISBN, Title, Price)

ImplemenDng EnDDes
Con)nued

EnFty Sets: Tables

The rst row of the table is the table scheme for the enFty class
Each of the other rows of the table implements an enFty
The set of all rows of the table, except the rst row, implements the
enFty set

Concept of a Table
Each column is labeled with a disFnct a8ribute name Ai, or is
also called column heading
The elements of a column is called the domain for that column
No two rows of the table are idenFcal
A table may (but not required) have a name, e.g. BOOKS
The number of rows is called the size of the table, the number
of columns is called the degree of the table
To emphasize the aSributes of a table, denote a table by wriFng
T(A1, A2, , An). E.g. BOOKS (ISBN, Title, Price)
The order of the rows of a table is not important
Similarly, the order of columns is also not important
Dierent columns may have the same domain, as long as the
aSributes are dierent

ImplemenDng the RelaDonships

ImplemenDng the RelaDonships

One-to-Many RelaFonship

Add PublisherOf relaFonship to Books enFty class

Add PubID to the Books enFty class: Books (ISBN, Title, PubID, Price)
The Books table scheme is now {ISBN, Title, PubID, Price}

ImplemenDng the RelaDonships

One-to-Many RelaFonship (Con)nued)

A2 is a key for the table scheme S

A2 in table scheme T is a foreign key, and is not a key for T
Foreign key(s) in a table scheme is a key in the referenced table
scheme

ImplemenDng the RelaDonships

Many-to-Many RelaFonship

Cannot be implemented with two disFnct one-to-many

relaFonships: caucing redundancy
We may use approach to implemenFng this by adding new
table scheme to the database

Book/Author enFty class: Book/Author (ISBN, AuID)

ReferenDal Integrity

ConsideraFons in enFty-relaFonship model

Each value of the foreign key must have matching value in the
referenced key
Otherwise, we would have a so-called dangling reference
The requirement is called referen)al constraint
The problem of ensuring the fullll of this requirement is called
referen)al integrity
How this might be a problem?

In inserFng new enFty to an enFty set

In updaFng a key of the referenced enFty
In deleFing the enFty which is refered in the other enFty

How to prevent this?

Sepng up the cascading updates and deleFons