Most audience in Facebook Groups;
Total liked and shared within Facebook network;
Memandangkan nampak banyak POST berkaitan Final Year Project (FYP), terlintas kat fikiran aku nak cerita tentang benda asas yg juga penting selain HTML, iaitu database atau kadang2 orang sebut DB. Mula2 ingat nak cerita pasal JavaScript (JS) dan Cascading Style Sheet (CSS), tapi lepas fikir2 aku rasa priority lebih kepada DB. Bila sebut pasal DB, mungkin sesetengah orang akan terbayang phpMyAdmin.
Memandangkan nampak banyak POST berkaitan Final Year Project (FYP), terlintas kat fikiran aku nak cerita tentang benda asas yg juga penting selain HTML, iaitu database atau kadang2 orang sebut DB. Mula2 ingat nak cerita pasal JavaScript (JS) dan Cascading Style Sheet (CSS), tapi lepas fikir2 aku rasa priority lebih kepada DB. Bila sebut pasal DB, mungkin sesetengah orang akan terbayang phpMyAdmin. Bila takde phpMyAdmin terus blur “Ahhh habislah DB aku rosak!”. Sebenarnya phpMyAdmin tu hanyalah sebuah alat atau tools yg dibina menggunakan PHP untuk mudahkan kita nak administrate / tadbir data dalam MySQL. DB yg sebenar adalah MySQL. Bila kita install software XAMPP, WAMP atau MAMP kat laptop tu maksudnya kita dah jadikan laptop tu sebagai server. Itu adalah server local yg hanya pengguna laptop tu je boleh capai. Kalau connect ke local area network (LAN) atau wireless LAN, laptop2 lain dalam network tu pon boleh connect guna IP address. AMP tu adalah singakatan 3 software iaitu Apache (webserver software yg membolehkan kita access http://localhost), MySQL (DB software yg membolehkan kita ‘SELECT * FROM…‘ dalam PHP file), dan PHP (server-side scripting language yg membolehkan kita proses input data macam yg aku cerita HTML form baru ni).
Benda yg nak dikongsikan minggu ni adalah tentang cara yg aku biasa buat untuk pastikan data dalam DB sesebuah system mampu berfungsi dengan baik. Maksud berfungsi kat sini adalah tak bermasalah bila berlakunya mana2 proses Create new, Read, Update, atau Delete (CRUD). Keyword yg nak aku highlight pasal ‘berfungsi’ kat sini adalah ‘DB structure’. Kalau buat bangunan sekalipon tanpa structure yg bagus akan menimbulkan pelbagai masalah. Contohnya kita expect data akan masuk ke DB bila execute SQL query INSERT INTO pelanggan (id,nama,jantina)… tapi tengok2 tak masuk. Search kat Google macam2 jawapan keluar, try2 pon tak jadi jugak. Kenapa? Kemungkinan besar sebabnya adalah struktur DB yg korang buat tu kurang tepat. Sebab2 lain adalah salah tulis SQL syntax. Mungkin jugak ada melibatkan reserved keyword macam ‘order’. Katalah korang buat system order nasi lemak online, then ada table nama ‘order’. Bila buat coding SELECT * FROM order… memang sampai bila2 pon tak menjadi sebab ‘order’ tu adalah reserved keyword dalam MySQL. Kalau korang terkena ngan error macam ni, solution dia kena letak symbol ´ atau Acute untuk nama table tu, jadinya order. Sama jugak solution untuk column. Berkenaan cara nak buat struktur DB, aku biasanya buat 5 steps kat bawah ni;
Step 1 : Buat flow system untuk proses2 yg terlibat : Target masa untuk siapkan task ni dalam tempoh maksimum 12 jam contohnya.
Mungkin ada sesetengah tu berpendapat ‘Aku nak buat system, tak payahlah kot buat diagram2 ni’, tapi sebenarnya flow chart tu lah yg akan membantu kita untuk faham dengan lebih jelas macam mana perjalanan system dan data. Mentang2 kau hebat design, kau hebat coding then kau terus buat kat laptop sebab nak jimatkan masa. Sebaik2nya draft flow chart kat kertas dulu, tengok flow system tu betul2. Masa draft tu, jangan fikir complex / advanced sangat, try lakar yg simple2 then cuba bentangkan / ceritakan kat kawan2 tentang flow chart tu. Biasanya akan ada soalan macam ‘Habis tu kalau user lupa password nak login macam mana?’, then secara automatik korang akan cari idea untuk tambah flow / features kat system tu. Paling kurang pon korang akan search solution kat Google then conteng2 lagi kertas tu. Tempoh masa maksimum 12 jam tak semestinya terus menerus, mungkin hari ni 2 jam, esok 3 jam, lebih kurang macam tu la. Jangan stress2, buat system hati kena tenang je, muka kasi senyum banyak2. Bila dah lebih jelas tentang flow system tu, then bolehlah proceed ke bahagian teknikal.
Bergantung pada keselesaan korang sama ada nak design user interfaces (UI) dulu kemudian baru masuk ke DB atau sebaliknya terpulang. Aku biasanya akan buat UI dulu kemudian baru design DB sebab pada pendapat aku, lebih senang nak tengok apa input yg diperlukan untuk nak jadikan sebagai data. Contohnya nama, email, dan no. tel. Buat UI pon biasanya aku draft on paper dulu, kalau tak pon guna je apa2 software yg boleh memperlihatkan macam mana user akan nampak. Petua aku, jangan tenung lama2, nanti lagi banyak nak tambah itu ini. Buat yg asas2 je, then makeup kemudian. System / Application software yg UI kurang cantik tak mengapa asalkan function semua boleh jalan. Sekadar selingan, pompuan tak perlu makeup lebih2, cukup sekadar sejuk mata memandang je hahahahaha. Inilah 1 sebab kenapa kita perlu setkan limit masa untuk sesuatu task tu. Ambillah masa untuk belajar rahsia daripada pakar2 kat JomLaunch (https://launch.jomweb.my/) Sabtu nanti, tengok macam mana diaorang kejar masa untuk siapkan sesuatu projek.
Step 2 : Kenal pasti entiti2 yg terlibat : Target masa : maksimum 6 jam.
Aku harap korang tak keliru bila sebut DB dan table. DB adalah database yg boleh mengandungi banyak table dalamnya. Contohnya nama DB System Tempahan Nasi Lemak Online ialah stnlo, then dalam tu ada table pelanggan, nasi_lemak, order, dan lain2. Entiti kat sini aku rujuk kepada objek2 (akan dijadikan sebagai table) yg terlibat dalam system tu. Contohnya dalam system order nasi lemak online ni, entiti yg terlibat adalah
pelanggan
nasi lemak
order
users
Ada 2 entiti utama dalam system tu iaitu pelanggan dan nasi lemak, kemudian barulah boleh berlakunya proses tempahan / order. Pelanggan akan tempah nasi lemak daripada penjual. Kita anggap penjual ni tak gaji orang, jadi dia sorang je gunakan system ni sebagai penjual, pelanggan akan access untuk membuat tempahan sahaja. So kat sini entiti2 ni kita jadikan sebagai table dalam DB.
Akan ada 5 table keseluruhan iaitu
pelanggan
nasi_lemak
order
users
logs
Mana datangnya logs tu? Ianya datang daripada proses login, logout, dan aktiviti2 lain yg berlaku dalam system tu. Siapa yg login? Mestilah user, iaitu penjual dan pelanggan. Penjual login untuk nak manage order, manakala pelanggan login untuk nak place / buat order. Korang jangan main suka2 je anggap login tu sekadar masuk username dan password je. Sebenarnya ia berfungsi sebagai rekod penggunaan sesebuah system. Nak bagi mudah faham lagi, bila korang nak guna makmal, kena mintak kebenaran penjaga makmal dan tulis kat buku log bila time masuk, nak buat apa dalam tu, dan bila time keluar. Buku log tu lah kita convert jadi ‘logs’ dalam system. So bila dah dapat kenal pasti entiti yg perlu ada, boleh proceed ke next step.
Step 3 : Kenal pasti column untuk setiap entiti : Target masa : maksimum 12 jam.
Nak bagi senang faham tentang step ni, kita tengok pada seorang manusia. Seseorang tu mesti ada nama, jantina, umur, pakai telefon, dan lain2. Pilih mana2 kriteria tu untuk dijadikan sebagai column pada sesebuah table. Setiap column perlu ada jenis data (data type) masing2. Contohnya integer, variable characters, boolean, dan macam2 lagi. Boleh rujuk kat Internet macam https://en.wikibooks.org/wiki/MySQL/Language/Data_Types. Contohnya untuk pelanggan;
datetime_lastupdate | nama | jantina | tel
1 | 2018-09-01 10:50:40 | NULL | Azhar | L | 0123456789
2 | 2018-09-01 08:30:25 | NULL | Jackson | L | 0112345678
3 | 2018-09-02 10:50:40 | NULL | Lina | P | 038998343
Data untuk UID iaitu column id tu tak akan berulang untuk data2 atau row seterusnya, column yg lain2 tu mungkin akan wujud data yg sama. Contohnya macam column datetime_reg tu, dua orang pelanggan iaitu Azhar dan Lina didaftarkan pada tarikh dan masa yg sama dalam system. Mungkin data seterusnya akan ada lagi pelanggan yg sama namanya, tetapi data id tu tak akan sama. Sebab tu kita set column id tu sebagai primary key auto_increment. Maksudnya system akan tentukan secara automatik data untuk column tu dalam susunan menaik (automatic incrementation). Kenapa perlu ada UID untuk setiap entiti / table? Sebab ia akan menjadi foreign key (FK) dalam table lain macam dalam step seterusnya ni.
Step 4 : Kenal pasti hubungkait / relationship antara setiap entiti : Target masa : maksimum 24 jam.
Korang mesti dah didedahkan pasal Entity Relationship Diagram (ERD), one to one, one to many, optional-mandatory, left join, dan macam2 lagi. Nak mudahkan cerita, step ni adalah tentang kegunaan UID serta hubungkait antara penjual dengan pelanggan dengan order dengan nasi lemak. Dalam contoh ni, cuba buat ayat atau diagram untuk nak fahamkan hubungkait entiti macam kat bawah ni: Relationship : Seorang penjual (one) mungkin menerima hanya 1 atau banyak (many) tempahan nasi lemak (many) daripada ramai pelanggan (many).
Keterangan : Penjual kena bekerja (mandatory) untuk membolehkan nasi lemak dipesan oleh pelanggan. Seorang pelanggan (optional) mungkin order hanya sebungkus atau lebih (optional).
Penjual (Mandatory – One to many – Optional) Pelanggan (Mandatory – One to many – Optional) Order
Untuk menghubungkan data antara entiti2 tu, aku akan gunakan column UID daripada setiap table sebagai column dalam table penghubung, iaitu order. So structure table order adalah macam ni;
|
|
`id` integer(20) not null primary key auto_increment `datetime_reg` datetime not null `datetime_lastupdate` datetime not null `kuantiti` integer(20) not null `jumlah_harga` decimal(5,2) not null `pelanggan_id` integer(20) not null `payment_status` enum('Pending', 'Settled') not null default 'Pending' |
Daripada structure table ni, kita boleh tahu sesuatu order tu dibuat daripada pelanggan mana melalui FK pelanggan_id. Bila ia jadi FK, ID untuk seseorang pelanggan tu boleh wujud beberapa kali dalam table ni. Katalah Azhar tu order sekali 2 bungkus lepas tu tak order dah esoknya. Jackson pulak order semalam 1 bungkus dan hari ni 3 bungkus. So data dalam table order tu akan jadi macam ni;
|
|
`id` | `datetime_reg` | `datetime_lastupdate` | `kuantiti` | `jumlah_harga` | `pelanggan_id` | `payment_status` 1 | 2018-09-01 11:03:05 | NULL | 2 | 5.00 | 1 | Settled 2 | 2018-09-01 11:10:18 | NULL | 1 | 2.50 | 2 | Settled 3 | 2018-09-02 10:05:39 | NULL | 2 | 5.00 | 3 | Settled 4 | 2018-09-02 09:30:23 | NULL | 3 | 7.50 | 2 | Pending |
Kalau korang perasan, hanya column pelanggan_id sahaja yg kita masukkan kat sini. Kita tak masukkan column nama dan tel macam kat table pelanggan. Sebabnya dengan hanya data daripada pelanggan_id tu kita boleh dapatkan maklumat penuh seseorang pelanggan menggunakan SQL JOIN statement. Korang cek sendiri ye sama ada ianya LEFT JOIN ke INNER JOIN ke OUTER JOIN ke. So apa yg aku nak tunjukkan kat sini adalah kenapa setiap table tu perlukan UID.
Step 5 : Ambik kira tentang function untuk reporting atau statistik : Target masa : maksimum 24 jam.
Penting jugak untuk ambik kira bahagian reports dan statistik. Kalau dalam system sebenar, inilah bahagian yg boss nak tengok, “Bulan ni berapa duit masuk? Mana lebih banyak, bulan lepas ke bulan ni?” Contohnya dalam table kat atas, korang boleh dapatkan jumlah nasi lemak yg ditempah dalam sehari, seminggu, atau sebulan. Berapa ramai pelanggan yg sama dan berbeza dalam seminggu. Adjust table structure dan relationship tu untuk bolehkan korang dapat maklumat2 yg diperlukan untuk reports. Mungkin dalam PHP file boleh tulis SQL statement macam ni untuk dapatkan jumlah harga pesanan pada 1 Sept 2018;
SELECT SUM(jumlah_harga) AS jumlah_harga_pesanan_sehari FROM order WHERE datetime_reg >= ‘2018-09-01 00:00:00’ and datetime_reg <= ‘2018-09-01 23:59:59’;
Kalau berdasarkan tempoh masa yg aku cadangkan tu, jumlahnya hanyalah 78 jam atau bersamaan 3 hari suku je kalau buat straight tak tido2. Tapi pandai2lah susun masa. Elakkan stress sebab nanti korang mungkin akan jadi give up dan kurang sihat. Buatlah apa aktiviti yg korang suka asalkan dapat elakkan stress. Bila semua steps tu dah settle, aku pon buat SQL query dalam PHP file dan test. Disebabkan aku ni manusia biasa yg tak lepas daripada buat kesilapan, biasanya akan ada lagi changes kat DB structure. Buat changes tu, tengok balik, test lagi dan akhirnya inshaAllah siaplah DB.
Kesimpulannya DB adalah salah satu benda yg sangat penting dalam skop application software / system development tak kiralah apa jenis DB yg korang gunakan. Kalau setakat webpage mungkin tak perlukan DB sebab kita boleh hard-code page contents tu. Aku cerita pasal MySQL sebab dah biasa gunakan DB ni, mungkin korang guna Oracle, MSSQL, Microsoft Access, atau flat file. Pada pendapat aku, walau apa jenis software DB yg korang gunakan, cara nak buat structure tu lebih kurang macam yg aku cerita ni je. Next POST nanti aku cerita pasal JS dan CSS pulak.
Share the post "Kepentingan database structure"
Author: Ahmad Fazli Ismail
Seorang pekerja dalam bidang ICT bermula tahun 2005 hingga sekarang. Bidang ni berkembang sangat pantas, oleh itu aku kena sentiasa belajar sambil bekerja. Belajar tak semestinya di sekolah atau universiti sahaja, tapi di mana2 tempat selagi masih hidup di dunia.
View all posts by Ahmad Fazli Ismail
