AB1401

Information Technology

Seminar 5: Database I

Database Design
 Learning Objectives
 To understand how data is represented

 Differentiate between databases and

spreadsheets

 To design databases using Entity-

Relationship Diagrams

 To decompose ERD diagram into database

schema
 What is Data?

Data is a a fact
or observation
about people,
places, things,
and events.

Different types of data

 Data As a Corporate Asset
 Raw material used to produce information

 Valuable resource

 Information
◦ Timely and accurate data can trigger beneficial
actions
◦ Basis for knowledge
◦ Used in decision making
Representing the Real World as Data
What Data are Businesses interested in?
 Entity
◦ a person, place, thing, or event on which we maintain
information
◦ Examples: Employees, Customers, Products, Warehouses

 Attribute – characteristic or quality of particular entity

◦ Employee’s IC, Customer’s Address, Product’s Unit Price

 Relationships Among Entities

◦ Customer -Orders -Product(s)
◦ Order -Serviced by –Employee
◦ Professor teaches a course
From Spreadsheets to Databases
 Spreadsheets are great for keeping track of
data for one type of entities
◦ Participants of a conference
◦ Students of a class
◦ Customers of a company
◦ ….
What is the basic Spreadsheet “Data
Model”?
 Each row stores data about one entity
 Each column stores data about an attribute
 Each cell stores data about an attribute of

an entity
 Spreadsheet Limitations
 Things get complicated when we want to keep
track of several inter-related entities

 For example:
◦ Customers
◦ Products
◦ Orders

 Main difficulty is that an “Order” is essentially a

relationship between one Customer and one or
more Products
 Storage of Information is not even
half the story
 The reason we build databases is in order to
easily retrieve information to answer
questions that support managerial
decision-making
 For example:

Who are our top 10 customers based on

their total order value in the year 2002?
 Can you do this using a spreadsheet?
Enter Relational Databases
 A relational DB supports storage of data as a set of
inter-related tables

◦ Each table stores data about a set of Entities

◦ Each table row is a record about one such Entity
◦ Each record column is a field specifying an
attribute of this
entity
◦ Each record has a field that acts as a unique
identifier of an entity
◦ Relationships among entities are specified by
referring to this unique identifier from other
tables
 Relational Database Example

Database for a small business that sells used cars and also provides
service
Database ex work for the cars it sells
 Data Representation
 A field or data element is
the smallest unit of data
that has meaning to
humans.

 A record is a collection of
fields that contain
information concerning a
specific thing or event.

 A collection of records is
called a file.

 A group of related files

would be referred to as a
database.
Types of Database Management
Systems

 Flat Files
 Hierarchical (e.g., XML, IMS)
 Network (e.g., Codasyl)
 Relational (e.g., Oracle, MS Access)
 Object-Oriented (e.g., Orion, O2)
 Relational Databases
 Most popular method for organizing and
storing information is the relational
database model which stores information in
files or tables that have rows and columns
 Popular software applications include:

◦ Microsoft Access
◦ Oracle
◦ Sybase
◦ DB2
◦ FileMaker
Database Management System
 Database Management System (DBMS)
◦ Allows the creation of a database
◦ Supports specialized languages for easy retrieval
of data from a set of inter-related tables
◦ Examples: Microsoft Access

 The parts of a DBMS:

◦ DBMS engine
◦ data dictionary
◦ data manipulation (query functions)
◦ application generation, and
◦ data administration.
Database Environment
Database Design
 Designing Databases
 Modeling a business requirement with
database model (Logical Design)

 Translate the database model into a database

schema (Physical Design)
 Logical Database Design:
Entity-Relationship Modeling

 Represents conceptual view of a database

 Represented in an entity relationship

diagram(ERD)

 Components of an ERD
◦ Entities: corresponds to tables
◦ Attributes: corresponds to fields of a table
◦ Relationships: represents links between tables
What Do Entities Represent?
 Refers to things about which we want to store
information (customers, employees, products
etc.)

 Entity – role (e.g. employee), place (e.g.

Northwest Region), a thing (e.g. product),
event (e.g sale) etc…
 Attributes
 Attributes or fields describe an entity

 Two types of attributes

◦ Key fields: containing values which uniquely
identify records, e.g. IC, NRIC
◦ Non-key fields: containing values which may be
non-unique, e.g. gender

 Values contained in fields may be:

◦ Single valued: male or female
◦ Composite: Name (First name and last name:
Frodo Baggins)
◦ Derived: total cost, average, count
 Relationships
 Describe how two entities are related.

 Connectivity describes relationship classification

• 1:1, 1:M, M:N

 Relationship participation
• Mandatory: must have a corresponding occurrence
• Optional: may not have a corresponding occurrence

 Cardinality expresses number of entity occurrences

associated with one occurrence of related entity
• Minimum Cardinality: If zero, then optional; If one, then
mandatory
• Maximum Cardinality: stated as “many”
 ERD Notation (Crow’s Foot)
 Uses 5 symbols

• Rectangle – entity
• Solid line – relationship
• | - single relationship
• 0 – zero/optional
relationship
• Crow’s foot ( ) –
multiple relationship
 Sample Invoice
ABC Corporation
Invoice

Customer:Alex Tan Date:12/06/05

