RSS

Rancangan Basis Data

27 Jun

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 ada transitive 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 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_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 ada transitive 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

Rancangan Kode :

  • Format untuk kode unduh adalah 9999999
  • Dimana kode unduh merupakan nomor urut proses unduh yang dilakukan di sistem
 
7 Comments

Posted by on June 27, 2011 in Tugas Akhir AWM

 

7 responses to “Rancangan Basis Data

  1. TEPUPUNK

    October 19, 2011 at 10:44 pm

    THX…MANTAP…LAGI BUTUH PENJELASAN..DAPET DSNI….

    GB

     
  2. Yosua Risandy

    December 4, 2012 at 1:04 pm

    Reblogged this on jojoalmostover's Blog and commented:
    e follek

     
  3. Feryanto Sunarli

    November 30, 2013 at 11:09 pm

    terima kasih banyak….🙂

     
  4. kelompok 10

    May 16, 2014 at 8:09 pm

    Pengen tau dong definisi LRS dari buku apa ya? lagi butuh buat Tugas Akhir nih.

     
  5. reza

    October 9, 2014 at 3:13 pm

    Bikim diagramnya pake sofware apa y

     
  6. dina

    May 22, 2016 at 8:18 pm

    thx bro…ini yg saya cari….

     
  7. horse riding boots mens

    July 13, 2016 at 6:17 am

    A safety helmet is part of the critical equipment for a bike
    cyclist; instead it is important for any kind of cruiser whose trip
    does not include the leading hatch to cover the head.

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: