Panduan Untuk Penambangan Data yang Ramah Anggaran

Tidak seperti pemrograman aplikasi tradisional, di mana fungsi API berubah setiap hari, pemrograman database pada dasarnya tetap sama. Versi pertama Microsoft Visual Studio .NET dirilis pada Februari 2002, dengan versi baru dirilis setiap dua tahun, tidak termasuk rilis Service Pack. Laju perubahan yang cepat ini memaksa personel TI untuk mengevaluasi aplikasi perusahaan mereka setiap beberapa tahun, membiarkan fungsionalitas aplikasi mereka tetap utuh tetapi dengan kode sumber yang sama sekali berbeda agar tetap terkini dengan teknik dan teknologi terbaru.

Hal yang sama tidak dapat dikatakan tentang kode sumber database Anda. Kueri standar SELECT / FROM / WHERE / GROUP BY , yang ditulis kembali pada hari-hari awal SQL, masih berfungsi sampai sekarang. Tentu saja, ini tidak berarti tidak ada kemajuan dalam pemrograman database relasional; ada, dan mereka lebih logis daripada teknis .

Mulai dari hari-hari ketika Bill Inmon dan Ralph Kimball menerbitkan teori mereka tentang desain gudang data, kemajuan dalam pemrograman basis data telah difokuskan untuk mencegah hilangnya informasi berharga dan mengekstraksi semua informasi berharga dari data. Setelah Inmon dan Kimball memperkenalkan dunia basis data ke pergudangan data, perubahan besar dilakukan pada alat ETL (Extract/Transform/Load) yang memberi pengembang basis data akses mudah ke metadata, dan data dari sumber basis data non-relasional, yang sulit untuk dikerjakan. di masa lalu. Ini meningkatkan jumlah data yang tersedia untuk mengekstrak informasi berharga, dan peningkatan data yang tersedia ini menyebabkan kemajuan dalam pemrosesan data melalui kubus OLAP dan algoritme penambangan data.

Menambahkan gudang data, kubus OLAP, dan algoritme penambangan data ke arsitektur database Anda dapat secara dramatis merampingkan proses bisnis dan menerangi pola dalam data Anda yang sebelumnya tidak akan pernah Anda ketahui keberadaannya. Otomatisasi juga dapat berdampak besar pada kemampuan intelijen bisnis.

Namun, sebelum Anda mulai menambahkan alat dan teknologi baru, Anda harus memastikan bahwa database transaksi dibuat dengan benar.

Basis Data Transaksi

Basis data transaksi adalah fondasinya, dan jika basis data transaksi Anda tidak dapat diandalkan dan akurat, maka menambahkan apa pun di atasnya adalah resep bencana.

Poin penting yang perlu diingat ketika menambahkan lapisan tambahan ke database Anda adalah bahwa semua proyek harus menunjukkan laba atas investasi , itulah sebabnya yang terbaik adalah untuk mendapatkan hasil maksimal dari arsitektur Anda saat ini sebelum menambahkan lapisan lebih lanjut. Semua lapisan ini memanfaatkan data yang berasal dari database transaksi. Dalam banyak situasi, Anda bisa mendapatkan hasil yang sama hanya dengan menanyakan basis data transaksi Anda. Tentu saja, membuat semua laporan Anda dibaca dari gudang data atau kubus OLAP adalah metode yang ideal, tetapi ketika sebuah organisasi belum siap untuk tingkat kerumitan itu, lebih penting bahwa kebutuhan pelaporannya dipenuhi terlebih dahulu. Setelah kebutuhan pelaporan dasar terpenuhi, akan lebih mudah untuk memulai diskusi tentang bagaimana gudang data yang tepat, dan mungkin kubus OLAP, dapat menguntungkan bisnisnya.

Hampir setiap programmer mengetahui tiga aturan normalisasi database. Prosedur tersimpan yang membaca dari database transaksi adalah jalur menuju optimasi. Masalah yang harus dicari adalah keterbacaan, beberapa panggilan ke tabel database yang sama, dan penggunaan variabel yang tidak perlu.

Semua pemrogram basis data elit pilih-pilih tentang keterbacaan prosedur tersimpan mereka. Ada beberapa kesamaan dalam cara profesional database memformat kueri mereka, yang berbeda dari pengembang aplikasi. Biasanya, kata kunci dan fungsi agregat ditulis dalam huruf kapital, sedangkan nama tabel dan bidang menggunakan huruf besar atau garis bawah. Alias ​​tabel memiliki beberapa korelasi dengan nama tabel yang sebenarnya. Penjajaran bagian dari prosedur tersimpan memiliki beberapa jenis pola blok.

Di bawah ini adalah contoh kueri yang menggunakan format yang dapat dibaca.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Hal berikutnya yang harus dicari adalah jika kueri mengenai tabel lebih dari sekali. Di sebagian besar kueri, tabel hanya perlu diakses sekali, tidak termasuk waktu yang jarang Anda perlukan untuk menggabungkan fungsi agregat lainnya. Ini adalah kesalahan lain yang dibuat oleh beberapa pemrogram aplikasi, mungkin karena pemrogram aplikasi berpikir dalam kerangka desain berorientasi objek.

Desain berorientasi objek membuat objek terpisah untuk setiap elemen data unik, tetapi pemrogram basis data perlu berpikir dalam kerangka logika yang ditetapkan. Hanya karena kueri mengakses tabel lebih dari yang dibutuhkan tidak berarti bahwa kueri menghasilkan data yang tidak akurat, namun kinerja kueri terpengaruh.

Kekhawatiran lain dijatuhkan, atau digandakan, catatan setiap kali Anda bergabung, mengorbankan keakuratan kueri Anda. Penggunaan variabel yang tidak perlu adalah tanda lain bahwa kueri dikembangkan oleh pengembang aplikasi. Pengembang aplikasi menggunakan variabel di seluruh kode mereka sementara kueri sangat jarang perlu menggunakan variabel kecuali jika dideklarasikan sebagai parameter untuk prosedur tersimpan. Sekali lagi itu adalah tanda bahwa pengembang tidak berpikir dalam kerangka logika yang ditetapkan.

ETL (Extract Transform Load) Dan Pelaporan

Setelah database transaksi klien memiliki kueri yang berfungsi dengan baik, langkah selanjutnya adalah merampingkan proses bisnis.

Cara termudah untuk mengidentifikasi kebutuhan bisnis untuk proses ETL atau pelaporan otomatis adalah dengan mencari tahu siapa yang membaca data dari database transaksi dan kemudian memanipulasi data menggunakan spreadsheet. Spreadsheet adalah struktur yang sama dengan tabel database. Keduanya berisi baris dan kolom. Jika Anda memiliki pengguna akhir yang memanipulasi data mereka sendiri, Anda harus bertanya pada diri sendiri, “Mengapa proses itu tidak dapat diotomatisasi?”

Mengotomatiskan proses bisnis memberikan pengembalian investasi langsung dan harus selalu dipertimbangkan sebelum beralih ke proyek yang lebih mahal, seperti pergudangan data. Mengidentifikasi pengguna akhir yang memanipulasi data melalui spreadsheet mungkin terdengar sederhana tetapi ada peringatan untuk proses ini.

Pengembang suka mengotomatiskan proses; itu yang mereka lakukan. Pengguna akhir tidak selalu menyukai proses otomatis, terutama jika mereka mengancam pekerjaan mereka. Jadi, jangan naif dan berpikir bahwa pengguna akhir akan mengejar Anda dan mengidentifikasi tugas harian yang dapat diotomatisasi. Anda benar-benar perlu memimpin dalam mengidentifikasi peluang perampingan.

Sistem ETL yang dibangun dengan baik juga harus menyediakan kemampuan untuk melacak kembali semua data yang dimuat dalam database transaksi kembali ke file sumber aslinya. Ini adalah bagian penting dari arsitektur database. Jika Anda tidak mengetahui tanggal/waktu yang tepat kapan setiap catatan ditambahkan, bersama dengan nama sumber (nama pengguna atau nama file) yang menambahkan catatan, maka Anda tidak siap untuk menangani data buruk yang dimuat ke dalam basis data transaksi Anda. Anda harus bertanya pada diri sendiri, "Bagaimana jika seseorang mengirimi kami file yang buruk?" Berapa lama waktu yang Anda butuhkan untuk mengidentifikasi catatan yang berasal darinya?

Gudang data

Ada dua teori untuk desain gudang data. Perbedaan antara teori Inmon dan Kimball dapat diringkas sebagai berikut:

Teori Inmon adalah pertama-tama mengembangkan data warehouse dan kemudian membangun dimensional data mart untuk pelaporan dari data warehouse. Teori Kimball pertama-tama mengembangkan data mart dimensi untuk pelaporan dan kemudian menggabungkannya bersama-sama untuk membuat gudang data.

Anda selalu ingin memberikan pengembalian investasi tercepat kepada klien. Membangun data mart adalah proses yang sederhana. Anda mulai dengan mengambil kueri di balik laporan Anda dan mengubahnya dari mengembalikan kumpulan hasil menjadi menyimpan kumpulan hasil dalam tabel permanen. Anda cukup menambahkan TRUNCATE TABLE ; INSERT INTO tablename sebelum kata kunci SELECT asli. Setelah Anda memiliki beberapa tabel data mart fungsional, mengidentifikasi peluang untuk menggabungkan data mart harus dilakukan; cari kueri laporan yang menggunakan daftar tabel yang sama, lalu gabungkan daftar bidang. Ini membutuhkan kueri yang lebih rumit, terutama ketika daftar tabel bertambah. Namun, selama Anda menguji kueri secara menyeluruh, setiap perubahan inkremental dapat dilakukan tanpa mengganggu proses bisnis normal.

Setiap kali Anda membuat peningkatan pada desain gudang data Kimball, Anda memiliki kesempatan untuk menunjukkan ROI kepada klien. Itu karena data warehouse dibangun terlebih dahulu dan data mart pelaporan dibangun dari data warehouse statis. Oleh karena itu, Anda menanggung sebagian besar biaya Anda di awal proyek gudang data.

