Rancangan Basis Data

Pembuatan rancangan basis data untuk sistem informasi manajemen aplikasi permainan edukasi ini diawali dengan membuat Entity Relationship Diagram (ERD), yang kemudian dirubah menjadi Logical Record Structure (LRS), gambaran dari LRS tersebut akan menghasilkan sebuah tabel relasi basis data. Tabel basis data tersebut kemudian di normalisasi untuk mencegah terjadinya duplikasi maupun redudansi data. Proses selanjutnya adalah pembuatan spesifikasi basis data serta rancangan kodenya.

1.     Diagram E-R (Entity Relationship Diagram)

Hubungan diagram E-R (Entity Relationship) ini pada dasarnya didapat dari hasil analisa data sebagai berikut:

Gambar 4.1 Diagram E-R (Entity Relationship Diagram)

    Dari diagram di atas, dapat kita lihat bahwa entity yang didapat dari hasil analisa simpanan adalah pembuat game dan game dengan hubungan untuk membuat. Akan tetapi guna mengatur proses pengunduhan sehingga dapat didata, serta untuk melihat perkembangan sistem, maka dibuatlah sebuah entity lain, yaitu pengguna game, yang dihubungkan dengan entity game dengan hubungan unduh.

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.

Gambar 4.2 Transformasi diagram E-R ke bentuk LRS

    Proses membuat game dapat digabungkan dengan entity Game, begitu juga dengan unduh, yang dapat digabungkan dengan game. Untuk pembuat Game dan Pengguna Game 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.

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.

Gambar 4.3 Logical Record Structure (LRS)

    Dari diagram di atas dapat kita lihat bahwa LRS untuk sistem ini terdiri dari 3 tipe record, yaitu pembuat, game dan pengguna. Pembuat berhubungan dengan game dan record pengguna dengan game.

1.     Transformasi LRS ke Tabel Relasi

Dari gambar LRS di atas, dapat dibuat konsep rancangan tabel relasi, yang kemudian kita normalisasi untuk mendapatkan sebuah rancangan tabel relasi yang akan digunakan di dalam sistem kita.

1.     Pembuat

Kd_pembuat	nama	instansi	telepon	email
PK				CK

1.     Game

Kd_game	judul	deskripsi		jenis		kategori
PK
screenshot	Kd_pembuat		Kd_pengguna		Tgl_unduh
	FK		FK

1.     Pengguna

Kd_pengguna	email
PK	CK

1.     Normalisasi

4.1.5.1 Tabel Pembuat

Berikut adalah bentuk awal dari tabel pembuat sebelum dinormalisasi:

Tabel Pembuat (Unnormal) :

Kd_pembuat	Nama	instansi	telepon	email	Password
PK				CK

Gambar 4.4 Bentuk awal tabel pembuat

1.     1 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 1NF, dikarenakan tabel pembuat sudah memenuhi persyaratan bentuk 1NF, yaitu tidak memiliki atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel pembuat bersifat atomik (tunggal).

Tabel Pembuat (1NF) :

Kd_pembuat	Nama	instansi	telepon	email	Password
PK				CK

Gambar 4.4 Normalisasi 1NF tabel pembuat

1.     2 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 2NF, dikarenakan tabel pembuat 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 pembuat memiliki ketergantungan penuh pada atribut kd_pembuat (primary key).

Tabel Pembuat (2NF) :

Kd_pembuat	Nama	instansi	telepon	email	Password
PK				CK

Gambar 4.4 Normalisasi 2NF tabel pembuat

1.     3 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 3NF, dikarenakan tabel pembuat sudah memenuhi persyaratan bentuk 3NF, yaitu tidak adatransitive depedency, dimana setiap atribut disimpan pada tabel masing-masing.

Tabel Pembuat (3NF) :

Kd_pembuat	Nama	instansi	telepon	email	Password
PK				CK

Gambar 4.5 Normalisasi 3NF tabel pembuat

4.1.5.2 Tabel Game

Berikut adalah bentuk awal dari tabel game sebelum dinormalisasi (unnormal):

Tabel Game (Unnormal) :

Kd_game	judul	deskripsi		jenis		kategori
PK
screenshot	Kd_pembuat		Kd_pengguna		Tgl_unduh
	FK		FK

