Bab 6

Sistem Manajemen Basis Data

Tujuan Pembelajaran
Setelah memperlajari bab ini, Anda harus:
► Memahami hirarki dari data.
► Memahami struktur basis data dan bagaimana mereka bekerja.
► Memahami bagaimana menghubungan tabel-tabel bersama di dalam basis data.
► Mengenali perbedaan antara basis data dan sistem manajemen basis data.
► Memahami konsep basis data.
► Memahami dua metode dasar untuk menentukan kebutuhan data.
► Memahami diagram hubungan entitas dan diagram kelas.
► Memahami dasar dari laporan dan formulir.
► Memahami perbedaan dasar dari bahasa pertanyaan terstruktur dan query-by-example.
► Paham mengenai personil penting yang terlibat dengan basis data.
► Memahami keuntungan dan biaya dari sistem manajemen basis data.
Pendahuluan
Sistem manajemen basis data mengatur/mengelola data dengan volume besar yang digunakan
perusahaan di dalam kegiatan transaksi sehari-hari. Data harus diatur/dikelola sehingga manajer dapat
menemukan data spesifik dengan mudah dan cepat untuk pengambilan keputusan. Perusahaan membagi
seluruh koleksi data menjadi sekumpulan tabel-tabel data yang berkaitan. Koleksi data berkaitan yang lebih kecil
tersebut mengurangi redundansi data. Akibatnya, konsistensi dan akurasi data meningkat.
Struktur data perusahaan telah berubah dari tahun ke tahun. Saat ini, kebanyakan perusahaan
menggunakan basis data yang menyesuaikan dengan struktur relasional. Dua alasan penting untuk hal ini
adalah struktur basis data relasional mudah digunakan dan terdapat hubungan implisit antar tabel di dalam
struktur. Kemudahan penggunaan telah memberanikan banyak manajer untuk menjadi pengguna langsung dari
sumber daya basis data.
Sebuah basis data harus didesain dengan hati-hati. Para profesional dalam bidang sistem informasi dan
bisnis bekerja sama untuk menciptakan spesifikasi-spesifikasi basis data. Berbagai pendekatan seperti process-
oriented modeling dan enterprise modeling memungkinkan desain basis data untuk menunjukkan masalah-
masalah yang ada serta memanfaatkan peluang-peluang melalui sinergi antar area bisnis. Berbagai teknik
seperti entity-relationship diagram dan class diagram mengklarifikasi komunikasi di antara spesialis informasi
dan para pengguna sehingga desain basis data memenuhi kebutuhan perusahaan.
Kepentingan basis data yang meningkat sebagai sumber data yang mendukung pembuatan keputusan
membutuhkan manajer untuk belajar lebih mengenai desain dan penggunaan. Formulir (forms) dan laporan
(reports) merupakan metode standar untuk akses tersebut, tetapi pertanyaan (queries) menjadi lebih penting.
Seluruh hal-hal lain menjadi sama, manajer yang dapat paling baik menggunakan langsung sumber daya basis
data, membuat keputusan paling baik untuk perusahaan.
Pada bab ini, kami menyajikan contoh dan konseptualisasi dari basis data. Seperti yang
ditunjukkan/diperlihatkan oleh topik, kami sesekali mengulang sebuah konsep. Maklum dengan kami. Konsep
basis data sangat penting bagi manajer sehingga penjelasan berulang dibenarkan.

ORGANISASI DATA
Komputer pada awalnya digunakan untuk menyelesaikan permasalahan-permasalahan yang membutuhkan
perhitungan numerik yang kompleks dan membosankan. Permasalahan-permasalahan tersebut membutuhkan
sedikit input dan sedikit output. Sekarang, perusahaan-perusahaan membutuhkan input dan output dalam jumlah
yang sangat besar. Perusahaan-perusahaan sering membutuhkan komputer untuk menyelesaikan
permasalahan yang sama, dengan input yang berbeda, berkali-kali. Menghitung tagihan pelanggan setiap kali
penjualan dibuat merupakan proses sederhana yang mungkin diulang berkali-kali.
Perusahaan-perusahaan menyimpan data dalam jumlah besar di dalam sistem informasi komputer
secara sederhana karena mereka melakukan banyak sekalu transaksi bisnis. Banyak sekali data yang ada akan
menjadi tidak berguna untuk pembuatan keputusan bisnis tanpa sebuah cara yang efektif dan efisien untuk
mengelolanya. Untuk menggunakan data dan menghindari kekacauan, konsep “data” harus dipecah/dibagi dan
dikurangi menjadi konsep-konsep yang lebih kecil. Konsep-konsep data yang lebih kecil membangun blok yang
dapat digabungkan untuk mereproduksi data asli/awal dalam bentuk yang terorganisir dan mudah diakses.

Hirarki Data
Data bisnis biasanya diorganisir menjadi sebuah hirarki data fileds yang digabungkan untuk membentuk recirds,
dan records yang digabungkan untuk membentuk files. Data field merupakan unit terkecil dari data; ia
merepresentasikan jumlah terkecil dari data yang akan diperoleh/diambil dari sebuah komputer pada tertentu.
Sebuah contoh dari sebuah data field mungkin adalah sebuah kode untuk sebuah mata kuliah yang Anda ambil.
Record merupakan sebuah koleksi data fields terkait. Pengguna secara logis berpikir bahwa data fields di dalam
sebuah record berkaitan, seperti suatu kode mata kuliah yang akan berkaitan dengan suatu nama mata kuliah.
File merupakan sebuah koleksi dari records yang berkaitan, seperi sebuah file dari seluruh records berisi kode-
kode dan nama mata kuliah.
Files dapat direpresentasikan sebagai tabel; Tabel 6.1 merupakan sebuah contoh file yang dapat kita
sebut COURSE. Records adalah baris-baris di dalam tabel. Nilai-nilai di dalam baris-baris merepresentasikan
nilai dari data fields – “MIS105” dan “Information Systems Literacy” menjadi nilai dari kode dan deskripsi dari
mata kuliah untuk record pertama. Hirarki yang sederhana terdiri dari records yang bergabung menjadi sebuah
file yang menyusun/menetapkan seluruh data penting organisasi yang digunakan dalam pembuatan keputusan
dengan bantuan komputer atau computer-aided decision making.
Sebuah basis data adalah sebuah koleksi files. Definisi umum basis data adalah koleksi dari seluruh
data perusahaan berbasis komputer. Definisi basis data yang lebih terbatas adalah koleksi data yang
dikontrol/dikelola oleh perangkat lunak sistem manajemen basis data. Berdasarkan definisi tersebut, data
perusahaan yang dikontrol dan dikelola oleh suatu sistem manajemen basis data akan dianggap masuk ke
dalam basis data; files komputer pada komputer pribadi manajer akan dianggap di luar basis data. Pada
bahasan ini, kami secara khusus menggunakan definisi umum basis data – yang mana basis data merupakan
koleksi seluruh data berbasis komputer. Tetapi, di dalam bab ini, kami menyelidiki definisi yang terbatas tersebut
– data yang dikontrol oleh perangkat lunak sistem manajemen basis data.

Lembar Kerja (Spreadhseet) sebagai Sebuah Basis data Sederhana

Tabel dengan baris dan kolom dapat direpresentasikan di dalam sebuah spreadsheet. Karena banyak sekali
pengguna tidak asing dengan spreadsheets, ia menjadi cara yang berguna untuk memperkenalkan konsp basis
data.1 Kolom pada spreadsheet merepresentasikan data fields, dan judul kolom memaut nama-nama data field.
Baris pada tabel meliputi nilai-nilai field.
Gambar 6.1 mengilutrasikan sebuah lembar kerja (spreadsheet) Excel yang memuat nilai-nilai dari tabel
COURSE pada Tabel 6.1. Konsep tabel adalah penting, karena struktur basis data yang paling terkenal untuk
organisasi bisnis, relational basis data structure, secara konsep mirip dengan koleksi tabel-tabel yang
berkaitan. Kebanyakan istilah yang digunakan oleh spesialis informasi yang bekerja dalam bidang sistem
manajemen basis data berhubungan dengan istilah yang digunakan untuk menggambarkan tabel, tetapi
beberapa istilah dan konsep tambahan diperlukan.
Area akademis telah ditanggalkan dan diletakkan pada kolom yang terpisah. Mata kuliah untuk area
akademis ditunjukkan sebagai kolom-kolom pada baris yang sama. Kolom untuk kode dan deskripsi mata kuliah
diulang, Tabel 6.2 bukan merupakan sebuah flat file.
Tabel 6.1
 Gambar 6.1
Contoh Spreadhseet
dari Tabel COURSE

Mengulang kolom melanggar persyaratan untuk sebuah flat file. Alasan mengapa sebuah tabel harus
merupakan flat file adalah karena komputer membaca data fields dari sebuah record sesuai urutan. Ketika
urutannya tidak konstan, komputer tidak dapat membaca records dengan benar. Pada baris pertama Tabel 6.2,
komputer akan membaca lima nilai: “MIS,” “105”, Information Systems Literacy”, “315”, dan “Basis data
Management Systems”. Komputer akan diharapkan untuk membaca lima nilai pada record setelahnya: “POM”,
“250”, “Introduction to Operation Mgt”, “MGT”, dan “300”. Tetapi, ada peringatan bahwa komputer telah membuat
kesalahan; ia keliru mengenai kedua nilai pertama dari baris ketiga sebagai nilai keempat dan kelima pada baris
kedua. Sebuah flat file, yang tanpa pengulangan kolom, menyajikan urutan yang konstan dari data fields yang
dibutuhkan manajemen basis data.
Alasan kedua adalah flat file memperkenankan relational basis data structure untuk dinormalisasikan.
Normalisasi adalah sebuah proses formal untuk mengeliminasi data fields yang berlebihan sambil memelihara
kemampuan basis data untuk menambah, memodifikasi, dan menghapus records tanpa menyebabkan
kekeliruan/kesalahan. Normalisasi berada di luar jangkauan pembahasan teks ini, tetapi ia merupakan fokus
utama dari sistem manajemen basis data.

Tabel 6.2
 Tabel 6.3

