MODUL I

Dasar-Dasar MYSQL dan Normalisasi

Tujuan
1. Mengurangi redudansi data pada basis data yang dibuat.
2. Perubahan data (penyisipan, pengubahan dan penghapusan) terjadi hanya
pada kelompok data tersebut.
3. Mencegah anomali pada data (keanehan pada proses penyisipan,
pengubahan dan penghapusan).
4. Agar Struktur data lebih mudah dipahami dan dikembangkan.

Tugas Pendahuluan
1. Sebutkan dan jelaskan dengan rinci tahapan-tahapan yang semestinya
dilakukan dalam pembuatan suatu program basis data.
2. Sebutkan dan jelaskan dengan rinci tahapan-tahapan yang semestinya
dilakukan dalam proses normalisasi, berikan contoh untuk menggambarkan
proses yang terjadi di setiap tahapan normalisasi.
3. Sebutkan macam-macam tipe data yang ada dalam MySQL serta kebutuhan
memory dan penggunaannya dengan jelas.
4. Sebutkan kegunaan key dalam suatu tabel. Lalu sebutkan dan jelaskan
macam - macam key yang ada dalam konsep basis data.
5. Sebutkan dan jelaskan macam-macam relationship (keterhubungan) yang
ada dalam konsep basis data.
6. Sebutkan dan jelaskan masing-masing relationship (keterhubungan) yang
terdapat pada rancangan PDM Modul 1.
Jawaban
1. Proses perancangan database terdiri dari 6 tahap:

1.1. Pengumpulan data dan Analisa

Merupakan suatu tahap dimana kita melakukan proses indentifikasi dan
analisa kebutuhan-kebutuhan data dan ini disebut pengumpulan data dan analisa.
Untuk menentukan kebutuhan-kebutuhan suatu sistem database, kita harus
mengenal terlebih dahulu bagian-bagian lain dari sistem informasi yang akan
berinteraksi dengan sistem database, termasuk para user yang ada dan para
useryang baru beserta aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para user
dan aplikasi-aplikasi inilah yang kemudian dikumpulkan dan dianalisa.

Berikut ini adalah aktifitas-aktifitas pengumpulan data dan analisa:

1.1.1 Menentukan kelompok pemakai dan bidang-bidang aplikasinya.
1.1.2 Peninjauan dokumentasi yang ada.
1.1.3 Analisa lingkungan operasi dan pemrosesan data.
1.1.4 Daftar pertanyaan dan wawancara.

1.2. Perancangan database secara konseptual

Pada tahap ini akan dihasilkan conceptual schema untuk database yang
tergantung pada sebuah DBMS yang spesifik. Sering menggunakan sebuah high-
level data modelseperti ER/EER modelselama tahap ini. Dalam conceptual schema,
kita harus merinci aplikasi-aplikasi databaseyang diketahui dan transaksi-transaksi
yang mungkin.

Tahap perancangan database secara konseptual mempunyai 2 aktifitas pararel:

1.2.1 Perancangan skema konseptual
Menguji kebutuhan-kebutuhan data dari suatu database yang merupakan
hasil dari tahap 1 dan menghasilkan sebuah conceptual database schemapada
DBMS-independent model data tingkat tinggi seperti EER (Enhanced Entity
Relationship) model. Untuk menghasilkan skema tersebut dapat dihasilkan dengan
penggabungan bermacam-macam kebutuhan user dan secara langsung membuat
skema database atau dengan merancang skema-skema yang terpisah dari kebutuhan
tiap-tiap user dan kemudian menggabungkan skema-skema tersebut. Model data
yang digunakan pada perancangan skema konseptual adalah DBMS-independent
dan langkah selanjutnya adalah memilih DBMS untuk melakukan rancangan
tersebut.

1.2.2 Perancangan transaksi

Menguji aplikasi-aplikasi databasedimana kebutuhan-kebutuhannya telah
dianalisa pada fase 1, dan menghasilkan perincian transaksi-transaksi ini.Kegunaan
tahap ini yang diproses secara paralel bersama tahapp perancangan skema
konseptual adalah untuk merancang karakteristik dari transaksi-transaksi database
yang telah diketahui pada suatu DBMS-independent. Transaksi-transaksi ini akan
digunakan untuk memproses dan memanipulasi database suatu saat dimana
database tersebut dilaksanakan.

