2.

0 ENTITY

RELATIONSHIP MODEL

INTRODUCTION
ER Model is the construct and conventions used to

create a model of the user data. The entity-relationship model is used to interpret, specify, and document requirements for databaseprocessing systems. It describes data as entities, relationships, and attributes. Entity-relationship models are usually construct during the analysis phase of the database development process.

Perhubungan (Relationship)

FACTORY

CAR

CUSTOMER

Entity

The diagram above shows a car-purchasing model that involves the relationship between the factory, car and customer. Here, we can see clearly that factory produces car and a customer purchases the car. Entity: FACTORY, CAR & CUSTOMER. Relationship: Produce & Purchased by.

Entity Relationship Diagram Definition: An entity-relationship

(ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and Ovals are used to represent attributes.

Elements of E-R model:

Entiti Atribut Relationship

Entity Relationship Diagram

Entity = thing or object. Entity set = collection of similar entities. Similar to a class in object-oriented languages. Attribute = property of (the entities of) an entity set. Attributes are simple values, e.g. integers or character strings, not structs, sets, etc.

Entity
Definition Entity is a person, place, object, event or concept, which you want to store the information in a database. Entity which is a thing in the real world with an independent existence

Entity
The symbol of entity :
PELAJAR

PEKERJA

Must have an attributes and unique key. Will become a Table in a database.

Entities can be thought of as nouns.

Examples: a computer, an employee, a

song, a mathematical theorem. Entities are represented as rectangles.

 We can classify entity as being strong or

weak entities types. 1. Weak Entity type : an entity type that is existence-dependent on some other entity type. Example family of staff depends on existence of entity staff. 2. Strong Entity type : an entity type that is not existence-dependent on some other entity type.

Entity Classification
PERSON PLACE OBJECT EVENT Example: Student, Employee Example: Country, Branch Example: Product, Building Example: Student Registration, Payment

CONCEPT

Example: Course, Order

What is Entity Type?

Entity type is a collection of entities, which share the same characteristic. What is Entity Instances? Entity instances are data for entity type.

Entity Type :- BOOK

Attribute :Book_Code Book_Title Publisher_Code Description Price

Two entity instances for BOOK :

P01 Access 2000 Processing M-G1 Database 76.00 P02 Concepts of Database P-H1 Database 100.00

Attribute
Attribute is a character of an entity or object. Attribute has a name and a data type
Contoh : Atribut untuk entiti BUKU ialah Book_Code, Type, Price, Title, dan Publisher_Code.

 Each entity has particular properties,

called attributes, which describe properties of entities and relationships.

Entity Attributes

EMPLOYEE

Employee number, Name, Address, Gender, Date of birth Name, Location, Size, Population, Attraction

TOWN

MACHINE COURSE

Machine number, Name, State, Location, History Course code, Name, Level, School, Number of credits

Relationship
A relationship captures how two or more

entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.
Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem.

Example of ER.

Conclusion
Entity represent the basic object in

the e-r model.

The E-R model is expressed in

terms of entities in the business environment, the relationships amongst those entities, and the attributes (or properties) of both the entities and their relationships.

Conclusion
In other words, the things in the users

world are represented by entities, and the associations among those things are represented by relationships.

2.0 Entity-Relationship (ER) Modeling.

ER Modeling is a top-down approach to database

design. Entity Relationship (ER) Diagram

A detailed, logical representation of the entities, associations and data elements for an organization or business
Chen Model & Crows Foot Model

Notation uses three main constructs Data entities Relationships Attributes

Chen Notation

Association between the instances of one or more entity types

EntityName Verb Phrase AttributeName

Person, place, object, event or concept about which data is to be maintained

Represents a set or collection of objects in the real world that share the same properties

named property or characteristic of an entity

NOTATION FOR E-R MODEL

Entity An entity is an object or concept about which you want to store information.

Weak Entity A weak entity is dependent on another entity to exist.

NOTATION FOR E-R MODEL

Attributes Attributes are the properties or characteristics of an entity.

Key attribute A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.

NOTATION FOR E-R MODEL

Multivalued attribute A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values. Derived attribute A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.

NOTATION FOR E-R MODEL

Relationships Relationships illustrate how two entities share information in the database structure.

Weak relationship To connect a weak entity with others, you should use a weak relationship notation.

Crows Foot Notation

Entity

Attribute

Relationship

EntityName EntityName List of Attributes

Verb phrase

Acceptable

Relationships
Associations between instances of one or more entity types that is of interest Given a name that describes its function. relationship name is an active or a passive verb.

Relationship name: writes Author Book

An author writes one or more books A book can be written by one or more authors.

Degree of Relationships
Degree: number of entity types that participate in a relationship Three cases

Unary: between two instances of one entity type Binary: between the instances of two entity types Ternary: among the instances of three entity types

Cardinality and Connectivity

Relationships can be classified as either
one to one one to many many to many

Connectivity

Cardinality : minimum and maximum number

of instances of Entity B that can (or must be) associated with each instance of entity A.

Cardinality EXAMPLE
In our model, we wish

to indicate that each school may enroll many students, or may not Each school enrolls enroll any students at all. We also wish to at least zero indicate that each student attends exactly and at most many one school. The students following diagram indicates this optionality and cardinality:

STUDENT

Each student attends at least one and at most one

SCHOOL

school

Cardinality and Connectivity

Professor

teaches

Class

Professor

teaches

Class

A professor teaches class OR A class is taught by professor

How Many??

Cardinality and Connectivity

Connectivity

1
Professor teaches

M
Class

(1,4)

(1,1)

Cardinality

Connectivity
teaches

Professor

Class

(1,1) Cardinality

(1,4)

Connectivity
Chen Model 1 to represent one. M to represent many Crows Foot
One many One or many Optional? well see after this Mandatory one , means (1,1) 1

Binary Relationships

1:M relationship Relational modeling ideal Should be the norm in any relational database design

The 1: M relationship between PAINTER and PAINTING

The Implemented 1:M relationship between PAINTER and PAINTING

Binary Relationships

1:1 relationship Should be rare in any relational database design A single entity instance in one entity class is related to a single entity instance in another entity class Could indicate that two entities actually belong in the same table

The 1:1 Relationship Between PROFESSOR and DEPARTMENT

The Implemented 1:1 Relationship Between PROFESSOR and DEPARTMENT

Binary Relationships

M:N relationships

Must be avoided because they lead to data redundancies.

Can be implemented by breaking it up to produce a set of 1:M

relationships Can avoid problems inherent to M:N relationship by creating a composite entity or bridge entity

This will be used to link the tables that were originally related in a M:N relationship The composite entity structure includes-as foreign keys-at least the primary keys of the tables that are to be linked.

The M:N Relationship Between STUDENT and CLASS Bowser Accounting 1 (ACCT-211)

Smithson

Intro to Microcomputing (CIS-220)

Intro to Statistics (QM-261)

This CANNOT be implemented as shown next..

The tables have many redundancies!!

+ CLASS_CODE
CLASS_CODE

+ STU_NUM

Changing the M:N relationship to TWO 1:M relationships

The database designer has 2 main options to define a composite tables primary key: either use the combination of those foreign keys or create a new primary key.

Foreign keys reference the primary keys in the other tables of which it has a relationship with

Converting the M:N relationship into TWO 1:M relationships

Mandatory vs. Optional Cardinalities

Specifies whether an instance must exist or can be absent in the

relationship
Mandatory Optional

Lecturer
(1,1)

handles
(0,N) M

Class

Lecturer
(0,N)

handles
(1,1)

Class

A Lecturer may handle zero or many classes.

A class is handled by one and only one Lecturer.

Keys
A key is a special column in a table. While some keys

are used for searching and indexing, other are used for linking related tables or uniquely identifying a record. A database table can survive without a primary key or an index, but this deters the whole purpose of a database: the easy retrieval of information.

Primary Key
The purpose of a primary key is to uniquely identify

each record in a table. In general, a primary key is defined on a single column, but it is not uncommon to have it defined on two columns. There are three basic rules that you should observe when defining primary keys: Every record must have a value in the primary key. It cannot be null. Primary key values must be unique. Primary key values should not be reused. If a record is deleted, its primary key should not be reassigned to another record, as this can create errors and confusion.

Foreign Key
A foreign key is a field from a table that refers to (or targets) a specific key, usually the primary key, in another table. This is a convenient way of logically linking information from related tables. For instance, the products table contains a foreign key (idman_prd) that references the primary key field (id_man) in the manufacturers table. This way, each product has an associated manufacturer its foreign key points to the unique identifier of the manufacturer. Please note that the foreign key is not unique, but the referenced field (the primary key in the referenced table) usually is.

However, in order to indicate that there is a relation between the two tables, you need two fields: a primary key in the manufacturers table and a foreign key in the products table.