Database Design Thoughts

Database Design Thoughts
Toon Koppelaars
Real-World Performance
Oracle Server Technologies

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, timing, and pricing of any
features or functionality described for Oracle’s products may change and remains at the
sole discretion of Oracle Corporation.

About Me
• Part of Oracle eco-system since 1987
– Have done and seen quite a lot of application development
– Database design, SQL and PL/SQL
• Big fan of “Using Database As a Processing Engine”
– Not just as a persistence layer
• Member of Oracle’s Real-World Performance Group
3

Terminology
• Data model versus, database design
• Three major data models: hierarchical (60’s), network (70’s) and relational
– https://en.wikipedia.org/wiki/Hierarchical_database_model (IMS)
– https://en.wikipedia.org/wiki/Network_model (CODASYL)
– https://en.wikipedia.org/wiki/Relational_model (SQL)
• This talk is about designing databases within the relational data model
4

45 Minutes
• Database design is subjective field
• Mix of “art”, “experience” and “science”
– Art  different tastes
– Experience  everybody his/her own
• I’ll avoid the art and experience aspects, and only provide some science in
this talk
– And even then, I had to choose from many topics that could have been discussed
5

Contents
1. Dependencies, Keys and Third Normal Form
2. Boyce-Codd Normal Form
3. Some Logic
4. Nulls, Generalization and Specializations
5. Recommended Practices
6. Snack: Something to Think About
6

Dependencies, Keys and Third Normal Form
• Database design == Coherent set of table designs
• We’re going straight in now...
• With an ORDERLINES table design
7

Take a Look at This Table
8
Big chunk of table design, is constraint design
Very important one

Important Dependencies Concept
• Assume ORDERLINES table has following properties:
– If two rows have same PRODUCT#, then PRODUCT_SHORTNAME must also be same
– If two rows have same ORDER#, then CUSTOMER_ID, ORDER_DATE and
DELIVERY_ADDR must also (each) be same
– If two rows have same CUSTOMER_ID, then DISCOUNT_PERC must also be same
9
These are in fact
additional constraints

Specifying a Dependency Constraint
Using FOPL
FOPL: First Order Predicate Logic
Using SQL

Table Design and Constraint Design
These should be part of
your database design
documentation
These should be part of
your database design
documentation
https://community.oracle.com/ideas/13028

Dependencies
• We say, “table has five dependencies”
– PRODUCT# “determines” PRODUCT_SHORTNAME
– CUSTOMER_ID “determines” DISCOUNT_PERC
– ORDER# “determines” CUSTOMER_ID, ORDER_DATE and DELIVERY_ADDR
• Or other way around,
– PRODUCT_SHORTNAME “depends upon” PRODUCT#
– DISCOUNT_PERC “depends upon” CUSTOMER_ID
– CUSTOMER_ID, ORDER_DATE and DELIVERY_ADDR “depend upon” ORDER#
12
Being able to spot dependencies and other types of
constraints in table designs is very important skill

Can You Spot the Dependency Here?
13
What’s wrong with such table design?
Why do you not want this?

Dependencies
Empno Ename Deptno Salary Dname
101 Mike 30 4200 London
102 Toon 20 1200 Amsterdam
103 Mark 30 1800 London
104 John 40 4000 San Francisco
105 Bob 40 3400 San Francisco
EMPLOYEES table
Dname is not
stored once…

Moving On To Keys
• Understanding concepts of dependencies and keys are essential
• These two concepts drive:
– What tables you introduce
– What columns go to which table
15

Keys (Of a Table)
• Primary key dictates that we
do not allow two rows for a
given ORDER# with the same
PRODUCT#
16
Being able to reason about / find
multi-column (concatenated)
keys, is very important skill
What does this mean? (3x)

Third Normal Form (3NF)
• If table has dependencies where left-hand
is not a key in table, then table is not
in 3NF
• So, how do we fix ORDERLINES to be in 3NF?
17
None of these is a key in OrderLines

Fixing ORDERLINES to be in 3NF
• PRODUCT_SHORTNAME: needs to move to table where PRODUCT# is key
• DISCOUNT_PERC: needs to move to table where CUSTOMER_ID is key
• CUSTOMER_ID, ORDER_DATE and DELIVERY_ADDDR:
need to move to table where ORDER# is key
• This potentially leads to introducing new tables
18

3NF Table Design
19
If columns were already
present in other tables,
then they were redundant
in ORDERLINES

Contents
3. Some Logic
20

Boyce-Codd Normal Form (BCNF)
• BCNF is a slightly stricter form of 3NF
– The way 3NF was formally defined, leaves room for BCNF to exist
– 3NF only talks about dependencies for non-prime attributes (columns)
• Just remember this:
A table might not be in BCNF if and only if, it has overlapping
concatenated candidate keys
– Eg: Primary key (C1,C2) and Unique (C2,C3)
– If “C3 depends on C1”, or “C1 depends on C3 “ not in BCNF
21

Contents
3. Some Logic
22

Some Logic You Should Know
• When reasoning about WHERE-clauses or constraints:
– De Morgan Law
– Implication Rewrite Rule
• There is a lot more 
23

De Morgan
• Transforming logical-OR into logical-AND, and vice-versa
– Not (A and B) is-equivalent-to not-A or not-B
– Not (A or B) is-equivalent-to not-A and not-B
• Sometimes good to play with this in WHERE-clauses or in CHECK
constraints
24

Implication Rewrite Into Or (very important!)
• Transforming if-then into logical-OR, and vice-versa
– A implies B is-equivalent-to not-A or B
– A or B is-equivalent-to not-A implies B
or not-B implies A
– A implies B is-equivalent-to not-B implies not-A
• You often require this for multi-column CHECK constraints
25
If A is true then B is true

Contents
3. Some Logic
26

What’s the Issue With Nulls in Database Designs?
• They introduce all kinds of edge-cases and divergent behavior:
– “= null”, is not the same as, “is null”
– Empty string equals null?
– Ordering of nulls
– Aggregate functions ignore nulls
– Predicate with nulls behave differently in WHERE- and CHECK-clauses
27
Simply put: they are a prime source of bugs
in your code on top of database design

How Come We See Nulls so Often?
• Because we have nullable columns…
28

To Be Applicable or Not
• Nullable columns introduced for three reasons:
1. Data values that could have been stored are inapplicable
2. Data values are not yet, or no longer, applicable  special case of 1
3. Data values are nice to know (if known) or truly optional
• Let’s look at first one
29

Reason 1: Data Values Are Inapplicable
• In EMP-DEPT language: COMM column is only applicable for salesmen
– You really should have constraints then:
• Check (JOB != ‘salesman’ or COMM is not null)
• Check (JOB = ‘salesman’ or COMM is null)
• Often there are multiple sets of inapplicable columns
– Depending on value in some other column only one of the sets should have values
– That column = the inspection column (JOB above)
30

Causing Wide Tables
31
Mandatory cols Optional col-set 1 Optional col-set 2 Optional col-set 3
Single, wide, table
Data values Data values
Type 1
rows
Type 2
rows
Type 3
rows
Inspection column here
Optional columns

What Could Be Alternative Designs?
• Without all the NULLs?
32

Fix: Introduce More Tables
33
Four tables
Col-set 1
Col-set 2
Col-set 3
Including same key-
column(s) of main table
Including same key-
Including same key-
Type 1
rows
Type 2
rows
Type 3
rows

Generalization and Specialization Tables
34
Aka: super-type
and sub-type tables
Generalization table
Specialization table 1

Or, Another Alternative With Three Tables
35
Split into
three tables

36
Split into
three tables

37
And merge

