Unregistered Member
sign up
 Login

Username or Email

Password

Forget Password?

Free Register

 Main Page
 Announcement
 Discussion
 Article
 Photo Album
 Market Place
 Sharing List
 Stateboard
 Member List
 Like
 Applications
 Sign-Up

Article

 DilaDellila • 8 years ago • 3,605 viewed


Artikel yang bertajuk memahami konsep asas dalam pengurusan DB ini bertujuan informasi untuk semua pembaca. Konsep ini boleh diaplikasikan kepada semua jenis DB. Sekiranya ada yang tersilap, saya memohon maaf dan harap anda boleh menegur dan memperbetulkan kesilapan tersebut.

‘Straight to the point’, saya lebih suka membincangkan dan menerangkan sesuatu melalui kaedah ‘visualization’ atau dengan kata lain, apa yang saya lihat itulah realitinya. Bagi saya kaedah ini adalah sangat bersesuaian sebelum kita memulakan langkah atau tindakan yang patut diambil. Walaupun kaedah atau konsep visualization ini melibatkan perkara yang nyata dan logic tapi perlu berhati-hati kerana apa yang kita lihat tidak semestinya menjangkaui apa yang kita fikirkan. Apabila ini terjadi, saya lebih suka membuat penilaian dan tanggapan-tanggapan tertentu sebelum terus mengambil langkah. Saya akan memikirkan pelbagai kemungkinan, masalah serta cara penyelesaiannya dan menyimpannya dalam memori. Tujuannya adalah sebagai satu persiapan atas kemungkinan-kemungkinan yang akan berlaku. Barulah saya akan pergi ke masalah dengan lebih terperinci iaitu mengamati, mengenalpasti, membuat pemerhatian, menganalisis, dan cari penyelesaian. Tak cukup dengan itu, saya akan menggunakan konsep ‘direct communication’ sekiranya apa yang saya lihat kurang jelas.

Saya bukan cakap-cakap kosong. Apa yang saya beritahu berdasarkan pengalaman. Sebagai contoh, saya pernah bekerja di sebuah syarikat yang mana urusniaganya adalah bercabang-cabang. Saya puji syarikat ini kerana mempelbagaikan urusniaga untuk keuntungan maksimum dan pusingan modal tetapi terdapat banyak masalah yang saya lihat/perhatikan dan tidak diatasi sejak syarikat ini ditubuhkan. Bayangkan, 30 tahun syarikat ini berdiri kukuh tetapi tidak ada perubahan yang dibuat untuk mengatasi masalah itu. Nak tahu apa masalah syarikat ini?. Cuba teka. Sudah tentulah masalah yang berkaitan dengan pengurusan seperti ‘file and data management’-mengakibatkan kerja menjadi kurang efisyen dan pembaziran masa, ‘office management’-tidak ada hieraki tertentu, ‘staff management’-berlaku pengabaian yang menyebabkan terjadinya konflik, ‘finance management’-tidak tentu/seimbang menimbulkan kekeliruan angka. Oleh kerana masalah ini dipandang enteng oleh majikan, ramai pekerjanya tidak tahan bekerja di syarikat itu termasuklah saya. Kalau diberitahu pun bos akan memberi alasan tidak ada masa, takut kerja lain tertangguh, atau dengan ayat ini ‘Cuba kamu tengok dan lihat sendiri. Berapa lama syarikat ini bertahan?. Macam-macam masalah datang tetapi saya boleh uruskan walau tanpa bantuan kamu’. Sombongkan.

Saya bukan nak memburukkan syarikat in tetapi saya mengambil contoh untuk mengetengahkan masalah untuk membincangkan konsep pengurusan DB. Diantara semua masalah yang saya nyatakan diatas, saya mengambil bahagian ‘file and data management’. Berikut adalah masalah yang saya reka sendiri.

Company A merupakan sebuah syarikat penjual barang-barang elektrik. Setiap bulan company A harus menyemak barangan elektrik tersebut untuk tujuan kemaskini. Tingkahlaku ini kita boleh klasifikasikan sebagai semakan status stok dalam inventori. Apabila stok didapati berkurangan, company A harus membuat tempahan agar bekalan stok tidak habis atau berkurangan. Kita wakilkan sebagai 'Purchase Order'. Untuk tujuan itu, company A telah membuat quotation daripada pihak pembekal atau kita gelarkan sebagai company B sebelum urusniaga jual beli berlaku. Company A menyediakan satu invois membuat tempahan dan menghantar invois tersebut kepada Company B sebaik sahaja persetujuan urusniaga berlaku antara kedua-dua pihak. Company B akan menghantar stok yang ditempah bersama dengan satu invois yang baru atau lebih dikenali sebagai 'Sales Order' kepada company A. Pembayaran dilakukan dan transaksi selesai. Kemudian, Company A mengemaskini stok mereka dan menghasilkan satu laporan baru. (Semua data dan transaksi yang berlaku dicatat dan direkodkan dalam format excel dan diletakkan dalam folder dan file yang berasingan. Belum ada lagi sistem yang wujud untuk merekod, menyusun, mengemaskini secara auto dan pantas)

