0% found this document useful (0 votes)
72 views

Database Fundamentals: INFM 603 - Information Technology and Organizational Context

This document discusses database fundamentals including database schemas, tables, fields, records, primary keys, foreign keys, and data types. It explains how object-oriented design concepts like classes, objects, attributes, and associations map to database design concepts like entities, records, attributes, and relationships. It also covers database environments, types, and the process of normalization to eliminate data duplication and anomalies. Normalization is explained through first, second, and third normal forms with examples.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
72 views

Database Fundamentals: INFM 603 - Information Technology and Organizational Context

This document discusses database fundamentals including database schemas, tables, fields, records, primary keys, foreign keys, and data types. It explains how object-oriented design concepts like classes, objects, attributes, and associations map to database design concepts like entities, records, attributes, and relationships. It also covers database environments, types, and the process of normalization to eliminate data duplication and anomalies. Normalization is explained through first, second, and third normal forms with examples.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

INFM 603 – Information Technology

and Organizational Context


Lecture 7

Database Fundamentals
A Database Schema
Schema Owner [1]

Tables Indexes Procedures

Views Constraints

schema objects
1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN. (with slight changes by V.G.D.)
2
Caution about Schema Objects
• The meaning of “object” here is different
than that in UML.

3
Table
• “A table is the primary unit of physical
storage for data in a database.”1

• Usually a database contains more than one


table.

1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN.
4
Table

5
A Database with Multiple Tables
[1]
Publishers Books Customers

Authors Inventory Orders

1) Stephens, R.K. and Plew. R.R., 2001. Database Design. SAMS, Indianapolis , IN. (with slight changes by V.G.D.)
6
Table
Customers

7
Field (Column)
Customers

a field

8
Record (Row)
Customers

a record

9
Primary Key
Customers

primary key field

Primary key is a unique identifier of records in a table.

Primary key values may be generated manually or automatically.


10
Primary Key
Roles (Performances)

primary key fields

A primary key can consist of more than one field.


11
Foreign Key
primary key field
parent table

Directors

relationship child table


Movies

foreign key field

12
Relationship Types
• One-to-one

• One-to-many

• Many-to-many

13
Data Types
• Alphanumeric (Text, Memo)
• Numeric (Number, Currency, etc.)
• Date/Time
• Boolean (Yes/No)

14
Entity
• “An entity is a business object that
represents a group, or category of data.” 1

• Do we know a similar concept?

1) Stephens, R.K. and Plew. R.R., 2001. Database Design, pp. 21. SAMS, Indianapolis , IN.
15
Instance (Record, Tuple)
• “A single, specific occurrence of an entity is
an instance. Other terms for an instance are
record and tuple.”1

• Do we know a similar concept?

1) Stephens, R.K. and Plew. R.R., 2001. Database Design, pp. 210. SAMS, Indianapolis , IN.
16
Attribute
• “An attribute is a sub-group of information
within an entity.”1

• Do we know a similar concept?

1) Stephens, R.K. and Plew. R.R., 2001. Database Design, pp. 21. SAMS, Indianapolis , IN.
17
Relationship
• A relationship is a link that relates two
entities that share one or more attributes.

• Do we know a similar concept?

18
OO Design  DB Design
• Class  Entity (Table)
• Object  Record
• Attribute  Attribute (Field)
• Association  Relationship
• …

19
Database Environments
• Mainframe

• Client/Server

• Internet-based

20
Database Types
• Flat-file
• Hierarchical
• Network
• Relational
• Object-oriented
• Object-relational

21
INFM 603 – Information Technology
and Organizational Context
Lecture 7

Normalization
(Advanced – may not be required for
LBSC690)
Normalization
• A method for organizing data elements into
tables.
• Done in order to avoid
– Duplication of data
– Insert anomaly
– Delete anomaly
– Update anomaly

23
We will look at
• First Normal Form

• Second Normal Form

• Third Normal Form

24
Example (Unnormalized)
• Table: SalesOrders (Un-normalized)
– SalesOrderNo
– Date
– CustomerNo
– CustomerName
– CutomerAddress
– ClerkNo
– ClerkName
– Item1Description
– Item1Quantity
– Item1UnitPrice
– Item2Description
– Item2Quantity
– Item2UnitPrice
– Item3Description
– Item3Quantity
– Item3UnitPrice
– Total

25
Normalize into 1NF
• Separate repeating groups into new tables.

• Start a new table for the repeating data.

• The primary key for the repeating group is


usually a composite key.

26
Example (1NF)
• Table: SalesOrders • Table: OrderItems
– SalesOrderNo – SalesOrderNo
– Date – ItemNo
– CustomerNo – ItemDescription
– CustomerName – ItemQuantity
– CustomerAddress – ItemUnitPrice
– ClerkNo
– ClerkName
– Total

27
Normalize into 2NF
• Remove partial dependencies.

• Start a new table for the partially dependent


data and the part of the key it depends on.

• Tables started at this step usually contain


descriptions of resources.

28
Dependencies
• Functional dependency: The value of one
attribute depends entirely on the value of
another.
• Partial dependency: An attribute depends on
only part of the primary key. (The primary
key must be a composite key.)
• Transitive dependency: An attribute depends
on an attribute other than the primary key.

29
Example (2NF)
• Table: OrderItems • Table: InventoryItems
– SalesOrderNo – ItemNo
– ItemNo – ItemDescription
– ItemQuantity
– ItemUnitPrice

30
What if we did not do 2NF
• Duplication of data: ItemDescription would appear
for every order.
• Insert anomaly: To insert an inventory item, you
must insert a sales order.
• Delete anomaly: Information about the items stay
with sales order records. Delete a sales order record,
delete the item description.
• Update anomaly: To change an item description,
you must change all the sales order records that
have the item.

31
Normalize into 3NF
• Remove transitive dependencies.

• Start a new table for the transitively dependent


attribute and the attribute it depends on.

• Keep a copy of the key attribute in the original


table.

32
Example (3NF)
• Table: SalesOrders • Table: Customers
– SalesOrderNo – CustomerNo
– Date – CustomerName
– CustomerNo – CustomerAddress
– ClerkNo
– Total • Table: Clerks
– ClerkNo
– ClerkName

33
What if we did not do 3NF
• Duplication of data: Customer and Clerk details
would appear for every order.
• Insert anomaly: To insert a customer or clerk, you
must insert a sales order.
• Delete anomaly: Information about the customers
and clerks stay with sales order records. Delete a
sales order record, delete the customer or clerk.
• Update anomaly: To change the details of a
customer or clerk, you must change all the sales
order records that involve that customer or clerk.

34
Example (Final Tables)
• Table: SalesOrders • Table: InventoryItems
– SalesOrderNo – ItemNo
– Date – ItemDescription
– CustomerNo
– ClerkNo • Table: Customers
– Total – CustomerNo
– CustomerName
• Table: OrderItems – CustomerAddress
– SalesOrderNo
– ItemNo • Table: Clerks
– ItemQuantity – ClerkNo
– ItemUnitPrice – ClerkName

35

You might also like