How to Design a Good Database

How to Design a Good Database
PHPID Online Meetup for COVID-19
8 April 2020 - https://zoom.us/j/510834649
8 April 2020 How to Design a Good Database Code Factory

About Me
• Editor PojokProgrammer.net
• Writers welcome!
• CEO Cronos Studio
• Developers welcome!
• Pegiat Komunitas
• PHP Indonesia
• MySQL Indonesia
• Drupal Indonesia
• VB.Net Indonesia
How to Design a Good Database8 April 2020 Code Factory

E-Commerce
Social Media

ERP Software

Apa Persamaannya?

GoodDesign Matters
• Data are foundation of your application.
• A well-designed database is easy to understand.
• A well-designed database performs fast and efficient.
Poorly
Designed
Database
Poorly
Designed
Application
Low
Performance &
Chaotic Data
Difficult to
Maintain &
Enhance

Agenda
• Characteristics of Good Database Design
• How to Design a Good Database
• Case Study: Inventory System

Are You Ready?

Characteristics of GoodDatabase Design

ThingsTo Consider
• What Functionality is Needed from the Database?
• Break Your Data Into Logical Pieces
• Avoid Data Separated by Separators
• Centralize Name Value Table Design
• Self-reference PK And FK For Unlimited Hierarchical Data
• Database Design Tips
• Relational vs. NoSQL Databases

Database Functionality
• Transactional (OLTP): Write intensive application. Your end
user is more interested in CRUD, i.e., creating, reading,
updating, and deleting records.
• Analytical (OLAP): Read intensive applications. Your end user
is more interested in analysis, reporting, forecasting, etc.
These kinds of databases have a less number of inserts and
updates. The main intention here is to fetch and analyze data
as fast as possible.

Database Functionality

Break Your Data Into Logical Pieces
• This rule is from the first rule of 1st normal form.
• If your queries are using too many string parsing functions
like substring, charindex, etc., then probably this rule needs
to be applied.
• Common Example, Name and Address Field
• Break this field into further logical pieces so that we can
write clean and optimal queries.

• This rule is from the second
rule of 1st normal form.
• Data stuffed with separators
need special attention and
should be to moved to a
different table
• Link them with keys for better
management.
Avoid Data with Separators

• Name and value tables
contains key and some data
associated with the key.
• Lookup Tables
• Differentiating the data
using a type field.
• Adding new type of does not
require to create new table.
Centralize Name Value Table Design

• Data with unlimited parent child
hierarchy.
• Consider a multi-level marketing
scenario where a sales person can
have multiple sales people below
them.
• Using a self-referencing primary key
and foreign key will simplify
database design.
Self-reference for Hierarchical Data

Database Design Tips
• Use English for table and field naming, all plural or all singular
• Use well defined and consistent names for tables and columns (e.g.
School, StudentCourse, CourseID ...)
• Don’t use unnecessary prefixes or suffixes for table names (i.e. use
School instead of TblSchool, SchoolTable etc.).
• Keep passwords as encrypted or hashed for security. Decrypt them in
application when required.
• Use integer id fields for all tables. If id is not required for the time
being, it may be required in the future (for association
tables, indexing ...).

Database Design Tips
• Choose columns with the integer data type (or its variants) for
indexing. varchar column indexing will cause performance problems.
• Use constraints (foreign key, check, not null ...) for data integrity.
Don’t give whole control to application code.
• Lack of database documentation is evil. Document your database
design with ER schemas and instructions. Also write comment lines
for your triggers, stored procedures and other scripts.
• Use indexes for frequently used queries on big tables.
• Place Image and blob data in separate tables.

Relational vs. NoSQL Databases
• Not every database fits every business need.
• Many companies rely on both relational and non-relational
databases for different tasks.
• NoSQL databases gained popularity for their speed and
scalability.
• There are still situations in which a highly structured SQL
database more preferable