Kunci Fields
Tabel 6.3 menggambarkan nilai-nilai pada tabel BOOK dan mengilustrasikan konsep dari sebuah kunci. Kunci
dalam sebuah tabel merupakan sebuah field (atau gabungan dari dua atau lebih fields) yang memuat sebuah
nilai yang secara unik mengidentifikasi setiap record di dalam tabel. Hal ini berarti bahwa setiap baris dalam
tabel secara unik teridentifikasi. Seringkali sebuah field tunggal menjadi sebuah kunci untuk sebuah tabel.
Membedakan antara dua atau tiga baris tidak cukup; nilai kunci harus unik untuk seluruh tabel. Jika Anda
dijelaskan bahwa nilai field dari ISBN adalah “X125”, Anda akan tahu bahwa nilai field dari Title adalah “Basis
data Examples.” Field ISBN adalah kunci.
Sekilas mungkin terlihat bahwa nilai dari field Title juga akan mengidentifikasi setiap baris dengan unik.
Tetapi, judul “Busines Management” terjadi dua kali, sehingga komputer tidak dapat menjelaskan apakah nilai
ISBN “P1693” atau “A129” yang harus digunakan. Buku secara tidak sengaja dapat memiliki judul yang sama,
tetapi ISBN selalu unik.
Beberapa tabel mungkin memiliki dua fields yang menjadi kandidat untuk menjadi kunci. Kunci kandidat
merupakan sebuah field yang secara unik mengidentifikasi setiap baris tabel, tetapi tidak dipilih untuk menjadi
kunci. Pada tabel COURSE yang digambarkan pada Tabel 6.1, field Description akan secara unik
mengidentifikasi setiap baris. Tetapi, field Code dipilih untuk menjadi kunci. Seringkali ketika dihadapkan dengan
sebuah pilihan antara dua field yang masing-masing dapat menjadi kunci, field yang lebih kompak/ringkas dipilih;
Nilai field yang lebih panjang (seperti nilai field Description dibandingkan dengan nilai field Code) dihindari
karena nilai field yang lebih panjang menyajikan/membawa resiko kesalahan penulisan nilai kunci field yang
lebih tinggi.
Beberapa tabel memerlukan nilai dari dua atau lebih fields untuk secara unik mengidentifikasi setiap baris
dalam tabel. Sebuah contoh yang mungkin muncul ketika mata kuliah memiliki proyek. Tabel 6.4 menunjukkan
proyek, tetapi catat bahwa tidak ada nilai data field tunggal yang akan secara unik mengidentifikasi setaip baris.
Nilai-nilai pada kolom field Code berulang antar baris. Sama seperti nilai field pada seluruh kolom lainnya. Tetapi,
ketika nilai-nilai pada field Code dan Number dikombinasikan, nilai-nilai kombinasi menjadi unik.
 Tabel 6.4

Tabel-tabel yang Berhubungan

Anda dapat dengan mudah melihat hubungan di antara tabel COURSE dan PROJECT (Tabel 6.1 dan 6.4).
Kedua tabel tersebut berbagi sebuah field yang sama, Code, dan nilai dari field Code menentukan baris dalam
tabel yang mana yang secara logis tergabung. Sebagai contoh, jika Anda ingin tahu mengenai proyek yang
diperlukan untuk mata kuliah berjudul “Information System Literacy”, Anda harus menemukan nilai yang
cocok/sesuai di dalam data field yang dimiliki bersama oleh kedua tabel. Field Code ada di kedua tabel dan
memungkinkan data pada kedua tabel untuk dibawa bersama, atau terkait dengan hal ini, “MIS105” ialah nilai
field Code ketika “Information System Literacy” merupakan nilai field Description. Hal ini terhubung dengan nilai
field Code pada tabel PROJECT yang menunjukkan bahwa mata kuliah “Information System Literacy” memiliki
proyek untuk “Home Page Development” dan “Working with Windows.”
Kadang, tabel-tabel yang awalnya berdiri sendiri sebagai tabel yang independen nantinya mungkin
diperlukan untuk digabung. Melihat Tabel 6.5, tabel DEPARTEMENT. Tabel menunjukkan enam departemen
yang menawarkan mata kuliah yang terdapat pada tabel COURSE. Kedua tabel tidak berbagi sebuah kolom
yang sama. Anda mungkin dapat menebak departemen mana yang menawarkan setiap mata kuliah
berdasarkan nilai pada field Abbreviation, tetapi komputer perlu sebuah kecocokan yang pasti, bukan sebuah
tebakan.
Kita akan menambahkan field Abbreviation pada tabel COURSE sehingga kedua tabel dapat digabung
dengan sebuah field yang sama. Tabel 6.6 menggambarkan tabel COURSE dengan penambahan Abbreviation.
Sekarang, seorang siswa yang memiliki masalah dalam kelas “Introduction to Marketing” dapat mencocokkan
nilai field Abbreviation “MGTMKT” pada tabel COURSE dengan nilai field Abbreviation “MGTMKT” pada tabel
DEPARTMENT dan tahu untuk memanggil “910-4500” untuk bantuan.

Tabel 6.5
 Tabel 6.6

STUKTUR-STRUKTUR BASIS DATA

Struktur-struktur basis data merupakan cara organisir data dalam rangka membuat pengolahan data menjadi
lebih efisien. Struktur kemudian diimplementasikan melalui sebuah sistem manajemen basis data. Kita
mendiskusikan tiga stuktur standar, tetapi terdapat kepentingan dalam mengembangkan struktur-struktur baru
untuk memproses data dengan jumlah yang sangat besar secara lebih efisien.2
Basis data Management System (DBMS) atau Sistem Manajemen Basis data merupakan sebuah
aplikasi perangkat lunak yang menyimpang struktur dari basis data, data itu sendiri, hubungan antar data di
dalam basis data, serta formulir (forms) dan laporan (reports) berkaitan dengan basis data. Deskripsi data field
juga termasuk – nama field, tipe data, jumlah angka desimal, jumlah karakter, nilai default, dan seluruh deskripsi
field lainnya. Hal ini lah yang menyebabkan mengapa basis data dikontrol oleh sebuah sistem manajemen basis
data yang disebut self-describing set of related data.

Struktur-struktur Hirarkis Basis data

Sistem manajemen basis data pertama, IDS (Integrated Data Store),3 dikembangkan oleh GE pada 1964. Basis
data ini mempengaruhi standardiasi dari pekerjaan Comittee on Data System Languages (CODASYL). Komite
memiliki anggota-anggota yang berasal dari pemerintahan, industri, dan akademisi sehingga standar yang
dikembangkan akan terbuka untuk semua. CODASYL membentuk Data Base Task Group dan membebankan
kelompok dengan tanggung jawab untuk mengembangkan standar basis data.
Sistem manajemen basis data IDS menyesuaikan dengan struktur hirarkis basis data (hierarchial basis
data structure). Struktur hirarkis dibentuk oleh kelompok, sub-kelompok, serta sub-kelompok lebih jauh lagi dari
data; Jika Anda hendak menggambar struktur, maka akan muncul/tampak sebagai cabang-cabang dari sebuah
pohon. Seperti halnya cabang-cabang pada sebuah pohon, untuk pergi dari sebuah record pada satu cabang ke
sebuah record pada satu cabang yang berbeda diperlukan sistem manajemen basis data yang menavigasikan
kembali menjadi sambungan yang sama untuk cabang-cabang tersebut. Gambar 6.2 menunjukkan navigasi dari
tabel DEPARTMENT ke tabel COURSE.
Struktur hirarkis untuk basis data-basis data pada awalnya terkenal karena ia bekerja baik dengan sistem
proses/pengolahan transaksi yang melakukan pekerjaan seperti kontrol inventori/persediaan, memasukkan
pesanan, piutang usaha/dagang, dan hutang usaha/dagang. Tugas akuntansi seperti yang tersebut merupakan
di antara operasi bisnis yang paling pertama dikomputerisasi.
 Gambar 6.2. Struktur
Hirarkis Antara Tabel
DEPARTMENT dan
COURSE

Alasan lain untuk popularitasnya adalah struktur hirarkis memanfaatkan sumber daya komputer dengan efisien,
khusunya ketika banyak mayoritas records di dalam basis data digunakan di dalam sebuah aplikasi.
Organisasi/perusahaan ingin seluruh konsumen/pelanggan untuk mendapatkan tagiha, seluruh vendor/suplier
untuk dibayar, dan seluruh pesanan untuk diproses. Untuk aplikasi-aplikasi seperti itu, struktur hirarkis membuat
penggunaan sumber daya basis data sangat efisien. Pada 1960-an, ketika struktur hirarkis dikembangkan,
sumber daya komputer mahal.
Tetapi, ketika manajer ingin hanya sedikit record yang dipilih dari banyaknya jumlah record di dalam basis
data, struktur hirarkis tidak efisien. Hal ini dikarenakan setiap record basis data hirarkis memiliki sebuah field
yang menunjuk pada alamat penyimpanan dari record logis selanjutnya di dalam basis data. Record tidak harus
disimpan satu per satu secara fisik pada perangkat penyimpanan. Sebuah pointer menempatkan record
“logically next” (record selanjutnya), dan sistem manajemen basis data memiliki kembali record “logically next”.
Tetapi, keputusan manajerial mungkin membutuhkan sebuah record yang spesifik untuk mengatasi sebuah
masalah bisnis. Seorang manajer ingin sebuah record terkait purcahse order untuk mengatasi pengaduan
pelayanan dari kosnumen/pelanggan tertentu, bukan sebuah daftar dari ribuan purchase order yang dilakukan
pada hari itu.
Bagaimanapun juga, ketika para manajer menginginkan beberapa rekaman dari banyak rekaman yang
ada pada basis data, struktur hirarkinya tidak efisien. Hal ini disebabkan setiap rekaman hirarki basis
data memiliki medan yang terhubung dengan rekaman selanjutnya pada basis data. Rekaman tidak
harus disimpan secara fisik satu demi satu dalam basis data. Sebuah pointer menempatkan rekaman
yang berikutnya dan sistem basis data akan menerima rekaman tersebut. Bagaimanapun, keputusan
yang dibuat hanya membutuhkan satu rekaman yang spesifik untuk mengatasi masalah bisnis.
Seorang manajer menginginkan pruchase order yang spesifik untuk mengatasi keluhan dari berbagai
pelanggan.

Struktur Jaringan Basis data

Struktur jaringan basis data dibuat untuk memungkinkan penerimaan rekaman yang spesifik.
Juga memungkinankan untuk mengubungan rekman yang ada dengan rekaman lain yang ada dalam
basis data.
 Jaringan menyelesaikan permasalahan dalam menggabungkan rekaman dalam basis data.
Secara konsep, rekaman apapun dalam basis data bisa terhubung dengan rekaman lainnya dalam
basis data. Namun koneksi yang luas ini menjadi kelemahan penerapak struktur jaringan untuk
masalah praktis. Bisa menjadi kacau jika membuat semua rekaman benar-benar terhubung dengan
rekaman lainnya. Bahkan para ahli dalam sistem informasi menemukan kesulitan untuk membangun
dan menggunakan struktur jaringan.

Struktur Hubungan Basis data

