a) ERD (Diagram Hubungan Entitas) dari kasus diatas lengkap dengan atribut

dan cardinalitynya
1. Diagram E-R (Entity Relationship Diagram)
Hubungan diagram E-R (Entity Relationship) ini pada dasarnya didapat dari hasil
analisa data sebagai berikut:
Petugas
Bertanggung
Jawab
Pembelian
No Induk Pegawai
Nama Pegawai
Tanggal Lahir Nomor Resep
Tanggal Resep Keterangan
Harga
1
Obat
Mengambil
Kode Obat Nama Obat
Jumlah Obat Tanggal Pembuatan
N
1
N

Gambar 1 Diagram E-R (Entity Relationship Diagram)
Dari diagram di atas, dapat kita lihat bahwa entity yang didapat dari hasil analisa
simpanan adalah petugas resep dan resep dengan hubungan untuk membuat. Akan
tetapi guna mengatur proses pengunduhan sehingga dapat didata, serta untuk melihat
perkembangan sistem, maka dibuatlah sebuah entity lain, yaitu obat resep, yang
dihubungkan dengan entity resep dengan hubungan unduh.
b) Gambarkan Transformasinya ke logical record structure (LRS)
1. Transformasi ERD ke bentuk LRS
Transformasi diagram ERD ke LRS merupakan suatu kegiatan untuk membentuk data-
data dari diagram hubungan entitas ke suatu LRS. Diagram ER diatas akan
ditransformasikan ke bentuk LRS. Berikut adalah langkah pengelompokkan pada
diagram ER untuk menentukan entity pada diagram LRS.
Petugas
Bertanggung
Jawab
Pembelian
No Induk Pegawai
Nama Pegawai
Tanggal Lahir Nomor Resep
Tanggal Resep Keterangan
Harga
1
Obat
Mengambil
Kode Obat Nama Obat
Jumlah Obat Tanggal Pembuatan
N
1
N

Gambar 2 Transformasi diagram E-R ke bentuk LRS
Proses membuat resep dapat digabungkan dengan entity Resep, begitu juga dengan
unduh, yang dapat digabungkan dengan resep. Untuk petugas Resep dan Obat Resep
tetap merupakan sebuah entity tanpa perubahan maupun penggabungan. Proses
selanjutnya adalah membuat LRS dari diagram di atas, dengan cara menyatukan
proses-proses yang digabungkan ke dalam entity.
c) Buat LRS yang dihasilkan
1. LRS (Logical Record Structure)
Setelah ERD ditransformasikan ke bentuk LRS, maka hasil akhir dari proses
transformasi tersebut adalah sebuah diagram yang sudah dapat menggambarkan basis
data yang akan digunakan. LRS terdiri dari tipe record, yang berupa sebuah persegi
dengan field yang dibutuhkan di dalamnya. LRS terdiri juga dari hubungan antara tipe
record tersebut.
- No Induk Pegawai
- Nama Pegawai
- Tanggal Lahir
- Nomor Resep
- Tanggal Resep
- Keterangan
- Harga
- No Induk Pegawai
- Kode Obat
- Kode Obat
- Nama Obat
Pembelian
Obat

Gambar 3 Logical Record Structure (LRS)
Dari diagram di atas dapat kita lihat bahwa LRS untuk sistem ini terdiri dari 3 tipe
record, yaitu petugas, resep dan obat. Petugas berhubungan dengan resep dan record
obat dengan resep.
d) Buatlah Tabel-tabel yang dihasilkan seandainya akan diimplementasikan
dalam model database relasional
1. Transformasi LRS ke Tabel Relasi
1. Petugas
No_Induk_pegawai Nama Tanggal_lahir
PK

1. Pembelian
No_resep Tanggal_resep Keterangan Harga No_induk_pegawai Kode_obat
PK

FK FK
1. Obat
Kd_obat Nama_obat
PK CK

1. Normalisasi
4.1.5.1 Tabel Petugas
Berikut adalah bentuk awal dari tabel petugas sebelum dinormalisasi:
Tabel Petugas (Unnormal) :
No_induk_pegawai Nama Tanggal_lahir
PK