1.3 Pemilihan DBMS

Pemilihan database ditentukan oleh beberapa faktor diantaranya faktor
teknik, ekonomi, dan politik organisasi.Contoh faktor teknik:
Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis DBMS
(relational, network, hierarchical, dan lain-lain), struktur penyimpanan, dan jalur
akses yang mendukung DBMS, pemakai, dan lain-lain.
1.4 Perancangan database secara logika (data model mapping)
Tahap selanjutnya adalah membuat sebuah skema konseptual dan skema
eksternal pada model data dari DBMS yang terpilih. Tahap ini dilakukan oleh
pemetaan skema konseptual dan skema eksternal yang dihasilkan pada tahap 2.
Pada tahap ini, skema konseptual ditransformasikan dari model data tingkat tinggi
yang digunakan pada tahap 2 ke dalam model data dari model data dari DBMS yang
dipilih pada tahap 3. Pemetaan tersebut dapat diproses dalam 2 tingkat:
1.4.1 Pemetaan system-independent
Pemetaan ke dalam model data DBMS dengan tidak mempertimbangkan
karakteristik atau hal-hal yang khusus yang berlaku pada implementasi DBMS dari
model data tersebut.

1.4.2 Penyesuain skema ke DBMS yang spesifik

Mengatur skema yang dihasilkan pada langkah 1 untuk disesuaikan pada
implementasi yang khusus di masa yang akan datang dari suatu model data yang
digunakan pada DBMS yang dipilih.Hasil dari tahap ini memakai perintah-perintah
DDL (Data Definition Language) dalam bahasa DBMS yang dipilih yang
menentukan tingkat skema konseptual dan eksternal dari sistem database. Tetapi 10
dalam beberapa hal, perintah-perintah DDL memasukkan parameter-parameter
rancangan fisik sehingga DDL yang lengkap harus menunggu sampai tahap
perancangan databasesecara fisik telah lengkap.Tahap ini dapat dimulai setelah
pemilihan sebuah implementasi model data sambil menunggu DBMS yang spesifik
yang akan dipilih. Contoh: jika memutuskan untuk menggunakan beberapa
relational DBMS tetapi belum memutuskan suatu relasi yang utama. Rancangan
dari skema eksternal untuk aplikasi-aplikasi yang spesifik seringkali sudah selesai
selama proses ini.

1.5 Perancangan database secara fisik

Perancangan database secara fisik merupakan proses pemilihan struktur-
struktur penyimpanan dan jalur-jalur akses pada file-file databaseuntuk mencapai
penampilan yang terbaik pada bermacam-macam aplikasi.Selama fase ini,
dirancang spesifikasi-spesifikasi untuk database yang disimpan yang berhubungan
dengan struktur-struktur penyimpanan fisik, penempatan record dan jalur akses.
Berhubungan dengan internal schema (pada istilah 3 level arsitektur DBMS).
Beberapa petunjuk dalam pemilihan perancangan database secara fisik:

1.5.1 Response time

Waktu yang telah berlalu dari suatu transaksi database yang diajukan untuk
menjalankan suatu tanggapan. Pengaruh utama pada response time adalah di bawah
pengawasan DBMS yaitu : waktu akses database untuk data item yang ditunjuk oleh
suatu transaksi. Response time juga dipengaruhi oleh beberapa faktor yang tidak
berada di bawah pengawasan DBMS, seperti penjadwalan sistem operasi atau
penundaan komunikasi.

1.5.2 Space utility

Jumlah ruang penyimpanan yang digunakan oleh file-file database dan
struktur-struktur jalur akses.

1.5.3 Transaction throughput

Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem
database, dan merupakan parameter kritis dari sistem transaksi (misal : digunakan
pada pemesanan tempat di pesawat, bank, dll). Hasil dari fase ini adalah penentual
awal dari struktur penyimpanan dan jalur akses untuk file-file database.

1.6 Implementasi Sistem database

