ORACLE’
Objectives
¢ Describe the stages of system development ¢ List and define basic types of data relationships ¢ Define a relational database and its components ¢ Read an entity relationship diagram
¢ Translate an entity relationship diagram into a relational database design
Trang 3
Objectives
Before you build your tables, you design your database In this lesson, you examine the data modeling process and relational database concepts, and define normalization You also translate an entity relationship model into a relational database design
At the end of this lesson, you should be able to
e Describe the stages of system development e List and define basic types of data relationships e Define a relational database and its components e Read an entity relationship model
Trang 4ORACLE’ Overview se Carefully consider the components of the database
¢ Complete the system development cycle ¢ Model and design the database
¢ Meet the challenges to managing data with good database design
Trang 5
Overview
When you create a database, you need to carefully consider its components For assistance with the design, you can follow the concepts outlined in this lesson System Development Cycle
In order to logically and successfully create the database objects in the Oracle7 Server, you complete the system development cycle Each stage of the cycle contains specific activities that you perform to achieve the best possible database design Database Design
Database design is just one of the stages of the development cycle Through good database design, you can achieve a reliable, high-performance system
Challenges to Managing Data
Trang 6ORACLE’
System Development Cycle
¢ Database development
— ls atop-down, systematic approach
— Transforms business information requirements into an operational database
— Consists of five stages
Trang 7System Development Cycle
From concept to production, develop a database by using the system development cycle The cycle contains multiple stages of development This top-down, systematic approach to database development transforms business information requirements into an operational database
Stages of Development Strategy and Analysis
e Study and analyze the business requirements Interview users and managers to identify the information requirements Incorporate the enterprise and application mission statements as well as any future system specifications
e Build models of the system Transfer the business narrative developed in the strategy and analysis phase into a graphical representation of business information needs and rules Confirm and refine the model with the analysts and experts Design
e Design the database The entity relationship model maps entities to tables, attributes to columns, relationships to foreign keys, and business rules to constraints
Build and Document
e Build the prototype system Write and execute the commands to create the tables and supporting objects for the database
e Develop user documentation, help-screen text, and operations manuals to support the use and operation of the system
Transition
e Refine the prototype Move an application into production with user acceptance testing, conversion of existing data, and parallel operations Make any
modifications required
Production
e Roll out the system to the users Operate the production system Monitor its
Trang 8ORACLE’ Database Design ¢ Convert a model into a workable software representation
¢ Combine rules, judgment, and common sense to create your design
¢ The following factors are key to database design: — Performance
— Integrated application
Trang 9Database Design
Designing a relational database system involves converting a model into a workable software representation The entities (or objects) perceived by the user are
transformed into tables in the database All forms of design involve a mixture of
rules, judgements, and common sense, and relational design is no different
During a design effort, your goal is to design reliable, high-performance systems using the deliverables from the analysis effort The following key factors describe in detail why you should bother to design at all
Performance
The initial design of a system has an enormous impact on its final performance Generally the impact is much greater than any remedial tuning
Integrated Application
Application systems are typically developed by teams of developers Without some design specification from which to work, developers will each build in their own style Not only does good design promote a cohesive look and feel, but it also helps ensure that all components of the resulting application system are integrated with each other
Integration with Other Systems
Often, there are requirements that a new system integrate with existing systems, or even with systems yet to be built Good design extends the integration benefits mentioned above into corporate or worldwide systems
Documentation and Communication
A major part of a designer’s job is to communicate design decisions to others At the
very least, these decisions need to be documented
Scalability
Tackle performance issues during design rather than during production For example, developing an application in a small, controlled environment does not test real-world situations or a large set of data, factors that can reveal design flaws
Trang 11Data Model
Models are a cornerstone of design Engineers build a model of a car before putting it into production to work out any details 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 for the following purposes: e Communicate e Categorize e Describe e Specify e Investigate e Evolve e Analyze e Imitate
The objective is to produce a model that fits a multitude of these uses, can be
understood by an end user, but contains sufficient detail for a developer to build a
Trang 12ORACLE’
Benefits of Entity Relationship Models
¢ Communicate concepts in people’s minds ¢ Effective for collecting and documenting an
organization’s information requirements
¢ Provide an easily understood pictorial map of the
system
¢ Can be easily developed and refined
¢ Clearly define the scope of the information needs ¢ Separate the information required by a business from
the activities performed by the business Entity Relationship Modeling Concepts ¢ Entity — Athing of significance about which information needs to be known — Examples: customers, sales representatives, orders ¢ Attribute
— Something that describes or qualifies an entity — Examples: name, phone, identification number ¢ Relationship
— Anassociation between two entities
— Examples: orders and items, customers and sales
representatives
Trang 13
Entity Relationship Modeling
Entity relationship models are derived from business specifications or narratives This model is a graphical representation of business information needs and rules
Entity Relationship Models
Entity relationship 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 Entity Relationship Models
Documents information requirements for the organization in a clear, precise
format
Provides an easily understood pictorial map for the database design Develops and refines the model easily
Provides a clear picture of the scope of the information requirements
Offers an effective framework for integrating multiple applications, development projects, and purchased application packages Key Components Component Description Entity A thing of significance about which information needs to be known
Attribute Something that describes or qualifies an entity
Relationship A named association between entities showing optionality or degree
Trang 14ORACLE’
Entity Relationship Model
¢ Create an entity relationship diagram from business specifications or narratives
CUSTOMER : EMPLOYEE # id assigned to wid * name the sales * last name o phone rep to °o first name ¢ Scenario — ",, Assign one or more customers to a sales representative " — "., Some sales representatives do not yet have assigned customers " Entity Relationship Modeling Conventions Entity
Soft box Attribute
Singular, unique name Singular name
Uppercase Lowercase
Synonym in parentheses Mandatory marked with "*"
Optional marked with "o"
CUSTOMER assigned to EMPLOYEE
# id KR _-_-_- _- _— _—_ #* = id
* name the sales | * last name o phone rep to °o first name
Unique Identifier (UID) Primary marked with "#"
Secondary marked with "(#)"
Trang 15
Entity Relationship Model Concepts
An entity relationship model is composed of entities, attributes, and relationships Entities
An entity represents a thing of significance about the business system, or a discrete category or collection of related data Examples are customer, orders, and employees To represent an entity in a model, use the following conventions:
e Soft box with any dimensions e Singular, unique entity name e Entity name in uppercase
e Optional synonym names in uppercase within parentheses ““()”
Attributes
An attribute describes entities and holds the specific information that should be
known about an entity For example, for the customer entity, the attributes would be customer number, name, phone number, and address
If an entity does not have attributes that need to be known from the business
viewpoint, then it is not within the scope of the system requirements, and should not appear in the model
Each of the attributes is either required or optional This state is called optionality To represent an entity in a model, use the following conventions:
e Use singular names in lowercase
e Tag mandatory attributes, or values that must be known, with an asterisk “*”’
e Tag optional attributes, or values that may be known, with an “o” 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
Trang 16ORACLE’
Entity Relationships: Example
se Syntax
Trang 17Entity Relationship Model Concepts continued
Relationships
Each entity must have a relationship that represents the information requirements and rules of the business The relationship is a two-directional association between two entities, or between an entity and itself When an entity has a relationship with itself, it is recursive
Each direction of the relationship contains
e A name, for example, taught by or assigned to e An optionality, either must be or may be
e A degree, either one and only one or one or more
Note: Cardinality is a synonym for the term degree Relationship Syntax
Each source entity {may be | must be} relationship name {one and only one | one or more} destination entity
Note: Convention is to read clockwise
Relationship Diagramming Conventions Symbol Description
Dashed line Optional element indicating “may be.” Solid line Mandatory element indicating “must be.” Crow’s foot Degree element indicating “one or more.” Single line Degree element indicating “one and only one.”
Trang 18RN nnn Relationship Types ¢ One-to-one — Have a degree of one and only one in both directions — Are rare — Example: Husband and wife ¢ Many-to-one
— Have a degree of one or more in one direction and a degree of one and only one in the other direction
— Are very common
— Example: passengers and plane ¢ Many-to-many
— Have a degree of one or more in both directions — Are resolved with an intersection entity
Trang 19Entity Relationship Model Concepts continued
Unique Identifier Through the Relationship
An entity may be uniquely identified through a relationship Use a UID bar to indicate that a relationship is part of the entity’s unique identifier The relationship included in a UID must be mandatory and one and only one in the direction that participates in the UID
Example
When you order items, you have an order number and an item with a unique line item number But when another order is placed, that item number is no longer unique Therefore, the item is uniquely identified by its attribute number and the specific order number to which the item is related Order number Item number Product number 100 1 209 100 2 399 100 3 876 101 1 630 101 2 297 Recursive Relationship
A relationship between an entity and itself is called a recursive relationship It is represented by a “pig’s ear.”
Relationship Types
Type Description
One-to-one Degree of one and only one in both directions These types are rare, and may really be the same entity, or an attribute of the entity
Many-to-one Degree of one or more in one direction and a degree of one and only one in the other direction Very common
Trang 20
ORACLE’
Normalization
Benefits
¢ Minimizes data redundancy ¢ Reduces integrity problems
¢ Identifies missing entities, relationships, and tables Rule Description
First normal form All attributes must be single-valued Second normal form | An attribute must depend upon its entity's
entire UID
Third normal form No non-UID attribute can be dependent upon
Trang 21Entity Relationship Model Concepts continued
Normalization
Before creating the database design, you want to eliminate the problems of data redundancy by normalizing the data model Modify the data model to support different functional requirements and alternate database designs by normalizing the storage of data before you create the database
Benefits of Normalization
e Minimizes data redundancy e Reduces integrity problems
e Identifies missing entities, relationships, and tables Normalization Rules Rule Description First normal form (1 NF) All attributes must be single-valued and not repeating Second normal form (2NF) An attribute must depend upon its entity’s entire unique identifier
Third normal form (3NF) No non-UID attribute can be dependent upon another non-UID attribute
Trang 22
ORACLE’
Integrity Constraints
¢ Ensure data consistency
Trang 23Integrity Constraints and Keys
Ensure that users perform only operations that leave the database in a correct and consistent state by enforcing data integrity constraints All data integrity constraints should be enforced by the database server or the application software Keys
correspond to integrity constraints The three types of keys are primary key, unique key, and foreign key Integrity Constraint Type Description
Entity No part of a primary key can be NULL and the value must be unique
Referential Foreign key values must match a primary key or be NULL Column Values in the column must match the defined datatype User-defined Values must comply with the business rules
Examples of User-Defined Data Integrity Constraints
e Anemployee in the finance department cannot have a title of programmer e A salesperson’s commission cannot exceed 50% of the base salary
Trang 24ORACLE’
Defining a Primary Key
¢ Aprimary key (PK) allows no duplicate values and cannot
be NULL
¢ Each row is uniquely identified by a column or set of columns (composite primary key)
Trang 25Integrity Constraints and Keys continued
Primary Keys
Each row in the table is uniquely identified by a column or set of columns called a primary key (PK) The primary key is defined as allowing no duplicate values and cannot be NULL
A primary key consisting of multiple columns is called a composite primary key or a compound primary key The columns of a composite primary key must be unique in combination, although the individual columns can have duplicates No part of a primary key can contain a null value
Candidate Keys
A table can have several candidate keys A candidate key is a column or combination of columns that can serve as the primary key for the table
Trang 26ORACLE’
Defining a Foreign Key
¢ A foreign key (FK) is a column or combination of columns in one table that refers to a PK or unique key (UK) in the same table or in another table
¢ Ks are based upon data values and are purely logical
¢ The value must either match the value in the related column or be NULL
¢ If an FK is part of a PK, then it cannot be NULL
Defining a Foreign Key: Example
Trang 27Integrity Constraints and Keys continued
Foreign Keys
Trang 28ORACLE’
Database Design
¢ Table and column names should map back to the entities and attributes, respectively
¢ Develop your own naming conventions ¢ Additional requirements
Design the indexes Establish view definitions Plan the physical storage space Redefine integrity constraints
Trang 29
Designing the Database
The database design stage produces design specifications for a relational database,
including definitions for relational tables, indexes, views, and storage space
Map the Entity Relationship Model to a Table Instance Chart 1 Map the simple entities to tables
2 Map the attributes to columns and document sample data Clearly label the column names and their associated generic datatypes; for example, character,
number, or date
3 Map the unique identifiers to a primary Key Be sure to include any foreign key components of the primary Key
4 Map relationships to foreign keys Additional Requirements
e Design the indexes, which are database objects that provide direct, quick access to rows You may want to create indexes for alternate keys, foreign keys, and
columns frequently used in the search condition
e Establish view definitions, which are logical tables based on one or more tables or views Views can restrict access, provide improved presentation of information, and can contain a pre-packaged complex query
e Plan the physical storage space, which is the amount of space required to store the data of a table in the database
e Redefine integrity constraints
we For more information, see
Trang 30ORACLE’
Database Design Steps
Create a table instance chart from the components in the entity relationship diagram @——~ s customer Table eQ > Column ID Name Phone Sales _rep id name 3 > Key type | PK FK Nulls/ NN,U | NN Unique FK table S_EMP O_> FK ID column Datatype | NUM CHAR CHAR NUM Max 7 25 20 7 length
Trang 31Designing the Database continued
Symbols Used to Document the Table Instance Chart Symbol Definition
PK Primary key column FK Foreign key column
FK1, FK2 Two foreign keys within the same table
FK1, FK1 Two columns within the same composite foreign key NN Not null column
U Unique column
UI, Ul Two columns that are unique in combination Guidelines
e The table name should be easy to trace back to the entity name The plural of the entity name is sometimes used because the table will contain a set of rows e Column names should be easily traced to the entity relationship model Short
Trang 32ORACLE’
Step 1: Map Entities to Tables
¢ Create a table instance chart — Table name
— Columnnames
— Key types
— Null and unique references — Foreign key information
— Column datatype and maximum length
— Sample data
¢ Record the table name at the top of the chart
Step 2: Map the Attributes to Columns
¢ Map each attribute in the entity relationship model to a column name in the table
¢ Document mandatory columns with a NN reference
¢ Add sample data for each column
¢ Do not name columns with SQL reserved words
Trang 33
Designing the Database continued
Map the Entities to Tables
Create a table instance chart for the new table The table instance chart should contain columns for the name of the table, the names of the columns, the key types, null and unique references, foreign key information, column datatype and maximum length, and sample data Record the name of the table
Map the Attributes to Columns
Map each attribute in the entity relationship model to a column name in the table Add sample data to the chart to show the contents of the table in a visual form Map mandatory attributes, tagged with an asterisk (*), to columns defined as NOT NULL (NN)
Do not name columns with SQL reserved words, such as NUMBER Name columns with consistent abbreviations, such as NO or NUM (but not both) to avoid
programmer and user confusion
For more information, see
Oracle7 Server SQL Reference, Release 7.3, “Object Names and Qualifiers” section
Trang 34ORACLE’
Step 3: Map the Unique Identifiers to
Primary Keys
¢ Record the UID as the primary key ¢ Label the NN and U references
¢ Label the alternate UID as NN and U references, but choose only one for a PK
¢ Add aFK column for each UID that is through a relationship
— Mark it as PK and FK key types — Mark the NN and U references — Add sample data
Trang 35
Designing the Database continued
Map the Unique Identifiers to Primary Keys
Map the UIDs identified in the entity relationship model by a number symbol (#) to primary key columns and label the key type as PK Map a UID containing a single attribute to a single-column PK Label the not null and unique references as NN and U Map a UID that includes multiple attributes to a composite PK Label those columns NN and U1 If you have an alternate primary Key, label it as NN and U, but choose only one PK
If the entity’s UID includes the relationship (indicated by the UID bar), add a FK column for each relationship and label it as PK and FK key types Add FK columns to the end of the table instance chart or to the right of all columns, even if the FK is part of the PK Choose a unique name for each FK column and add sample data
ITEM ORDER
#* id i" #* id
oO price — o date ordered Oo quantity made | © date shipped Oo quantity shipped up of | 9 payment type
Trang 36ORACLE’
Step 4: Map Relationships to Foreign Keys
¢ For many-to-one relationships
— Take the PK at the one end and create a column for the PK in the other table at the many end — Mark it as a FK ¢ For mandatory relationships, be sure to mark the NN reference Step 4: Map Relationships to Foreign Keys—continued ¢ For one-to-one relationships, mark the U reference
— Ifthe relationship is optional in both directions, place the FK in the table at either end of the relationship — Ifthe relationship is mandatory, place the unique FK in
the table at the mandatory end
¢ For mandatory relationships, be sure to mark the
NN reference
Trang 37
Designing the Database continued
Map Relationships to Foreign Keys
The last step is to map relationship to foreign keys There are two types of
relationships to consider: Many-to-one and one-to-one If your relationship is part of the unique identifier, you have already mapped it Be sure to label mandatory
relationships with the NN reference Choose a unique name for the foreign key column
Many-to-One Relationships
Map the many-to-one relationship by taking the primary key at the one end and putting it in the table at the many end as a foreign key This technique also applies to recursive relationships
One-to-One Optional Relationships
You can place the foreign key in the table at either end of the relationship for an optional one-to-one relationship Be sure to add the U reference
#* id assigned
BC ÐO —— —— ™ nó ion date of birth D size IO
weight the
species temporary home for
One-to-One Mandatory Relationships
*O
00
Trang 38ORACLE’
Summary
¢ Follow the system development cycle
¢ Model your system with an entity relationship model
Trang 39Summary
Logically and successfully create database objects in the Oracle7 Server by
completing the system development cycle Each stage helps you to achieve the best possible database design
Stages of Development
e Study and analyze the business requirements e Build models of the system
e Design the database
e Build the prototype system e Write the user documentation e Refine the prototype
e Roll out the system to the users Entity Relationship Model
e Entities are things of significance
e Attributes describe or qualify two entities e Relationships associate two entities e Establish unique identifiers
e Follow normalization rules
Database Design
e Create a table instance chart