Advantages of Alternative Designs
• Minimal number of nullable columns  less bugs
• No bytes wasted storing Nulls
– Often additional columns will have been added…
– Introducing massive row-chaining
38
1 byte/column/row
0 bytes
Now these suddenly also
take 1 byte/column/row

Advantages of Alternative Design
• Many data access use-cases require columns of one (or two) tables
– Better packed data, quicker access to column  performs better
• New columns can go straight to correct table, without requiring massive
table and index rebuilds due to row-chaining
– Easier maintenance, less impact
39

But Then, Don’t Do This
40
Wide view, outer-joining main table with 3 tables
All your SQL accesses

Do This
41

Or This
42

Or This
43

And, Yes, Sometimes This
44

Reason 2: Not Yet (or No Longer) Applicable
• Let’s look at an ORDERS table with STATUS column
45

Reason 2: Not Yet (or No Longer) Applicable
• DELIVERY_DATE only applicable for Delivered orders
• CANCEL_REASON only applicable for Cancelled orders
46
Constraints…

Reason 3: Nice to Know or Truly Optional
• If we know release-date of product, lets store it
• Some products have special-handling-instructions
47

My View on Nulls
• Nulls due to nice-to-know/truly-optional  don’t worry about them
– Likely not used in SQL logic and/or business logic
• Avoid nulls due to inapplicability
– Introduce generalization/specializations
• Seriously consider avoiding nulls due to not-yet/no-longer applicable
– How? By also introducing new (specialization) tables for these columns
48

Final Loose Thought on NULL’s
• Not Null should have been the default
• Database designs should have few nullable columns
• They are not constraints…
• Trying to insert NULL should just be a data-type error
49
This is an historic
mistake imho

Contents
3. Some Logic
50

Recommended DB Design Practices
• Application should be based on proper DB design
• "Proper" = two-fold
1. It must fit business requirements
2. It must follow sound relational principles
1) Is up to you talking to business owners and understanding their
requirements  experience (and art?)
2) Is about science + objective reasoning on alternative designs
Alternative table designs + alternative constraint designs
51

Recommended Practices For a Sound Database Design
0. Choose table and column names wisely
1. Use 3rd normal form
Avoid structural redundancies (dependencies)
2. Don't design incidental redundancies
Aka premature optimization
E.g. Total value of order-lines at order level
3. Table has sequence-based primary key?
Then also have 2nd business key, usually concatenated key
4. Put special things in separate tables (subtypes/specializations)
Avoid lists of null-able columns due to non-applicability
5. Never allow nulls in columns involved in data integrity constraints
Includes columns referenced by any SQL assertion you can document
52

Conclusions
• There is a lot of science to database design
• Database design is also constraint design
• Don’t be afraid of many tables  DBMS’s were born to join
• You might end up with foundation for your application that is easier to
understand, is easier to maintain, and provides better performance
53

Snack: Something to Think About
54

The Value of Sharing Database Design Pictures
• Do you share database design pictures with end-users?
– And point to tables on them while talking about them?
• Why?
– Do you think users understand these?
55

The Value of Sharing Meteorological Pictures With Viewers
• Seen these?
• Do you understand them?
– Blue, red, purple lines
– Dashed lines
– Little triangles, half circles
– Sometimes combined
– Capital L’s, capital H’s
– Vague white lines
• Does seeing these, add value to you?
56

Much Detail in Them That We Don’t Get...
57

What You’re Interested In
58
For your location

My Opinion: Little Value in Sharing Them
• Like weather pictures:
– Users don’t get the information held within them
– Few users are interested in whole picture
– These pictures miss lot of information (think: constraints/assertions)
• Database design is frame of reference for database designer and
application developer
59

What Users Are Interested In
60
For their use-cases

Thank You For Your Time
61

Database Design Thoughts

More Related Content

What's hot (20)

Similar to Database Design Thoughts (20)

Recently uploaded (20)

Database Design Thoughts