Kubus OLAP

Kubus OLAP dapat bermanfaat bagi organisasi dengan menyediakan data agregat dengan waktu respons yang cepat, kemampuan penelusuran ad-hoc untuk pengguna akhir, dan penambangan data. Bila Anda memiliki kubus OLAP yang tepat, Anda dapat mengekstrak setiap bit nilai dari data Anda. Sebuah kubus OLAP dibangun di atas gudang data, tetapi menggunakan bahasa yang berbeda, MDX, dari database SQL standar. Ini juga membutuhkan upaya konfigurasi yang lebih terlibat daripada server database. Kompleksitas itu membuat proyek OLAP menjadi mahal, ditambah lagi sulit untuk menemukan pengembang MDX yang berpengalaman.

Arsitek data terkadang melihat kubus OLAP yang ada dengan tidak lebih dari dasbor sederhana yang menggunakan kubus, tanpa satu proses pun yang tidak dapat digantikan oleh kueri SQL, gudang data, atau laporan kalengan. Kubus OLAP dapat memberikan waktu respons yang lebih cepat daripada laporan kalengan, tetapi dalam kebanyakan situasi perbedaannya dapat diabaikan. Anda juga dapat memperoleh manfaat dari kemampuan menelusuri, namun, sebelum memberikan kemampuan menelusuri pengguna akhir, sebaiknya gunakan laporan terekam yang menyediakan antarmuka ad hoc yang serupa.

Ini memungkinkan Anda untuk merekam kueri ad hoc yang dijalankan oleh pengguna akhir, kemudian Anda dapat mengidentifikasi laporan terekam baru yang tidak disadari oleh pengguna akhir dapat dibuat. Karena waktu respons dan peningkatan penelusuran biasanya minimal saat mengembangkan kubus OLAP, tidak perlu menyarankannya ke klien sampai mereka membutuhkan arsitektur database yang dapat menangani penambangan data yang terlibat. Ini adalah saat Anda benar-benar dapat membuat klien terkesan dan menunjukkan kepada mereka sesuatu tentang bisnis mereka yang mungkin tidak pernah mereka ketahui tanpa arsitektur database yang kuat.

Seperti yang disebutkan sebelumnya, membangun kubus OLAP bisa jadi menantang. Merupakan kebijakan yang baik untuk mempertimbangkan kubus OLAP hibrida. PowerPivot dari Microsoft Excel menyediakan alat penambangan data yang mudah digunakan tanpa kerumitan OLAP cube penuh. Kerugian utama dari hibrida adalah bahwa ia tidak memiliki waktu respons yang sama. Namun, keuntungan besar adalah lebih mudah membuat laporan penambangan data menggunakan Excel dibandingkan dengan menggunakan MDX. Saat data mining, ada tiga laporan yang berguna. Kita dapat melihat beberapa contoh dunia nyata dan bagaimana menafsirkannya.

Semua laporan ini berasal dari aplikasi perdagangan hari otomatis yang dibuat oleh penulis.

Pelaporan Visual

Laporan Plot Sebar

Laporan plot sebar adalah laporan tingkat detail yang membandingkan dua variabel. Menambahkan warna dan ukuran ke titik sebenarnya membantu memvisualisasikan hasil aktual dalam kaitannya dengan variabel tersebut.

Laporan Kotak dan Kumis

Laporan ini merangkum nilai x dan y dari laporan plot sebar. Nilai sumbu x didiskritisasi menjadi satu set ember.

Ujung setiap kumis (garis) mewakili outlier. Bilah kuning dan biru muda mewakili rentang standar deviasi atas dan bawah.

Model Regresi Linier

Laporan ini menunjukkan korelasi antara nilai sumbu x dan y, serta pemulusan garis, yang dapat diwakili oleh rumus matematika. Nilai R kuadrat dimasukkan untuk menunjukkan seberapa andal korelasinya.

Kesimpulan

Seiring pertumbuhan perusahaan Anda, biasanya database Anda juga akan tumbuh.

Sebagian besar organisasi pada awalnya tidak memerlukan database profesional atau perusahaan ilmu data khusus yang menangani kebutuhan mereka. Sebaliknya, mereka memiliki staf TI mereka yang menangani banyak tanggung jawab atau, seperti kata pepatah, "pakai banyak topi". Ini berfungsi sampai titik tertentu , tetapi pada akhirnya, Anda perlu membawa spesialis.

Item yang tercantum dalam dokumen ini adalah cara cepat dan mudah untuk mengidentifikasi masalah database yang mungkin tidak Anda sadari. Semoga, ini juga membahas bagaimana Anda dapat membangun alat penambangan data terbaik tanpa menghabiskan banyak lisensi perangkat lunak yang mahal. Dengan cara ini Anda akan mendapatkan gambaran yang lebih baik tentang seberapa besar manfaat yang dapat diperoleh organisasi Anda dengan menambahkan profesional database ke staf TI Anda.