Gambar 4.6 Bentuk awal tabel game

1.     1 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 1NF, dikarenakan tabel pembuat sudah memenuhi persyaratan bentuk 1NF, yaitu tidak memiliki atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel pembuat bersifat atomik (tunggal).

Tabel Game (1NF) :

Kd_game	judul	deskripsi		jenis		kategori
PK
screenshot	Kd_pembuat		Kd_pengguna		Tgl_unduh
	FK		FK

Gambar 4.6 Normalisasi 1 NF tabel Game

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 game. Sehingga setelah proses normalisasi 2NF akan didapatkan tabel:

Tabel Game (2NF) :

Kd_game	judul	deskripsi	Jenis	Kd_pembuat
PK				FK

Tabel Kategori (2NF):

Kd_kategori	Kategori
PK	CK

Tabel RelasiKategori (2NF):

Kd_kategori	Kd_game
Composite Key

Tabel Screenshot (2NF):

Kd_screenshot	Kd_game
PK	FK

Tabel Unduh (2NF):

Kd_game	Kd_pengguna	Tgl_unduh
Composite Key

Gambar 4.10 Normalisasi 2NF tabel game

1.     3 NF

Tidak diperlukan perubahan pada tabel game untuk normalisasi 2NF, dikarenakan tabel game sudah memenuhi persyaratan bentuk 3NF, yaitu tidak ada transitive depedency, dimana setiap atribut disimpan pada tabel masing-masing.

Tabel Game (3NF) :

Kd_game	judul	deskripsi	Jenis	Kd_pembuat
PK				FK

Tabel Kategori (3NF):

Kd_kategori	Kategori
PK	CK

Tabel RelasiKategori (3NF):

Kd_kategori	Kd_game
Composite Key

Tabel Screenshot (3NF):

Kd_screenshot	Kd_game
PK	FK

Tabel Unduh (3NF):

Kd_game	Kd_pengguna	Tgl_unduh
Composite Key

Gambar 4.11 Normalisasi 3NF tabel game

4.1.5.3 Tabel Pengguna

Berikut adalah bentuk awal dari tabel pengguna sebelum dinormalisasi:

Tabel Pengguna (Unnormal) :

Kd_pengguna	email
PK	CK

Gambar 4.12 Bentuk awal tabel pengguna

1.     1 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 1NF, dikarenakan tabel pengguna sudah memenuhi persyaratan bentuk 1NF, yaitu tidak memiliki atribut yang berulang. Dapat dilihat dari setiap atribut dari tabel pembuat bersifat atomik (tunggal).

Tabel Pengguna (1NF) :

Kd_pengguna	email
PK	CK

Gambar 4.13 Normalisasi 1NF tabel pengguna

1.     2 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 2NF, dikarenakan tabel pengguna sudah memenuhi persyaratan bentuk 2NF, yaitu tidak adapartial depedency, setiap atribut pada tabel memiliki ketergantungan penuh pada primary key tabel tersebut. Setiap atribut dari tabel pembuat memiliki ketergantungan penuh pada atribut kd_pengguna (primary key).

Tabel Pengguna (2NF) :

Kd_pengguna	email
PK	CK

Gambar 4.14 Normalisasi 2NF tabel pengguna

1.     3 NF

Tidak perlu melakukan perubahan pada tabel pembuat untuk proses normalisasi 3NF, dikarenakan tabel pengguna sudah memenuhi persyaratan bentuk 3NF, yaitu tidak adatransitive depedency, dimana setiap atribut disimpan pada tabel masing-masing.

Tabel Pengguna (3NF) :

Kd_pengguna	email
PK	CK

Gambar 4.15 Normalisasi 3NF tabel pengguna

Daftar tabel setelah proses normalisasi bentuk ketiga adalah:

Tabel Pembuat (3NF):

Kd_pembuat	Nama	instansi	telepon	email	Password
PK	CK

Tabel Game (3NF):

Kd_game	judul	deskripsi	Jenis	Kd_pembuat
PK				FK

Tabel Kategori (3NF):

Kd_kategori	Kategori
PK	CK

Tabel RelasiKategori (3NF):

Kd_kategori	Kd_game
Composite Key

Tabel Screenshot (3NF):

Kd_screenshot	Kd_game
PK	FK