Gambar 4 Bentuk awal tabel petugas
1. 1 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 1NF,
dikarenakan tabel petugas sudah memenuhi persyaratan bentuk 1NF, yaitu tidak
memiliki atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel petugs bersifat
atomik (tunggal).
Tabel Petugas (1NF) :
No_induk_pegawai Nama Tanggal_lahir
PK

Gambar 5 Normalisasi 1NF tabel petugas
1. 2 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 2NF,
dikarenakan tabel petugas sudah memenuhi persyaratan bentuk 2NF, yaitu tidak ada
partial depedency, setiap atribut pada tabel memiliki ketergantungan penuh pada
primary key tabel tersebut. Setiap atribut dari tabel petugas memiliki ketergantungan
penuh pada atribut kd_petugas (primary key).
Tabel Petugas (2NF) :
No_induk_pegawai Nama Tanggal_lahir
PK

Gambar 6 Normalisasi 2NF tabel petugas
1. 3 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 3NF,
dikarenakan tabel petugas sudah memenuhi persyaratan bentuk 3NF, yaitu tidak ada
transitive depedency, dimana setiap atribut disimpan pada tabel masing-masing.
Tabel Petugas (3NF) :
No_induk_pegawai Nama Tanggal_lahir
PK

Gambar 7 Normalisasi 3NF tabel petugas
4.1.5.2 Tabel Pembelian
Berikut adalah bentuk awal dari tabel resep sebelum dinormalisasi (unnormal):
Tabel Pembelian (Unnormal) :
No_resep Tanggal_resep Keterangan Harga No_induk_pegawai Kode_obat
PK

FK FK
Gambar 8 Bentuk awal tabel resep
1. 1 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 1NF,
dikarenakan tabel petugas sudah memenuhi persyaratan bentuk 1NF, yaitu tidak
memiliki atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel petugas
bersifat atomik (tunggal).
Tabel Pembelian (1NF) :
No_resep Tanggal_resep Keterangan Harga No_induk_pegawai Kode_obat
PK

FK FK
Gambar 9 Normalisasi 1 NF tabel Resep





1. 2 NF
Diperlukan adanya tabel tambahan untuk menampung kategori, serta screenshot dan
unduh. Dikarenakan field tersebut tidak memiliki ketergantungan dengan primary key
dari tabel resep. Sehingga setelah proses normalisasi 2NF akan didapatkan tabel:
Tabel Resep (2NF) :
No_resep Keterangan Harga No_induk_pegawai
PK

FK
Tabel Beli (2NF):
Kode_obat No_resep Tanggal_resep
Composite Key

Gambar 10 Normalisasi 2NF tabel resep
1. 3 NF
Tidak diperlukan perubahan pada tabel resep untuk normalisasi 2NF, dikarenakan tabel
resep sudah memenuhi persyaratan bentuk 3NF, yaitu tidak ada transitive depedency,
dimana setiap atribut disimpan pada tabel masing-masing.
Tabel Resep (3NF) :
No_resep Keterangan Harga No_induk_pegawai
PK

FK
Tabel Beli (3NF):
Kode_obat No_resep Tanggal_resep
Composite Key

