0% found this document useful (0 votes)
26 views13 pages

DB Lecture-4

Uploaded by

pola88978
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views13 pages

DB Lecture-4

Uploaded by

pola88978
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

10/23/2024

Lecture 4
Data Modeling Using the
Entity-Relationship (ER) Model

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.1

Lecture objectives

1. Database Development Process.


2. Using High-Level Conceptual Data
Models for Database Design.
3. ER Model Concepts (Entities,
Attributes, and Keys).
4. A Sample Database Application.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.2

1
10/23/2024

1. Database
Development
Process

DFD
Sequence
……..

Nontechnical
User

Application Programs
© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.3

2. Using High-Level Conceptual Data


Models for Database Design

❖ Requirements collection and analysis


❖ Database designers interview prospective
database users to understand and document
data requirements
❖ Result: data requirements
❖ Functional requirements of the application

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.4

2
10/23/2024

Using High-Level Conceptual Data


Models (cont’d.)

❖ Conceptual schema
❖ Conceptual design.
❖ Description of data requirements.
❖ Includes detailed descriptions of the entity
types, relationships, and constraints.
❖ Transformed from high-level data model into
implementation data model.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.5

Using High-Level Conceptual Data


Models (cont’d.)

❖ 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 design
parameters for the database files specified.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.6

3
10/23/2024

3. ER Model Concepts

❖ ER model describes data as:


❖ Entities
❖ Attributes
❖ Relationships

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.7

Entities
❖ Entity: is a thing in the real world with an
independent existence
❖ An entity may be a person, a place, an object, an
event, or a concept in the user environment
about which the organization wishes to
maintain data

❖ Examples:
❖ An object with a physical existence (person, car,
employee).
❖ An object with a conceptual existence (a job, or
a university course).

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.8

4
10/23/2024

An Entity…
❖ SHOULD BE:
❖ An object that will have many instances in the
database.
❖ An object that will be composed of multiple
attributes.
❖ An object that we are trying to model

❖ SHOULD NOT BE:


❖ A user of the database system
❖ An output of the database system (e.g. a report)

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.9

Entities
❖ Entity type – a collection of entities that share
common properties or characteristics.
❖ Entity instance – A single occurrence of an
entity type.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.10

10

5
10/23/2024

Strong vs. Weak Entities

❖ Strong entity
➢ exists independently of other types of entities
➢ has its own unique identifier, identifier underlined
with single line.
❖ Weak entity
➢ dependent on a strong entity (identifying
owner)…cannot exist on its own.
➢ does not have a unique identifier (only a partial
identifier).
➢ entity box and partial identifier have double lines.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.11

11

Example of a weak identity and its


identifying relationship

Name

DEPENDENT Age
DependentOf

EID
Name EMPLOYEE
Phone

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.12

12

6
10/23/2024

Attributes
❖ Attribute: property or characteristic of an entity or
relationship type (used to describe an entity).
❖ Name should be a singular noun
❖ Name should be unique
❖ Examples:
❖ An “Employee” entity may be described by the
employee’s name, age, address, salary, and job
❖ A “Student” entity may be described by the
student’s name, student number, current address,
permanent address, birthDate, sex, class, and
phone

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.13

13

Attributes

❖ Classifications of attributes:
1. Required versus Optional Attributes
2. Simple versus Composite Attribute
3. Single-Valued versus Multivalued Attribute
4. Stored versus Derived Attributes
5. Complex Attributes.
6. Identifier (key) Attributes

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.14

14

7
10/23/2024

1) Required vs. Optional Attributes

❖ Required: must have a value for every entity


(or relationship) instance with which it is
associated, e.g. Student ID

❖ Optional: may not have a value for every


entity (or relationship) instance with which it is
associated, e.g. Student Major

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.15

15

2) Simple vs. Composite Attributes


❖ Attributes that are not divisible are called simple
or atomic attributes, e.g. Sex

❖ Composite attribute: An attribute that has


meaningful component parts (attributes) or tree

The address is
broken into
component parts

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.16

16

8
10/23/2024

3) Single-Valued versus Multi-valued


Attribute
❖ Single: must have a single value, e.g.
Employee’s Marital status

❖ Multi-valued: may take on more than one


value for a given entity (or relationship)
instance, e.g. an employee can have more than
one skill

❖ Question: which type of attributes represent


“College degrees” single or multi-valued
attribute?

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.17

17

4) Stored versus Derived Attributes

❖ Stored: a value must be physically stored in


the database, .e.g. birthdate

❖ Derived: values can be calculated from related


attribute values (not physically stored in the
database), e.g. years employed for employees
could be calculated from date employed and
current date

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.18

18

9
10/23/2024

5) Complex Attribute

❖ Complex: composite and multivalued attributes.


Composite attribute between parentheses () and
separating the components with commas, and by
displaying multi-valued attributes between braces { }

❖ Example
{Address_phone(
{Phone(Area_code,Phone_number)},
Address(Street_address(Number,Street,
Apartment_number),City,State,Zip) )}

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.19

19

6) Identifier (key) Attributes

❖ Key or uniqueness constraint


❖ Attributes whose values are distinct for each
individual entity in entity set.
❖ Key attribute: Uniqueness property must
hold for every entity set of the entity type, e.g.
Student ID.
❖ Key attribute : Cannot be Null.
❖ Key attribute may be more than one
attribute, e.g. “Project ID” and “Employee ID”.
❖ If the entity does not have key attributes of their
own, it will called “Weak entity”

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.20

20

10
10/23/2024

Notation Summary

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.21

21

4.Initial Conceptual Design of the


COMPANY Database
❖ An entity type EMPLOYEE with attributes Name,
Ssn, Sex, Address, Salary, Birth_date,
Department, Age, and Supervisor. Both Name
and Address may be composite attributes. Each
employee works on more than one project with
different hours.

❖ An entity type DEPENDENT with attributes


Employee, Dependent_name, Sex, Birth_date,
and Relationship (to the employee).

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.22

22

11
10/23/2024

Initial Conceptual Design of the


COMPANY Database

Age

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.23

23

Initial Conceptual Design of the


COMPANY Database
❖ An entity type DEPARTMENT with attributes Name,
Number, Locations, Manager, and Manager_start_date.
Department may be found in more than one Location.
Name and Number are specified to be unique.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.24

24

12
10/23/2024

Initial Conceptual Design of the


COMPANY Database
❖ An entity type DEPARTMENT with attributes Name,
Number, Locations, Manager, and Manager_start_date.
Department may be found in more than one Location.
Name and Number are specified to be unique.

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.25

25

Thank you

© 2023 by Prof. Manal Abdel-Kader Abdel-Fattah 4.26

26

13

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy