BAB 2 LANDASAN TEORI
2.1 Teori Umum Dalam penyusunan skripsi ini memiliki beberapa teori-teori umum yang digunakan sebagai landasan.Berikut ini adalah beberapa teori-teori yang ada.
2.1.1
Pengertian Sistem Menurut Connollly dan Begg (2005, p285), sistem adalah jangkauan dan batasan dari sebuah sistem basis data termasuk pandangan umum dari user, user itu sendiri dan area aplikasi. 1. Data Menurut Connoly (2010:70), Data merupakan bagian terpenting dari komponen suatu database.Connolly mengamati bahwa data bertindak sebagai jembatan antara komponen mesin dan komponen manusia.Database berisi kedua data operasional dan metadata, "Data tentang data."Struktur database disebut skema. 2. Informasi Menurut Turban (2008:5), informasi mengacu pada data yang telah terorganisir sehingga informasi tersebut memiliki makna dan nilai kepada penerima informasi. 3. Sistem Menurut Indrajani (2011,p48) beberapa pengertian sistem , yaitu : Sekumpulan elemen yang saling berhubungan atau berinteraksi sehingga membentuk satu persatuan , Sekelompok komponen yang saling berhubungan dan bekerjasama untuk mencapai satu tujuan yang sama dengan menerima input dan menghasilkan output dalam proses transformasi yang teratur.
7
8 4. Sistem Informasi Menurut Satzinger (2005:7), Sistem Informasi adalah sekumpulan komponen terkait yang mengumpulkan, memproses, menyimpan, dan menyediakan hasil (output) dari informasi yang dibutuhkan untuk menyelesaikan tugas bisnis. Menurut C.J Date (2006: p9), Basis Data terdiri dari beberapa kumpulan dari data tetap yang digunakan oleh sistem aplikasi untuk diberikan kepada perusahaan. Dari kutipan di atas, dapat disimpulkan bahwa basis data adalah sekumpulan data yang saling berhubungan dan dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi. 5. Database Menurut Connolly dan Begg ( 2010, p65), basis data adalah kumpulan data yang berelasi secara logika dan sebuah deskripsi dari data tersebut dan dirancang untuk memenuhi kebutuhan informasi organisasi.
2.1.2
Dabatabase Management System (DBMS)
2.1.2.1 Pengertian Database Management System (DBMS) Menurut Connolly dan Begg (2010, p66) Database Management System (DBMS) adalah sebuah perangkat lunak (software) yang dapat membantu user untuk mendefinisikan, membuat, memelihara dan mengontrol akses ke dalam suatu basis data. Menurut Connolly dan Begg (2010, p66)
DMBS
menyediakan fasilitas berikut : 1. User dapat mendefinisikan basis data, biasanya melalui sebuah Database Definition Language (DDL), DDL dapat memberitahukan user tipe dan struktur data dan kendala dari data yang disimpan dalam basis data. 2. User dapat menambah, mengubah, menghapus, dan mengambil / menemukan data dari basis data, biasanya
9 melalui Data Manipulation Language (DML).
Dengan
adanya pusat penyimpanan data dan deskripsi , DML dapat melakukan pemeriksaan umum kepada suatu data melalui query language. Query Language yang biasa digunakan adalah Sctructured Query Language (SQL), yang dimana formal digunakan dan secara de facto menjadi standar query language pada relational DBMS.
3. DBMS juga dapat mengontrol akses ke dalam basis data. Untuk contoh, DMBS dapat menyajikan. Security system, untuk mencegah user yang tidak memliki wewenang untuk mengakses file - file atau data yang bukan merupakan haknya. Integrity system, untuk memelihara konsistensi data yang disimpan. Concurrency control system, untuk memberikan shared akses untuk basis data. Recovery control system, untuk memperbaiki basis datamenjadi konsisten state sebelumnya karena adanya kesalahan sebuah hardware atau software. User accessible catalog, berisi deskripsi dari data dalam basis data.
2.1.2.2 Komponen DBMS Menurut Connolly dan Begg (2010, p68-71) komponen DBMS terbagi lima yaitu : 1
Hardware (perangkatkeras) Dalam menjalankan aplikasi dan DBMS diperlukan
perangkat keras.Perangkat keras yang dibutuhkan dapat berupa single personal computer, single mainframe, dan computer jaringan berupa server.
10 2
Software (perangkat lunak) Komponen perangkat lunak meliputi DBMS software dan
program aplikasi beserta Sistem Operasi(OS), termasuk perangkat lunak tentang jaringan bila DBMS digunakan dalam jaringan seperti LAN. 3
Data Data merupakan komponen utama terpenting dari DBMS
khususnya sudut pandang dariend user mengenai data. Data berperan sebagai jembatan penghubung antara komponen mesin dan komponen manusia. 4
Prosedur Prosedur berupa
panduan bvb dan
instruksi
dalam
membuat rancangan dan penggunaan basis data. Pengguna system dan staf yang mengelola dan menggunakan basis data membutuhkan prosedur dalam menjalankan system basis data itu sendiri. Proses didalam basisdata dapat berupa: 1 Login kedalam basis data,penggunaan fasilitas DBMS 2 Cara menjalankan dan memberhentikan DBMS 3 Membuat salinan basis data 4 Memeriksa hardware dan software yang sedang berjalan 5 Mengubah struktur basis data 6 Meningkatkan kinerja atau membuat arsip data pada secondary storage.
5
People Komponen terkahir dari DBMS adalah people atau
manusia. Ada empat tipe people yang berpartisipasi dalam lingkungan DBMS yaitu: 1
Data Administration
Data Administrator (DA) bertanggung jawab untuk mengatur sumber
data
yang
mencakup
perencanaan
basisdata,
11 pengembangan dan pemeliharaan, kebijakan dan prosedur, serta perancangan konseptual dan logical dari basis data. 2
Database Administration
Database Administraton bertanggung jawab terhadap realisasi fisik dari basis data yang mencakup perancangan fisikal dan implementasi,
keamanan
dan
pengaturan
integritas,
pemeliharaan system operasional dan memastikan kepuasan user terhadap performa aplikasi. 3
Desainer database (logical dan fisikal) Ada 2 tipe dari database designer yaitu logical database designer yang berkonsentrasi pada identifikasi data, hubungan antar data, dan batasan dari data yang disimpan dalam basis data.Physical database designer memutuskan
bagaimana perancangan logical dari basis
data yang diubah menjadi basis data fisikal.
4
Programer application Programmer dalam
Aplication
mengimplementasikan
bertanggung program
aplikasi
jawab yang
menyediakan fungsi– fungsi yang dibutuhkan oleh end – user. 5
End users End–users merupakan client dari basis data yang telah dirancang, di implementasikan, dan di pelihara untuk menyediakan kebutuhan informasi.
2.1.2.3 Keuntungan dan Kerugian DBMS Menurut Connolly dan Begg (2010, p77-80) keuntungan dari Database Management System (DBMS) antara lain : 1. Untuk menghindari data yang disimpan berulang-ulang (control of data redudancy) 2. Data menjadi lebih konsisten (data consistency)
12 3. Lebih banyak informasi dari jumlah data yang sama 4. Sharing data 5. Integritas data meningkat 6. Meningkatkan keamanan / security 7. Enforcement of standarts 8. Economy of scale 9. Balance of conflicting requirements 10. Meningkatkan askesibilitas dan respon data 11. Meningkatkan produktifitas 12. Meningkatkan maintance melalui data independence 13. Meningkatkan concurrency 14. Meningkatkan backup dan servis recovery 2.1.3
Arsitektur ANSI-Sparc Three Level Menurut Connolly (2010, p86), ANSI-SPRC merupakan singkatan dari The American National Standards Institute Standard Planning And Recuirment Committee. Arsitektur tersebut dikenal dengan 3 level pendekatan dengan sistem katalog. 3 (tiga) level tersebut adalah : 1 Level Eksternal Eksternal adalah cara pengguna menerima data. Level ini juga mendeskripsikan bagian dari basis data yang relevan dari setiap pengguna.
2 Level Konseptual Menyediakan pemetaan dan ketidak tergantungan yang diinginkan di antara level eksternal dan internal. Level ini mendeskripsiskan data apa yang disimpan ke dalam basis data dan hubungan antar data.
3 Level Internal Internal adalah cara DBMS dan sistem operasi menerima data. Level ini mendeskripsiskan bagaimana data disimpan dalam basis data.
13 Berikut ini adalah gambar yang menjelaskan ketiga level arsitektur tersebut :
Gambar 2.1 Arsitektur ANSI-Sparc (Sumber : Connolly, 2010, p86) Menurut Connolly dan Begg (2010, p80-81) kerugian dari Database Management System (DBMS) antara lain : 1. Complexity 2. Size 3. Cost of DBMS 4. Additional hardware costs 5. cost of conversion 6. Performance 7. Greater impact of a failure
Tujuan dari Tiga Tingkatan Arsitektur Basis Data ANSI-SPARC, yaitu : 1. Setiap pengguna harus dapat mengakses data yang sama , tetapi memiliki pandangan yang berbeda disesuaikan data
14 2. Pengguna tidak harus berurusan dengan penyimpanan database fisik.Mereka harus diizinkan untuk bekerja dengan data itu sendiri , tanpa memperhatikan bagaimana secara fisik disimpan. 3. Database administrator harus mampu mengubah struktur penyimpanan database tanpa mempengaruhi pandangan pengguna. 4. Struktur internal dari database harus tidak terpengaruh oleh perubahan aspek fisik penyimpanan : Sebagai contoh : migrasi atau perpindahan ke disk baru. 5. Database administrator harus mampu mengubah struktur konseptual atau global database tanpa mempengaruhi pengguna : Ini harus mungkin tetap mempertahankan pandangan pengguna individu yang diinginkan.
2.1.4
Database Language Menurut
Connolly
dan
Begg
(2010,
p91-93)
sebuah
sublanguage terdiri dari 2 bagian yaitu:
2.1.4.1 Data Definition Language (DDL) Menurut Connolly dan Begg (,p92) DDL adalah sebuah bahasa
yang
mengizinkan
DBA
atau
user
untuk
mendeskripsikan dan memberi nama suatu entity, attribute, dan relationship yang dibutuhkan untuk aplikasi, bersama dengan associated integrity dan security constraints.
2.1.4.2 Data Manipulation Language (DML) Menurut Connolly dan Begg (,p92) DML adalah sebuah bahasa yang menyediakan himpunan dari operasi untuk mendukung operasi manipulasi basis data pada data yang ada di basis data. Terdapat 2 tipe DML yaitu : Procedural DML : sebuah bahasa yang mengizinkan user untuk memberitahukan sistem
data apa yang dibutuhkan
dan cara untuk mendapatkan data tersebut
15 Nonprocedural DML : sebuah bahasa yang mengizinkan user untuk menyatakan data apa yang dibutuhkan daripada bagaimana cara untuk mendapatkannya
2.1.4.3 Data Flow Diagram (DFD) Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi. DFD ini sering disebut juga dengan nama Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model fungsi. Menurut Yourdon (2011), data flow diagrams merupakan diagram yang mengilustrasikan bagaimana diproses oleh system dalam hal input dan output.
Gambar 2.2 Notasi Data Flow Diagram
2.1.4.4 DFD Level
16 DFD dapat digambarkan dalamDiagramContext dan Level n. Huruf n dapat menggambarkan level dan proses di setiap lingkaran. DiagramContext DiagramLevel n −DFD Logis −DFD Fisik
2.1.4.5 Context Diagram (CD) Jenis
pertama
Context
Diagram,
adalahdata
flow
diagramtingkat atas (DFD Top Level), yaitu diagram yang paling tidak detail, dari sebuah sisteminformasi yang menggambarkan aliran-aliran data ke dalam dan ke luar sistemdan ke dalam dan ke luar entitas-entitas eksternal.(CDmenggambarkansistemdalamsatu lingkaran dan hubungan dengan entitas luar. Lingkaran tersebut menggambarkan keseluruhan proses dalam sistem). Beberapa hal yang harus diperhatikan dalam menggambar CD; Terminologi sistem: Batas Sistem adalah batas antara “daerah kepentingan sistem”. Lingkungan Sistem adalahsegala sesuatu yang berhubungan atau mempengaruhi sistemtersebut. Interfaceadalahaliranyangmenghubungkansebuahsistemde nganlinkungan sistemtersebut.
2.1.4.6 Diagram Leveln / Data FlowDiagram Levelled Dalamdiagramn DFD dapat digunakan untuk menggambarkan diagramfisik
maupun
diagramdiagram
logis.
Dimana
DiagramLeveln merupakanhasil pengembangan dari Context Diagramke dalamkomponen yang lebih detail tersebut disebut dengan top-down partitioning. Jika kita melakukan pengembangan dengan benar, kita akan mendapatkan DFD-DFD yang seimbang. Beberapa hal yang harus diperhatikandalammembuatDFDialah: Pemberian Nomor pada diagramlevel n dengan ketentuan
17 sebagai berikut: Setiap penurunan ke level yang lebih rendah harus mampu
merepresentasikanprosestersebutdalam
sepesifikasiprosesyangjelas.
Sehingga
seandainyabelumcukupjelas makaseharusnyaditurunkanke level yang lebih rendah. Setiap penurunan harus dilakukan hanya jika perlu. Tidak semua bagian dari sistemharus diturunkan dengan
jumlah
level
yangsamakarenayangkompleksbisa sajaditurunkan,danyangsederhana mungkin
tidak
perlu diturunkan. Selain itu, karena tidak semua proses
dalamlevel
yang
sama
punya
derajat
kompleksitas yang sama juga. Konfirmasikan
DFD
yang
telah
dibuat
pada
pemakai dengan cara top- down. Aliran data yang masuk dan keluar pada suatu proses di level n harus berhubungan dengan aliran data yang masuk dan keluar pada level n+1. Dimana level n+1 tersebut mendefinisikan sub-proses pada level n tersebut. Penyimpananyangmunculpadalevelnharusdidefinisikan kembalipada level n+1, sedangkan penyimpanan yang muncul pada level n tidak harus muncul pada level n-1 karena penyimpanan tersebut bersifat lokal. Ketika
mulai
menurunkan
DFD
dari
level
tertinggi,cobalah untuk mengidentifikasi external events dimana system harus memberikan respon. Externaleventsdalam haliniberartisuatukejadianyangberkaitandengan pengolahandatadiluarsistem,dan menyebabkansistem kitamemberikan respon. Jangan menghubungkan langsung antara satu penyimpanan dengan penyimpanan lainnya (harus melalui proses).
18 Jangan
menghubungkan
langsung
dengan
tempat
penyimpanan data dengan entitas eksternal / terminator (harus melalui proses), atau sebaliknya. Janganmembuatsuatuprosesmenerimainput tetapi tidak pernah mengeluarkan output yang disebut denganistilah “black hole”. Janganmembuatsuatutempatpenyimpanan
menerimainput
tetapi tidak pernah digunakan untuk proses. Janganmembuatsuatuhasilprosesyanglengkapdengandatayangt erbatas yang disebut dengan istilah “magic process”. Jikaterdapatterminatoryangmempunyai banyak masukan dan keluaran, diperbolehkan satu
untuk digambarkan lebih dari
sehingga
mencegah
penggambaranyangterlalurumit,dengan memberikan tanda asterik(*)atau garis silang ( #
), begitu dengan bentuk
penyimpanan. Aliran data ke proses dan keluar sebagai output keterangan aliran data berbeda.
2.1.4.7 DFD Fisik DFD
Fisik
adalahrepresentasigrafikdarisebuahsistem
yangmenunjukanentitas-entitas
internaldaneksternaldarisistem
tersebut,danaliran-alirandatakedalamdan entitastersebut.
keluardarientitas-
Entitas-entitasinternaladalahpersonel,tempat
(sebuahbagian),ataumesin(misalnya,sebuahkomputer)dalam sistemtersebut
yangmentransformasikandata.Maka
DFDfisiktidakmenunjukkanapayang dilakukan,tetapimenunjukkan dimana,bagaimana,danolehsiapaproses-proses
dalamsebuah
sistemdilakukan. Perludiperhatikandidalam memberikanketerangandilingkaranlingkaran
(simbolproses)danaliran-
alirandata(simbolalirandata)dalam label/keterangan
dari
DFDfisik
menggunakan
katabendauntukmenunjukanbagaimana
sistemmentransmisikandataantaralingkaran-lingkaran tersebut.
19
2.1.4.8 DFD Logis DFDLogisadalahrepresentasigrafikdarisebuahsistem yangmenunjukkan
proses-prosesdalamsistemtersebutdanaliran-
alirandatakedalamdankeluar Kitamenggunakan
DFD
dari
proses-proses
logis
untuk
tersebut. membuat
dokumentasisebuahsistem informasikarenaDFDlogisdapatmewakililogika tersebut,yaituapayangdilakukanolehsistem tersebut,tanpaperlumenspesifikasi dimana, bagaimana, dan oleh siapa proses-proses dalamsistem tersebut dilakukan. Keuntungan dari DFD logis dibandingkan dengan DFD fisik adalah dapat memusatkan perhatian pada fungsi-funsi yang dilakukan sistem. 2.1.5
Database System Development Lifecycle Menurut Connolly dan Begg (2010, p313-315) sebagai sebuah sistem basis data menjadi komponen yang penting untuk sistem informasi organisasi yang besar, basis data system
20 development lifecycle menjadi asosiasi dari dengan lifecycle dari sistem informasi. Tahapan dari basis data system lifecyle akan di gambarkan pada gambar dibawah :
Gambar 2.3 Basis Data System Development Lifecycle ( Sumber : Connolly dan Begg, 2010, p314) Kegiatanutama
yang
berhubungan
dengansetiap
tahapdatabaselifecyclepengembangan sistem. 1. Perencanaan Basis Data(Database planning) Merencanakan bagaimana tahapan dari lifecycle dapat di relalisasi dengan cara paling efektif dan efisien. 2. Definisi sistem (System definition) Menspesifikasikan cakupan dan batasan dari sistem basis data, termasuk tampilan user, user, dan area aplikasi. 3. Pengumpulan dan analisis kebutuhan (Requirements collection and analysis) Mengumpulkan dan menganalisa kebutuhan untuk sistem basis data yang baru / yang akan dibangun. 4. Perancangan basis data (Database design) Perancangan basis data secara konseptual, logikal dan fisikal. 5. Pemilihan DMBS (DBMS selection (optional)) Memiliki DBMS yang sesuai untuk sistem basis data. 6. Merancang Conceptual Database Design Perancangan database konseptual dimulai denganmengidentifikasikan tipe– tipe entity, mengidentifikasikan tipe – tipe hubungan atau relationship, mengidentifikasikan atribut dan domain atribut. 7. Merancang Logical Database Design Perancangan database logikal terdiri dari validasi model dengan normalisasi, membuat rancangan logical. 8. Merancang Physical Databse Design Menerjemahkan rancangan logikal ke dalam database.
21 9. Prototyping (Prototyping (optional)) Membangun workingmodel dari sistem basis data, yang dimana mengizinkan designer - designer atau user - user untuk menvisualisasi dan mengevaluasi bagaimana tampilan akhir dan fungsinya. 10. Implementasi (Implementation) Membuat definisi basis data fisikal dan program aplikasi.
11. Konversi data dan loading (Data conversion and loading) Memindahkan data dari sistem lama ke sistem yang baru dan jika mungkin, menkorversi data aplikasi-aplikasi yang sudah ada untuk dijalankan di basis data yang baru. 12. Testing Sistem basis data dilakukan test untuk error dan divalidasi dengan user requirements yang sudah ditentukan. 13. Perawatan Operasional (Operational maintenance) Ketika sistem basis data sudah diimplementasikan secara penuh. sistem harus terus dimonitor dan dijaga. Jika perlu, requirement yang baru dapat ditambahkan ke sistem basis data melalui tahapan pada lifecyle.
2.1.6
Entity Relationship Modeling Menurut Connolly dan Begg (2010, p371) Entity relationship modeling adalah pendekatan top-down untuk peracangan basis data dimulai dengan mengidentifikasi data yang penting yang dipanggil entities
dan
relationships
kemudian
diantara
data
harus
direpresentasikan di dalam model. Berikut beberapa konsep pada entity relationship modeling :
2.1.6.1 Entity Types Menurut Connolly dan Begg (2010, p372-374) Entity types merupakan sebuah grup dari objek yang mempunyai properties yang sama, dimana diidentifikasikan oleh perusahaan dan memiliki keberadaan yang bebas atau tidak tergantung.
22 Entity Occurrence adalah suatu objek dari tipe entitas yang data diidentifikasikan secara unik.Tipe entitas dibedakan menjadi dua yaitu : -
Strong Entity Type : tipe entitas yang keberadaannya tidak bergantung kepada tipe entitas lainnya
-
Weak Entity type : tipe entitas yang keberadaanya bergantung kepada tipe entitas lainnya.
2.1.6.2 Relationship Types Menurut Connolly dan Begg (2010, p374-379) relationship types adalah kumpulan asosiasi antara satu atau lebih tipe entitas. Tiap relationship type diberi sebuah nama untuk mendeskripsikan fungsinya. Relationship Occurrence adalah asosiasi yang diidentifikasi secara unik yang termasuk dalam satu occurrence dari setiap partisipan entity type. Degree of a relationship type adalah banyaknya tipe entitas yang ada atau berpatisipasi dalam suatu relationship. Recursive relationship adalah sebuah relationship type yang dimana tipe entity yang sama berpatisipasi lebih dari sekali dalam beberapa peran yang berbeda.
Nama Relasi
Staff
Memiliki Cabang
23 2.1.6.3 Attributes Menurut Connolly dan Begg (2010, p379-383) attribute adalah type.
sebuahproperty dari sebuah entity atau relationship Contohnya
sebuah
staff
entity
type
nya
dapat
dideskripsikan oleh attribute StaffNo, name, position, dan salary. Attribute domain adalah kumpulan atau himpunan nilai yang diperbolehkan untuk satu attribute atau lebih. Berikut adalah macam - macam tipe atribut :
2.1.6.3.1
Simple and Composite Attributes -
Simple attribute : sebuah attribute composed dari sebuah single komponen dengan sebuah keberadaan independet. Simpleattribute tidak dapat dibagi lagi menjadi bagian yang lebih kecil. Biasanya juga dipanggil dengan atomic attributes.
-
Composite attribute : sebuah attribute composed dari beberapa komponen - komponen, setiap komponen mempunyai keberadaan independen.Contohnya pada address terdiri dari street,city, dan postcode.
2.1.6.3.2
Single Valued and Multi Valued Attributes -
Single valued attribute : sebuah attribute yang mempunyai single value untuk setiap occurrence dari setiap entity type atau attribute yang mempunyai satu nilai untuk setiap kejadian.
-
Multi
valued
attribute
:sebuah
attribute
yang
mempunyai beberapa nilai untuk setiap kejadian. Misalnya entity Branch memiliki beberapa nilai pada attribute telNo .
24 2.1.6.3.3
Derived Attributes Derived
attribute
adalah
sebuah
attribute
yang
mewakili sebuah nilai yang didapat dari nilai dari attribute yang berhubungan atau kumpulan attributes, tidak terlalu penting dalam sebuah entity type yang sama.
2.1.6.4 Keys Berikut adalah beberapa jenis keys, antara lain : -
Candidate key : kumpulan atau himpunan attribute minimal yang secara unik diidentifikasi seiap occurence dri setiap entity type.
-
Primary key :candidate key yang dipilih secara unik untuk mengidentifikasikan setiap
occurence dari sebuah entity
type. -
Composite key :Candidate key yang terdiri dari 2 attribute atau lebih.
Penggunaan key merupakan cara untuk mempertegas identitas atau membedakan sebuah entitas dengan entitas yang lain. Key dapat diartikan sebagai sebuah atribut atau gabungan beberapa atribut yang dapat membedakan sebuah entitas dengan entitas yang lain. 1) Candidate Key, yaitu jumlah minimal atribut-atribut yang dapat mengidentifikasikan setiap kejadian/record secara unik (Connolly dan Begg, 2010, p381). 2) Primary Key, yaitu candidate key yang dipilih untuk mengidentifikasikan setiap kejadian/record dari suatu entitas secara unik (Connolly dan Begg, 2010, p381). 3) Composite Key, yaitu candidate key yang terdiri dari dua atau lebih atribut (Connolly dan Begg, 2010, p382). 4) Alternate Key, yaitu candidate key yang tidak dipilih sebagai primary key(Connolly dan Begg, 2010, p381).
25 5) Foreign Key, yairu sebuah primary key pada sebuah entitas yang digunakan pada entitas lain untuk mengidentifikasi sebuah relationship (Connolly dan Begg, 2010, p381).
2.1.6.5 Structural Constraints Constraints seharusnya harus mencerminkan bagaimana batasan yang ada dalam relationship sebagaimana di "dunia nyata".Contohnya sebuah property untuk disewa harus mempunyai owner dan setiap branch harus mempunyai staff.Tipe utama dari constraint dalam relationship dinamakan multiplicity. Menurut Connolly dan Begg (2010, p385-3) Multiplicity adalah jumlah dari suatu kejadian yang mungkin dari entity type dan dapat dihubungkan dengan kejadian tunggal dari tipe entitas yang terasosiasi melalui relationship. Berikut tiga tipe relationship dengan integrity constraints : 1. One to One (1:1) Relationships Misalnya pada relationship manages, yang dimana setiap relationship mewakili hubungan antara satu kejadian entityStaff dan suatu kejadian entity Branch. Dengan kata lain, seorang staff dapat mengatur nol atau suatu branch dan setiap branch diatur seorang staff.
Gambar 2.4One to One Relationships (Sumber : Connolly dan Begg, 2010, p386)
26 2. One to Many (1:*) Relationships Setiap relationship mewakili hubungan antara satu kejadian entitas Staff dan satu kejadian entitas Staff. Dengaan kata lain, seorang admin dapat mengawasi nol atau lebih properti dan sebuah property diawasi oleh nol atau satu admin.
Gambar 2.5One to Many Relationships (Sumber :Connolly dan Begg, 2010, p388) 3. Many to Many (*:*) Relationships Setiap relationship mewakili hubungan antara satu kejadian entitas
Newspaper
dan
satu
kejadian
entitas
PropertyForRent. Dengan kata lain, satu Newspaper mengiklankan satu atau lebih properti dan satu property diiklankan pada nol atau lebih newspaper.
Gambar
2.6Many
to
:Connolly dan Begg, 2010, p389)
Many
Relationships
(Sumber
27 Alternative ways to represent
Meaning
multiplicity constrains 0..1
Nol atau satu kejadian entity
1..1 (atau 1)
Satu kejadian entity
0..* (atau *)
Nol atau banyak kejadian entity
1..*
Satu atau banyak kejadian entity
5..10
Minimun 5 dan maksimum 10 kejadian entity
0,3,6-8
Nol atau tiga atau senam, tujuh, atau delapan kejadian entity
Tabel 2.2A summary of ways to represent multiplicity constraints (Sumber :Connolly dan Begg, 2010, p391)
2.1.7
Normalisasi Suatu perusahaan memiliki data dalam jumlah yang sangat banyak dan data-data tersebut digolongkan berdasar jenis-jenis tertentu untuk kemudian dianalisis. Namun terkadang data-data tersebut mengalami penumpukan sehingga membuat data susah untuk dianalisis. Menurut Connollydan Begg (2010, p416), normalisasi yaitu suatu teknik yang digunakan untuk menghasilkan sejumlah hubungan
dengan
sifat
yang
diinginkan
dan
diberikan
persyaratan data dari suatu perusahaan. -
Un-normalized Form Menurut Connollydan Begg (2010,
p430), un-normalized
form adalah suatu tabel yang berisi satu atau lebih kelompok yang berulang. -
First Normalized Form (1NF) Menurut
Connollydan
Begg
(2010,
p430-434),
1NF
dilakukan jika persimpangan setiap baris dan kolom hanya mengandung satu nilai. Cara untuk menghilangkan repeating group pada tabel yang tidak normal adalah:
28 1.
Dengan memasukkan data ke kolom yang kosong dari baris yang mengandung data-data yang berulang.
2.
Dengan memasukan data-data yang berulang bersama pada relasi yang terpisah.
-
Second Normalized Form (2NF) Menurut Connollyand Begg (2010, p434-435), 2NF jika suatu hubungan pada 1 NF dan setiap atribut yang bukan primary key fungsional berkaitan pada primary key.
-
Third Normalized Form (3NF) Menurut Connollyand Begg (2010, p435-437), 3NF jika hubungan berada dalam bentuk 1NF dan 2NF lalu tidak ada atribut yang merupakan sebuah primary key yang berkaitan secara kuat dengan primary key.
2.1.8
Metodologi Perancangan Basis Data Ada tiga tahap dalam metodologi perancangan basis data yaitu : 1. Perancangan Conceptual Database Menurut Thomas Connolly dan Carolyn Begg (2010, p470-485) langkah awal dalam perancangan konseptual basis data ini adalah untuk membangun satu atau lebih model data konseptual dari data yang dibutuhkan oleh suatu perusahaan. Konseptual data model terdiri dari tipe entitas, tipe relasi, atribut dan domainnya, primary keys dan alternate keys, dan batasan integrity. Konseptual model data didukung oleh dokumentasi, meliputi ER diagrams, dan kamus data, yang dimana dihasilkan melalui pengembangan model data. Langkah - langkah dalam membuat model data konseptual adalah: 1. Perancangan Conceptual Database Langkah awal dalam perancangan konseptual basis data ini adalah untuk membangun satu atau lebih model data konseptual dari data yang dibutuhkan oleh suatu perusahaan. Konseptual data model terdiri dari tipe entitas, tipe relasi, atribut dan domainnya, primary keys
29 dan alternate keys, dan batasan integrity. Konseptual model data didukung oleh dokumentasi, meliputi ER diagrams, dan kamus data, yang dimana dihasilkan melalui pengembangan model data. Langkah - langkah dalam membuat model data konseptual adalah: a. Mengidentifikasi tipe - tipe entitas Tujuannya adalah untuk mengidentifikasi tipe – tipe entitas yang dibutuhkan. Langkah awal dalam membangun sebuah model data konseptual local adalah mendefinisikan objek – objek utama yang
pengguna
tetarik
dan
sangat
membutuhkannya. Objek – objek ini adalah tipe entitas untuk model.Metode dari mengidentifikasi entitas adalah memeriksa spesifikasi kebutuhan – kebutuhan pengguna.
b. Mengidentifikasi tipe – tipe relasi Tujuannya adalah untuk mengidentifikasi relasi – relasi penting yang terdapat di antara entitas. Relasi didefinisikan menggunakan kata kerja atau frase kata kerja seperti manages, owns, dan associated with. Diperhatikan bahwa harus berhati - hati untuk relasi yang kompleks yang dapat melibatkan lebih dari dua entitas dan relasi rekursif yang melibatkan satu tipe entitas saja. c. Mengidentifikasi dan menghubungkan atribut dengan tipe - tipe entitas atau relasi Tujuannya adalah untuk menghubungkan atribut dengan tipe entitas yang sesuai dan tipe relasi yang sesuai.Pada langkah ini mendefinisikan fakta tipe – tipe tentang entitas dan relasi yang telah dipilih untuk direpresentasikan ke dalam basis data. Dengan cara yang sama untuk mengidentifikasi
30 entitas, lihat nouns atau noun phrases di dalam spesifikasi kebutuhan pengguna. d. Menentukan domain dari atribut Tujuannya adalah untuk menentukan domain untuk atribut – atribut di dalam local model data konseptual. Domain adalah sebuah penampung nilai dari satu atau lebih atribut yang mengambil nilainya. e. Menentukkan atribut – atribut candidate, primary, dan alternate key Tujuannya
adalah
untuk
mengidentifikasi
sebuah candidate keys untuk setiap tipe entitas dan, jika ada lebih dari satu candidate key¸ untuk memilih satu harus menjadi primary key dan lainnya menjadi alternate keys. Candidate key adalah sekumpulan atribut dari sebuah entitas yang memiliki nilai unik untuk entitas tersebut. Mungkin saja mengidentifikasi lebih dari satu candidate key, jika demikian harus memilih satu yang harus menjadi primary key dan candidate key sisanya dipanggil dengan alternate keys. Panduan dalam memilih sebuah primary key dari sekitar candidate keys adalah: 1. Candidate key dengan jumlah atribut yang sedikit. 2. Candidate key yang memungkinkan nilainya jarang sekali berubah 3. Candidate key dengan karakter paling sedikit. 4. Candidate key dengan jumlah paling sedikit dari nilai maksimumnya. 5. Candidate key yang paling gampang untuk digunakan dari sudut pandang pengguna. f. Pertimbangkan penggunaan peningkatan konsep model (optional step) Tujunannya yaitu untuk mempertimbangkan penggunaaan peningkatan konsep modeling, seperti
31 specialization atau generalization, aggregration, dan composition. g. Pengecekan model untuk redundancy Tujuannya yaitu untuk mengecek apakah ada redundancy pada model.Pada langkah ini, local konseptual data model diperiksa dengan tujuan yang spesifik yaitu apakah ada redundancy dan penghapusan yang muncul. Tiga langkah untuk melakukannya yaitu: 1. Memeriksa kembali relasi one to one (1:1) 2. Menghilangkan relasi yang redundant 3. Mempertimbangkan dimensi waktu. h. Memvalidasi model konseptual terhadap transaksi pengguna Tujuannya yaitu untuk memastikan bahwa model
konseptual
mendukung
permintaan
permintaan dari transaksi. Memeriksa dua pendekatan kemungkinan untuk memastikan bahwa model konseptual mendukung permintaan transaksi yaitu: 1. Mendeskripsikan transaksi mengecek semua informasi termasuk entitas, relasi dan atribut – atributnya yang dibutuhkan oleh setiap transaksi yang disediakan model, dengan
mendokumentasikan
deskripsi
dari
setiap permintaan transaksi. 2. Menggunakan alur transaksi memvalidasi model data terhadap permintaan – permintaan transaksi yang meliputi diagram yang merepresentasikan alur yang di ambil oleh setiap transaksi secara langsung pada ER diagram.
–
32 i.
Melihat kembali data model konseptual dengan pengguna. Tujuannya yaitu untuk melihat kembali model data konseptual dengan pengguna untuk memastikan bahwa mereka mempertimbangkannya untuk benar – benar direpresentasikan data – data yang dibutuhkan oleh perusahaan.
2. Perancangan Logical Database Menurut Thomas Connolly dan Carolyn Begg (2010, p490-518) perancangan basis data logikal ini adalah untuk menerjemahkan model data konseptual ke dalam bentuk model data logikal kemudian memvalidasi model ini untuk mengecek bahwa secara struktural benar dan dapat didukung permintaan transaksi. Langkah – langkah dalam merancang basis data logikal adalah: a. Menurunkan relasi untuk model data logikal Tujuannya adalah untuk membuat relasi untuk model data logikal untuk merepresentasikan entitas, relasi, dan atribut yang telah di identifikasi. Mendeskripsikan bagaimana relasi di turunkan berdasarkan struktur yang mungkin terdapat pada model data konseptual yaitu: 1. Strong entity types Untuk setiap entitas kuat pada model data, membuat sebuah relasi yang meliputi semua atribut yang sederhana dari entitas tersebut. 2. Weak entity types Untuk setiap entitas lemah pada model data, membuat sebuah relasi yang meliputi semua atribut yang sederhana dari entitas tersebut.Primary key dari entitas lemah ini adalah sebagian atau sepenuhnya diturunkan dari setiap pemilik entitas lalu identifikasi primary key
33 dari sebuah entitas lemah tidak dapat dibentuk sampai semua relasi dengan pemilik entitas telah dipetakan. 3. One to many binary relationship Untuk setiap relasi one to many, entitas yang berada pada “one side” dari relasi ditunjuk sebagai entitas orang tua dan entitas yang berada pada “many side” ditunjuk sebagai entitas anak. 4. One to one binary relationship Dalam membuat relasi untuk merepresentasikan sebuah relasi one to one sedikit lebih kompleks secara kardinaliti
tidak
dapat
digunakan
untuk
mengidentifikasi entitas orang tua dan anak pada sebuah relasi. 5. One to one recursive relationship Untuk relasi one to one recursive sama seperti dengan relasi one to one yaitu tidak dapat digunakan untuk mengidentifikasi entitas orang tua dan anak. Tetapi, dalam kasus spesial ini, entitas pada kedua sisi relasi adalah sama. 6. Superclass/subclass relationship Untuk setiap relasi superclass/subclass di dalam model data konseptual, mengidentifikasikan entitas superclass sebagai entitas orang tua dan entitas subclass sebagai entitas anak. 7. Many to many binary relationship Untuk setiap relasi many to many membuat sebuah relasi untuk merepresentasikan relasi dan meliputi atribut apa saja yang merupakan bagian dari relasi. Atribut yang berupa primary key dari entitas yang berpartisipasi dalam hubungan ke dalam relasi yang baru dianggap sebagai foreign key. Salah satu dari kedua foreign key ini akan berupa primary key dari relasi yang baru, dan memungkinkan akan bergabung dengan satu atau lebih atribut.
34 8. Complex relationship Untuk setiap relasi yang kompleks, membuat sebuah relasi untuk merepresentasikan relasi dan meliputi atribut apa saja yang merupakan bagian dari relasi. Atribut yang berupa primary key dari entitas yang ikut dalam hubungan ke relasi baru dianggap sebagai foreign key. Foreign key yang merepresentasikan many dalam hubungan, secara umum juga akanberperan sebagai primary key dari relasi baru dan memungkinkan akan bergabung dengan atribut lainnya. 9. Multi valued attributes Untuk setiap atribut multi valued didalam sebuah entitas,
membuat
sebuah
relasi
baru
untuk
merepresentasikan atribut multi valued dan meliputi primary key dari sebuah entitas di dalam sebuah relasi baru, untuk bertindak sebagai foreign key. Kecuali kalau atribut multi valued itu sendiri sebuah alternate key dari sebuah entitas, primary key dari relasi baru merupakan gabungan dari atribut multi valued dan primary key dari entitas.
b. Melakukan validasi relasi menggunakan normalisasi Tujuannya adalah untuk mengvalidasi relasi di dalam model data logikal menggunakan normalisasi.Pada langkah ini divalidasikan sekelompok atribut pada setiap relasi menggunakan aturan – aturan dari normalisasi.Tujuan dari normalisasi ini adalah untuk memastikan bahwa relasi mempunyai minimal dan juga angka cukup dari atribut yang perlu untuk mendukung kebutuhan dari perusahaan.
35 c. Melakukan validasi relasi terhadap transaksi pengguna Tujuannya adalah untuk memastikan bahwa relasi pada data model logikal mendukung transaksi – transaksi yang dibutuhkan. d. Mengecek batasan integritas Tujuannya
adalah
untuk
mengecek
batasan
integritas yang direpresentasikan di dalam model data logical.Batasan integritas adalah batasan yang diharapakan untuk tentukan untuk melindungi basis data dari ketidak sempurnaan, ketidak akuratan, atau ketidak konsistenan. Pada tahap ini dipertimbangkan hanya dengan rancangan level tinggi, menspesifikasikan apa batasan integritas yang dibutuhkan, terlepas bagaimana ini mungkin dicapai. Beberapa pertimbangan tipe – tipe dari batasan integritas adalah: 1. Data yang diperlukkan 2. Batasan domain atribut 3. Multiplicity 4. Entity integrity 5. Referential integrity 6. General contraints
e. Melihat kembali model data logikal bersama pengguna Tujuannya adalah untuk melihat kembali model data logikal bersama pengguna untuk memastikan bahwa mereka mempertimbangkan
model
untuk
benar
–
benar
merepresentasikan kebutuhan data yang dibutuhkan oleh perusahaan. f. Menggabungkan model data logikal ke dalam model yang global (optional step) Tujuannya yaitu untuk menggabungkan local model data logikal menjadi sebuah global logikal data model yang merepresentasikan semua sudut pandang pengguna pada basis data. Tahap ini hanya jika dibutuhkan untuk
36 merancang basis data dengan beberapa sudut pandang pengguna yang sedang di atur menggunakan pandangan pendekatan integritas. g. Mengecek untuk perkembangan di masa depan Untuk menentukan apakah ada perubahan signifikan yang mendatang dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan ini.
3. Perancangan Physical Database Menurut Thomas Connolly dan Carolyn Begg (2010, p523-543) perancangan fisikal basis data adalah proses produksi yang mendeskripsikan implementasi dari basis data pada penyimpanan secondary. Yang menjelaskan relasi dasar, file perusahaan, dan pengindeksan yang digunakan untuk mencapai akses yang efisien ke data, dan batasan integritas yang terhubung dan pertimbangan keamanan. Langkah – langkah dalam merancang fisikal basis data adalah: 1. Menerjemahkan model data logikal untuk pemilihan DBMS Langkah pertama dalam perancangan fisikal basis data melibatkan terjemahan dari relasi data model logikal menjadi sebuah bentuk yang dapat diimplementasikan ke dalam target relasional DBMS. Tahap – tahapnya meliputi: 1. Merancang relasi dasar. Tujuannya adalah untuk memutuskan bagaimana merepresentasikan relasi dasar diidentifikasi di dalam basis data model logikal di dalam DBMS. Untuk memulai proses perancangan fisikal, pertama harus mengumpulkan dan mengasimilasi informasi mengenai relasi yang dihasilkan selama perancangan basis data logikal. Informasi yang dibutuhkan bisa didapatkan dari kamus data dan menjelaskan definisi dari relasi menggunakan DBLC yaitu Database Design Language.
37 2. Perancangan representasi dari data yang diturunkan Tujuannya adalah untuk memutuskan bagaimana untuk merepresentasikan data turunan apa saja yang sekarang di dalam model data logikal di dalam DBMS. Atribute yang nilainya dapat ditemukan dengan cara memeriksa nilai dari atribut lain dikenal dengan sebutan ”derived” atau “calculated attribute” seperti contoh nomor pegawai di berbagai cabang, total gaji bulanan untuk semua pegawai dan nomor properti yang akan pegawai tangani. Sering, derived attribute tidak muncul di dalam model data logikal tetapi didokumentasikan di dalam kamus data. 3. Perancangan batasan umum Tujuannya yaitu untuk merancang batasan umum untuk pemilihan DBMS. Pengubahan terhadap relasi mungkin dapat dibatasi oleh batasan integritas yang mengatur transaksi – transaksi pada dunia nyata yang akan direpresentasikan oleh perubahan. 2. Perancangan organisasi file dan indeks Tujuannya adalah untuk menentukkan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai kinerja yang dapat diterima, yang dimana cara dari relasi dan tuples akan disimpan pada penyimpanan sekunder. Aktifitas pada tahap ini dibagi menjadi empat bagian yaitu: 1. Menganalisa transaksi Tujuannya adalah untuk mengerti fungsionalitas dari transaksi yang akan berjalan pada basis data dan untuk menganalisa transaksi yang penting. Dalam menganalisa transaksi,
terdapat
beberapa
kriteria
untuk
mengidentifikasi kinerja transaksi seperti: a. Transaksi yang sering berjalan dan akan mempunyai pengaruh yang signifikan terhadap kinerja. b. Transaksi yang kritikal terhadap operasi bisnis
38 c. Waktu selama hari atau minggu ketika akan terbentuk permintaan yang tinggi pada basis data. 2. Memilih organisasi file Tujuannya adalah untuk menentukkan organisasi file yang efisien untuk setiap relasi dasar. Pemilihan organisasi file dapat dikategorikan menjadi beberapa tipe file yaitu: a. Heap b. Hash c. Indexed sequential office access method d. B *Tree e. Clusters 3. Pemilihan indeks Tujuannya adalah untuk menentukkan apakah penambahan indeks akan meningkatkan kinerja dari sistem.
4. Mengestimasi kebutuhan disk space Tujuannya adalah untuk mengestimasi ukuran dari disk space yang akan dibutuhkan oleh basis data. 3. Perancangan tampilan untuk pengguna Tujuannya adalah untuk merancang tampilan pengguna yang telah diidentifikasi selama pengumpulan kebutuhan dan menganalisis tahapan dari database system development lifecycle.Langkah awal dalam metodologi perancangan basis data melibatkan hasil produksi dari model data konseptual untuk tampilan pengguna tunggal atau beberapa gabungan tampilan
pengguna
yang
diidentifikasikan
selama
pengumpulan kebutuhan dan menganalisa tahapan. 4. Perancangan mekanisme pengamanan Tujuannya
adalah
untuk
merancang
mekanisme
keamanan untuk basis data yang dispesifikasikan oleh pengguna selama kebutuhan dan tahapan pengumpulan dari database system development lifecycle.
39 Selama pengumpulan menganalisa
database
system
kebutuhan
dan
development
tahapan lifecycle,
keamanan yang spesifik harus telah didokumentasikan di dalam spesifikasi kebutuhan sistem. Tujuannya adalah untuk memutuskan bagaimana kebutuhan keamanan ini akan direalisasikan. Relasi DBMS menyediakan dua tipe keamanan basis data yaitu : 1. System security System security menutupi akses dan penggunaan dari basis data pada level system, seperti username dan password. 2. Data security Menutupi akses dan penggunaan objek basis data seperti relations dan views dan suatu tindakan yang pengguna dapat lakukan pada objek.
5. Pertimbangkan kembali dengan redundansi yang sudah terkontrol Tujuannya
adalah
untuk
menentukkan
apakah
redundansi di kontrol dengan aturan – aturan normalisasi yang akan meningkatkan kinerja sistem. Salah satu tujuan dasar dari perancangan relasi basis data adalah untuk mengumpulkan atribut bersama di dalam sebuah relasi karena ada functional dependency di antaranya.Hasil dari normalisasi adalah perancangan logikal basis data yang secara struktur konsisten dan mempunyai redundansi yang sedikit. Namun terkadang menormalisasikan sebuah basis data tidak menghasilkan proses yang efisien secara maksimum. Denormalisasi digunakan secara spesifik untuk meningkatkan proses kecepatan atau critical transaksi dengan cara:
40 1. Menggabungkan relasi one to one Memeriksa kembali relasi one to one untuk menentukkan efek dari menggabungkan relasi menjadi satu relasi. 2. Menduplikasi atribute non key di dalam relasi one to many untuk mengurangi penggabungan Dengan tujuan yang tepat untuk mengurangi atau menghapus gabungan dari frequent atau critical queries, pertimbangkan keuntungan yang akan menghasilkan dalam menduplikasi satu atau lebih atribut non key dari relasi parent di dalam relasi child di dalam sebuah relasi one to many. 3. Menduplikasi atribut foreign key di dalam relasi one to many untuk mengurangi penggabungan Dengan tujuan yang tepat untuk mengurangi atau menghapus gabungan dari frequent atau critical queries, pertimbangkan keuntungan yang akan menghasilkan dalam menduplikasi satu atau lebih atribut foreign key di dalam relasi. 4. Menduplikasi atribut di dalam relasi many to many untuk mengurangi penggabungan Selama perancangan logikal basis data, dipetakan setiap relasi many to many menjadi tiga relasi yaitu, dua relasi diturunkan dari entitas asalnya dan relasi baru merepresentasikan relasi antara dua entitas. 5. Memperkenalkan repeating groups Repeating groupstelah di hilangkan dari data model logikal sebagai hasil dari kebutuhan semua entitas di dalam bentuk normal pertama. 6. Membuat tabel extract Memungkinkan ada situasi dimana laporan harus berjalan pada waktu tinggi selama the day.Laporan ini mengakses data turunan dan melakukan penggabungan multi relasi pada relasi dasar yang sama.
41 7. Mempartisi relasi Daripada pendekatan
menggabungkan
relasi
bersama,
alternatif yang mengalamatkan
kunci
masalah dengan mendukung relasi yang sangat besar dan pengindeksan untuk mendekomposkan menjadi angka yang kecil dan lebih dapat diatur dinamakan partitions. 6. Memonitori dan menyesuaikan sistem operasional Tujuannya adalah untuk melakukan pengawasan sistem operasional dan meningkatkan kinerja dari sistem untuk membetulkan pemutusan perancangan yang tidak pantas atau mencerminkan perubahan kebutuhan.
2.2 Teori Khusus Teori-teori yang akan dibahas adalah penjualan, pembelian, persedian. 2.2.1
Penjualan Menurut Mulyadi (2008:160) Penjualan
adalah “Suatu
kegiantan yang terdiri dari transaksi penjualan barang dan jasa, secara kredit maupun tunai”. Sedangkan Menurut Soemarso .S.R, (2009 : 160) Penjualan adalah “Jumlah yang dibebankan kepada pembeli untuk barang dagang yang diserahkan merupakan pendapatan perusahaan
yang bersangkutan”. Bersadarkan teori
Menurut Mulyadi (2008:160) dan Soemarso .S.R, (2009 : 160) dapat disimpulkan bahwa Penjualan adalah suatu usaha yang terpadu untuk mengembangkan rencana-rencana strategis yang diarahkan pada usaha permuasan kebutuhan dan keinginan pembeli, guna mendapatkan penjualan yang menghasilkan laba. Penjualan merupakan sumber hidup suatu perusahaan, karena dari penjualan dapat diperoleh laba serta suatu usaha memikat konsumen yang diusahakan untuk mengetahui daya tarik mereka sehingga dapat mengetahui hasil produk yang dihasilkan.
42 2.2.2
Pembelian Menurut
Sofjan
Assauri
(2008,p.223)
Pembelian
merupakan salah satu fungsi yang penting dalam berhasilnya operasi suatu perusahaan. Fungsi ini dibebani tanggung jawab untuk mendapatkan kuantitas dan kualitas bahan-bahan yang tersedia pada waktu dibutuhkan dengan harga yang sesuai dengan harga yang berlaku. Pengawasan perlu dilakukan terhadap pelaksanaan fungsi ini, karena pembelian menyangkut investasi dana dalam persediaan dan kelancaran arus bahan ke dalam pabrik.
Menurut Mulyadi (2007,p.711) aktivitas dalam proses pembelian barang adalah: 1. Permintaan pembelian 2. Pemilihan pemasok 3. Penempatan order pembelian 4. Penerimaan barang, dan 5. Pencatatan transaksi pembelian Permintaan pembelian adalah contoh suatu aktivitas yang merupakan satuan pekerjaan yang ditujukan untuk memicu bagian pembelian melakukan pengadaan barang sesuai dengan spesifikasi dan
jadwal
sebagaimana
barang.Penerimaan
barang
yang adalah
dibutuhkan contoh
oleh
aktivitas
pemakai tentang
penerimaan kiriman dari pemasok sebagai akibat adanya order pembelian yang dibuat oleh bagian pembelian. Bersadarkan teori Menurut Mulyadi (2007,p.711) dan Sofjan Assauri (2008,p.223) dapat disimpulkan bahwa pembelian merupakan pengelolaan masukan ke dalam proses produksi organisasi.
2.2.3
Persediaan Menurut Muhammand dkk (2010:97) Persediaan adalah Aktiva yang tersedia untuk dijual dalam kegiatan usaha normal, dalam proses produksi dan dalam perjalanan, atau dalam bentuk
43 bahan atau perlengkapan (supplies) untuk digunakan dalam proses produksi dan pembelian jasa. Menurut Mulya, (2010:214) Persediaan adalah aktiva yang tersedia
untuk
di
jual
dalam
kegiatan
usaha
normal
perusahaan,aktiava dalam proses produksi dan atau dalam perjalanan atau dalam bentuk bahan atau perlengkapan yang digunakan dalam proses produksi atau paeamberian jasa. Bersadarkan
teori
Menurut
Mulya,
(2010:214)
dan
Muhammand dkk (2010:97) dapat disimpulkan bahwa persediaan adalah barang-barang yang telah selesai diproses oleh perusahaan tetapi masih belum dijual. Perusahaan-perusahaan industri yang beroperasi berdasarkan pesanan mempunyai persediaan barang jadi yang relatif kecil.
2.3 Problem Solving ProblemSolving adalah memberikan pembenaran terhadap pola piker apabila terdapat suatu kesalahan,tidak ada keraguan dalam merespon pengaruh buruk secara cepat. •
Elemen Problem Solving Beberapa elemen harus tersedia apabila menginginkan suatu keberhasilan pemecahan suatu masalah,beberapa elemen antara lain (Mcleod,2001:112). 1. DesireState – adalah apa yang system harus capai. 2. CurrentState – adalah apa yang telah dicapai oleh system pada saat ini.Apabila kedua state awal tersebut berbeda maka terdapat beberapa masalah yang
bersifat
urgent
yang
harus
segera
dipecahkan. 3. SolutionCriterion – adalah untuk mewujudkan keberhasilan pada current state maka kita harus menjaga performa pada desirestate. 4. InternalConstraints – adalah mengambil bentuk dari sumber daya yang terbatas yang ada dalam perusahaan.
44 5. EnvironmentalConstraints – adalah mengambil bentuk tekanan dari berbagai lingkungan elemen yang melarang aliran dari sumber daya ke dalam dan ke luar perusahaan.
45