Address:54 Nanyang Terrace Invoice Number:09341
Singapore 639749
Phone: 94565501

Product Number Description Quantity Price Product Total

1003 Fontographer for Windows 3 258.98 776.94
1004 OCR Scanner 1 299.88 299.88
1324 ScanMaster Plus 1 459.98 459.98

Total: 1,536.80

Terms: net 30days

 Business Rules
 A customer may receive 0 Invoices (customer
hasn’t ordered yet)
 A customer may receive many Invoices
 An Invoice may be received by only 1

customer
 A product may be on 0 Invoice (product

hasn’t been ordered yet)

Examples of ERDs

1 M
 Developing an ERD
 Iterative Process
 Step1: Read the case (requirements) & capture the
business rules
 Step2: Identify and draw entities (nouns) and their
attributes including key attributes
 Step 3: Identify relationships (verbs) as described
in the case and the numerical nature of the
relationship (cardinality)
 Step3: Modify the ERD:
 as you read the case and as more information is provided
 When there are M:N relationships: create intersection
table
 Step 4: Repeat process until database designers
(you) and users agree ERD is complete
 Group Exercise #1:
Draw ERD Diagram

Each department (e.g. Accounting; ITOM; Law; MIB;

Corporate Services etc) within the School may offer
courses (e.g. AB113; BC307 etc). Some departments
do not offer any courses, e.g. Corporate Services
Department. But a course must be offered by a
department.

A course will be taught by at least one professor.

Students must enroll in at least one course each
semester.
 Creating a Data Model
 Top Down Design
◦ Start by identifying the major entities about which
the organization needs to store data
◦ Determine what attributes need to be stored
about each entity
◦ Determine relationships between entities

 Bottom-up Design
◦ Examine the different forms and records and
extract the entities, attributes and their
relationships
◦ Derive the data model from the details of current
operations
Moving from Data Model to Database
Design
 Database Schema
 Design of a relational database that could be
implemented with a DBMS
◦ Identify tables, primary keys, foreign keys

 Presents entities and attributes in text form

◦ Student (MatricNo.,Student_Name,Student Address)
◦ Primary and foreign keys are identified
 Normalization
 Normalization – process of assuring that a
relational database structure can be
implemented as a series of two-
dimensional tables

 We will follow three rules of normalization

 Eliminate repeating groups or many-to-many
relationships
 Assure that each field in a relation depends
only on the primary key for that relation
 Remove all derived fields from the relations

33
 Database Schema for Customer and
Invoice

 CUSTOMER(CustomerNumber, CustomerName,
CustomerAddress, Customer Phone)

 INVOICE(InvoiceNumber, InvoiceDate, InvoiceTotal,

Invoice Terms, CustomerNumber)

 1:M relationship is implemented by placing the key of “1”

entity as an attribute in the “M” table.

 CustomerNumber is the primary key in Customer Table and

foreign key in the Invoice Table
 Sample Data for Invoice Table

InvoiceNumber …InvoiceTotal CustomerNumber

09341 100 C101
09342 400 C102
09343 324 C101
09344 100 C103
09355 240 C102
 Database Schema for Invoice and
Product

 INVOICE(InvoiceNumber, InvoiceDate, InvoiceTotal, Invoice

Terms, CustomerNumber)
 PRODUCT(ProductNumber, ProductDescription, Price)
 INVOICE-PRODUCT(InvoiceNumber, ProductNumber,
Quantity)

 M:M relationship is implemented by creating a new table

(intersection table) that contains the primary key fields from each of
the entities that it is connecting.

 The combination of InvoiceNumber and ProductNumber is unique

and is the primary key for this table.

 When a primary key has more than one field, it is referred as

combination key or concatenated key.
 Intersection Tables
 Intersection tables are used to provide a link
between two tables in a M:N relationship.

 M:N relationships cannot be implemented

because it gives rise to redundancies.

 The solution is to break the M:N relationship

into two 1:M relationships.
Sample Data for Invoice-Product Table

InvoiceNumber ProductNumber Quantity

09341 P1003 4
09341 P1005 2
09341 P1324 1
09357 P1005 1
09357 P1324 2
Complete Database Schema

 CUSTOMER(CustomerNumber, CustomerName,
CustomerAddress, Customer Phone)

 INVOICE(InvoiceNumber, InvoiceDate, InvoiceTotal,

Invoice Terms, CustomerNumber)

 PRODUCT(ProductNumber, ProductDescription,
Price)

 INVOICE-PRODUCT(InvoiceNumber,
ProductNumber, Quantity)
 Transforming ERD into a Database
Schema - Summary
 Entities become Tables

 Attributes become Fields

◦ Primary key is required for each table

 Relationships are implemented through

Foreign keys
◦ 1:1 – primary key from either side becomes
foreign key in the other
◦ 1:M – primary key from 1 side becomes foreign
key in M side
◦ M:N – intersection table formed with
concatenated primary key
 Group Exercise #2:
Create Database Schema
Each department (e.g. Accounting; ITOM; Law; MIB;
Corporate Services etc) within the School may offer
courses (e.g. AB113; BC307 etc). Some departments
do not offer any courses, e.g. Corporate Services
Department. But a course must be offered by a
department.

A course will be taught by at least one professor.

Students must enroll in at least one course each
semester.