Organisasi bisnis tidak pernah menerapkan sistem manajemen basis data yang dibangun dalam
struktur jaringan. Namun organisasi masih membutuhkan cara untuk mengatasi permasalahan
manajerial yang menggunakan basis data maka dari itu mereka memfokuskan pada sekumpulan data
dan hubungan satu data dengan yang lainnya.
Masalah lainnya adalah tabel yang bawah hanya bisa terhubungan dengan satu tabel di atasnya.
Seperti daun pada pohon, satu tabel hanya bisa terhubung dengan satu cabang. Secara konsep, tabel
course akan memiliki dua tabel yang berhubungan dengan Fakultas dan Departemen. Hubungan ini
tidak diperbolehkan oleh struktur hirarki basis data.
Sebuah terobosan byang berasal dari penelitian dasar yang menggunakan hubungan aljabar
dilakukan secara independen oleh C.J. Date dan E.F.Codd. Pekerjaan mereka sangat erat kaitannya
dengan struktur hubungan basis data yang banyak digunakan dalam organisasi bisnis sekarang ini.
Struktur basis data ini terlihat seperti kumpulan tabel yang mirip dengan tabel spreadsheet.
Sedangkan struktur jaringan dan hirarki bergantung pada hubungan fisik dalam penyimpanan,
hubungan dalam struktur hubungan jaringan berjenis implisit. Hubungan yang implisiti bisa
diimplikasikan dari data. Ketika data lapangan yang umum berada di antara dua tabel yang ada,
rekaman dari dua tabel bisa digabungkan ketika nilai data lapangan bernilai sama. Inilah bagaimana
kita menggabungkan tabel Departemen dan Course secara bersamaan menggunakan nilai yang ada
dalam Abbreviation.
Konsep dari struktur basis data yang terdiri dari tabel yang hubungannya secara implisit
dibangun oleh nilai yang cocok dalam data lapangan yang mudah digunakan dan dimengerti.
Kemudahan untuk menggunakannya sangat penting. Ketika organisasi menjadi lebih datar, beberapa
spesialis yang ada untuk menggabungkan data dari konputer berbasis sistem dan mendapatkan
laporan dari para manajer. Sekarang ini para manajer dan staf profesional harus mengakses informasi
secara langsung dari basis data dalam rangka mendukung pembuatan keputusan. Tabel seperti
struktur hubungan basis data sistem manajemen merupakan format yang bisa dimengerti secara cepat
bagi manajer maupun staf profesional.

Contoh Hubungan Basis data

Sebuah contoh dari data lapangan, tabel dan hubungan natara tabel akan mengatur beberapa
tahapan untuk konsep basis data yang akan dijelaskan nanti. Sebuah basis data yang diber nama
Schedule telah dibuat dari yang digunakan di awal chapter. Basis data menguraikan informasi menjadi
beberapa tabel karena jika informasi hanya ditempatkan dalam satu tabel maka akan banyak nilai data
lapangan yang terduplikasi maka akan terjadi kelebihan data.
 Basis data meningkatkan konsistensi dan keakuratan data. Ini menjadi perhatian yang penting.
Para manajer membuat keputusan yan penting untuk perusahaan, mereka membutuhkan data yang
akurat dan konsisten dengan data lainnya dalam basis data. Mengurangi jumlah data yang berlebihan
itu bagus namun lebih penting jika memperoleh data yang konsisten dan akurat.

Basis data Jadwal

Contoh yang digunakan disini diimplementasikan pada Microsoft Access, sebuah aplikasi sistem
manajemen basis data, namun implementasinya akan mirip pada produk basis data lainnya. IBM,
Oracle, Microsoft dan perusahaan lainnya menyediakan aplikasi sistem manajemen basis data.
Implementasi bisa sedikit berbeda namun semuanya menggunakan struktur yang sama.
Tabel course ditunjukkan dalam Gambar 6.4. Itu merupakan daftar dari nilai data lapangan.
Tabel itu sendiri harus didefiniskan dalam aplikasi ini sebelum nlainya dimasukkan ke dalam data
lapangan. Gambar 6.5 menunjukkan definisi dari kode lapangan. Icon yang ada di sebelah kiri kode
adalah kunci, yang menunjuk bahwa konde merupakan kunci pada tabel Course. Kode merupakan
tempat tulisan, ia bisa diisi dengan kamlimat, angka atau simbol.
Perhatikan bahwa pemabatassan lainnya bisa ditempatkan pada nilai kode. Sebuah input bisa
digunakan untuk memaksa karakter tertentu untuk bisa masuk dengan cara tertentu. Nilai kode kita,
LLL000 dalam DBMS bisa membuktikan bahwa tiga karakter pertama adalah huruf dan tiga karakter
berikutnya adalah angka. Untuk tipe lainnya, seperti nomor telepon atau kode pos, data input bisa
dikembangkan. Nilai default bisa ditentukan untuk memvalidasi nilai yang dimasukkan. Nilai yang
dimasukkan jika tidak memenuhi persyaratan akan ditolak dan tidak akan dicatat dalam basis data.
Kolom kode merupakan bagian penting pada tabel, jadi nilai duplikat tidak akan bisa dimasukkan.
Nilai kunci pasti unik. Namun kolom lain bisa dimungkinkan untuk memasukkan nilai duplikat jika
designernnya memilih opsi tersebut.
Gambar 6.6 menggambarkan bahwa kolom nilai abreviasi bisa dipindahkan ke atas dari daftar
nilai yang ada pada tabel Departemen. Perlu diingat bahwa dari tabel 6.6 kolom abreviasi telah
ditambahkan ke dalam tabel Course jadi rekaman dari Course dan Departemen bisa digabungkan. Nilai
data dari kolom abrevias dalam tabel Departemen diperlihatkan kepada pengguna dalam menu drop-
down ketika mereka mencoba memasukkan nilai pada kolom abreviasi dalam tabel Course. Ini akan
membuktikan bahwa pengguna yang memasukkan data ke dalam tabel Course tidak akan membuat
kesalahan ketika memasukkan nilai abreviasi.
Desain dari kolom yang ada dalam tabel Course memungkinakan pengguna untuk mendukung
data yang akurat dan konsisten. Kekonsistenan antara tabel Course dan Departemen dipaksakan
karena nilai data yang dimasukkan ke dalam kolom abreviasi dalam tabel Course merupakan nilai yang
dipilih dari daftar value yang sudah ada dalam kolom abreviasi di tabel Departemen. Sebuah inputan
data bisa memastikan bahwa nilai kode terdiri dari tiga huruf dan tiga angka. Keakuratan dipaksakan
oleh aturan validasi. Kolom definisi termasuk simpel namun bagus.
Kelebihan data mendjadi lebih sulit untuk dikonsepkan terutama ketika tabel sudah dipisah.
Tabel 6.7 memperlihatkan satu tabel dari kolom Course dan Departemen sebelum mereka dipisahkan
menjadi tabel yang berbeda. Perlu diketahui bahwa nama departemen, lokasi dan nomor telepon itu
diulang. Dalam tabel 6.6 tabel course hanya memiliki departemen abreviasi yang diulang dan kolom
pengulanan tersebut memungkinak Course untuk berhubungan dengan Departemen. Kolom yang
berlebihan membutuhkan lebih banyak penyimpanan, proses rekaman yang lama dan data yang tidak
konsisten. Jika departemen bisnis internasional merubah namanya menjadi “Global Business”. Jika
hanya dua dari tiga rekaman dalam tabel 6.7 yang diubah maka basis data tidak bisa memastikan
nama departemen yang mana yang benar. Kelebihan tersebut memungkinkan kita untuk menyatukan
catatan dari departemen yang terpisah dan tabel-tabel COURSE.

Gambar 6.7 menunjukkan bidang, tabel, dan hubungan antartabel dari basis data Schedule.
Bidang-bidang pada tabel yang mengandung kata kunci ditulis tebal. Garis-garis antartabel
menggambarkan bidang mana yang bersifat umum. Bidang ini menggabungkan tabel-tabel yang
berhubungan satu sama lain. Fitur lainnya yang ada ada Gambar 6.7 akan dijelaskan lebih lanjut.

Konsep Basis data

Saat pengguna-pengguna membayangkan catatan pada sebuah basis data, mereka cenderung
menganggap bahwa urutan catatan yang ditampilkan pada sebuah laporan mencerminkan urutan
disimpannya catatan pada disk komputer. Padahal, sebuah catatan yang pengguna anggap muncul
sebelum atau sesudah catatan lain bisa saja disimpan di bagian disk yang sama sekali berbeda.
Sebuah sitem manajemen basis data dapat menampilkan data dengan urutan yang benar secara logis
dan intuisi meskipun catatan-catatan tunggal sebuah basis data bisa saja tersebar di berkas-berkas
berbeda dan di seluruh bagian penyimpanan komputer. Sebagai contoh, pada Gambar 6.4, Kode yang
dinamakan “ACG201” dan “ACG301” muncul berdampingan, padahal, kedua catatan tersebut bisa saja
disimpan di dua tempat yang sangat berbeda. Pengintegrasian catatan-catatan yang tersebar di
banyak lokasi dan dilakukan secara logis ini dinamakan konsep basis data. Lokasi fisik pada medium
penyimpanan tidak bergantung pada anggapan pengguna akan lokasinya secara logis.
Dua tujuan utama konsep basis data adalah meminimalkan kelebihan data dan mencapai
kemandirian data. Kelebihan data, yang sebelumnya sudah dibahas, memboroskan ruang
penyimpanan, memperlambat proses pencatatan, dan berpotensi menyebabkan inkonsistensi data.
Kemandirian data adalah kemampuan untuk melakukan pengubahan pada struktur data tanpa
harus mengganti program aplikasi yang memproses data tersebut. Sebagai contoh, program komputer
untuk membuat purchase order tentu terpisah dengan data purchase order pada basis data.
Kemandirian data terjadi saat spesifikasi data pada tabel dan kamus yang secara fisik terpisah dari
program dapat disimpan.
Mengacu kembali pada Gambar 6.5. Ukuran bidang Kode dapat ditingkatkan dari 8 menjadi 10
karakter pada definisi tabel tanpa harus memengaruhi aplikasi apa pun yang sedang menggunakan
 bidang tersebut. Ketika program komputer secara langsung mengakses berkas data untuk memulihkan
data, program tersebut harus mengeluarkan format data secara eksplisit. Hal ini hanya dapat
diwujudkan jika kode program komputer ditulis ulang dan jika jumlah karakter Kode diubah dari 8
menjadi 10. Jika terdapat 25 aplikasi komputer yang sedang mengakses Kode, semua aplikasi tersebut
harus dimodifikasi. Dengan kemandirian data, penulisan ulang tidak akan dibutuhkan dan yang harus
diubah hanyalah pada bagian definisi bidang basis data.
Sebuah kamus data mengandung definisi data tersimpan pada basis data dan dikendalikan oleh
sistem manajemen basis data. Gambar 6.5 menunjukkan satu contoh tabel pada basis data Schedule.
Struktur basis data yang dicakup oleh kamus data termasuk pengumpulan semua definisi bidang,
definisi tabel, hubungan tabel, dan lain-lain. Nama bidang data, tipe data (misal, teks atau nomor atau
tanggal), nilai sah data, dan ciri-ciri lainnya juga disimpan di dalam kamus data. Perubahan pada
struktur data hanya dapat dilakukan satu kali pada kamus data dan hanya akan berpengaruh terhadap
program aplikasi yang sedang menggunakan data tersebut.

MENCIPTAKAN SEBUAH BASIS DATA

Pada dasarnya, proses penciptaan sebuah basis data terdiri atas tiga langkah. Pertama,
menentuan data apa saja yang dibutuhkan. Kedua, mendeskripsikan data. Ketiga, memasukkan data
ke dalam basis data.

Penentuan kebutuhan data

