How to Design a Good Database for Your Application

Database Design
How to Design a Good Database
for Your Great Application
Seminar Program Studi Manajeman Informatika
18 April 2018 - AMIK BSI Kampus Salemba

About Me
• Editor PojokProgrammer.net
• Writers welcome!
• CEO BiruniLabs
• Trainers welcome!
• CEO Cronos Studio
• Developers welcome!
• Pegiat Komunitas
• PHP Indonesia
• Drupal Indonesia
• VB.Net Indonesia
Created by Nur Hidayat
(nur.hidayat@cronosstudio.id)
Prepared for
AMIK BSI Salemba

E-Commerce
Social Media
Prepared for
AMIK BSI Salemba

ERP Software
How to Design a Good Database AMIK BSI Salemba

Apa Persamaannya?

Good Design 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
AMIK BSI Salemba

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

Are You Ready?

Characteristics of Good
Database Design

Things To 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
Prepared for
AMIK BSI Salemba

• 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
Prepared for
AMIK BSI Salemba

• 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
Prepared for
AMIK BSI Salemba

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
Prepared for
AMIK BSI Salemba

How to Design
a Good Database

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

• 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
Prepared for
AMIK BSI Salemba

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

• 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
Prepared for
AMIK BSI Salemba

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.

Case Study:
Inventory System

Things To Do
• Requirements
• Conceptual Model
• Logical Model
• Physical Model
• Change Your Mindset
• SQL Rule of Thumb
• Data Retrieval using SELECT

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

Logical Model

Physical Model

Data Retrieval using SELECT

SQL Rule of Thumb
• Use single SQL statement whenever possible
• Use PL/SQL or Stored Procedure
• Use Java (or other programming language)
• Rethink why you want to do it (refine your approach)
From Tom Kyte (Oracle Evangelist)

Change Your Mindset
• Apa yang akan kalian lakukan jika mendapatkan tugas seperti
di bawah ini
• Tampilkan angka 1 sampai dengan 100, namun…
• setiap kelipatan 3 ubah angkanya menjadi kata Rumah,
• setiap kelipatan 5 ubah angkanya menjadi kata Sakit, dan
• setiap kelipatan 15 ubah angkanya menjadi kata Rumah Sakit.

Solution

SELECT t.id AS trans_id, t.trans_code AS trans_code
, t.trans_date AS trans_date, a.id AS detail_id, a.item_id
, trim(concat(t.remarks,' - ',a.remarks)) AS remarks,
b.code AS item_code, b.name AS item_name
, CASE
WHEN t.type_id=1 THEN a.quantity
WHEN t.type_id=2 THEN -a.quantity
ELSE 0 END
AS quantity
, @sal := @sal + CASE
WHEN t.type_id=1 THEN a.quantity
WHEN t.type_id=2 THEN -a.quantity
ELSE 0 END
AS saldo
FROM transactions t
JOIN transaction_details a ON t.id = a.trans_id
JOIN items b ON a.item_id = b.id
JOIN ( SELECT @sal:=0 ) v
WHERE b.id = :id
ORDER BY t.trans_date, t.id, a.id
Query for Stock Card
Prepared for
AMIK BSI Salemba

Contact Us
• Telegram: @hidayat365
• PHP Indonesia for Student https://t.me/PHPIDforStudent
• MySQL Indonesia https://t.me/mysqlid
• Github: https://github.com/hidayat365
Link Quesioner (wajib):
http://tiny.cc/bsikuesioner
AMIK BSI Salemba

Thank You

How to Design a Good Database for Your Application

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a How to Design a Good Database for Your Application

Semelhante a How to Design a Good Database for Your Application (20)

Mais de Nur Hidayat

Mais de Nur Hidayat (7)

Último

Último (20)

How to Design a Good Database for Your Application