• You need ACID compliancy
(Atomicity, Consistency,
Isolation, Durability).
• Your data is structured and
unchanging
• Standards-based proven
technology with good
developer experience and
support
• Storing large volumes of
data without structure.
• Using cloud computing and
storage. Easily spread data
across servers
• Simpler or looser project
objectives
• Rapid development, able to
start coding immediately
RDBMS
NoSQL

How to Design a GoodDatabase

Concepts to Master
• Conceptual Model
• Logical Model
• Physical Model
• Natural Key vs Surrogate Key
• Normalisasi vs. Denormalisasi

Requirements
• Perusahaan ada di beberapa lokasi.
• Setiap lokasi ada beberapa warehouse.
• Sistem harus mengetahui stok barang per warehouse.
• Ada beberapa jenis barang tersedia, misalkan raw material
dan finished goods.
• Sistem harus mencatat semua transaksi barang masuk.
• Sistem harus mencatat semua transaksi barang keluar.
• Sistem harus dapat mengeluarkan Laporan Kartu Stok.

We Will Need
• Locations entity (data lokasi)
• Warehouse entity (data gudang)
• Items entity (data barang)
• Item_Types entity (data jenis barang)
• Transactions entity (data transaksi)
• Transaction_Types entity (data jenis transaksi)

Conceptual Model
• Identifikasikan semua entitas (entity) yang terlibat dalam
sistem yang ingin dikembangkan.
• Buat Conceptual Model berupa relasi antar entitas tersebut.
• Gambarkan hanya relasi antar entitas tersebut, tidak
termasuk atribut dari entitas tersebut.

Conceptual Model

Logical Model
• Tambahkan attributes yang diperlukan oleh setiap entitas.
• Definisikan atribut yang bertindak sebagai PK, namun kita
tidak perlu mendefinisikan FK.

Logical Model

Physical Model
• Tentukan tipe data dari masing-masing kolom sesuai dengan
RDBMS yang kita pilih.
• Pemetakan relasi FK serta buat associative table untuk relasi
many-to-many.

Physical Model (IDEF1X)

Natural Key vs. Surrogate Key
• Ada kalanya sebuah tabel sudah memiliki kolom yang
nilainya unik untuk setiap baris (row)
• Kolom seperti ini disebut Natural Key, dan bisa kita jadikan
sebagai Primary Key.
• Best-practice tetap menambahkan Surrogate Key dan
menjadikannya sebagai Primary Key.
• Surrogate Key di-generate oleh database, biasanya berupa
field integer yang nilainya auto increment.
• Natural Key yang ada cukup sebagai unique index.

Normalisasi vs. Denormalisasi
• Normalization must be used as required, to optimize the
performance.
• Under-normalization will cause excessive repetition of data.
• Over-normalization will cause excessive joins across too
many tables.
• Both of them will get worse performance.

Thank You

BANTUTENAGA
MEDISLAWAN
CORONA !!!
Code Factory How to Design a Good Database
Rumah Komunitas mengajak teman-
teman ikut berpartisipasi dalam
program penggalangan dana untuk
pembuatan APD (Alat Pelindung Diri)
dan diproduksi di tempat konveksi
Rumah Komunitas.
Informasi Selengkapnya :
bit.ly/donasi-bersama-lawan-corona
#BersamaLawanCorona
#DiRumahAja
#StayAtHome
#WorkFromHome

About Me
• Telegram: @hidayat365
• PHP Indonesia for Student
https://t.me/PHPIDforStudent
• MySQL Indonesia
https://t.me/mysqlid
• Github
https://github.com/hidayat365
• This Slide
https://slideshare.net/hidayat365

Feedback
•Feedback https://bit.ly/phpom01-f
•Donasi https://bit.ly/donasi-bersama-lawan-
corona

How to Design a Good Database

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to How to Design a Good Database

Similar to How to Design a Good Database (20)

More from Nur Hidayat

More from Nur Hidayat (7)

Recently uploaded

Recently uploaded (20)

How to Design a Good Database

Editor's Notes