Penentuan data mana saja yang dibutuhkan untuk dikumpulkan dan disimpan adalah langkah
utama untuk membuat sistem informasi berbasis komputer. Dua pendekatan dasar dapat digunakan
untuk menentukan kebutuhan data: sebuah pendekatan berorientasi proses dan enterprise modeling.

Pendekatan berorientasi proses

Saat sebuah perusahaan melakukan pendekatan berorientasi proses untuk menentukan

kebutuhan data, perusahaan tersebut harus menjalankan serangkaian langkah. Pertama, definisi
masalah. Lalu, pengambilan keputusan pemecah masalah yang telah diidentifikasi sebelumnya dan
pendeskripsian informasi yang dibutuhkan untuk setiap keputusan. Selanjutnya, penentuan
pemprosesan yang dibutuhkan untuk menghasilkan informasi, dan terakhir, penspesifikasian data yang
dibutuhkan oleh pemprosesan. Pendekatan berorientasi proses disebut juga dengan pendekatan
berorientasi masalah dan permodelan berorientasi proses. Di bawah ini langkah-langkah
pendefinisian kebutuhan data di dalam pendekatan berorientasi proses:
1. Mendefinisikan masalah
2. Mengindentifikasi keputusan yang diperlukan
3. Mendeskripsikan kebutuhan informasi
4. Menentukan pemprosesan yang diperlukan
5. Menspesifikasikan kebutuhan data
Alasan mengapa pendekatan berorientasi proses disebut juga sebagai pendekatan berorientasi
masalah adalah karena pendekatan ini bermula dari masalah. Sebuah masalah dapat bersifat baik
ataupun buruh; dapat menjadi ancaman ataupun kesempatan pemanfaatan lebih lanjut bagi sebuah
perusahaan. Saat masalah selesai diidentifikasi, data dan pemprosesan yang berkaitan dengan
pemecahan masalah tersebut dapat ditentukan. Kelebihan pendekatan ini adalah kemampuan
pengurusan masalah dengan baik.

Pendekatan enterprise modeling

Kelebihan pendeketan ini adalah pemanfaatan tinjauan luas sumber data sebuah perusahaan.
Seluruh area dipertimbangkan dan sinergi sumber data antar area bisnis berbeda dapat diwujudkan.
Walaupun pendekatan ini memungkinkan pendefinisian kebutuhan data tiap sistem secara logis,
pendekatan ini memiliki kekurangan dalam menge-link data sebuah masalah bisnis yang satu ke yang
lain. Sebuah sistem informasi tidak dapat dengan mudah membagikan data jika terisolasi dari sistem
lainnya yang mengurus masalah bisnis lain. Kelemahan ini dapat diatasi dengan menentukan sebuah
kebutuhan data perusahaan lalu menyimpannya ke dalam basis data. Hal ini merupakan prinsip dasar
pendekatan enterprise modeling.
Ketika sebuah perusahaan menggunakan pedekatan enterprise modeling, seluruh data
perusahaan akan disebut sebagai model data perusahaan. Proses yang bermula saat perencanaan
strategis sumber informasi ini diilustrasikan pada Gambar 6.8

Teknik Pemodelan Data

Pemodelan kebutuhan data perusahaan didukung oleh teknik yang menggambarkan data,
bagaimana data agregat ke dalam tabel, dan bagaimana tabel berhubungan satu sama lain. Beberapa
teknik sudah tersedia, tapi kami akan fokus pada dua: diagram relasi entitas dan diagram kelas.
Diagram hubungan entitas yang digunakan untuk menggambarkan hubungan antara koleksi
konseptual data sehingga catatan yang terkait dapat digabungkan bersama-sama. Diagram kelas yang
digunakan untuk menggambarkan baik hubungan data dan tindakan yang beroperasi pada data dalam
hubungannya. Teknik ini menyediakan alat-alat untuk memfasilitasi komunikasi antara pengguna dan
spesialis sistem informasi mengenai struktur data yang digunakan dalam aplikasi sistem informasi
Diagram Hubungan Entitas
Diagram Hubungan Entitas (ERD), "seperti namanya berurusan dengan data didalam entitas dan
hubungan antara entitas. Bila pengguna dan spesialis dari informasi mulai berkomunikasi tentang data
yang diperlukan untuk sistem informasi, mereka berbicara dalam hal koleksi data terkait bidang yang
bertentangan dengan bidang data individu. Koleksi konseptual dari data terkait ini disebut entitles.
Meskipun secara intuitif menarik untuk memikirkan entitas sebagai tabel, kita tetap tidak bisa. Tabel
adalah hasil dari membagi entitas menjadi unit yang lebih kecil yang sesuai dengan aturan untuk
struktur basis data. Suatu entitas dapat berubah menjadi sebuah tabel, tapi sering entitas dipecah
menjadi beberapa tabel. ERD adalah konseptualisasi tingkat yang lebih tinggi dari data dibandingkan
tabel. ERD juga mengungkapkan entitas yang harus konseptual berhubungan dengan orang lain.
Hubungan antara entitas tidak ditunjuk oleh bidang data umum dalam entitas, karena selama tahap
awal pengembangan sistem ketika ERD pertama kali dikonseptualisasikan bidang data yang tepat
untuk setiap tabel yang tidak diketahui. Namun, pengguna dan sistem informasi profesional dapat
mengkonsepkan bagaimana catatan dalam entitas mungkin berhubungan dengan catatan dalam
entitas lain.

Entitas di ERD akan memiliki nama, seperti tabel yang memiliki nama. Juga, hubungan yang
menghubungkan entitas seperti garis menggabungkan tabel melalui kolom umum antara tabel. ERD
akan menunjukkan jika rekor dalam satu entitas akan berhubungan dengan satu atau lebih catatan
dalam entitas lainnya. Dalam cara yang sama, Anda dapat melihat dari Gambar 6.7 bahwa satu record
dalam tabel mata kuliah dapat berhubungan dengan banyak catatan (dinyatakan dengan simbol infinity)
pada tabel proyek.
Mari kita asumsikan bahwa kita perlu untuk menggambarkan data yang diperlukan untuk sistem
informasi yang baru. Sistem akan melacak perusahaan dan karyawan mereka serta produk mereka.
Dari uraian singkat ini, kita dapat membayangkan bahwa tiga entitas data yang terpisah akan ada:
perusahaan, karyawan, dan produk. Entitas direpresentasikan sebagai kotak dalam ERD, sehingga
Gambar 6.9 menggambarkan entitas.
Sebelum hubungan antara entitas saya menyatakan, kita harus membuat beberapa asumsi.
Pertama, catatan entitas perusahaan berisi informasi tentang nama perusahaan, alamat, dan
sebagainya. Kedua, perusahaan mungkin memiliki banyak karyawan, tetapi seorang karyawan bekerja
untuk satu perusahaan. Asumsi ini agak sederhana, karena beberapa orang bekerja dua atau lebih
pekerjaan, tetapi akan membuat penjelasan ERD lebih mudah diikuti. Terakhir, kita asumsikan bahwa
catatan dalam item tertentu menunjukan entitas produk dan bukan produk generik seperti "minuman
ringan."
Karena perusahaan menjual produk, ada hubungan antara entitas perusahaan dan produk.
Demikian pula, perusahaan mempekerjakan karyawan, sehingga ada hubungan antara dua entitas.
Hubungan diwakili oleh garis bernama, seperti yang ditunjukkan pada Gambar 6.10. Penamaan ini
penting untuk dokumentasi; itu berfungsi sebagai penjelasan mengapa para desainer telah membuat
hubungan antara entitas.

Sebuah terobosan byang berasal dari penelitian dasar yang menggunakan hubungan aljabar
dilakukan secara independen oleh C.J. Date dan E.F.Codd. Pekerjaan mereka sangat erat kaitannya
dengan struktur hubungan basis data yang banyak digunakan dalam organisasi bisnis sekarang ini.
Struktur basis data ini terlihat seperti kumpulan tabel yang mirip dengan tabel spreadsheet.
Sedangkan struktur jaringan dan hirarki bergantung pada hubungan fisik dalam penyimpanan,
hubungan dalam struktur hubungan jaringan berjenis implisit. Hubungan yang implisiti bisa
diimplikasikan dari data. Ketika data lapangan yang umum berada di antara dua tabel yang ada,
rekaman dari dua tabel bisa digabungkan ketika nilai data lapangan bernilai sama. Inilah bagaimana
kita menggabungkan tabel Departemen dan Course secara bersamaan menggunakan nilai yang ada
dalam Abbreviation.
Konsep dari struktur basis data yang terdiri dari tabel yang hubungannya secara implisit
dibangun oleh nilai yang cocok dalam data lapangan yang mudah digunakan dan dimengerti.
Kemudahan untuk menggunakannya sangat penting. Ketika organisasi menjadi lebih datar, beberapa
spesialis yang ada untuk menggabungkan data dari konputer berbasis sistem dan mendapatkan
laporan dari para manajer. Sekarang ini para manajer dan staf profesional harus mengakses informasi
secara langsung dari basis data dalam rangka mendukung pembuatan keputusan. Tabel seperti
struktur hubungan basis data sistem manajemen merupakan format yang bisa dimengerti secara cepat
bagi manajer maupun staf profesional.

Contoh Hubungan Basis data

Sebuah contoh dari data lapangan, tabel dan hubungan natara tabel akan mengatur beberapa
tahapan untuk konsep basis data yang akan dijelaskan nanti. Sebuah basis data yang diber nama
Schedule telah dibuat dari yang digunakan di awal chapter. Basis data menguraikan informasi menjadi
beberapa tabel karena jika informasi hanya ditempatkan dalam satu tabel maka akan banyak nilai data
lapangan yang terduplikasi maka akan terjadi kelebihan data.
Basis data meningkatkan konsistensi dan keakuratan data. Ini menjadi perhatian yang penting.
Para manajer membuat keputusan yan penting untuk perusahaan, mereka membutuhkan data yang
akurat dan konsisten dengan data lainnya dalam basis data. Mengurangi jumlah data yang berlebihan
itu bagus namun lebih penting jika memperoleh data yang konsisten dan akurat.

Basis data Jadwal

