• Save
Db design
Upcoming SlideShare
Loading in...5
×
 

Db design

on

  • 984 views

I am not the author of this file but wanted to collect it for study purpose.

I am not the author of this file but wanted to collect it for study purpose.

Statistics

Views

Total Views
984
Views on SlideShare
982
Embed Views
2

Actions

Likes
2
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Db design Db design Presentation Transcript

  • Database Design Patterns
    Stephen Forte
  • Speaker.Bio.ToString()
    CTO and co-Founder of Corzen, Inc.
    Sold to Wanted Technologies (TXV: WAN)
    International Conference Speaker for 10+ Years
    RD, MVP and INETA Speaker
    Wrote a few books
    SQL Server 2005 Developers Guide (Microsoft Press)
    Co-moderator & founder of NYC .NET Developers Group
    http://www.nycdotnetdev.com
    Former CTO of Zagat Survey
  • What Are Design Patterns?
    What Are Design Patterns?
    Design Patterns for Databases?
    Data Model Patterns
    Infrastructure Patterns
    Agenda
  • What Are Design Patterns?
    Standard solutions to common problems in software design
    Real-world, proven techniques
    About design and interaction of objects
    Provide a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges
  • Where Did They Come From?
    Roots in architecture field for following patterns in building buildings and cities
    Urban planning
    Christopher Alexander (1950s)
    Started to develop for IT in the 1970s
    Smalltalk contributed patterns
    In 1987 Kent Beck and Ward Cunningham presented their “patterns” at the OOPSLA
    Classic book: Steve Burbeck
    Application Programming in Smalltalk-80 (1992)
  • Gang of Four
    The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns
    Classic Text: Design Patterns: Elements of Reusable Object-Oriented Software (1994)
    Gamma
    Helm
    Vissides
    Johnson
  • Why Use Design Patterns?
    Can speed up the development process by providing tested, proven development paradigms
    Proven design elements
    Used from other software engineering projects
    Withstood scrutiny from the software development community
    Mitigates a project’s risk
    Makes a project more predictable
    Allow developers to communicate using well-known and well understood names for software interactions
  • General Solution Templates
    Design patterns provide general solutions
    Documented in a format that doesn't require specifics tied to a particular problem
    Design patterns are only a template
    Up to you to apply to a problem and implement
  • What Are Design Patterns?
    Design Patterns for Databases?
    Design Patterns for Databases?
    Data Model Patterns
    Infrastructure Patterns
    Agenda
  • Design Patterns for Databases?
    Why not?
    All the logic applies to database design as to software
    They exist but have not been documented as well as they have for software development
    Not for C# code, but for actual databases
  • Database Design Patterns
    Data model patterns
    Multi-User Highly Transactional design pattern
    Slowly Changing Dimensions design pattern
    Data Warehouse design pattern
    Infrastructure patterns
    Highly-available patterns
    Point of Failure design pattern
    Data partitioning patterns
    Horizontal Partitioning
    Vertical Partitioning
  • What Are Design Patterns?
    Design Patterns for Databases?
    Data Model Patterns
    Infrastructure Patterns
    Agenda
    Data Model Patterns
  • Data Model Patterns
    Choosing the most efficient physical database design should be easy
    Almost every database you design should fall into one of three patterns
    The most common mistake is mixing different models into the same database
  • Data Model Patterns
    Multi-User Highly Transactional (OLTP)
    Slowly Changing Dimensions (SCD)
    Data Warehouse (OLAP)
  • Transactional Design Pattern
    Any data model that collects data
    Your typical OLTP
    Even if “transactions” (BEGIN TRANS) are not used
    Standard database normalization
    First normal form
    Second normal form
    Third normal form
    Can explore templates for data models based on the category of data you are collecting
  • Data Model Categories
    Order Entry
    People and Organizations
    Accounting
    Sports Scores 
    Time/Item Tracking
    Inventory
  • Slowly Changing Dimension Design Pattern
    Anything that can be derived from an OLTP database for reporting or web view
    Biggest mistake is to run a query against loads of normalized “raw” data
    Traditionally “flatter”
    Some de-normalized aspects
    Good implementation of XML
    Highly indexed since the data is “published”
  • SCD Design Pattern
    Optimized for reporting, Web access
    Usually the #1 mistake is to try to merge this into one system
    ETL becomes very important in this design pattern
    ETL
    Published Database
    OLTP
  • SCD Databases
    My former employer: Zagat
    Raw data OLTP of about 4 million records
    Published SCD of about 200K records, updated nightly as reviews came in
    My current employer: Corzen
    Raw data OLTP of about 800 million records
    Published SCD data of about 12 million records, updated weekly as the time series dictates
    Even a pure play e-commerce site like Amazon.com has a OLTP and SCD pattern:
    OLTP: All ordering
    SCD: Product catalog
  • demo
    Building an SCD Database
  • Data Warehouse Design Pattern
    DSS data with pre-calculated rollups
    Star schema
    Simplest data warehouse schema
    Consisting of a single "fact table" with a compound primary key
    One segment for each "dimension,“ with additional columns of additive, numeric facts
  • Star Schema
    Fact tables and dimension tables
    Fact tables in star schema are mostly in third normal form, but dimensional tables are in de-normalized second normal form
    If you want to normalize dimensional tables, they look like snowflakes (another pattern)
    The same problems of relational databases arise!
    Need complex queries!
    Avoid the temptation to normalize the dimensional tables!!!
  • Star Schema
  • demo
    Populating Fact Tables
  • What Are Design Patterns?
    Design Patterns for Databases?
    Data Model Patterns
    Infrastructure Patterns
    Agenda
    Infrastructure Patterns
  • Infrastructure Patterns
    Highly-available patterns
    Data partitioning data patterns
    Horizontal Partitioning
    Vertical Partitioning
  • Highly-Available Patterns
    “% 9s” uptime: 99.999%
    Translation
    Less than 5 minutes of unscheduled downtime a year
  • HA Patterns
    PoF pattern avoids a single point of failure
    Redundancy on all fronts-database, hardware
    Log shipping
    Microsoft SQL Server 2005 changes the equation
    Always on Technologies available with SP1
    Point of Failure Pattern
  • Data Partitioning Data Patterns
    Solving the problem of data bloat
    Advantages of moving less frequently accessed data to different disks
    Performance
    Storage
  • Data Partitioning Data Patterns
    Horizontal Partitioning
    Vertical Partitioning
  • Horizontal Partitioning
    Table Partitioning
    The process of splitting a table into pieces with the same structure but fewer rows
    Annual, Quarterly, Region
  • Horizontal Partitioning
    Good for archived data over a time series
    Move to a separate device-can be a read only device
    Will drive a developer crazy if you have to UNION it all back-but usually worth the tradeoff
  • Horizontal Partitioning
    SQL Server 2005 Table and Index Partitioning
    Keep data in one table
    Groups of data stored in other files
    Only get a benefit if you have more than one disk
  • DEMO
    Horizontal Partitioning
  • Data Partitioning Data Patterns
    Horizontal Partitioning
    Vertical Partitioning
  • Vertical Partitioning
    The process of splitting the table into different parts, with fewer columns, but the same amount of rows
    Use a One-to-One relationship
  • Vertical Partitioning
    Great for larger data that is not often needed or changed
    Will help with inserts, updates and deletes performance
    Used by MySpace to break out audio, video, images, HTML, etc
    http://www.baselinemag.com/article2/0,1540,2082921,00.asp
  • DEMO
    Vertical Partitioning
  • Choosing the Correct Partitioning
    Horizontal v Vertical Partitioning-When to use?
    Horizontal good for archived data
    Vertical good for inconsistent data that can be separated but still related to the primary key
    You can use both-depending on your table
  • Summary
    Design patterns are useful for database design
    Designing a table schema follows one of three patterns:
    OLAP, SCD, OLTP
    Infrastructure patterns help before and after your initial design
  • Q&A
  • Thanks
    Please fill out your evaluation form!Remember to put “Design Patterns” in the subject
    stevef@orcsweb.com
    Stephenforte.net/owdasblog