Ini adalah senarai butiran yang terdapat dalam senarai Quo,PO,SO,Payment Receipt, dan Stok.
• Quo
• PO-PO No, PO Date, Resale No, Name, Contact, Supplier, No, Product Code, Product Name, Des, Req Date, Qty, Unit Price, Price, Quote No, Total, Terms/Notes, Acknowledgement Name, Date, Buyer, Date.
• SO
• Payment Receipt
• Stok

Butiran-butiran atau maklumat yang disenaraikan diatas ditukarkan dalam satu bentuk ‘database’ dan beberapa ‘entity’ atau ‘table’. (Perhatian : Saya hanya menyentuh bahagian ‘Purchase Order’ sahaja untuk tujuan pemahaman).

‘Database’ atau dikenali sebagai pangkalan data adalah struktur yang mengandungi pelbagai maklumat data yang berguna dan tentang hubungkaitnya ‘Relationship’. ‘Database’ digunakan oleh syarikat-syarikat yang berstatus besar mahupun kecil diseluruh dunia. ‘Database’ menyimpan, merekod, dan menyatukan semua data yang berkaitan untuk tujuan laporan, penilaian, penjimatan masa, dan melihat aliran data keluar dan masuk dalam organisasi. ‘Relationship’ adalah hubungkait antara dua ‘table/entity’ yang berlainan dalam satu ‘database’. ‘Table’ adalah perwakilan bagi setiap kumpulan data yang telah dikategorikan mengikut keperluan. ‘Table’ mengandungi semua maklumat yang diperlukan dan diwakilkan dengan satu ‘primary key’. Juga lebih dikenali sebagai ‘entity’. ‘Primary Key’ adalah ‘attribute’ yang mewakilkan setiap ‘column’ dalam ‘table’ yang mana fungsinya adalah saling bergantungan.

Demikianlah penerangan ringkas sebelum kita meneruskan langkah seterusnya iaitu pembinaan ‘database’. Sekarang, saya bina dan namakan ‘database’ tersebut sebagai DBMS dan ‘table’ tersebut adalah PO dan SO. Rujuk gambar dibawah.


Kedua-dua ‘table’ ini adalah asas dalam beberapa pembentukan ‘table’ baru setelah mengalami proses ‘normalization’. Maksudnya, ‘table’ ini boleh dipecahkan kepada bahagian-bahagian kecil yang boleh dikatkan dengan ikatan tertentu yang dipanggil ‘relationship’. Bahagian-bahagian ‘table’ yang kecil itu digelar sebagai ‘first, second, and third noramalization’. Tujuan proses ‘normalization’ ini mengelakkan ‘redundancy’ iaitu sekiranya kita memasukkan data yang sama, pertindihan data akan berlaku. Lihat contoh sebahagian data ‘table’ PO yang tertera.


Terdapat pertindihan dalam semua ‘table row’. ‘row’ pertama hingga ke-3 menunjukkan pertindihan pada ‘attribute’ atau ‘product code and resale no field’. Begitu juga pada ‘row’ yang ke-4 dan ke-5 tetapi tidak pada ‘resale no field’. ‘Redundancy’ akan menjadi lebih ketara apabila banyak data telah direkodkan. ‘Redundancy’ akan menimbulkan masalah seperti penggunaan ruang yang besar untuk memasukkan data (saiz fail menjadi besar), melibatkan pembaziran masa semasa memasukkan atau mengemaskini data yang sama, dan menjadikan data dalam ‘database’ itu tidak stabil. Oleh itu, ‘table’ perlu dinormalkan melalui 'normalization process' terlebih dahulu. 'Normalization Process' adalah satu proses menyingkirkan kumpulan berulangan untuk menghasilkan satu atau lebih bentuk ‘table’ baru yang normal. Gambar dibawah menunujukkan ‘Table’ PO yang telah dinormalkan kepada beberapa bentuk ‘table’ yang baru.


‘supplier table’ adalah bentuk normal ‘table’ yang pertama diikuti ‘company table’ ke-2, dan ‘product table’ ke-3. Semua ‘table’ ini kemudiannya diikat satu sama lain melalui ‘relationship’. Lihat model E-R dibawah.


Artikel lain yang menyusul membincangkan ‘relationship’ dan bagaimana hendak menggunakannya. Setakat ini sahaja yang mampu saya berikan dan terima kasih kerana meluangkan masa membaca artikel yang tidak seberapa ini.

Virtual Friends - Copyright © 2001-2020 Webber Dot My Solutions (002351632-A). All rights reserved