Contoh yang digunakan disini diimplementasikan pada Microsoft Access, sebuah aplikasi sistem
manajemen basis data, namun implementasinya akan mirip pada produk basis data lainnya. IBM,
Oracle, Microsoft dan perusahaan lainnya menyediakan aplikasi sistem manajemen basis data.
Implementasi bisa sedikit berbeda namun semuanya menggunakan struktur yang sama.
Tabel course ditunjukkan dalam Gambar 6.4. Itu merupakan daftar dari nilai data lapangan.
Tabel itu sendiri harus didefiniskan dalam aplikasi ini sebelum nlainya dimasukkan ke dalam data
lapangan. Gambar 6.5 menunjukkan definisi dari kode lapangan. Icon yang ada di sebelah kiri kode
adalah kunci, yang menunjuk bahwa konde merupakan kunci pada tabel Course. Kode merupakan
tempat tulisan, ia bisa diisi dengan kamlimat, angka atau simbol.
Perhatikan bahwa pemabatassan lainnya bisa ditempatkan pada nilai kode. Sebuah input bisa
digunakan untuk memaksa karakter tertentu untuk bisa masuk dengan cara tertentu. Nilai kode kita,
LLL000 dalam DBMS bisa membuktikan bahwa tiga karakter pertama adalah huruf dan tiga karakter
berikutnya adalah angka. Untuk tipe lainnya, seperti nomor telepon atau kode pos, data input bisa
dikembangkan. Nilai default bisa ditentukan untuk memvalidasi nilai yang dimasukkan. Nilai yang
dimasukkan jika tidak memenuhi persyaratan akan ditolak dan tidak akan dicatat dalam basis data.
Kolom kode merupakan bagian penting pada tabel, jadi nilai duplikat tidak akan bisa dimasukkan.
Nilai kunci pasti unik. Namun kolom lain bisa dimungkinkan untuk memasukkan nilai duplikat jika
designernnya memilih opsi tersebut.
Gambar 6.6 menggambarkan bahwa kolom nilai abreviasi bisa dipindahkan ke atas dari daftar
nilai yang ada pada tabel Departemen. Perlu diingat bahwa dari tabel 6.6 kolom abreviasi telah
ditambahkan ke dalam tabel Course jadi rekaman dari Course dan Departemen bisa digabungkan. Nilai
data dari kolom abrevias dalam tabel Departemen diperlihatkan kepada pengguna dalam menu drop-
down ketika mereka mencoba memasukkan nilai pada kolom abreviasi dalam tabel Course. Ini akan
membuktikan bahwa pengguna yang memasukkan data ke dalam tabel Course tidak akan membuat
kesalahan ketika memasukkan nilai abreviasi.
Desain dari kolom yang ada dalam tabel Course memungkinakan pengguna untuk mendukung
data yang akurat dan konsisten. Kekonsistenan antara tabel Course dan Departemen dipaksakan
karena nilai data yang dimasukkan ke dalam kolom abreviasi dalam tabel Course merupakan nilai yang
dipilih dari daftar value yang sudah ada dalam kolom abreviasi di tabel Departemen. Sebuah inputan
data bisa memastikan bahwa nilai kode terdiri dari tiga huruf dan tiga angka. Keakuratan dipaksakan
oleh aturan validasi. Kolom definisi termasuk simpel namun bagus.
Kelebihan data mendjadi lebih sulit untuk dikonsepkan terutama ketika tabel sudah dipisah.
Tabel 6.7 memperlihatkan satu tabel dari kolom Course dan Departemen sebelum mereka dipisahkan
menjadi tabel yang berbeda. Perlu diketahui bahwa nama departemen, lokasi dan nomor telepon itu
diulang. Dalam tabel 6.6 tabel course hanya memiliki departemen abreviasi yang diulang dan kolom
pengulanan tersebut memungkinak Course untuk berhubungan dengan Departemen. Kolom yang
berlebihan membutuhkan lebih banyak penyimpanan, proses rekaman yang lama dan data yang tidak
konsisten. Jika departemen bisnis internasional merubah namanya menjadi “Global Business”. Jika
hanya dua dari tiga rekaman dalam tabel 6.7 yang diubah maka basis data tidak bisa memastikan
nama departemen yang mana yang benar.

1 1

Perusahaan

M M

Karyawan Produk

Gambar 6.11 Diagram Hubungan Entitas

Bagian terakhir dalam membuat ERD adalah menentukan seberapa banyak catatan individu
dalam satu entitas yang akan berhubungan dengan catatan individu lainnya. Langkah ini merupakan
kunci dari konseptualisasi yang berdampak terhadap berapa banyak daftar basis data yang akan dibuat.
Dalam contoh kami, kami mengasumsikan bahwa sejumlah perusahan mungkin menyewa sejumlah
karyawan, akan tetapi karyawan hanya dapat bekerja untuk satu perusahaan. Kata kunci di sini adalah
“dapat” dan “mungkin.” Perusahaan tertentu dibolehkan menyewa lebih dari satu karyawan, tetapi hal
itu kadang tidak diperlukan.
Gambar 6.11 mendeskripsikan bagaimana kita bisa menspesifikasikan bahwa suatu catatan di
suatu entitas perusahaan dapat berhubungan dengan banyak catatan dalam entitas produk dan juga
satu record di entitas perusahaan dapat berhubungan dengan banyak catatan di entitas karyawan.
Hubungan “menyewa” memiliki bilangan “1” di samping entitas perusahaan dan bilangan “M” di
samping entitas karyawan. Bilangan “M” berarti “banyak”. Hubungan tersebut akan dibaca sebagai
“satu catatan perusahan mungkin berhubungan dengan banyak catatan karyawan dan satu catatan
karyawan mungkin berhubungan dengan satu catatan perusahaan saja.” Hubungan antara entitas
perusahaan dan karyawan disebut hubungan “satu-ke-banyak.” Hubungan antara entitas perusahaan
dan produk juga disebut dengan hubungan satu-ke-banyak
Untuk melengkapi diskusi kita mengenai hubungan entitas, Anda perlu menyediakan suatu
contoh hubungan “banyak-ke-banyak.” Anggap suatu entitas lainnya, yaitu proyek, akan ditambahkan.
Sebuah proyek dapat memiliki banyak karyawan, dan satu karyawan dapat berada di banyak proyek.
Entitas proyek juga dapat memiliki hubungan dengan entitas karyawan. Hubungan ini disebut sebagai
hubungan banyak-ke-banyak, sebagaimana yang ditunjukkan dalam Gambar 6.12.
Dalam praktiknya, diagram hubungan entitas dikembangkan di awal proses, sebelum suatu data
spesifik diidentifikasikan. Kemudian, daftar bidang data akan dihasilkan dan akan mempengaruhi
pembentukan basis data. ERD merupakan cara yang kuat untuk melakukan komunikasi dan
dokumentasi antara sistem informasi profesional dan para penggunanya. Ketika ide dapat
dikomunikasikan dan didokumentasikan dengan baik, ahli sistem informasi dapat mengembangkan
manajemen struktur sistem databse dengan lebih baik untuk mendukung pengambilan keputusan.

DIAGRAM KELAS
Diagram hubungan entitas merupakan suatu representasi grafik dari data dan hubungan di
antaranya, tidak mencakup tindakan yang dilakukan terhadap data tersebut. Adapun suatu teknik di
mana data yang digunakan dalam aplikasi sekaligus tindakan terkait data yang ada dapat
direpresentasikan secara grafik. Grafik ini disebut Diagram Kelas, dan diagram ini merupakan salah
satu dari beberapa desain model berorientasi tujuan. Objek adalah potongan atau bagian konseptual
dari suatu sistem informasi – data, tindakan yang dilakukan terhadap data tersebut merupakan
hubungan antar objek. Objek memiliki karakteristik lainnya yang berguna dalam analisis dan
perancangan sistem informasi, namun kita hanya fokus terhadap dampak dari penggambaran data.

Gambar 6.12. Diagram Hubungan Entitas dengan Hubungan Banyak-Ke-Banyak

Gambar 6.13. Diagram Kelas

 Diagram kelas terdiri dari kelas-kelas yang memiliki nama tersendiri, bidang dalam kelas tersebut,
dan tindakan (terkadang disebut sebagai metode) yang berlaku terhadap kelas tertentu. Diagram kelas
di Gambar 6.13 mengilustrasikan diagram hubungan entitas yang baru saja kita bahas. Perhatikan
bahwa diagram kelas dimulai dengan nama kelas di segmen paling atas dari persegi panjang tersebut.
“clsFIRM” adalah nama kelas dari entitas PERUSAHAAN yang telah kami deskripsikan sebelumnya.
(Dalam diagram kelas, nama kelas yang digunakan dapat ditambahkan dengan “cls”, tetapi hal ini
bukan merupakan suatu keharusan) Selanjutnya, segmen tengah dalam diagram tersebut secara
eksplisit menyatakan bidang dari kelas yang ada. Tidak seperti struktur daftar basis data, bidang yang
berlebihan antara dua kelas tidak dapat diulangi. Selain itu, perhatikan juga sebuah asterisk
merepresentasikan bagian “banyak” dalam suatu hubungan satu-ke-banyak.
Melihat hubungan antara kelas clsFIRM dan clsPRODUCT, perhatikan bahwa hubungan ini
dinamakan “Jual.” Anda akan membaca hubungannya sebagai “satu contoh dalam kelas clsFIRM
menjual satu atau lebih contoh dalam kelas clsPRODUCT.” Selain itu juga, “satu contoh dalam kelas
clsPRODUCT akan dijual oleh hanya satu contoh dalam kelas clsFIRM.” Diagram kelas muncul secara
intuitif sebagaimana diagram hubungan entitas, tetapi inklusi tindakan yang beroperasi terhadap data
(seperti addProduct) menyediakan insight lebih dalam mengenai bagaimana data dan aplikasi bekerja
bersama.
Meskipun tiap kelas di Gambar 6.13 memiliki sebuah tindakan add, delete, dan update, hanya
clsPRODUCT yang memiliki tindakan “sellProduct” atau jual produk. Tindakan “sellProduct” dapat
terlibat dalam hal penentuan apakah produk tertentu masih memiliki persediaan, penurunan persediaan
suatu produk berdasarkan jumlah produk yang dipesan, dan juga memungkinkan inisiasi suatu
pesanan untuk produk dalam jumlah yang lebih banyak dari suatu vendor apabila jumlah persediaan
telah sampai ke titik re-order. Diagram Kelas masih merupakan suatu representasi data tingkat tinggi
yang konseptualn tetapi penambahan tindakan terhadap data dapat membantu membawa kejelasan
untuk perancangan spesifik dari daftar databese.

MENGGUNAKAN BASIS DATA

Kami biasanya berinteraksi dengan basis data dari komputer personal bahkan jika data yang
dibutuhkan berada di jaringan lain. Formulir, laporan, dan pertanyaan-pertanyaan lainnya adalah
metode umum untuk mengakses basis data yang ada di suatu sistem manajemen basis data.

Laporan dan Formulir

Sebagian besar interaksi pengguna dengan basis data adalah melalui formulir dan laporan. GUI
disediakan oleh sebagian besar vendor software manajemen basis data yang membuat
pengembangan formulir dan laporan menjadi sederhana. Banyak laporan dan formulir yang dibutuhkan
oleh pengguna dapat dibuat tanpa bantuan dari ahli sistem informasi.
Perbedaan terbesar antara formulir dan laporan adalah formatnya. Formulir biasanya
menunjukkan satu catatan dalam satu waktu dan tidak memberikan ringkasan data dan secara umum
tidak mengumpulkan keseluruhan data dari sekian banyak daftar basis data. Perhatikan bahwa formulir
memiliki kemampuan ini, namun mereka tetap jarang dipakai. Perbedaan terbesar lainnya adalah
formulir dapat digunakan untuk menambah, menghapus, atau mengubah catatan basis data. Gambar
6.14 menunjukkan sebuah formulir untuk memasukkan kuliah kedalam basis data. Formulir ini
dikembangkan di dalam Access, tetapi ini merupakan sebuah representatif dari hal-hal yang dibuat di
kebanyakan software DBMS.
NAVIGASI Pengguna dapat melakukan navigasi dari satu catatan ke catatan lainnya menggunakan
navigation bar di bagian bawah formulir. Ikon “*” di navigation bar menyatakan bahwa formulir akan
membuat sebuah catatan baru. Formulir memungkinkan pembuatan catatan baru sekaligus
memodifikasi catatan yang telah ada sebelumnya.
KETEPATAN Formulir melaksanakan pendefinisian bidang data yang spesifik ketika basis data
dibuat. Definisi tersebut dapat menspesifikasi nilai valid tertentu, kisaran data untuk nilai numerik, dan
hal-hal lainnya yang mendukung ketepatan. Mereka juga bisa membuat aturan di luar masalah definisi
bidang data. Formulir memberikan suatu kesempatan untuk menyesuaikan nilai data untuk aplikasi
dalam area bisnis tertentu yang spesifik, tidak hanya naturan nilai umum yang dapat diterapkan untuk
seluruh pengguna basis data.

