Jumat, 13 Desember 2013

TECHNOPRENEURSHIP PELUANG BISNIS SOFTWARE E-KOPERASI

BAB I
LATAR BELAKANG

1.1.Latar Belakang Bisnis
Pada tahun-tahun terakhir ini banyak sudah ketergantungan terhadap internet dan gatget, salah satu yang mereka hadapi yang terbesar adalah kebutuhan akan informasi. Berkembangnya waktu maka berkembang pula besarnya kebutuhan akan sistem teknologi informasi pada waktu ke waktu agar semua kegiatan dikerjakan dengan cepat, murah dan tepat waktu. Berkembangnya teknologi dengan kebutuhan sekarang sudah berkembang menjadi kebutuhan yang tidak bisa lepas dari kegiatan dan kebutuhan.
Oleh karena itu banyak orang yang ingin menerapkan teknologi secara mudah pada perusahaan atau pun pekerjaan mereka tersebut. Kebutuhan akan teknologi tersebut kami wujud kan dengan melayani orang-orang yang ingin memudahkan pekerjaan mereka.
Dengan tersebarnya usaha koperasi di provensi banten maka peluang bisnis aplikasi koperasi (e-koperasi) peluangnya sangat besar dan tersebar ke semua pelosok, menurut data dari pemerintah provensi saat memperingati hari koperasi jumlah nya mencapai lebih dari 5950 unit koperasi dengan jumlah anggota 928.873. sumber : http://ratutatuchasanah.com/hut-koperasi-ke-66-tingkat-provinsi-banten-dan-kota-cilegon/. Menurut survey dari team kami ternyata mereka masih kesulitan untuk mengolah data dan informasi yang mendesak untuk mengolah usaha mereka.

1.2.Identifikasi Peluang Bisnis
Dari latar belakang diatas maka kami simpulkan peluang bisnis software dengan pembuatan aplikasi e-koperasi sangat dibutuhan di Provensi Banten dengan alasan kami menawarkan produk berupa aplikasi e-koperasi adalah karena belum banyak nya orang yang melayani jasa pembutan software ini. Selain itu juga kami ingin mengenalkan betapa mudahnya mengurusi sebuah perusahaan koperasi dengan menggunakan aplikasi e-koperasi yang tidak  memakan ruang dan biaya yang banyak.

1.3.Penjelasan Produk
Aplikasi yang kami produksi adalah Aplikasi yang kami beri nama e-koperasi berbasis webbased dimana aplikasi tersebut kami akan bagun dengan sistem cold computing (computer awan) yang tersimpan di server kami untuk memudahkan pengolahan data dan informasi yang terpusat agar biaya yang di tanggung oleh konsumen lebih muruh dan efektif.
Dengan mengunkan aplikasi kami maka resource yang di gunakan oleh pengguna tidak memberatkan mereka, cukup mereka registrasi ke kami maka aplikasi siap di pakai oleh mereka.

1.4.Tujuan
a)                  Tujuan Umum
(1)          Mendapatkan keuntungan dari penjualan software.
(2)          Membuka lapangan kerja bagi mereka yag mempunyai potensi
b)                  Tujuan Khusus
Memberikan pelayanan dan solusi bagi sebuah perusahaan yang mengalami kesulitan dalam mengelola data base perusahaan mereka.

1.5.Potensi Bisnis
Peluang bisnis ini cukup menjanjikan karena belum banyaknya orang yang menyediakan jasa dalam pengolahan database mereka.






BAB II
ANALISIS SWOT
1.1.Faktor Internal
a)                  Strength ( Kekuatan)
Keunggulan Produk Kami menawarkan produk software yang berbasis webbased sehingga konsumen tidak sulit dan dibebankan terhadap untuk membenahi kebutuhan dari sitsem databasenya sendiri, kami juga mengunakan metode framerowk yang sudah teruji public dari sisi keamanan data dan kecepatan proses data serta kemudahan dalam pemakian aplikasi.
b)                 Weakness (Kelemahan)
Sumber Daya Manusia Belum banyaknya orang yang berminat ingin bekerja pada bidang pengembangan serta jual beli software.

1.2.Faktor Eksternal
a)                  Opportunities ( Peluang )
Banyaknya Konsumen Belum mandirinya sebuah perusahaan dan belum banyaknya orang yang ahli bidang aplikasi  maka mereka mencari cara instan untuk membeli software dari pada membuatnya sendiri.
Sistem Pemasaran Mudahnya mempublikasikan sebuah usaha lewat website atau pun mediasosial pada umumnya.
b)                  Threats ( Ancaman )
Serangan Virus atau pun rusaknya sistem karena software bergantung pada sistem utama yang di buat, apabila terserang virus atau pun instalasi listrik yang tidak memadai akan rentan terjadinya kerusakan pada sitem tersebut

BAB III
PERENCANAAN BISNIS
..............
...........

BAB IV
REAL BUSINESS PLAN
.....
.....
BAB V
IMPLEMENTASI
5.1.       Implentasi
Dalam impletnasi  ini kami  buatkan demo program sbb:
5.1.1. Menu Utama
contoh koperasi

5.1.2. Contoh Transaksi
5.1.3. Contoh Laporan
5.1.4. Contoh Dasboard

yang berminat mempunyai aplikasi Koperasi Link 

oleh fsakti FASANA IT | Tutorial Computer Updated at : 01.01

Kamis, 21 November 2013

Belajar Class Diagram dengan UML

Belajar Class Diagram dengan UML
clasdigram
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.
Sekarang kita akan mempelajari apa itu Class Diagram menurut para ahli:
Class Diagram menggambarkan struktur dan deskripsi class, packagedan objek beserta hubungan
satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain (Romi Satria Wahono dalam tulisan IlmuKomputer.com).

oleh fsakti FASANA IT | Tutorial Computer Updated at : 23.09

Minggu, 10 November 2013

Pengenalan Notasi pada Pemodelan UML

Pengenalan Notasi pada Pemodelan UML
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.
(Romi Satrio Wahono).

Tulisan ini merupakan lanjutan dari link dibawah dan silahkan junjungi :
http://bo-fsakti.blogspot.com/2013/07/uml-unified-modeling-language-pemodelan.html
 
http://skripsisakti.blogspot.com/2013/11/belajar-uml-unified-modeling-lanuage.html

Karna sangat pentingya UML dalam tahapan  Analisa dan design kita perlu mengenal lebih jauh tentang notasi pada pemodelan UML agar nantinya dalam penerapannya memudahkan kita.
 

1. Actor
 
Actor menggambarkan segala pengguna software aplikasi (user). Actor memberikan suatu gambaran jelas tentang apa yang harus dikerjakan software aplikasi. Sebagai contoh sebuah actor dapat memberikan input kedalam dan menerima informasi dari software aplikasi, perlu dicatat bahwa sebuah actor berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Sebuah actor mungkin seorang manusia, satu device, hardware atau sistem informasi lainnya. 

2. Use Case
  
Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai suatu tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case hanya menjelaskan apa yang dilakukan oleh actor dan sistem bukan bagaimana actor dan sistem melakukan kegiatan tersebut.
  • Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor. Actor dapat melihat dan berinisiatif terhadapnya
  • Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case abstrak senantiasa termasuk didalam (include), diperluas dari (extend) atau memperumum (generalize) use case lainnya.
Untuk menggambarkannya dalam use case model biasanya digunakan association relationship yang memiliki stereotype include, extend atau generalization relationship. Hubungan include menggambarkan bahwa suatu use case seluruhnya meliputi fungsionalitas dari use case lainnya. Hubungan extend antar use case berarti bahwa satu use case merupakan tambahan fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu terpenuhi.


 3. Class


 Class merupakan pembentuk utama dari sistem berorientasi obyek, karena class menunjukkan kumpulan obyek yang memiliki atribut dan operasi yang sama. Class digunakan untuk mengimplementasikan interface.
Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang dibangun. Class bisa merepresentasikan baik perangkat lunak maupun perangkat keras, baik konsep maupun benda nyata.

Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling atas untuk nama class, persegi panjang paling bawah untuk operasi, dan persegi panjang ditengah untuk atribut.
Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata benda yang bisa dengan jelas merepresentasikan informasi yang tersimpan didalamnya. Operasi menunjukkan sesuatu yang bisa dilakukan oleh obyek dan menggunakan kata kerja.

4. Interface
 
Interface merupakan kumpulan operasi tanpa implementasi dari suatu class. Implementasi operasi dalam interface dijabarkan oleh operasi didalam class. Oleh karena itu keberadaan interface selalu disertai oleh class yang mengimplementasikan operasinya. Interface ini merupakan salah satu cara mewujudkan prinsip enkapsulasi dalam obyek.

5. Interaction
 Interaction digunakan untuk menunjukkan baik aliran pesan atau informasi antar obyek maupun hubungan antar obyek. Biasanya interaction ini dilengkapi juga dengan teks bernama operation signature yang tersusun dari nama operasi, parameter yang dikirim dan tipe parameter yang dikembalikan

6. Note
Note digunakan untuk memberikan keterangan atau komentar tambahan dari suatu elemen sehingga bisa langsung terlampir dalam model. Note ini bisa disertakan ke semua elemen notasi yang lain.

7. Dependency

Dependency merupakan relasi yang menunjukan bahwa perubahan pada salah satu elemen memberi pengaruh pada elemen lain. Elemen yang ada di bagian tanda panah adalah elemen yang tergantung pada elemen yang ada dibagian tanpa tanda panah.
Terdapat 2 stereotype dari dependency, yaitu include dan extend. Include menunjukkan bahwa suatu bagian dari elemen (yang ada digaris tanpa panah) memicu eksekusi bagian dari elemen lain (yang ada di garis dengan panah). Extend menunjukkan bahwa suatu bagian dari elemen di garis tanpa panah bisa disisipkan kedalam elemen yang ada di garis dengan panah.

8. Association

Association menggambarkan navigasi antar class (navigation), berapa banyak obyek lain yang bisa berhubungan dengan satu obyek (multiplicity antar class) dan apakah suatu class menjadi bagian dari class lainnya (aggregation).
Navigation dilambangkan dengan penambahan tanda panah di akhir garis. Bidirectional navigation menunjukkan bahwa dengan mengetahui salah satu class bisa didapatkan informasi dari class lainnya. Sementara UniDirectional navigation hanya dengan mengetahui class diujung garis association tanpa panah kita bisa mendapatkan informasi dari class di ujung dengan panah, tetapi tidak sebaliknya.
Aggregation mengacu pada hubungan “has-a”, yaitu bahwa suatu class memiliki class lain, misalnya Rumah memiliki class Kamar.

9.  Generalization


Generalization menunjukkan hubungan antara elemen yang lebih umum ke elemen yang lebih spesifik. Dengan generalization, class yang lebih spesifik (subclass) akan menurunkan atribut dan operasi dari class yang lebih umum (superclass) atau “subclass is superclass”. Dengan menggunakan notasi generalization ini, konsep inheritance dari prinsip hirarki dapat dimodelkan.

10. Realization


Realization menunjukkan hubungan bahwa elemen yang ada di bagian tanpa panah akan merealisasikan apa yang dinyatakan oleh elemen yang ada di bagian dengan panah. Misalnya class merealisasikan package, component merealisasikan class atau interface.

demikaian semoga bermanfaat







Informasi lebih lengkap:

oleh fsakti FASANA IT | Tutorial Computer Updated at : 02.06

Kamis, 18 Juli 2013

UML - Unified Modeling Language pemodelan

Pemodelan dengan UML - Unified Modeling Language Pembahasan Lengkap

uml
"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software
components."



Unified Modelling Language (UML) adalah suatu alat untuk memvisualisasikan dan mendokumentasikan hasil analisa dan desain yang berisi sintak dalam memodelkan sistem secara visual (Braun, et. al. 2001).
Juga merupakan satu kumpulan konvensi pemodelan yang digunakan untuk menentukan atau menggambarkan sebuah sistem software yang terkait dengan objek (Whitten, et. al. 2004).


Tujuan Penggunaan UML
  1. Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa.
  2. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
  3. Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
  4. UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram (reserve enginering).
Komponen-komponen UML
Sejauh ini para pakar merasa lebih mudah dalam menganalisa dan mendesain atau memodelkan suatu sistem karena UML memiliki seperangkat aturan dan notasi dalam bentuk grafis yang cukup spesifik (Sugrue J. 2009).
Komponen atau notasi UML diturunkan dari 3 (tiga) notasi yang telah ada sebelumnya yaitu Grady Booch, OOD (Object-Oriented Design), Jim Rumbaugh, OMT (Object Modelling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).
BAGIAN-BAGIAN UML
Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.
a. View
View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram.
Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view,dan deployment view.
b. Use case view
Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya.
View ini digambarkan dalam use case diagramsdan kadang-kadang dengan activity diagrams. Viewini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).
c. Logical view
Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,danrelationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu.
View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).
d. Component view
Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya.
View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).
e. Concurrency view
Membagi sistem ke dalam proses dan prosesor.View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).
f. Deployment view
Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya.
View ini digambarkan dalam deployment diagramsdan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).
g. Diagram
Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :
1. Use Case Diagram
Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use casemerupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.
2Class Diagram
Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.
3. Component Diagram
Component software merupakan bagian fisik dari sebuah system, karena menetap di komputer tidak berada di benak para analis. Komponent merupakan implementasi software dari sebuah atau lebih class. Komponent dapat berupa source code, komponent biner, atau executable component. Sebuah komponent berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view.Sehingga component diagram merepresentasikan dunia riil yaitu component software yang mengandung component, interface dan relationship.
4. Deployment Diagram
Menggambarkan tata letak sebuah system secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes,executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.
5. State Diagram
Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh stateyang berbeda.
6. Sequence Diagram
Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antaraobject, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.
7. Collaboration Diagram
Menggambarkan kolaborasi dinamis sepertisequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan objectdan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakansequencediagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.
8. Activity Diagram
Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use caseatau interaksi.


Perangkat lunak yang mendukung pembuatan diagaram UML
  1. StarUML (http://staruml.sourceforge.net/en/)
StarUML adalah sebuah proyek open source untuk mengembangkan cepat, fleksibel, extensible, featureful, dan bebas-tersedia UML / platform MDA berjalan pada platform Win32.Tujuan dari proyek StarUML adalah untuk membangun sebuah alat pemodelan perangkat lunak dan juga platform yang menarik adalah pengganti alat UML komersial seperti Rational Rose, Bersama dan sebagainya
Acceleo adalah generator kode yang mengubah model menjadi kode. Acceleo mudah digunakan dan menyediakan “dari rak” generator (Jee,. Bersih, Php …) dan template editor untuk Eclipse.
ArgoUML adalah open source UML modeling tool terkemuka dan termasuk dukungan untuk semua diagram UML standar 1,4. Ini berjalan pada setiap platform Java dan tersedia dalam bahasa sepuluh. ArgoUML ditulis seluruhnya di Jawa dan menggunakan Java Kelas Foundation.Hal ini memungkinkan ArgoUML untuk berjalan di hampir semua platform
PROSES MEMBANGUN UML
Langkah-Langkah Penggunaan UML Batasan sistem harus ditentukan terlebih dahulu, tujuannya agar pemakai mengetahui dengan lingkungan mana saja sistem mereka berhubungan, untuk itu setiap komponen actor, (sumber atau tujuan) ini harus diberi nama sesuai dengan lingkungan luar yang mempengaruhi sistem ini.
Berikut ini tahapan penggunaan UML (Dharwiyanti. 2008) :

  1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul dengan menentukan item-item data apa saja yang akan ditempatkan dalam sistem.
  2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
  3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
  4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
  5. Berdasarkan use case diagram, mulailah membuat activity diagram.
  6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
  7. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
  8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodenya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
  9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan classmenjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
  10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
  11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
  12. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu. Lakukan uji modul dan uji integrasi serta perbaiki model berserta code-nya. Model harus selalu sesuai dengan code yang aktual.
  13. Piranti lunak siap dirilis.
Tutorial UML ini semoga bermanfaat, buat kita semua



 Informasi lebih lengkap:

oleh fsakti FASANA IT | Tutorial Computer Updated at : 21.27

Minggu, 30 Juni 2013

Contoh Penerapan Normalisasi - basis data

Contoh Penerapan Normalisasi - basis data

Dalam pembuatan aplikasi Normaliasi sangat penting terutama untuk konsep RDMS agar aplikasi atau saat kita analisa skripsi yang kita buat bisa singkroniasi dan mempercepat proses load data, konseksen.


Pada proses perancangan database dapat dimulai dari dokumen dasar yang dipakai dalam sistem sesuai dengan lingkup sistem yang akan dibuat rancangan databasenya. Berikut ini adalah contoh dokumen mengenai faktur pembelian barang pada PT. FSAKTI.



 















Sehubungan dengan dokumen dasar tersebut, tahapan yang harus dilakukan untuk melakukan normalisasi data adalah sebagai berikut :


1. Bentuk Normal Pertama ( 1 NF )

Bentuklah menjadi bentuk normal pertama dengan memisah-misahkan data pada atribut-atribut yang tepat dan bernilai atomik, juga seluruh record / baris harus lengkap adanya. Bentuk file adalah Flat File. Dengan normal pertama kita dapat membuat satu relasi yang terdiri dari 11 Atribut yaitu:


(No Faktur, Kode Supplier, Nama Supplier, Kode Barang, Nama Barang, Tanggal, Jatuh Tempo,
Quantitas, Harga, Jumlah, Total ). 
  
Sehingga hasil daripada pembentukan normal pertama (1 NF) adalah sebagai berikut ini : Relasi Faktur_Pembelian


Pada normal pertama tersebut masih terjadi banyak kelemahan, terutama pada proses ANOMALI  insert, update dan delete berikut ini :

Inserting / Penyisipan
Kita tidak dapat memasukkan kode dan nama supplier saja tanpa adanya transaksi pembelian, sehingga supplier baru bisa dimasukkan kalau ada transaksi pembelian. 
inserting


 Deleting / Penghapusan
Bila satu record / baris di atas dihapus, misal nomor faktur 779, maka berakibat pada penghapusan data supplier S02 (Hitachi) padahal data tersebut masih diperlukan.

Updating / Pengubahan

Kode dan nama supplier terlihat ditulis berkali-kali, bila nama supplier berubah, maka di setiap baris yang ada harus dirubah, bila tidak menjadi tidak konsisten.


Atribut jumlah (merupakan atribut turunan) seharusnya tidak perlu, karena setiap harga dikali kuantitas akan menghasilkan jumlah, sehingga hasilnya akan menjadi lebih konsisten.


2.  Bentuk Normal Kedua ( 2 NF )
Bentuk normal kedua dengan melakukan dekomposisi tabel diatas menjadi beberapa tabel dan mencari kunci primer dari tiap-tiap tabel tersebut dan atribut kunci haruslah unik.
Melihat permasalahan faktur di atas, maka dapat diambil beberapa kunci kandidat :  ( No Faktur, Kode Supplier, dan Kode Barang ). Kunci kandidat tersebut nantinya bisa menjadi kunci primer pada tabel hasil dekomposisi.
Dengan melihat normal pertama, kita dapat mendekomposisi menjadi tiga tabel berserta kunci primer yang ada yaitu : Relasi/Tabel Supplier (Kode Supplier) , Relasi/Tabel (Kode Barang), dan Faktur (No Faktur). Dengan melihat ketergantungan fungsional atribut-atribut lain terhadap atribut kunci, maka didapatkan 3 (tiga) relasi/tabel sebagai berikut:



normalisasi









Primary key pada relasi/tabel Supplier adalah kode_supplier
Primary key pada relasi/tabel Barang adalah kode_barang
Primary key pada relasi/tabel Faktur adalah no_faktur, sedangkan foreign key nya adalah kode_barang dan kode_supplier.

  

Dengan pemecahan relasi di atas, maka untuk pengujian bentuk normal kesatu (1 NF) yaitu insert, update, dan delete akan terjawab. Kode dan nama supplier baru dapat masuk kapanpun tanpa adanya transaksi pada relasi faktur. Demikian pula untuk proses update dan delete untuk relasi Supplier dan Barang.
Pada bentuk normal kedua tersebut masih terjadi permasalahan yaitu pada relasi/tabel Faktur, yaitu:

Atribut Quantitas pada relasi/tabel Faktur, tidak tergantung pada kunci utama, atribut tersebut bergantung fungsi pada No_faktur + Kode_barang, hal ini dinamakan ketergatungan transitif dan haruslah dipilah menjadi dua tabel. Sedangkan tanggal, jatuh_tempo dan kode_supplier bergantung fungsional pada No_faktur
No_faktur à tanggal,jatuh_tempo,kode_supplier
No_faktur, kode_barang à quantitas


Masih terdapat pengulangan, yaitu setiap kali satu faktur yang terdiri dari 5 macam barang maka  5 kali juga dituliskan no_faktur, tanggal, dan jatuh_tempo. Hal ini harus dipisahkan bila terjadi penggandaan tulisan berulang-ulang.

3. Bentuk Normal Ketiga ( 3 NF )
Bentuk normal ketiga mempunyai syarat, setiap relasi tidak mempunyai atribut yang bergantung transitif, harus bergantung penuh pada kunci utama dan harus memenuhi bentuk normal kedua (2 NF).
Untuk memenuhi bentuk normal ketiga (3 NF), maka pada relasi/tabel faktur harus didekomposisi (dipecah) lagi menjadi dua relasi/tabel yaitu relasi/tabel faktur dan relasi/tabel transaksi_barang, sehingga hasilnya adalah sebagai berikut ini:

nomral3

  
Kamus Data dari masing – masing relasi: 
Supllier  = { Kode Supplier, Nama_Supplier }
Barang  = { Kode Barang, Nama_Barang, Harga }
Faktur    = { No Faktur, Tanggal, Jatuh_Tempo, Kode_Supplier }
Transaksi_Barang = { No_Faktur, Kode_Barang, Quantitas }



4. Diagram Dekomposisi
            Kita dapat membuat diagram dekomposisi yang akan menjelaskan proses / tahapan uji normalisasi dari bentuk normal kesatu (1 NF) sampai normal ketiga (3 NF), seperti tampak pada gambar berikut:


 
diagram
 
4. ERD (Entity Relationship Diagram)
Gambaran hubungan Relationship antar relasi yang terbentuk, adalah seperti terlihat pada gambar berikut ini:
relasi













Pengertian Hubungan (Relasi) antar relasi pada gambar ERD (entity relationship diagram) pada gambar di atas adalah sebagai berikut:


Supplier ke Faktur relasinya adalah one to many, artinya adalah satu supplier mempunyai satu atau banyak faktur. Faktur punya relasi terhadap supplier 


Faktur ke Transaksi_Barang relasinya adalah one to many, artinya adalah satu faktur mempunyai satu atau beberapa transaksi barang (satu faktur terdiri dari satu atau lebih transaksi barang).


Barang ke Transaksi_Barang relasinya adalah one to many, artinya adalah satu barang bisa terjadi satu atau beberapa kali transaksi pembelian barang.
 

Implementasi ERD (entity relationship diagram) 

erd


normal

oleh fsakti FASANA IT | Tutorial Computer Updated at : 02.06

 
Ke bawah Ke ATAS