Setelah perancangan secara logika dan secara fisik lengkap, kita dapat
melaksanakan sistem database. Perintah-perintah dalam DDL dan SDL(Storage
Definition Language) dari DBMS yang dipilih, dihimpun dan digunakan untuk
membuat skema database dan file-file database (yang kosong). Sekarang
databasetersebut dimuat (disatukan) dengan datanya.Jika data harus dirubah dari
sistem komputer sebelumnya, perubahan-perubahan yang rutin mungkin diperlukan
untuk format ulang datanya yang kemudian dimasukkan ke database yang baru.
Transaksi-transaksi database sekarang harus dilaksanakan oleh para programmmer
aplikasi.Spesifikasi secara konseptual diuji dan dihubungkan dengan kode program
dengan perintah-perintah dari embedded DML yang telah ditulis dan diuji. Suatu
saat transaksi-transaksi tersebut telah siap dan data telah dimasukkan ke dalam
database, maka tahap perancangan dan implementasi telah selesai, dan kemudian
tahap operasional dari sistem database dimulai.
2. Normalisasi adalah upaya agar desain logik tabel-tabel berada dalam bentuk
normal (normal form) yang dapat didefinisikan dengan menggunakan
ketergantungan fungsi (functional dependency). Beberapa bentuk normalisasi
diantaranya adalah bentuk tidak normal (unnormalize), bentuk normal pertama
(1NF), bentuk normal kedua (2NF), normal ketiga (3NF), dan seterusnya.

2.1. Bentuk Tidak Normal (unnormalize)

Bentuk tidak normal (unnormalized) merupakan kumpulan data yang
direkam tidak ada keharusan dengan mengikuti suatu format tertentu.

Pada bentuk tidak normal terdapat repeating group (Pengulangan Group), sehingga
pada kondisi ini data menjadi permasalahan dalam melakukan manipulasi data
(insert, update, dan delete) atau biasa disebut anomali. Contoh:

2.2. Bentuk Normal Pertama (1NF)

Dalam relational database tidak diperkenankan adanya repeating group
karena dapat berdampak terjadinya anomali. Oleh karena itu tahap unnormal akan
menghasilkan bentuk normal tahap pertama (1NF) yang dapat di definisikan
sebagai berikut:
Suatu relasi atau tabel memenuhi normal pertama jika dan hanya jika setiap
setiap atribut dari relasi tersebut hanya memiliki nilai tunggal dalam satu baris
(record). Tiap field hanya satu pengertian, bukan merupakan kumpulan kata yang
mempunyai arti ganda dan tidak ada set atribut yang berulang-ulang atau atribut
bernilai ganda. Pada data tabel sebelumnya data belum normal sehingga harus
diubah kedalam bentuk normal pertama dengan cara membuat baris berisi kolom
jumlah yang sama dan setiap kolom hanya mengandung satu nilai.
Berikut perubahannya:

Bentuk normalisasi pertama (1 NF) ini mempunyai ciri yaitu setiap data
dibentuk file datar atau rata (flat file), data dibentuk dalam satu record demi satu
record dan nilai-nilai dari field-field berupa nilai yang tidak dapat dibagi-bagi lagi.

2.3. Bentuk Normal Kedua (2NF)

Dalam perancangan database relational tidak diperkenankan adalah partial
functional dependency kepada primary key, karena dapat berdampak terjadinya
anomali. Oleh karena itu tahap normalisasi pertama akan menghasilkan bentuk
normal kedua (2 NF) yang dapat didefinisikan sebagai berikut:
Suatu relasi memenuhi relasi kedua jika dan hanya jika relasi tersebut
memenuhi normal pertama dan setiap atribut yang bukan kunci (non key)
bergantung secara fungsional terhadap kunci utama (Primary key).

Berikut perubahannya:

Bentuk normal kedua ini mempunyai syarat yaitu bentuk data yang telah
memenuhi kriteria bentuk normal pertama. Atribut bukan kunci haruslah
bergantung secara fungsional pada kunci utama (primary key), sehingga untuk
membentuk normal kedua haruslah sudah ditentukan kunci-kunci field.

2.4. Bentuk Normal Ketiga (3NF)

Dalam perancangan database relational tidak diperkenankan adanya
transitive dependency karena dapat berdampak terjadinya anomali. Oleh karena itu
harus dilakukan normalisasi tahap ketiga (3 NF) yang dapat didefinisikan sebagai
berikut:
Suatu relasi memenuhi bentuk normal ketiga jika dan hanya jika relasi
tersebut memenuhi normal kedua dan setiap atribut bukan kunci (non key) tidak
mempunyai transitive functional dependency kepada kunci utama (primary key).

Berikut perubahannya:

Bentuk normal ketiga (3NF) ini relasi haruslah dalam bentuk normal kedua
dan semua atribut bukan kunci utama tidak punya hubungan transitif. Artinya setiap
atribut bukan kunci harus bergantung hanya pada primary key secara keseluruhan,
dan bentuk normalisasi ketiga sudah didapat tabel yang optimal.
2.5. BNCF
Sebuah relasi dalam bentuk Boyce-Codd Normal Form (BCNF) jika dan
hanya jika setiap determinan adalah candidate key. Boyce-Codd Normal Form
adalah tipe khusus dari bentuk normal ketiga. Sebuah relasi dalam BCNF adalah
juga bentuk dalam 3NF, tetapi relasi dalam 3NF mungkin tidak dalam BCNF.

2.6. Bentuk Normal Keempat (4NF)

Bentuk normal 4NF terpenuhi dalam sebuah tabel jika telah memenuhi
bentuk BCNF, dan tabel tersebut tidak boleh memiliki lebih dari sebuah
multivalued attribute. Untuk setiap multivalued dependencies (MVD) juga harus
merupakan functional dependencies.

2.7. Bentuk Normal Kelima (5NF)

Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah lossless
decomposition menjadi tabel-tabel yg lebih kecil. Jika 4 bentuk normal sebelumnya
dibentuk berdasarkan functional dependency, 5NF dibentuk berdasarkan konsep
join dependence. Yakni apabila sebuah tabel telah di-dekomposisi menjadi tabel-
tabel lebih kecil, harus bisa digabungkan lagi (join) untuk membentuk tabel semula.

3. Secara garis besar, database MySQL mempunyai 3 macam tipe data, yaitu:

3.1. Tipe Data Numeric

Tipe data numerik adalah tipe data yang digunakan untuk menyatakan data
berupa angka. Tiap tipe data memiliki rentang nilai tersendiri serta ukuran memori
yang bergantung pada rentang nilai nya tersebut.

3.1.1 INT
Digunakan untuk menyimpan data yang berupa bilangan bulat positif dan
negatif dengan jangkauan antara -2.147.483.648 s/d 2.147.483.647. Tipe data ini
mempunyai ukuruan 4 byte (32 bit).
3.1.2 TINYINT
Digunakan untuk menyimpan data yang berupa bilangan bulat positif dan
negatif dengan jangkauan antara -128 s/d 127. Tipe data ini mempunyai ukuran 1
byte (8 bit).

3.1.3 SMALLINT
Digunakan untuk menyimpan data yang berupa bilangan bulat positif dan
negatif dengan jangkauan antara -32.768 s/d 32.767. Tipe data ini mempunyai
ukuran 2 byte (16 bit).

3.1.4 MEDIUMINT
Digunakan untuk menyimpan data yang berupa bilangan bulat positif dan
negatif dengan jangkauan antara -8.388.608 s/d 8.388.607. Tipe data ini
mempunyai ukuran 3 byte (24 bit).

3.1.5 BIGINT
Digunakan untuk menyimpan data yang berupa bilangan bulat positif dan
negatif dengan jangkauan antara -8.388.608 s/d 8.388.607. Tipe data ini
mempunyai ukuran 8 byte (64 bit).

3.1.6 FLOAT
Digunakan untuk menyimpan data yang berupa bilangan pecahan positif
dan negatif presisi tunggal. Tipe data ini mempunyai ukuran 4 byte (32 bit).

3.1.7 DOUBLE
Digunakan untuk menyimpan data yang berupa bilangan pecahan positif
dan negatif presisi ganda. Tipe data ini mempunyai ukuran 8 byte (64 bit).

3.1.8 DECIMAL
Digunakan untuk menyimpan data yang berupa bilangan pecahan positif
dan negatif presisi ganda. Tipe data ini mempunyai ukuran 8 byte (64 bit).
3.1.9 REAL

Digunakan untuk menyimpan data yang berupa bilangan pecahan positif

dan negatif. Tipe data ini mempunyai ukuran 8 byte (64 bit).

3.1.10 NUMERIC
Digunakan untuk menyimpan data yang berupa bilangan pecahan positif
dan negatif. Tipe data ini mempunyai ukuran 8 byte (64 bit).

3.2. Tipe Data Date & Time

Tipe data yang digunakan untuk menyatakan tanggal, waktu, serta tahun.
Masing-masing memiliki format yang berurutan dalam menyatakan nya.