Gambar 6.14. Formulir Data Entry untuk Perkuliahan

KONSISTENSI Konsistensi sangatlah penting ketika field values dalam satu tabel digunakan untuk
menggabungkan records ke dalam tabel lain. Jika pengguna salah mengetik suatu field value, hal itu
akan berarti bahwa record tersebut tidak dapat digabungkan dengan tabel lainnya. Perhatikan pada
Figur 6.14 terdapat drop-down menu yang akan digunakan untuk memasukkan suatu nilai. Bagian
yang berlabel Offering Department berhubungan dengan bagian Abbreviation pada tabel MATA
KULIAH. Bagian tersbebut menghubungkan suatu record dari tabel MATA KULIAH kepada suatu
record dalam tabel JURUSAN. Menu drop-down hanya akan menampilkan nilai yang sudah
dimasukkan dalam bagian Abbreviation pada tabel JURUSAN, sehingga masukan pada form dibatasi
untuk dapat konsisten antara kedua tabel.
PENYARINGAN Basis datas memungkinkan untuk memiliki jumlah data yang sangat besar.
Pengguna dapat menyaring record yang ingin dilihat dengan menggunakan form. Bagian apapun
dalam form dapat digunakan sebagai penyaring. Sebagai contoh, suatu penyaring dapat terbentuk
sehingga hanya junior-level courses (courses dimana karakter keempat adalah “3”) yang akan
ditampilkan. Penyaringan membantu melawan informasi yang berlebih. Penyaringan juga dapat
membatasi akses pengguna terhadap data dalam basis data apabila record tertentu harus dijaga
kerahasiaannya.
SUBFORMS Figur 6.15 mengilustrasikan kombinasi antara form dan subform. Ketika pengguna
memasukkan informasi course, mereka juga mungkin untuk memasukkan informasi tentang proyek
pada waktu yang sama. Perhatikan bahwa terdapat dua bar navigasi, satu untuk form dan satu lagi
untuk subform. Masukkan dalam subform akan terasosiasi secara otomatis dengan form record.
Subforms membantu untuk mendorong akurasi dan konsistensi yang dibutuhkan oleh basis data.
Laporan adalah data teragregasi dari basis data yang diformat dengan cara yang akan
membantu pengambilan keputusan. Sebagai contoh, Figur 6.16 adalah laporan yang menampilkan
setiap jurusan dengan daftar setiap mata kuliah yang diajarkan dan proyek-proyek yang disyaratkan
untuk mata kuliah tersebut. Agregasi seperti ini sekarang terlihat seperti hal yang sepele, tapi sebelum
zaman basis data, penyajian seperti ini bisa jadi sulit untuk dilakukan. Akan tetapi, kemudahan
penggunaan membutuhkan pengorbanan; pengguna harus memahami bagaimana basis data bekerja
untuk dapat membuat laporan.
Lihat Figur 6.17 dan perhatikan bahwa nama-nama jurusan (seperti Ilmu Ekonomi) terlihat
dalam laporan, tetapi tidak terlihat dalam Figur 6.16. Mengapa mereka tidak ditampilkan? Mereka tidak
ditampilkan karena tidak memiliki proyek. Sebagai contoh, baik itu ECN375 maupun ECN460 tidak
memiliki record proyek di dalam basis data, sehingga jurusan Ilmu Ekonomi tidak dimasukkan dalam
laporan Figur 6.16. Mata kuliah-mata kuliah individual juga tidak ditampilkan, seperti ACG201, bahkan
ketika jurusan Akuntansi dan Keuangan terdapat dalam laporan Figur 6.16.
Satu asumsi dibuat oleh penghasil laporan yaitu jika tidak terdapat detail pada record pada
tingkat terendah, maka record tingkat yang lebih tinggi untuk detail tersebut hendaknya tidak perlu
ditampilkan. Figur 6.17 mengilustrasikan bahwa tabel JURUSAN berhubungan ke bawah dengan tabel
MATA KULIAH, yang selanjutnya, berhubungan ke bawah dengan tabel PROYEK. Kecuali jika terdapat
entri yang berhubungan dalam tabel PROYEK, maka
 Tabel MATA KULIAH tidak akan ditampilkan. Jika tidak ada record dari tabel MATA KULIAH
yang dipergunakan (sebagai contoh, kedua mata kuliah Ilmu Ekonomi tidak memiliki proyek), maka
record JURUSAN juga tidak akan ditampilkan.
Mengharuskan laporan menampilkan record bahkan ketika tidak ditemukan record yang sama
di tabel yang lebih rendah adalah suatu pekerjaan yang mudah. Tetapi jika para pengguna tidak
mengetahui bahwa laporan yang dibuat dengan aturan standar dapat mengecualikan record-record
tertentu, maka mereka dapat mengambil keputusan yang kurang terinformasi dengan baik.

Query
Beberapa pengguna ingin melangkah lebih jauh dari laporan dan formulir untuk memberikan
pertanyaan langsung ke basis data. Query adalah suatu permintaan kepada basis data untuk
menampilkan record-record yang dipilih. Sistem manajemen basis data biasanya memberikan
antarmuka yang mudah untuk digunakan bagi para pengguna.
Query pada umumnya memilih field data dalam jumlah terbatas dan kemudian membatasi
record-record yang ditampilkan berdasarkan satu kumpulan kriteria tertentu. Sebagai contoh,
seandainya Anda hanya ingin melihat kode mata kuliah, uraian mata kuliah, dan judul proyek dari mata
kuliah “MIS105”. Figur 6.18 menunjukkan bagaimana query seperti itu akan ditampilkan.

Format seperti ini disebut query-by-example (QBE), karena peranti lunak sistem manajemen
basis data menyajikan satu format terstandardisasi yang kemudian dilengkapi oleh pengguna sehingga
sistem tersebut dapat menghasilkan satu query yang sebenarnya. Formulir QBE akan menampilkan
tabel-tabel yang terkait di dalam query, atau dalam hal ini tabel-tabel MATA KULIAH dan PROYEK.
Selanjutnya ia akan memperkenankan pengguna untuk memilih field data dari tabel-tabel yang
seharusnya ditampilkan. Begitu pula dengan penambahan kriteria untuk membatasi pencarian. Dalam
kasus kita, kolom yang memuat nilai-nilai kode mata kuliah akan dibatasi hanya untuk nilai-nilai
“MIS105”. Jika proyek-proyek dari MIS105 maupun MIS315 yang diinginkan, “MIS315” seharusnya
dimasukkan ke dalam sel yang berada di bawah entri “MIS105”. Hasil dari query tersebut adalah tabel
dalam Figur 6.19.
Konsep query-by-example adalah suatu hal yang signifikan karena pentingnya arti seorang
manajer dapat melakukan akses langsung atas nilai-nilai basis data. Formulir dan laporan dapat
menampilkan sejumlah hasil yang mengaburkan hal-hal yang sebenarnya ingin ditemukan oleh
manajemen. Manajer dapat memanfaatkan QBE untuk dapat dengan cepat menemukan data tertentu
untuk memecahkan masalah.

Bahasa Query Terstruktur

Bahasa Query Terstruktur atau Structured Query Language (SQL) adalah kode yang digunakan
oleh sistem manajemen basis data relasional untuk mengerjakan pekerjaan-pekerjaan basis datanya.
Meskipun pengguna dapat melihat Figur 6.18 sebagai QBE, sistem manajemen basis data melihatnya
sebagai bahasa query terstruktur seperti dalam Figur 6.20. Perangkat lunak DBMS memiliki GUI dari
program-program “wizard” yang dapat menuntun pengguna menggunakan query dengan cara yang
mudah digunakan.

SQL menjadi topic penting dikarenakan oleh dua hal. Pertama, karena sekarang basis data
dapat diakses melalui web, manajer dan para ahli lainnya perlu memahami SQL karena SQL
merupakan metode untuk berintraksi dengan basis data pada web. Kedua, manajer perlu memahami
bahwa menulis pernyataan SQL tidaklah sulit untuk sebagian besar kebutuhan data mereka.

SELECT COURSE,Code, COURSE, Description,

PROJECT,Title

FROM COURSE, PROJECT

Gambar 6.20 WHERE COURSE,Code = PROJECT,Code

Kode Bahasa Query

Terstruktur untuk
Menemukan Proyek untuk
MIS105

Pemrosesan Basis Data Lanjutan

Online Analytical Processing (OLAP) atau proses analisis online menjadi hal umum di
software sistem manajemen basis data. Vendor termasuk dalam fitur ini untuk menganalisis data, mirip
dengan statistical cross-tabulation. Sebagai contoh, salah satu bidang pada table PROJECTS (Tabel
6.4) memiliki jumlah poin yang diberkan kepada proyek. Jika Anda ingin tahu jumlah semua poin untuk
proyek di setiap bidang di setiap departemen, maka OLAP akan sangat bermanfaat.
Data mining, data marts, dan data warehousing, mengacu pada konsep yang memandang data
perusahaan sebagai harta untuk dibuka, diperiksa, dan dimiliki. Mereka berfous pada metodologi yang
menawarkan akses cepat pada data agregat untuk keperluan pengambilan keputusan mereka.
Knowlodge discovery adalah konsep menarik lainnya. Karena basis data terus berkembang dan
menampung semakin banyak data, bagaimana pengguna bisa mengenali semua hubungan antaradata?
Data mana yang krusial untuk pengambilan keputusan? Apakah ada data yang penting pada basis
data yang tidak digunakan? Knowledge discovery ada untuk menjawab pertanyaan-pertanyaan
tersebut dengan cara menganalisis penggunaan data dan kesamaan data. OLAP, data mining, data
marts, data warehousing, dan knowledge discovery akan dibahas dalam Bab 8.

PERSONIL BASIS DATA

Beberapa personil kunci terlibat dalam basis data. Basis data Administrator bertanggung jawab
terhadap sumber daya basis data, baik secara teknis manupun manajerial. Basis data Programmer
dibutuhkan untuk mencaiptakan kode untuk data-processing yang efisien. Pengguna akhir basis data
merupakan personil kunci basis data lainnya. Berdasarkan keputusan yang dibuat dan jumlah data
yang didapatkan, pengguna akhir memiliki dampak besar terhadap desain, penggunaan, dan efisiensi
basis data.