Gambar 11 Normalisasi 3NF tabel resep
4.1.5.3 Tabel Obat
Berikut adalah bentuk awal dari tabel obat sebelum dinormalisasi:
Tabel Obat (Unnormal) :
Kode_obat Nama_obat
PK CK
Gambar 12 Bentuk awal tabel obat
1. 1 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 1NF,
dikarenakan tabel obat sudah memenuhi persyaratan bentuk 1NF, yaitu tidak memiliki
atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel petugas bersifat atomik
(tunggal).
Tabel Obat (1NF) :
Kode_obat Nama_obat
PK CK
Gambar 13 Normalisasi 1NF tabel obat
1. 2 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 2NF,
dikarenakan tabel obat sudah memenuhi persyaratan bentuk 2NF, yaitu tidak ada
partial depedency, setiap atribut pada tabel memiliki ketergantungan penuh pada
primary key tabel tersebut. Setiap atribut dari tabel petugas memiliki ketergantungan
penuh pada atribut kd_obat (primary key).
Tabel Obat (2NF) :
Kode_obat Nama_obat
PK CK
Gambar 14 Normalisasi 2NF tabel obat
1. 3 NF
Tidak perlu melakukan perubahan pada tabel petugas untuk proses normalisasi 3NF,
dikarenakan tabel obat sudah memenuhi persyaratan bentuk 3NF, yaitu tidak ada
transitive depedency, dimana setiap atribut disimpan pada tabel masing-masing.
Tabel Obat (3NF) :
Kode_obat Nama_obat
PK CK
Gambar 15 Normalisasi 3NF tabel obat
Daftar tabel setelah proses normalisasi bentuk ketiga adalah:
Tabel Petugas (3NF):
Kd_petugas Nama Tanggal_lahir
PK CK

Tabel Resep (3NF) :
No_resep Keterangan Harga No_induk_pegawai
PK

FK
Tabel Beli (3NF):
Kode_obat No_resep Tanggal_resep
Composite Key

Tabel Obat (3NF):
Kode_obat Nama_obat
PK CK
e) Buat spesifikasi Basis Data
1. Spesifikasi Basis Data
Spesifikasi basis data menjelaskan secara detail tentang masing-masing basis data
yang digunakan dalam sistem informasi manajemen resep di apotek adalah:
1. Nama File : Petugas
Media : Hardisk
Isi : Data data petugas resep
Organisasi : Sequensial
Primary Key : kd_petugas
Panjang Record : 42 byte
Struktur : Lihat tabel di bawah ini
Tabel 4.1 Struktur basis data petugas

No. Nama Atribut Jenis Panjang Keterangan
1 Kd_petugas Char 4 Kode petugas
2 Nama VarChar 30 Nama petugas
3 Tanggal_lahir Date 8

Rancangan Kode :
Format untuk kode petugas adalah : 9999
Dimana kode petugas merupakan nomor urut pendaftaran mereka dalam sistem.
1. Nama File : Resep
Media : Hardisk
Isi : Data data mengenai resep tersebut
Organisasi : Sequensial
Primary Key : kd_resep
Panjang Record : 48 byte
Struktur : Lihat tabel di bawah ini
Tabel 4.2 Struktur basis data resep
No. Nama Atribut Jenis Panjang Keterangan
1 No_resep Char 4 Kode resep
2 Keterangan VarChar 30 Deskripsi dari resep
3 harga Text 10

4 Kd_petugas Char 4 Kode petugas resep
Rancangan Kode :
Format untuk kode resep adalah : 9999
Dimana kode petugas merupakan nomor urut pendaftaran resep dalam sistem.
1. Nama File : Obat
Media : Hardisk
Isi : Data mengenai obat
Organisasi : Sequensial
Primary Key : -
Panjang Record : 34 byte
Struktur : Lihat tabel di bawah ini
Tabel 4.6 Struktur basis data obat resep
No. Nama Atribut Jenis Panjang Keterangan
1 Kd_obat Char 4 Kode obat
2 Nama_obat VarChar 30 Nama obat
Rancangan Kode :
Format untuk kode obat adalah 9999
Dimana kode obat merupakan nomor urut pendaftaran screenshot ke dalam
sistem.
1. Nama File : Beli
Media : Hardisk
Isi : Data mengenai proses beli yang dilakukan
Organisasi : Sequensial
Primary Key : -
Panjang Record : 20 byte
Struktur : Lihat tabel di bawah ini
Tabel 4.7 Struktur basis data beli
No. Nama Atribut Jenis Panjang Keterangan
1 Kd_beli Char 4 Kode beli
2 Kd_obat Char 4 Kode obat
3 Kd_resep Char 4 Kode resep
4 Tanggal Date 8 Tanggal unduh
Rancangan Kode :
Format untuk kode beli adalah 9999999
Dimana kode unduh merupakan nomor urut proses beli yang dilakukan di sistem