3.2.1 DATE
Digunakan untuk meyimpan data tanggal dalam format YY:MM:DD,
dengan ukuran memori sebesar 3 byte.

3.2.2 DATETIME

Digunakan untuk menyimpan data tanggal dan waktu dalam format

YY:MM:DD HH:MM:SS, dengan ukuran memori sebesar 8 byte.

3.2.3 TIME

Digunakan untuk menyimpan data waktu dalam format HH:MM:SS,

dengan ukuran memori sebesar 1 byte.

3.2.4 YEAR

Digunakan untuk menyimpan data tahun, ukuran memori sebesar 1 byte.

3.3. Tipe Data String
Tipe data string digunakan untuk menyimpan data string (text). Ciri utama
data string adalah suatu data yang memungkinkan untuk dikenai operasi aritmatika
seperti pertambahan, pengurangan, perkalian dan pembagian.
3.3.1 CHAR

Digunakan untuk menyimpan data karakter/string dengan ukuran tetap. Tipe data
ini mempunyai jangkauan antara 0 sampai dengan 255 karakter.

3.3.2 VARCHAR

Digunakan untuk menyimpan data karakter/string dengan ukuran dinamis.

Tipe data ini mempunyai jangkauan antara 0 sampai dengan 255 untuk MySQL
versi 4.1. Dan mempunyai jangkauan antara 0 s/d 65.535 untuk MySQL versi 5.0.3

3.3.3 TEXT
Digunakan untuk meyimpan data text. Tipe data ini mempunyai jangkauan
antara 0 sampai dengan 65.535 (216-1) karakter.
3.3.4 TINYTEXT

Digunakan untuk meyimpan data text. Tipe data ini mempunyai jangkauan
antara 0 s/d 255 untuk MySQL versi 4.0, dan mempunyai jangkauan antara 0 s/d
65.535 untuk MySQL versi 5.0.3

3.3.5 MEDIUMTEXT

Digunakan untuk meyimpan data text. Tipe data ini mempunyai jangkauan antara
0 sampai dengan 224-1 karakter

3.3.6 LONGTEXT
Digunakan untuk meyimpan data text. Tipe data ini mempunyai jangkauan antara
0 sampai dengan 232-1 karakter
3.3.7 ENUM
Digunakan untuk menyimpan data enumerasi (kumpulan data)
3.3.8 SET
Digunakan untuk menyimpan data himpunan data.
4. Key pada Basis Data merupakan gabungan beberapa atribut dimana
fungsinya adalah untuk membedakan semua basis data didalam tabel secara unik
ataupun suatu cara untuk menghubungkan antara tabel satu dengan tabel yang
lainnya. Didalam SQL, key terbagi menjadi beberapa jenis diantaranya adalah
sebagai berikut:

4.1 Primary Key

Primary Key merupakan sebuah aturan dimana fungsinya adalah untuk
membedakan anatara baris satu dengan baris lainnya yang ada pada tabel dan
bersifat unik. Ada ketentuan yang harus diperhatikan ketika field yang menjadi
primary key yakni: Data tidak boleh sama atau ganda (unik), dan Data tidak boleh
bernilai null.

4.2 Foreign Key

Foreign key, merupakan suatu atribut untuk melengkapi hubungan yang
menunjukan ke induknya, itu artinya field pada tabel merupakan kunci tamu dari
tabel lain. Dan biasanya penggunaan foreign key akan sangat dibutuhkan ketikan
menemukan banyak tabel dan ingin menghubungkan satu tabel dengan tabel
lainnya

4.3 Candidate Key

Candidate Key adalah satu atribut atau satu set atribut yang
mengidentifikasikan secara unik suatu kejadian spesifik dari entity. Satu set atribut
menyatakan secara tidak langsung dimana tidak dapat membuang beberapa atribut
dalam set tanpa merusak kepemilikan yang unik. Jika kunci kandidat berisi lebih
dari satu atribut, maka biasanya disebut sebagai composite key (kunci campuran).
4.4 Alternate Key
Alternate Key adalah kunci kandidat yang tidak dipakai sebagai kunci
primer. Kunci alternatif ini sering digunakan untuk kunci pengurutan misalnya
dalam laporan.
4.5 Composite Key
Composite key adalah kunci yang terdiri dari 2 atau lebih atribut yang secara
unik mengidentifikasi suatu kejadian entitas.