Basis data Administrator

Spesialis informasi yang ahli dalam mengembangkan, menyediakan, dan mengamankan basis
data adalah Basis data Administrator (DBA). Basis data Administrator melihat seluruh aktivitas basis
data. Mereka wajib memiliki kemampuan manajerial dan kemampuan teknis tinggi. Sebuah perusahaan
biasanya memiliki beberapa Basis data Administrator, dibawahi oleh Manajer Basis data Administrator.
Basis data Administrator harus memahami bisnis operasi perusahaan, karena keputusan pada operasi
tersebut mendorong sebagian besar konten basis data. Mereka juga harus ahli dalam teknologi basis
data, karena perangkat keras dan perangkat lunak DBMS memiliki dampak besar terhadap kecepatan
dan kemudahan dalam menggunakan basis data.
Tugas seorang DBA terbagi dalam 4 bidang utama, yaitu merencanakan, mengimplementasi,
operasi, dan keamanan.
 Perencanaan Basis data melibatkan bekerja dengan pengelola kawasan bisnis untuk mendefinisikan
kebutuhan data perusahaan. DBA harus menjadi anggota tim manapun yang terlibat dalam kegiatan
process-oriented atau yang memodelkan perusahaan untuk menentukan kebutuhan data. Sebagai tambahan,
DBA memegang peran kunci dalam memilih software dan hardware sistem manajemen basis data.
 Pengimplementasian Basis data terdiri dari menciptakan basis data untuk menyesuaikan dengan
spesifikasi sistem manajemen basis data yang dipilih, serta membangun kebijakan dan prosedur
penggunaan basis data.
 Operasi Basis data melibatkan penawaran program edukasi untuk pengguna basis data dan memberikan
bantuan ketika dibutuhkan.
 Pengamanan Basis data terdiri dari mengawasi aktivitas basis data menggunakan statistic yang disediakan
oleh sistem manajemen basis data. Sebagai tambahan, sistem manajemen basis data memastikan bahwa
basis data tetap aman. Dalam sebuah lingkungan bisnis, dimana vendor dibolehkan mengakses basis data
organisasi atau dimana organisasi membolehkan konsumen untuk mengakses basis data order untuk
menuliskan order mereka sendiri, keamanan basis data menjadi isu kompleks. Sangat penting untuk
menginat bahwa keamanan basis data melibatkan tidak hanya menjaga pengguna tidak berkepentingan, tapi
juga memberikan pengguna berkepentingan kemudahan mengakses.

Basis data Programmer

Seorang Basis data Programmer menggambarkan spesialisasi dan seleksi yang tinggi. Mereka biasanya
memiliki pengalaman dan latihan lebih banyak dibandingkan programmer lainnya di perusahaan. Salah satu
alasannya adalah karena basis data merupaka gudang utama bagi perusahaan. Jika terjadi error pada proses
pemrograman basis data, maka konsekuensinya akan dirasakan oleh sebagian besar pengguna. Karena alasan
tersebut, perusahaan ingin Basis data Programmer dipilih dari personil terbaik yang ada.
Basis data Programmer biasa menulis kode untuk memcah dan/atau mengumpulkan data dari basis data.
Seorang pengguna kemudian dapat mengunduh data tersebut dari basis data perusahaan ke computer
pribadinya. Salah satu keuntungannya adalah basis data perusahaan hanya perlu diakses sekali, dan
pemrosesan basis data selanjutnya terjadi hanya pada, computer pengguna, sehingga dapat mencapai efisiensi
yang lebih tinggi untuk penggunaan basis data. Keuntungan lainnya adalah pengguna tidak perlu mengakses
keseluruhan basis data perusahaan, dan karena pengguna lebih mungkin melakukan kesalalahan daripada
Basis data Programmer, maka basis data akan tetap aman.

Pengguna Akhir
Pengguna akhir tidak bisa dihiraukan sebagai personil penting yang berinteraksi dengan basis data.
Mereka menghasilkan laporan, pertanyaan terhadap basis data, dan menggunakan hasil dari penyelidikan basis
data untuk membuat keputusan yang berdampak terhadap perusahaan dan lingkungannya.
Software sistem manajemen basis data sudah berevolusi untuk berinteraksi dengan pembuatan
keputusan. Pengguna tidak perlu tau bagaimana bagaimana kode pernyataan bahasa terstruktur. Bentuk query-
by-example membiarkan pengguna memilih beberapa pilihan dan menjalankan penyelidikan. Kemudahan yang
meningkat telah menyebabkan peningkatan penggunaan oleh pengguna akhir basis data, sehingga
meningkatkan jumlah error oleh oenggun akhir.
Sistem manajemen basis data menggunakan asumsi mengenai apa yang pengguna inginkan ketika
mereka mengklik basis data. Jika pengguna tidak paham akan asumsi yang dibuat, data yang ditampilkan
mungkin tidak sesuai dengan apa yang dibutuhkan untuk pengambilan keputusan. Pengguna butuh pelatihan
mengenai sistem basis data sehingga sumber daya basis data bisa menjadi asset saat pengambilan keputusan.

SISTEM MANAJEMEN BASIS DATA SEBAGAI PERSPEKTIF

Sistem manajemen basis data memungkinkan kita untuk meembuat dataase, memelihara
kontennya, dan menyebarkan data ke pengguna dalam cakupan yang luas tanpa menambah biaya
pemrograman komputer. Kemudahan dalam penggunaannya juga membuat manajer dan staf
profesional dapat mengakses kontennya hanya dengan pelatihan sederhana.
Setiap bagian dari IT memiliki keebihan dan kekurangan, begitu pula dengan sistem manajemen
basis data.
Kelebihan Sistem Manajemen Basis data
Kelebihan DBMS telah disebutkan sebelumnya, namun masih tetap penting untuk disebutkan
kembali. DBMS memberi keuntungan pada perusahaan dan penggunanya untuk:
 Mengurangi jumlah data yang berlebih. Jumlah data berkurang dibandingkan pada saat file data disimpan
di komputer yang terpisah. Duplikasi data terbatas pada kebutuhan untuk menggabungkan data dari dua
tabel berbeda. Data yang memiliki keasamaan, pada hubungan relasi sistem manajemen basis data,
digunakan untuk membentuk hubungan implisit antar data.
 Mencapai kebebasan data. Spesifikasi data diatur dalam basis data itu sendiri, tidak di masing-masing
program aplikasi lagi. Perubahan mungkin dilakukan satu kali, pada struktur data, tanpa memerlukan
perubahan pada banyak program aplikasi untuk mengakses data.
 Memperoleh data dan informasi dengan cepat. Hubungan logis dan bahasa yang terstruktur membuat
pengguna dapat memperoleh data dalam hitungan detik atau menit , padahl biasanya bisa memerlukan
beberapa jam bahkan hari untuk memperolehnya dengan bahasa pemrograman tradisional seperti COBOL
atau Java. Hal tersebut dapat terjadi terjadi karena program komputer dalam bahasa COBOL maupun Java
tidak perlu ditulis ulang sebelum diakses. Sistem manajemen basis data sendiri akan menyediakan tools
seperti BE dan SQL untuk mengakses data.
 Meningkatkan keamanan. Baik frame utama maupun komputer mikro DBMS juga mencakup pengaman
multilevel seperti password, folder pengguna, dan enkripsi. Data yang dikelola oleh DBMS lebih aman
dibandingkan data lain di perusahaan.

Kekurangan Sistem Manajemen Basis data

Sebuah keputusan untuk menggunakan DBMS mengharuskan penggunanya untuk:
 Membeli software yang mahal. Frame utama dari DBMS cukup mahal. Komputer mikro DBMS, meskipun
harganya hanya beberpa ratus dollar, sangat substansial untuk perusahaan. Untungnya, Hukum Moore
masih berlaku, dan biaya dari perangkat keras dan lunak semakin menurun. Kekurangan ini menjadi semakin
tidak penting dari tahun ke tahun.
 Memerlukan konfigurasi hardware secara besar-besaran. Kemudahan dalam pengaksesan informasi
membuat semakin banyak pengguna menggunakan basis data. Peningkatan jumlah pengguna dapat
berakibat pada peningkatan kebutuhan jumlah komputer untuk mengakses basis data.
 Menerima dan mengelola staff DBA. DBMS membutuhkan pengetahuan spesifik untuk memaksimalkan
kegunaannya. Pengetahuan spesifik ini dimiliki oleh administrator basis data.

DBMS bukanlah persyaratan utama dalam pemecahan masalah. Akan tetapi, spesialis informasi
dan pengguna menganggapnya sebagai salah satu pertolongan utama bagi perusahaan dalam
pembuatan keputusan.
 Kesimpulan

Komputer kian lama kian kuat, dan biaya sumber daya komputasi terus menurun. Pada waktu yang bersamaan,
organisasi-organisasi bisnis memiliki data dalam jumlah besar dan menyimpannya di dalam basis data.
Perangkat lunak sistem manajemen basis data sangat penting untuk mengorganisir/mengelola data menjadi
sebuah struktur yang memfasilitasi pencarian dengan cepat.
Basis data relasional telah menjadi struktur basis data yang dominan pada perusahaan-perusahaan untuk
dua alasan. Pertama, secara konseptual, basis data relasional mudah untuk dimengerti. Kedua, struktur
relational basis data mudah untuk diubah karena menggunakan hubungan implisit antar data. Tabel pada
relational basis data mirip dengan spreadsheet; tabel merupakan file spreadhsheet, kolom pada spreadsheet
berhubungan dengan fields, baris pada spreadsheet berhubungan dengan record. Hubungan antar table
terbentuk ketika nilai data field dari field yang dimiliki bersama sama. Sistem manajemen untuk relational basis
data relatif mudah untuk para manajer untuk dimengerti dan digunakan.
Memahami struktur basis data dimulai dengan memahami peran data dalam pembuatan keputusan.
Perusahaan-perusahaan dapat memulai dengan permasalahan yang mereka hadapi dan membangun data yang
dibutuhkan dari metodologi yang berorientasi pada proses (process-oriented methodology). Jika perusahaan
ingin mengambil keuntungan dari kesamaan masalah yang ada di seluruh area bisnis, ia dapat menerapkan
pendekatan enterprise modeling. Apapun metode yang digunakan untuk spesifikasi, suatu teknik tetap harus
digunakan untuk menggambarkan data yang dibutuhkan. Diagram hubungan antar entitas (entity-relationship
diagrams) dan diagram kelas (class diagrams) merupakan alat yang memungkinkan pengguna dan spesialis
sistem informasi untuk mengkomunikasikan kebutuhan data.
Data secara khusus diambil melalui laporan (reports) dan formulir (forms). Tetapi, karena manajer
memerlukan akses langsung yang lebih cepat terhadap data, mereka menuliskan pertanyaan (queries) untuk
basis data-nya sendiri. Jika manajer tidak mengetahui asumsi yang digunakan oleh sistem manajemen basis
data untuk memproses queries, laporan (reports), dan foemulir (forms), mereka mungkin menemukan bahwa
data yang diambil bukan data yang dimaksud.
Besarnya data yang berkaitan dengan bisnis modern dan pengaruh pentingnya pada operasi bisnis telah
bergabung untuk menciptakan posisi basis data administrator pada kebanyakan organisasi-organisasi besar.
Tugas dari orang ini mencakup bekerja dengan manajemen untuk merencanakan struktur dan data organisasi
yang dimiliki oleh organisasi. Masalah keamanan sangat penting, khususnya karena Internet memungkinkan
individu di luar organisasi untuk mengakses informasi yang memuat basis data dari organisasi. Kurang
dipublikasikan, tapi sama pentingnya, yaitu peran basis data administrator dalam melatih pengguna yang
membutuhkan akses pada basis data. Keamanan perlu menjauhkan induvidu yang tidak berwenang serta
memperkenankan akses yang mudah bagi individu yang berwenang.
Seluruh manajer perlu untuk memahami struktur dasar basis data dan bagaimana untuk mengambil data
dari basis data. Pemahaman ini sangat penting untuk pengambilan keputusan yang cerdas.

