Halo! Nama saya Andrey Semenov, saya analis senior di Sportmaster. Pada postingan kali ini saya ingin mengangkat isu denormalisasi database sistem ERP. Kami akan melihat kondisi umum, serta contoh spesifik - katakanlah itu akan menjadi kedai monopoli yang bagus untuk bajak laut dan pelaut. Di mana bajak laut dan pelaut harus dilayani secara berbeda, karena gagasan tentang keindahan dan pola konsumen dari tuan-tuan yang baik ini sangat berbeda.
Bagaimana cara membuat semua orang bahagia? Bagaimana caranya agar Anda tidak menjadi gila dalam merancang dan memelihara sistem seperti itu? Apa yang harus dilakukan jika tidak hanya bajak laut dan pelaut biasa yang mulai berdatangan ke kedai?
Semuanya sedang dalam proses. Tapi mari kita mulai secara berurutan.
1. Keterbatasan dan asumsi
Semua hal di atas hanya berlaku untuk database relasional. Konsekuensi denormalisasi dalam bentuk anomali modifikasi, penghapusan, dan penyisipan, yang tercakup dengan baik, termasuk di Internet, tidak dipertimbangkan. Di luar cakupan publikasi ini terdapat kasus-kasus di mana denormalisasi adalah hal yang biasa, dengan contoh klasik: seri dan nomor paspor, tanggal dan waktu, dll.
Postingan ini menggunakan definisi bentuk normal yang intuitif dan dapat diterapkan secara praktis, tanpa mengacu pada istilah matematika. Dalam bentuk yang dapat diterapkan pada pemeriksaan proses bisnis nyata (BP) dan desain perangkat lunak industri.
Ada pendapat bahwa desain gudang data, alat pelaporan, dan perjanjian integrasi (yang menggunakan representasi informasi tabular) berbeda dari desain database sistem ERP karena kemudahan konsumsi dan penggunaan denormalisasi secara sadar untuk mencapainya mungkin lebih diutamakan daripada integritas. data perlindungan. Saya sependapat dengan pendapat ini, dan apa yang dijelaskan di bawah ini hanya berlaku untuk data master dan model data transaksional sistem ERP.
Penjelasan tentang bentuk-bentuk normal diberikan dengan menggunakan contoh yang dapat dimengerti sehari-hari oleh sebagian besar pembaca. Namun, sebagai ilustrasi visual, pada paragraf 4-5 sengaja digunakan tugas βfiksiβ. Jika Anda tidak melakukan ini dan mengambil beberapa contoh buku teks, misalnya, model penyimpanan urutan yang sama dari poin 2, Anda mungkin berada dalam situasi di mana fokus pembaca akan dialihkan dari usulan dekomposisi proses menjadi model, dengan pengalaman dan persepsi pribadi tentang bagaimana proses dan model penyimpanan data dalam IS harus dibangun. Dengan kata lain, ambillah dua analis TI yang berkualifikasi, misalkan yang satu memberikan layanan kepada ahli logistik yang mengangkut penumpang, dan yang lainnya kepada ahli logistik yang mengangkut mesin untuk produksi microchip. Minta mereka, tanpa membahas BP otomatis terlebih dahulu, untuk membuat model data untuk menyimpan informasi tentang perjalanan kereta api.
Ada kemungkinan bukan nol bahwa dalam model yang diusulkan Anda tidak hanya akan menemukan sekumpulan atribut yang sangat berbeda, tetapi juga kumpulan entitas yang berbeda, karena setiap analis akan mengandalkan proses dan tugas yang sudah dikenalnya. Dan dalam situasi seperti ini tidak mungkin untuk mengatakan model mana yang βbenarβ, karena tidak ada kriteria evaluasi.
2. Bentuk biasa
Bentuk normal pertama dari database membutuhkan atomisitas semua atribut.
Secara khusus, jika objek A memiliki atribut non-kunci a dan b, sehingga c=f(a,b) dan dalam tabel yang menjelaskan objek A Anda menyimpan nilai atribut c, maka bentuk normal pertama dilanggar dalam database . Misalnya, jika spesifikasi pesanan menunjukkan kuantitas, satuan pengukurannya bergantung pada jenis produk: dalam satu wadah dapat berupa potongan, dalam wadah lain liter, dalam kemasan ketiga dapat berupa potongan (dalam model di atas Good_count_WR) , maka atomisitas atribut dalam database dilanggar. Dalam hal ini, untuk mengetahui seperti apa seharusnya cluster tabel dari spesifikasi pesanan, Anda memerlukan deskripsi yang ditargetkan tentang proses kerja di IS, dan karena prosesnya bisa berbeda, mungkin ada banyak versi yang "benar".
Bentuk normal kedua dari database membutuhkan kepatuhan terhadap formulir pertama dan tabelnya sendiri untuk setiap entitas yang terkait dengan proses kerja di IS. Jika dalam satu tabel terdapat ketergantungan c=f1(a) dan d=f2(b) dan tidak terdapat ketergantungan c=f3(b), maka bentuk normal kedua pada tabel tersebut dilanggar. Pada contoh di atas, tidak ada ketergantungan antara order dan alamat pada tabel Order. Ubah nama jalan atau kota dan Anda tidak akan berpengaruh pada atribut penting pesanan.
Basis data bentuk normal ketiga membutuhkan kepatuhan terhadap bentuk normal kedua dan tidak adanya ketergantungan fungsional antar atribut entitas yang berbeda. Aturan ini dapat dirumuskan sebagai berikut: βsegala sesuatu yang dapat dihitung harus diperhitungkan.β Dengan kata lain, jika ada dua objek A dan B. Pada tabel yang menyimpan atribut objek A, atribut C terwujud, dan objek B memiliki atribut b, sehingga c=f4(b) ada, maka bentuk normal ketiga dilanggar. Pada contoh di bawah, atribut Quantity of Pieces (Total_count_WR) pada catatan pesanan jelas-jelas melanggar bentuk normal ketiga
3. Pendekatan saya dalam menerapkan normalisasi
1. Hanya proses bisnis otomatis target yang dapat memberikan kriteria kepada analis untuk mengidentifikasi entitas dan atribut saat membuat model penyimpanan data. Membuat model proses merupakan prasyarat untuk membuat model data normal.
2. Pencapaian bentuk normal ketiga dalam arti sebenarnya mungkin tidak praktis dalam praktik nyata pembuatan sistem ERP jika beberapa atau semua kondisi berikut terpenuhi:
- proses otomatis jarang mengalami perubahan,
- tenggat waktu untuk penelitian dan pengembangan sangat ketat,
- persyaratan integritas data relatif rendah (potensi kesalahan dalam perangkat lunak industri tidak menyebabkan hilangnya uang atau klien oleh pelanggan perangkat lunak)
- dan lain-lain
Dalam kondisi yang dijelaskan, biaya untuk mengidentifikasi dan mendeskripsikan siklus hidup objek tertentu dan atributnya mungkin tidak dapat dibenarkan dari sudut pandang efisiensi ekonomi.
3. Segala konsekuensi denormalisasi model data dalam IS yang sudah dibuat dapat dikurangi dengan studi pendahuluan menyeluruh terhadap kode dan pengujian.
4. Denormalisasi adalah cara untuk memindahkan biaya tenaga kerja dari tahap penelitian sumber data dan perancangan proses bisnis ke tahap pengembangan, dari periode implementasi ke periode pengembangan sistem.
5. Disarankan untuk mengupayakan bentuk normal ketiga dari suatu database jika:
- Arah perubahan dalam proses bisnis otomatis sulit diprediksi
- Terdapat lemahnya pembagian kerja dalam tim implementasi dan/atau pengembangan
- Sistem yang termasuk dalam sirkuit integrasi berkembang sesuai dengan rencananya sendiri
- Ketidakkonsistenan data dapat mengakibatkan perusahaan kehilangan pelanggan atau uang
6. Perancangan model data harus dilakukan oleh seorang analis hanya sehubungan dengan model proses bisnis target dan proses dalam IS. Jika pengembang merancang model data, ia harus membenamkan dirinya dalam bidang subjek sedemikian rupa sehingga, khususnya, ia memahami perbedaan antara nilai atribut - suatu kondisi yang diperlukan untuk mengisolasi atribut atom. Jadi, mengambil fungsi yang tidak biasa.
4 Masalah untuk ilustrasi
Katakanlah Anda memiliki kedai robot kecil di pelabuhan. Segmen pasar Anda: pelaut dan bajak laut yang datang ke pelabuhan dan butuh istirahat. Anda menjual teh dengan thyme kepada para pelaut, dan rum serta sisir tulang untuk menyisir janggut kepada bajak laut. Pelayanan di dalam kedai sendiri disediakan oleh robot nyonya rumah dan robot bartender. Berkat kualitas tinggi dan harga rendah, Anda telah mengusir pesaing Anda, sehingga semua orang yang turun dari kapal datang ke kedai Anda, yang merupakan satu-satunya di pelabuhan.
Kompleks sistem informasi kedai terdiri dari perangkat lunak berikut:
- Sistem peringatan dini tentang klien yang mengenali kategorinya berdasarkan ciri-cirinya
- Sistem kontrol untuk robot nyonya rumah dan robot bartender
- Sistem manajemen gudang dan pengiriman ke titik penjualan
- Sistem Manajemen Hubungan Pemasok (SURP)
Proses:
Sistem peringatan dini mengenali orang-orang yang meninggalkan kapal. Jika seseorang bercukur bersih, ia mengidentifikasinya sebagai seorang pelaut; jika seseorang ditemukan memiliki janggut, maka ia diidentifikasi sebagai bajak laut.
Memasuki kedai, tamu mendengar sapaan dari robot nyonya rumah sesuai dengan kategorinya, misalnya: βHo-ho-ho, bajak laut sayang, pergi ke meja Noβ¦β
Tamu menuju ke meja yang ditentukan, dimana robot bartender telah menyiapkan barang untuknya sesuai dengan kategorinya. Robot bartender mengirimkan informasi ke sistem gudang bahwa porsi pengiriman berikutnya harus ditingkatkan; gudang IS, berdasarkan sisa saldo penyimpanan, menghasilkan permintaan pembelian dalam sistem manajemen.
Meskipun sistem peringatan dini mungkin dikembangkan oleh TI internal Anda, program manajemen robot bar mungkin dibuat oleh kontraktor eksternal khusus untuk bisnis Anda. Dan sistem untuk mengelola gudang dan hubungan dengan pemasok merupakan solusi paket yang disesuaikan dari pasar.
5. Contoh denormalisasi dan dampaknya terhadap pengembangan perangkat lunak
Saat merancang proses bisnis, para ahli yang diwawancarai dengan suara bulat menyatakan bahwa di seluruh dunia bajak laut minum rum dan menyisir janggut mereka dengan sisir tulang, dan pelaut minum teh dengan thyme dan selalu bercukur bersih.
Direktori jenis klien muncul dengan dua nilai: 1 - bajak laut, 2 - pelaut, umum untuk seluruh rangkaian informasi perusahaan.
Sistem notifikasi klien segera menyimpan hasil pengolahan gambar sebagai pengenal (ID) klien yang dikenali dan jenisnya: pelaut atau bajak laut.
ID objek yang dikenali
Kategori klien
100500
Bajak laut
100501
Bajak laut
100502
Pelaut
Mari kita perhatikan sekali lagi hal itu
1. Pelaut kita sebenarnya adalah orang-orang yang bercukur
2. Bajak laut kita sebenarnya adalah orang-orang berjanggut
Masalah apa yang perlu dihilangkan dalam kasus ini agar struktur kita mencapai bentuk normal ketiga:
- pelanggaran atomisitas atribut - Kategori Klien
- menggabungkan fakta yang dianalisis dan kesimpulan dalam satu tabel
- hubungan fungsional tetap antara atribut entitas yang berbeda.
Dalam bentuk yang dinormalisasi, kita akan mendapatkan dua tabel:
- hasil pengenalan berupa sekumpulan ciri yang telah ditetapkan,
ID objek yang dikenali
Rambut wajah
100500
Ya
100501
Ya
100502
Tidak
- hasil penentuan tipe klien sebagai penerapan logika yang tertanam dalam IS untuk menafsirkan karakteristik yang ditetapkan
ID objek yang dikenali
ID Identifikasi
Kategori klien
100500
100001
Bajak laut
100501
100002
Bajak laut
100502
100003
Pelaut
Bagaimana organisasi penyimpanan data yang dinormalisasi dapat memfasilitasi pengembangan kompleks IP? Katakanlah Anda tiba-tiba mendapatkan klien baru. Biarlah bajak laut Jepang yang mungkin tidak berjanggut, tetapi mereka berjalan dengan burung beo di bahunya, dan bajak laut pecinta lingkungan, Anda dapat dengan mudah mengenali mereka dari profil biru Greta di dada kiri.
Para pembajak lingkungan, tentu saja, tidak dapat menggunakan sisir tulang dan meminta analog yang terbuat dari plastik laut daur ulang.
Anda perlu mengerjakan ulang algoritma program sesuai dengan masukan baru. Jika aturan normalisasi diikuti, maka Anda hanya perlu menambah input untuk beberapa cabang proses di beberapa sistem dan membuat cabang baru hanya untuk kasus-kasus tersebut dan di IS di mana rambut wajah penting. Namun, karena aturan tidak dipatuhi, Anda harus menganalisis seluruh kode, di seluruh sirkuit, di mana nilai direktori tipe klien digunakan dan dengan jelas menetapkan bahwa dalam satu kasus algoritme harus memperhitungkan profesional aktivitas klien, dan fitur fisik lainnya.
Dalam bentuk itu mencari untuk dinormalisasi, kita akan mendapatkan dua tabel dengan data operasional dan dua direktori:
- hasil pengenalan berupa sekumpulan ciri yang telah ditetapkan,
ID objek yang dikenali
Greta di dada kiri
Burung di bahu
Rambut wajah
100510
1
1
1
100511
0
0
1
100512
1
0
- hasil penentuan jenis klien (biarkan tampilan khusus yang menampilkan deskripsi dari direktori)
Apakah denormalisasi yang terdeteksi berarti sistem tidak dapat dimodifikasi untuk memenuhi kondisi baru? Tentu saja tidak. Jika kita membayangkan bahwa semua sistem informasi dibuat oleh satu tim tanpa pergantian staf, perkembangannya terdokumentasi dengan baik dan informasi ditransfer dalam tim tanpa kehilangan, maka perubahan yang diperlukan dapat dilakukan dengan sedikit usaha. Namun jika kita kembali ke kondisi awal permasalahan, 1,5 keyboard akan dihapus hanya untuk mencetak protokol diskusi bersama dan 0,5 lagi untuk memproses prosedur pengadaan.
Pada contoh di atas, ketiga bentuk normal dilanggar, mari kita coba melanggarnya secara terpisah.
Pelanggaran bentuk normal pertama:
Katakanlah barang diantar ke gudang Anda dari gudang pemasok dengan cara penjemputan menggunakan seekor kijang seberat 1.5 ton milik kedai Anda. Ukuran pesanan Anda sangat kecil dibandingkan dengan perputaran pemasok sehingga pesanan selalu diselesaikan satu per satu tanpa menunggu produksi. Apakah Anda memerlukan tabel terpisah dengan proses bisnis seperti itu: kendaraan, jenis kendaraan, apakah perlu memisahkan rencana dan fakta dalam pesanan Anda ke pemasok yang berangkat?
Bayangkan saja berapa banyak koneksi βekstraβ yang harus ditulis oleh programmer Anda jika Anda menggunakan model di bawah ini untuk mengembangkan sebuah program.
Katakanlah kita memutuskan bahwa struktur yang diusulkan terlalu rumit; dalam kasus kita, memisahkan rencana dan fakta dalam catatan pesanan adalah informasi yang berlebihan, dan spesifikasi pesanan yang dihasilkan ditulis ulang berdasarkan hasil penerimaan barang yang tiba, jarang terjadi kesalahan. -penilaian dan kedatangan barang dengan kualitas yang tidak memadai diselesaikan di luar IS.
Dan suatu hari Anda melihat bagaimana seluruh aula kedai dipenuhi dengan bajak laut yang marah dan tidak terawat. Apa yang telah terjadi?
Ternyata seiring berkembangnya bisnis Anda, konsumsi Anda juga meningkat. Suatu ketika, manajemen mengambil keputusan bahwa jika seekor kijang mengalami kelebihan muatan dalam volume dan/atau berat, yang sangat jarang terjadi, pemasok akan memprioritaskan muatannya dibandingkan minuman.
Barang yang tidak terkirim berakhir di pesanan berikutnya dan berangkat dengan penerbangan baru, adanya saldo minimum di gudang di kedai memungkinkan untuk tidak memperhatikan kasus yang hilang.
Pesaing terakhir ditutup di pelabuhan, dan kasus kelebihan beban Gazelle, yang dilewati dengan penentuan prioritas berdasarkan asumsi kecukupan saldo minimum dan kekurangan muatan kendaraan secara berkala, menjadi praktik umum. Sistem yang dibuat idealnya akan bekerja sesuai dengan algoritma yang tertanam di dalamnya dan akan kehilangan kesempatan untuk melacak kegagalan sistematis dalam memenuhi pesanan yang direncanakan. Hanya reputasi yang rusak dan pelanggan yang tidak puas yang dapat mendeteksi masalahnya.
Pembaca yang penuh perhatian mungkin telah memperhatikan bahwa jumlah pesanan dalam spesifikasi pesanan (T_ORDER_SPEC) di bagian 2 dan bagian 5 mungkin memenuhi atau tidak memenuhi persyaratan bentuk normal pertama. Itu semua tergantung pada apakah, dengan mempertimbangkan jenis barang yang dipilih, unit pengukuran yang pada dasarnya berbeda dapat dimasukkan ke dalam bidang yang sama.
Pelanggaran bentuk normal kedua:
Seiring bertambahnya kebutuhan Anda, Anda membeli beberapa kendaraan lagi dengan ukuran berbeda. Dalam konteks di atas, pembuatan direktori kendaraan dianggap mubazir; akibatnya, semua algoritme pemrosesan data yang melayani kebutuhan pengiriman dan gudang menganggap pergerakan kargo dari pemasok ke gudang sebagai penerbangan eksklusif seberat 1,5 ton. rusa. Jadi, seiring dengan pembelian kendaraan baru, Anda tetap membuat direktori kendaraan, namun saat menyelesaikannya, Anda harus menganalisis semua kode yang mereferensikan pergerakan kargo untuk mengetahui apakah di setiap tempat tertentu tersirat referensi karakteristiknya. kendaraan tempat bisnis dimulai.
Pelanggaran bentuk normal ketiga:
Pada titik tertentu Anda mulai membuat program loyalitas, catatan pelanggan tetap muncul. Mengapa, misalnya, menghabiskan waktu membuat tampilan material yang menyimpan data agregat penjualan ke klien individu untuk digunakan dalam pelaporan dan ditransfer ke sistem analitis, jika pada awal program loyalitas segala sesuatu yang menarik minat pelanggan dapat ditempatkan pada catatan klien ? Dan memang sekilas tidak ada gunanya. Namun setiap kali bisnis Anda terhubung, misalnya, saluran penjualan baru, pasti ada seseorang di antara analis Anda yang akan mengingat bahwa atribut agregasi seperti itu ada.
Saat merancang setiap proses baru, misalnya penjualan online, penjualan melalui distributor yang terhubung ke sistem loyalitas umum, seseorang harus ingat bahwa semua proses baru harus memastikan integritas data pada tingkat kode. Untuk database industri dengan ribuan tabel, ini sepertinya tugas yang mustahil.
Pengembang berpengalaman, tentu saja, tahu cara menghentikan semua masalah yang disebutkan di atas, tetapi menurut saya, tugas seorang analis berpengalaman bukanlah mengungkapnya.
Saya ingin mengucapkan terima kasih kepada pengembang terkemuka Evgeniy Yarukhin atas masukannya yang berharga selama persiapan publikasi.
Literatur
Connolly Thomas, Mohon Caroline. Basis data. Desain, implementasi dan dukungan. Teori dan praktek
Sumber: www.habr.com