5. Jenis Jenis Relasi pada Basis Data antara lain adalah:

5.1 Satu ke satu (One to One)
Setiap entitas pada himpunan entitas A berhubungan dengan paling banyak
dengan satu entitas pada himpunan entitas begitu juga sebaliknya setiap entitas pada
himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada
himpunan entitas A.

5.2 Satu ke Banyak (one to many)

Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak
entitas pada himpunan entitas B, tetapi tidak sebaliknya, dimana setiap entitas pada
himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada
himpunan entitas A.

5.3 Banyak ke Satu (Many to One)

Setiap entitas pada himpunan entitas A berhubungan dengan paling banyak
dengan satu entitas pada himpunan entitas B, tetapi tidak sebaliknya, dimana setiap
entitas pada himpunan entitas A berhubungan dengan paling banyak satu entitas
pada himpunan entitas B.
5.4 Banyak ke Banyak (Many to Many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak
entitas pada himpunan entitas B, demikian juga sebaliknya, di mana setiap entitas
pada himpunan entitas B dapat berhubungan dengan banyak entitas pada himpunan
entitas A.
6. Berikut adalah Rancangan PDM yang telah dibuat:
Penjelasan dari setiap Relasi pada PDM nya adalah sebagai berikut:

6.1 Tabel Pasien

Tabel Pasien berfungsi untuk menyimpan data diri mengenai pasien pada
klinik tersebut. Tabel ini berisi data pribadi dan data kesehatan para pasien. Posisi
dari tabel ini adalah sebagai Master. Tabel ini memiliki relasi dengan Tabel Rekam
Medis, Tabel Pelayanan Dokter, Tabel Transaksi, dan Tabel Transaksi Obat.

6.2 Tabel Kabupaten, Provinsi, dan Kecamatan

Tabel Kabupaten, Provinsi, dan Kecamatan berfungsi ntuk menyimpan daftar
nama Kabupaten, Provinsi, dan Kecamatan tempat pasien tinggal dengan tipe data
VARCHAR. Tabel Kabupaten merujuk kepada Tabel Provinsi tempat kabupaten
tersebut berada, dan Tabel Kecamatan merujuk kepada Tabel Kabupaten tempat
kecamatan tersebut berada. Posisi dari ketiga tabel ini adalah sebagai master.
6.3 Tabel Alamat
Tabel Alamat berfungsi untuk mencatat alamat pasien, supplier, dokter, staff,
dan farmasi dari klinik tersebut. Alamat ditulis secara lengkap berupa keterangan
alamat. Tabel ini mengambil data dari tabel kecamatan dan posisinya adalah
sebagai tabel master.

6.4 Tabel Rekam Medis

Tabel Rekam Medis berfungsi untuk mencatat rekam medis yang berisi
keterangan pengobatan dari pasien. Tabel ini mengambil rujukan dari tabel pasien,
pelayanan dokter, dan transaksi serta mencatat tanggal pasien tersebut menerima
pengobatan. Posisi dari tabel ini adalah sebagai tabel detail.

6.5 Tabel Dokter

Tabel Dokter berfungsi untuk menyimpan Data diri dari dokter yang
menangani pasien. Bidang dari Dokter tersebut merujuk kepada Tabel Poli. Alamat
dari dokter tersebut merujuk ke tabel alamat. Posisi dari tabel ini adalah sebagai
tabel master.
6.6 Tabel Poli
Tabel Poli berfungsi untuk menyimpan daftar nama bidang beserta
keterangannya pada setiap dokter dan staff di klinik tersebut. Posisinya adalah
sebagai tabel master.

6.7 Tabel Pelayanan Dokter

Tabel Pelayanan Dokter berfungsi untuk mencatat pelayanan dokter kepada
pasien dengan merujuk ke tabel pasien dan dokter yang menanganinya dengan
merujuk ke tabel dokter. Kemudian mencatat diagnosis dari gejala yang diderita
dan tanggal pengobatannya.
6.8 Tabel Administrasi
Tabel Administrasi berfungsi untuk mencatat biaya dan tanggal pengobatan
pasien berdasarkan data yang dirujuk dari tabel Pelayanan dokter dan tabel staff
beserta keterangan lengkapnya. Posisi dari tabel ini adalah sebagai tabel master.

6.9 Tabel Transaksi

Tabel Transaksi berfungsi untuk mencatat rincian biaya pengobatan dari
seorang pasien dengan merujuk ke tabel pasien. Tanggal dan harga dari pengobatan
dicatat dengan cermat dalam tabel ini. Posisi dari tabel ini adalah sebagai tabel
master.

6.10 Tabel Detail Transaksi

Tabel Detail Transaksi berfungsi untuk menunjukkan detail dari biaya
pengobatan pada tabel transaksi dengan rincian resepnya dari tabel resep dan
mengambil data dari tabel Administrasi. Tabel ini merupakan tabel detail.
6.11 Tabel Transaksi Obat
Tabel Transaksi Obat berfungsi untuk mencatat rincian pembelian obat dan
mengambil data dari tabel pasien yang membeli obatnya. Staff yang menangani
transaksi dirujuk ke Tabel Staff. Tabel ini posisinya adalah sebagai tabel master.

6.12 Tabel Detail Transaksi Obat

Tabel Detail Transaksi Obat berfungsi untuk mencatat detail pembelian obat
oleh pasien dengan mengambil data dari Tabel Transaksi Obat beserta data obat
yang dibeli dengan merujuk ke tabel obat. Tabel ini ini berada di posisi tabel detail.
6.13 Tabel Resep
Tabel Resep berfungsi untuk mencatat nama resep beserta keterangan, kode,
dan harganya yang diterima oleh pasien dari dokter lalu merujuk ke data dari tabel
pelayanan dokter. Posisi dari tabel ini adalah sebagai Tabel Master.

6.14 Tabel Detail Resep

Tabel Detail Resep berfungsi untuk menyimpan detail dari resep obat yang
diterima pasien dengan merujuk ke tabel pasien dan dari farmasi dengan merujuk
ke tabel farmasi. Obat yang dimaksud dirujuk ke tabel obat. Posisi tabel ini adalah
sebagai tabel detail.
6.15 Tabel Obat
Tabel Obat berfungsi untuk menyimpan daftar nama obat yang tersedia di klinik
tersebut beserta jenis dan harganya. Jenis dan bentuk obatnya merujuk ke Tabel
jenis dan bentuk obat. Posisi dari tabel ini adalah Tabel master.

6.16 Tabel Jenis dan Bentuk Obat

Tabel Jenis dan bentuk Obat berfungsi untuk mendata daftar jenis obat yang tersedia
di klinik tersebut beserta bentuk-bentuknya. Keterangan pada setiap jenis obat juga
ada di tabel ini. Tabel ini posisinya adalah tabel Master.

6.17 Tabel Farmasi

Tabel Farmasi berfungsi untuk menyimpan data diri mengenai farmasi yang
menangani obat untuk pasien. Alamat farmasi nya merujuk ke tabel alamat. Tabel
ini adalah Tabel Master.
6.18 Tabel Pembelian
Tabel Pembelian berfungsi untuk mencatat total harga obat yang dibeli
farmasi dari supplier kemudian merujuk ke tabel staff yang menangani pembelian
dan tabel supplier yang menyimpan data mengenai supplier yang memasok obat ke
farmasi. Tabel ini merupakan tabel master.

6.19 Tabel Detail pembelian

Tabel Detail pembelian berfungsi untuk mencatat detail pembelian obat dari
supplier dan berisikan daftar obat yang dipasok dengan merujuk datanya ke tabel
obat. Harga setiap obat juga tertera disini. Tabel ini merupakan Tabel Detail.
6.20 Tabel Supplier
Tabel Supplier berfungsi untuk mencatat data dari para pemasok yang menjual obat
ke farmasi. Berisi Nomor telepon dan keterangan dari supplier. Alamat dari
Supplier merujuk ke dalam Tabel Alamat. Tabel ini merupakan Tabel Master.

6.21 Tabel Staff

Tabel Staff berfungsi untuk menyimpan data diri mengenai setiap staff yang
bertugas di klinik tersebut. Bidang dari setiap staff dirujuk ke Tabel Poli. Jabatan
dari setiap staff merujuk kepada tabel jabatan.
6.22 Tabel Jabatan
Tabel Jabatan berfungsi untuk menyimpan daftar nama jabatan yang dipegang oleh
setiap staff. Tabel ini memiliki relasi dengan Tabel Staff. Fungsi dari tabel ini
adalah sebagai tabel master.