ISTILAH-ISTILAH KUNCI

data field file flat file

record basis data kunci
basis data management akurasi data query
system (DBMS) independensi data query-by-example (QBE)
struktur hirarkis basis data kamus data structured query language (SQL)
struktur jaringan basis data process-oriented modeling on-line analytical processing
struktur basis data relasional pendekatan enterprise modeling (OLAP)
hubungan fisik entity-relationship diagram (ERD) basis data administrator (DBA)
hubungan implisit class diagram basis data programmer
redundansi data formulir (form)
konsistensi data laporan (report)

KONSEP-KONSEP KUNCI

● struktur relational basis data ● permodelan data (data modeling)

● konsep basis data

QUESTIONS

1. How do the general and restrictive definitions of a basis data differ?

 Sebuah basis data adalah sebuah koleksi files. Definisi umum basis data adalah koleksi atau kumpulan dari
seluruh data perusahaan berbasis komputer. Definisi basis data yang lebih terbatas adalah koleksi data yang
dikontrol/dikelola oleh perangkat lunak sistem manajemen basis data. Berdasarkan definisi tersebut, data
perusahaan yang dikontrol dan dikelola oleh suatu sistem manajemen basis data akan dianggap masuk ke
dalam basis data; files komputer pada komputer pribadi manajer atau personil lainnya akan dianggap berada
di luar basis data.

2. Assume you know there is a salary value of $45,000. Is $45,000 (a) a data field value, (b) a data field name,
or (c) a record?
 Data field merupakan unit terkecil dari data; ia merepresentasikan jumlah terkecil dari data yang akan
diperoleh/diambil dari sebuah komputer pada tertentu. Record merupakan sebuah koleksi data fields yang
berkaitan. Nilai-nilai di dalam records merepresentasikan nilai dari data fields. Dalam hal ini, salary value
adalah data field dan $45,000 merupakan data field value.

3. You open a file (such as a spreadsheet file) and see column headings of “StudentID,” “StudentName,”
“Semester,” “Course1,” “Grade1,” “Course2,” “Grade2,” “Course3,” and “Grade3.” Why is this not a flat file?
 Untuk kasus ini, dapat dicontohkan dengan tabel berikut ini.
 Pada baris pertama, komputer akan membaca tujuh nilai, yaitu: “1206201831,” “Ayudya Triastika,” “6,”
“Management Information System,” “A,” “Supply Chain Management,” dan “A”. Untuk selanjutnya, komputer
diharapkan dapat membaca sembilan nilai, yaitu: “1206241962,” “Nabila Priscandy,” “6,” “Management
Information System,” “A,” “Supply Chain Management,” “A,” “Enterprise Competitiveness Analysis,” dan “A.”
Tetapi, komputer membaca “1206241962,” dan “Nabila Priscandy” sebagai nilai kedepalan dan kesembilan
untuk baris pertama.
Tabel tersebut tidak dapat disebut flat file karena melanggar persyaratan pengulangan kolom. Pengulangan
kolom menyebabkan urutan data menjadi tidak konstan. Salah satu alasan mengapa sebuah tabel harus
merupakan flat file adalah karena komputer membaca data fields dari sebuah record sesuai urutan. Ketika
urutannya tidak konstan, komputer tidak dapat membaca records dengan benar.

4. What is a key?
 Kunci dalam sebuah tabel merupakan sebuah field (atau gabungan dari dua atau lebih field) yang memuat
sebuah nilai yang secara unik mengidentifikasi setiap record di dalam tabel. Hal ini berarti bahwa setiap baris
dalam tabel akan secara unik teridentifikasi. Seringkali, sebuah field tunggal menjadi sebuah kunci untuk
sebuah tabel. Nilai kunci haruslah unik untuk seluruh tabel.

5. What is a candidate key?

 Beberapa tabel mungkin memiliki dua fields yang menjadi kandidat untuk menjadi kunci. Kunci kandidat
merupakan sebuah field yang secara unik mengidentifikasi setiap baris tabel, tetapi tidak dipilih untuk
menjadi kunci. Seringkali, ketika dihadapkan dengan sebuah pilihan antara dua field yang masing-masing
dapat menjadi kunci, field yang lebih kompak/ringkas dipilih karena nilai field yang lebih panjang
menyajikan/membawa resiko kesalahan penulisan nilai kunci field yang lebih tinggi.

6. How are relationships between tables established for relational basis data?
 Hubungan antar tabel dapat teridentifikasi bila tabel-tabel tersebut berbagi sebuah field yang sama dan nilai
dari field tersebut menentukan bagian dalam tabel yang mana yang secara logis tergabung. Kadang, tabel-
tabel yang awalnya berdiri sendiri sebagai tabel yang independen nantinya mungkin diperlukan untuk
digabung. Penggabungannya dilakukan dengan menambahkan sebuah field yang disengajakan untuk dimiliki
bersama oleh tabel-tabel tersebut. Penambahan field ini akan memudahkan proses identifikasi.

7. Why has the relational basis data structure been so much more successful than the hierarchial or network
work structures?
 Karena pada dasarnya, perusahaan butuh untuk mengatasi masalah manajerial menggunakan basis data
dan hal ini dapat dilakukan jika perusahaan menggunakan relational basis data structure. Selain itu, struktur
hierarkis dan jaringan bergantung pada hubungan fisik yang berbentuk alamat penyimpanan sedangkan
hubungan-hubungan di dalam relational basis data structure bersifat implisit sehingga mudah digunakan.

8. What is data independence?

 Independensi data adalah kemampuan untuk melakukan perubahan pada struktur data tanpa melakukan
perubahan pada program-program aplikasi yang memproses data. Contohnya, program komputer yang
memproses pesanan pembelian adalah program yang terpisah dari data pesanan pembelian yang disimpan
di dalam basis data. Independensi data tercapai dengan menempatkan spesifikasi data di dalam tabel-tabel
dan kamus yang secara fisik terpisah dari program.
9. How does data redundancy lead to data inconsistency?
 Basis data akan memecah informasi ke dalam beberapa tabel karena jika informasi disimpan hanya pada
satu tabel, maka akan terdapat banyak nilai data field yang terduplikasi; sehingga menyebabkan data
menjadi berulang (redundant). Data yang berulang akan membuat data menjadi inkonsisten karena
pengulangan tersebut.

10. What is the difference between the process-oriented approach to determining data needs and the enterprise
modeling approach?
 Pendekatan berorientasi proses merupakan suatu pendekatan yang berorientasi pada masalah dan dimulai
dengan mendefinisikan masalah sampai menspesifikasikan kebutuhan data yang dihasilkan. Pendekatan
pemodelan perusahaan dimulai dengan mengatur seluruh kebutuhan data perusahaan dan kemudian
menyimpannya dalam basis data.

11. When should a form use a process-oriented approach to determine data needs as opposed to an enterprise
modeling approach?
 Ketika masalah tertentu disajikan kepada perusahaan, pendekatan berorientasi proses lebih baik
dibandingkan dengan pendekatan pemodelan perusahaan.

12. What is represented in a class diagram that is not represented in an entity-relationship diagram?
 Sesuatu yang ditampilkan dalam class diagram tetapi tidak dapat ditampilkan dalam entity-relationship
diagram adalah adanya representasi dari tindakan-tindakan yang dapat dilakukan pada data, bukan hanya
data dan hubungan antar data seperti yang ditampilkan dalam entity-relationship diagram.

13. How are users more likely to obtain information from a basis data? Would they use query-by-example or
structured query language?
 Pengguna lebih memilih untuk menggunakan query-by-example daripada bahasa query yang terstruktur.

14. Who in the firm is primarily responsible for basis data security?
 Orang yang memiliki tanggung jawab utama terhadap keamanan basis data dalam perusahaan adalah Basis
data Administrator (DBA).

15. The cost of basis data management software and hardware is an often-cited disadvantage. Why are those
costs becoming less significant?
 Biaya dari hardware dan software basis data sesuai dengan Morore’s Law, dan biaya mereka akan turun
setiap tahunnya walaupun produknya semakin powerful.

CATATAN
1David C. Hayes and James E. Hunton, “What You
Better Know About Basis datas,” Jurnal of
Accountancy 187(1) (January 1999), 61-63.
2Helen Hasan, Peter Hyland, David Dodds, and
Raja Veeraraghavan, “Approaches to the
Development of Multi-Dimentional Basis datas:
Lessons from Four Case Studies,” Basis data for
Advances in Information Systems 31(3) (Summer
2000), 10-23.
3Robert W, Taylor and Randall L. Frank,
“CODASYL Data-Base Management System,” ACM
Computing Surveys 8(1) (March 1976), 67.
4Andrew B. Whinston adn Clyde W. Hotsapple, Transactions on Basis data System 1(1) (March
“DMS for Micros,” Datamation 27(4) (April 1981), 1876), 9-36.
165-166. 10Peter Chen, originator of the Entity-Relationship

5”CODASYL: Introduction to Feature Analysis of (ER) model, was awarded the Harry M. Goode
Generalized Data Base Management Systems,” Memorial Award from the IEEE Computer Society in
Communications of the ACM 14(5) (May 1971), 2002.
308-318. 11N. Colossi, W. Malloy, and B. Reinwald,

6C. J. Date, An Introduction to Basis data Systems “Relational Extensions for OLAP,” IBM Systems
(Addison-Wesley: Reading, MA, 1977). Journal 41(4), 714-731.
7E. F. Codd, “A Relational Model of Data for Large 12Adopted from Doug Levy, “Computing Cures

Shared Databanks,” Communications of the ACM Basis data May Put Drugs on Shelves Years
(June 1970), 377-387. Faster,” USA Today, May 17, 1998, Feature –
8Guy Doumeingth, Yves Dueq, and Bruno Vallespir, Money Section, 1-B.
“Production Management and Enterprise Modelling,”
Computers in Industry 42(2, 3), 245-263.
9Peter Chen, “The Entity-Relationship Model –

Towards a Unified View of Data,” ACM