1. Section 04 Lesson 01 Introduction to the Database
Use the student note section below for further explanation of the slide content.
Use your mouse to resize the content pane and read all of the student note section.
Welcome to the Oracle I-learning online lessons.
While reading this material, complete all the italicized tasks within the student note section. These will assist in highlighting important facts throughout the content.
Complete the ERD Exercise at the end of this lesson.

2. Glimpse of DB Design Why use design modeling?
Introduction to the components:
Tables (derived from entities)
Columns (derived from attributes)
Constraints (derived from relationships)
Lesson Overview
This material describes some principles of relational databases and introduces how to transform Entity Relationship model into a physical database design. While the focus of the DM course will remain on the conceptual understanding of Data Modeling, this lesson will help in establishing the connections to how the logical process translates to the physical database design.
Database Design allows you to build a blueprint to ensure that you will maintain integrity of the data that you store. Imagine not having correct information for mission critical pieces of information? Or not having this data relate to each other in a meaningful way? Relational Database software DEPENDS upon a logical design for it to work properly. No company, Oracle, IBM or Microsoft can guarantee the performance of their database management software if the initial design is flawed.
Certain components of the database will be introduced in this lesson. They are tables, columns and constraints. While more will be explained in later lessons, it is enough to know now that

3. Why Create a Data Design Model?
It provides an easy to read logical diagram of the proposed Database Design
Facilitates discussion
Ideal model can be adapted to an RDBMS model
Sound basis for physical database design
Why Create a Database Design?
The Entity Relationship model describes the data required for the business. This model should be totally independent from any implementation considerations. This same ER model could also be used as a basis for implementation of any type of DBMS or even a file system.
A New Starting Point
An Entity Relationship model is a high-level representation which cannot be implemented as is. People creating these models may not be aware of physical and database constraints, but they still have to provide a conceptually “workable” solution. This is why it is important to have a validated and agreed ER model before going into the physical database design. Transforming the ER model, creates a “first-cut” database design. This first-cut design is intended to serve as a new basis for defining the physical implementation of the database. This new model can easily be used for further discussions between designers, developers, and database administrators.

4. Data Models Oracle server Model of system in client’s mind
Entity model of client’s model
Table model of entity model
Oracle
server
Data Models
Models are a cornerstone of design. Engineers build a model of a car to work out any details before putting it into production. In the same manner, system designers develop models to explore ideas and improve the understanding of the database design.
Purpose of Models
Models help communicate the concepts in people’s minds. They can be used to do the following:
Communicate
Categorize
Describe
Specify
Investigate
Evolve
Analyze
Imitate
The objective is to produce a model that fits a multitude of these uses, can be understood by an end user, and contains sufficient detail for a developer to build a database system.
Tables on disk

5. Entity Relationship Model
Create an entity relationship diagram from business specifications or narratives
Scenario
“. . . Assign one or more employees to a department . . .”
“. . . Some departments do not yet have assigned employees . . .”
EMPLOYEE
#* number
* name
o job title
DEPARTMENT
o location
assigned to
composed of
ER Modeling
In an effective system, data is divided into discrete categories or entities. An entity relationship (ER) model is an illustration of various entities in a business and the relationships between them. An ER model is derived from business specifications or narratives and built during the analysis phase of the system development life cycle. ER models separate the information required by a business from the activities performed within a business. Although businesses can change their activities, the type of information tends to remain constant. Therefore, the data structures also tend to be constant.
Benefits of ER Modeling
Documents information for the organization in a clear, precise format
Provides a clear picture of the scope of the information requirement
Provides an easily understood pictorial map for the database design
Offers an effective framework for integrating multiple applications
Key Components
Entity: A thing of significance about which information needs to be known. Examples are departments, employees, and orders.
Attribute: Something that describes or qualifies an entity. For example, for the employee entity, the attributes would be the employee number, name, job title, hire date, department number, and so on. Each of the attributes is either required or optional. This state is called optionality.
Relationship: A named association between entities showing optionality and degree. Examples are employees and departments, and orders and items.