Tabel Unduh (3NF):

Kd_game	Kd_pengguna	Tgl_unduh
Composite Key

Tabel Pengguna (3NF):

Kd_pengguna	Email
PK	CK

1.     Spesifikasi Basis Data

    Spesifikasi basis data menjelaskan secara detail tentang masing-masing basis data yang digunakan dalam sistem informasi manajemen game di SEAMOLEC adalah:

1.     Nama File        : Pembuat

Media            : Hardisk

Isi            : Data – data pembuat game

Organisasi        : Sequensial

Primary Key        : kd_pembuat

Panjang Record    : 79 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.1 Struktur basis data pembuat

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_pembuat	Char	4	Kode pembuat
2	Nama	VarChar	30	Nama pembuat
3	Instansi	VarChar	30	Instansi asal pembuat
4	Telepon	N	15	Telepon pembuat
5	Email	VarChar	30	Email pembuat
6	Password	VarChar	15	Password pembuat

Rancangan Kode :

·         Format untuk kode pembuat adalah : 9999

·         Dimana kode pembuat merupakan nomor urut pendaftaran mereka dalam sistem.

1.     Nama File        : Game

Media            : Hardisk

Isi            : Data – data mengenai game tersebut

Organisasi        : Sequensial

Primary Key        : kd_game

Panjang Record    : 73 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.2 Struktur basis data game

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_game	Char	4	Kode game
2	Judul	VarChar	30	Judul dari Game
3	Deskripsi	Text	1024	Deskripsi dari game
4	Jenis	VarChar	15	Jenis dari game
5	Kd_pembuat	Char	4	Kode pembuat game

Rancangan Kode :

·         Format untuk kode game adalah : 9999

·         Dimana kode pembuat merupakan nomor urut pendaftaran game dalam sistem.

1.     Nama File        : Kategori

Media            : Hardisk

Isi            : Data mengenai daftar kategori game yang ada

Organisasi        : Sequensial

Primary Key        : -

Panjang Record    : 34 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.3 Struktur basis data kategori

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_kategori	Char	4	Kode untuk kategori
2	kategori	VarChar	30	Nama Kategori

Rancangan Kode :

·         Format untuk kode kategori adalah : 99

·         Dimana kode kategori merupakan nomor urut pendaftaran kategori dalam sistem.

1.     Nama File        : RelasiKategori

Media            : Hardisk

Isi            : Data mengenai kategori untuk produk game

Organisasi        : Sequensial

Primary Key        : -

Panjang Record    : 8 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.4 Struktur basis data relasi kategori

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_game	Char	4	Kode game
2	Kd_kategori	Char	4	Kode kategori

1.     Nama File        : Screenshot

Media            : Hardisk

Isi            : Data mengenai screenshot untuk produk game

Organisasi        : Sequensial

Primary Key        : -

Panjang Record    : 8 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.5 Struktur basis data game

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_screenshot	Char	4	Kode game
2	Kd_game	Char	4	Kode kategori

Rancangan Kode :

·         Format untuk kode screenshot adalah : 9999

·         Dimana kode screenshot merupakan nomor urut pendaftaran screenshot ke dalam sistem.

1.     Nama File        : Pengguna

Media            : Hardisk

Isi            : Data mengenai pengguna

Organisasi        : Sequensial

Primary Key        : -

Panjang Record    : 34 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.6 Struktur basis data pengguna game

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_pengguna	Char	4	Kode pengguna
2	email	VarChar	30	Email pengguna

Rancangan Kode :

·         Format untuk kode pengguna adalah 9999

·         Dimana kode pengguna merupakan nomor urut pendaftaran screenshot ke dalam sistem.

1.     Nama File        : Unduh

Media            : Hardisk

Isi            : Data mengenai proses unduh yang dilakukan

Organisasi        : Sequensial

Primary Key        : -

Panjang Record    : 20 byte

Struktur         : Lihat tabel di bawah ini

Tabel 4.7 Struktur basis data unduh

No.	Nama Atribut	Jenis	Panjang	Keterangan
1	Kd_unduh	Char	4	Kode pengguna
2	Kd_pengguna	Char	4	Kode pengguna
3	Kd_game	Char	4	Kode game
4	Tanggal	Date	8	Tanggal unduh