5Creating the Physical Model

Designing the Physical Model

Phase IV: Defining the physical model

Database Object Naming Conventions

• Keep the logical and physical names similar and descriptive.

• Capitalize table and attribute names.

• Use underscores instead of spaces to delineate separate words in an object’s name.

• Use a suffix of _PK to indicate primary keys.

• Use a suffix of _ID to indicate production keys.

• Find a good balance between using very specific and very vague names.

Database Object Naming Conventions

• Develop a reasonable list of abbreviations.

• List all the objects’ names, and work with the user community to define them.

• Resolve name disputes.

• Document your naming standards in the metadata document.

• Plan for the naming standards to be a living document.

Translating the DimensionalModel into a Physical Model

• Apply the naming standards to the tables and attributes of the dimensional model.

• List table columns with primary keys listed first.

• Label primary keys consistently.

• Identify the format and length of columns.

• Label unique keys with a (#).

• Label column optionality with NULL (o) or NOT NULL (*) constraints.

• Label foreign keys with _FK.

• Use synonyms for user tables.

Physical ModelProduct

* PRODUCT_ID v(11)* PRODUCT_DESC v(125)* PRODUCT_NAME v(35)* CATEGORY_ID v(20)* CATEGORY_DESC v(25)* SUPPLIER_ID v(20)* PRODUCT_STATUS v(10)* LIST_PRICE n* CATALOG_ID v(20)* PRODCUT_TYPE v(20)* PRODUCT_CODE v(10)* PROMOTION_CODE v(10)* WHSE_LOCATION v(10)* VALID_FROM_DATE d* VALID_TO_DATE d

# *Product _PK n# *Channel_PK n# *Promotion_PK n

Defining the Hardware

Transforming the base dimensional data model into the physical model includes some of the following:

• Defining naming and database standards

• Performing an initial sizing

• Designing tablespaces

• Defining an initial indexing strategy

• Using partitioning to split table and index data into smaller, more manageable chunks

• Determining where to place database objects on disk (RAID, striping, disk mapping)

• Using parallel processing

Architectural Requirements

Scalability

Manageability

Availability

Extensibility

Integrated

Accessibility

Reliability

Flexibility

User

Budget

Business

Technology

Architecture Characteristics

• Robust

• Available

• Reliable

• Extensible

• Scalable

• Supportable

• Recoverable

• Parallel

• VLM (very large memory)

• 64-bit

• Connective

• Open

Hardware Requirements

• SMP (Symmetric multiprocessing)

• Cluster and MPP (massively parallel processing)

• Hybrids using SMP and MPP

Evaluation Criteria

Determine the platform for your needs:

SMP Clusters MPP

Scalability

Maturity

Low

High

Low

High

Application

Database

Operating system

Hardware

Parallel Processing

• Parallel daily operations

• Shared resources– Memory– Disk– Nothing

• Loosely or tightly coupled

• Requirements differ from operational systems

• Benchmark– Available from vendors– Develop your own– Use realistic queries

• Scalability important

Making the Right Choice

Shared disks

Common bus

CPU CPU CPU CPU

Shared memory

Symmetric Multiprocessing (SMP)

• Communication by shared memory

• Disk controllers accessible to all CPUs

• Proven technology

Benefits:

• High concurrency

• Workload balancing

• Moderate scalability

• Easy administration

Limitations:

• Memory (cluster for improvements)

• Bandwidth

CPU CPU CPU CPU

Shared memory

SMP

Clusters

Node 1 Node 2 Node 3

Common high-speed bus

Shared disks

Common high-speed bus

Shared memory

CPU CPU CPU

Shared memory

CPU CPU CPU

Shared memory

CPU CPU CPU

Clusters

• Shared disk, loosely coupled

• Dedicated memory

• High-speed bus

• Shared resources

• SMP node

Massively Parallel Processing (MPP)

CPU

Memory

CPU

Memory

CPU

MemoryMemory

CPU

Disk Disk Disk Disk

MPP nCube Arrangements

• A shared nothing architecture

• Many nodes

• Fast access

• Exclusive memory on a node

• Low cost per node

• Scalable• nCUBE configuration

MPP Benefits

• Unlimited incremental growth

• Very scalable

• Fast access

• Low cost per node

• Good for DSS

MPP Limitations

• Rigid partitioning

• Cache consistency

• Restricted disk access

• High memory cost per node

• High management burden

• Careful data placement

Architectural Tiers

Tiered structures:

• Modular

• Logical separation

Distributed structures:

• Two-tier

• Three-tier

• Four-tier (and more)

DB server Apps server Workstations Web server Internet

Sample System Architecture

Gateway

Middleware

Technologies for integration

Database Server Requirements

• Robust

• Available

• Reliable

• Extensible

• Scalable

• Supportable

• Recoverable

• Parallel

Parallelism

• Database

• Query

• Load

• Index

• Sort

• Backup

• Recovery

Further Considerations

• Optimization strategy

• Partitioning strategy

• Summarization strategy

• Indexing techniques

• Hardware and software scalability

• Availability

• Administration

Processor 1

Elapsed timeNot parallel

Processor 2Processor 1

Processor 4Processor 3

Parallel

Parallel Processing

A large task broken into smaller tasks:

• Concurrent execution

• One or more processors

Processor 2Processor 1

Processor 4Processor 3

Parallel

Parallel Database

• Increased speed

• Improved scalability

• Performance gains– Availability– Flexibility– More users

Parallel Query

SQL code split among server processes

Query

Subquery

Subquery

Subquery

Feb 98 Mar 98

Order table

Jan 98

Parallel Load

Bypass SQL processing to speed throughput

Parallel Processing

• Index: reduces the time to create

• Sort: allocates memory in cache efficiently

Parallel Processing

• Backup: runs simultaneously from any node (online and offline)

• Recovery: runs simultaneously from redo logs

• Summaries: uses the CREATE TABLE AS SELECTstatement