6. Entity Relationship Modeling Conventions
Soft box
Singular, unique name
Uppercase
Synonym in parentheses
Attribute
Singular name
Lowercase
Mandatory marked with “*”
Optional marked with “o”
EMPLOYEE
#* number
* name
o job title
DEPARTMENT
#* number
* name
o location
assigned to
composed of
ER Modeling (continued)
Entities
To represent an entity in a model, use the following conventions:
Soft box with any dimensions
Singular, unique entity name
Entity name in uppercase
Optional synonym names in uppercase within parentheses: ( )
Attributes
To represent an attribute in a model, use the following conventions:
Use singular names in lowercase.
Tag mandatory attributes, or values that must be known, with an asterisk: *.
Tag optional attributes, or values that may be known, with the letter o.
Relationships
Unique Identifier (UID)
Primary marked with “#”
Secondary marked with “(#)”

7. Entity Relationship Modeling Conventions
Soft box
Singular, unique name
Uppercase
Synonym in parentheses
Attribute
Singular name
Lowercase
Mandatory marked with “*”
Optional marked with “o”
EMPLOYEE
#* number
* name
o job title
DEPARTMENT
#* number
* name
o location
assigned to
composed of
ER Modeling (continued)
Relationships
Each direction of the relationship contains:
A label, for example, taught by or assigned to
An optionality, either must be or may be
A degree, either one and only one or one or more
Note: The term cardinality is a synonym for the term degree.
Each source entity {may be | must be} relationship name {one and only one | one or more} destination entity.
Note: The convention is to read clockwise.
Unique Identifiers
A unique identifier (UID) is any combination of attributes or relationships, or both, that serves to distinguish occurrences of an entity. Each entity occurrence must be uniquely identifiable.
Tag each attribute that is part of the UID with a number symbol: #
Tag secondary UIDs with a number sign in parentheses: (#)
Unique Identifier (UID)
Primary marked with “#”
Secondary marked with “(#)”

8. Presenting Tables Table: EMPLOYEES columns rows unique key
Id Name Address Birth_date Dpt_id 126 PAGE 12, OXFORD ST PAPINI 53, HAYES AVE GARRET
rows
unique key
column
foreign key column
primary key column
EMPLOYEES (EPE)
pk uk1 uk1 fk
* * * *
Id Name Address Birth_date Dpt_id
Table diagram: EMPLOYEES
Presenting Tables
Tables are supported by integrity rules that protect the data and the structures of the database. Integrity rules require each table to have a primary key and each foreign key to be consistent with its corresponding primary key.
Tables - A table is a very simple structure in which data is organized and stored. Tables have columns and rows. Each column is used to store a specific type of value. In the above example, the EMPLOYEES table is the structure used to store employees’ information.
Rows - Each row describes an occurrence of an employee. In the example, each row describes in full all properties required by the system.
Columns - Each column holds information of a specific type like Id, Name, Address, Birth Date, and the Id of the department the employee is assigned to.
Primary keys - The Id column is a primary key, that is, every employee has a unique identification number in this table which distinguishes each individual row.
Unique keys - Both columns Name and Birth_date are associated with a Unique key constraint which means that the system does not allow two rows with the same name and Birth_date. This restriction defines the limits of the system.
Foreign keys - The foreign key column enables the use of the Dpt_id value to retrieve the department properties for which a specific employee is working.
For a quick definition of the database terms goto: o
foreign key

9. Transformation Process
Conceptual Model
Transformation Process
Using transformation rules you create a new model based on the conceptual model.
Conceptual Model The way you can describe requirements for the data business requires using a semantically rich syntax through graphical representation. You can describe many of the business rules with graphical elements such as subtypes, arcs, and relationships (barred and nontransferable ones). The only constraints in expressing business complexity that you have encountered so far are the graphical limitations. We know that this model acts as a generic one, because it is not related to any physical considerations. Therefore you can use it for any type of database. Nevertheless, it may be that the DBMS type you want to use (relational or others) does not support all of the semantic rules graphically expressed in your ER model.
Relational Model The Relational model is based on mathematical rules. This means that when you try to fit all of the syntax from the ER model into the physical database model, some of it may not have any correspondence in the relational model. To preserve these specified rules, you have to keep track of them and find the correct way to implement them.
Relational Model

10. Terminology Mapping ANALYSIS DESIGN ER Model Physical Design Entity
Attribute
Primary UID
Secondary UID
Business Constraints
Relationship
Table
Column
Primary Key
Unique Key
Foreign Key
Check Constraints
Changing from analysis to design also means changing terminology.
Using a very simple basis:
• An entity leads to a table.
• An attribute becomes a column.
• A primary unique identifier produces a Primary key.
• A secondary unique identifier produces a Unique key.
• A relationship is transformed into a Foreign key and foreign key columns.
• Constraints are the rules with which the database must cope to be consistent. Some of the business rules are translated into Check Constraints, other complex ones require additional programming and you can implement them at client side or server side or both.
This initial mapping of an ER model is limited to the design of tables, columns, and constraints that can be declared. A declarative constraint is a business constraint that can be ensured at the server level using database language statements only and requires no coding.
For a quick definition of the database terms goto:

11. ERD Exercise
Draw an Entity-Relationship diagram to represent the following:
a Each ORACLE DATABASE must be made up of one or more TABLESPACEs.
b Each TABLESPACE must be part of one and only one ORACLE DATABASE.
c Each TABLESPACE must be made up of one or more FILEs.
d Each FILE may be part of one and only one TABLESPACE.
e Each TABLESPACE may be divided into one or more SEGMENTs.
f Each SEGMENT must be included in one and only one TABLESPACE.
g Each SEGMENT must be inclusive of one or more EXTENTs.
h Each EXTENT must be included in one and only one SEGMENT.
I Each EXTENT must be composed on one or more BLOCKs.
j Each BLOCK must be part of one and only one EXTENT.
k Each FILE must be residing on one and only one DISK.
l Each DISK may be the host for one or more FILEs.
On a separate sheet of paper, complete this exercise BEFORE moving on to the next slide. Focus on the creation of entities listed above and diagramming the stated relationship.
FOR EXTRA CREDIT: Look up the words in CAPITAL letters and write their definitions. This will increase your understanding of database terminology.