🤲 🤞🏼 ⛹🏼 Denormalisasi sistem basis data ERP dan dampaknya terhadap pengembangan perangkat lunak: buka kedai di Tortuga 👩🏿‍🍳 🧘🏿 👠

Halo! Nama saya Andrey Semenov, saya seorang analis senior di Sportmaster. Dalam posting ini saya ingin mengangkat masalah denormalisasi sistem basis data ERP. Kami akan mempertimbangkan kondisi umum, serta contoh spesifik - katakanlah itu akan menjadi kedai monopoli yang luar biasa bagi bajak laut dan pelaut. Di mana bajak laut dan pelaut perlu dilayani secara berbeda, karena gagasan tentang pola indah dan konsumen dari tuan yang baik ini sangat berbeda.

Bagaimana cara membuat semua orang bahagia? Bagaimana tidak menjadi gila merancang dan memelihara sistem seperti itu? Apa yang harus dilakukan jika tidak hanya bajak laut dan pelaut yang sudah akrab mulai datang ke kedai minuman? Semuanya ada di bawah luka. Tapi mari kita mulai.

1. Keterbatasan dan Asumsi

Semua hal di atas hanya berlaku untuk database relasional. Diterangi dengan baik, termasuk di Internet, efek denormalisasi dalam bentuk anomali modifikasi, penghapusan dan penyisipan tidak dipertimbangkan. Di luar lingkup publikasi, masih ada kasus-kasus di mana denormalisasi adalah hal biasa, dengan contoh-contoh klasik: nomor seri dan paspor, tanggal dan waktu, dan sebagainya.

Posting menggunakan definisi intuitif dan praktis yang berlaku untuk bentuk normal, tanpa mengacu pada istilah matematika. Dalam bentuk di mana mereka 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 presentasi informasi tabel) berbeda dari desain sistem basis data ERP karena kemudahan konsumsi dan penerapan denasionalisasi sadar untuk mencapainya dapat diutamakan daripada perlindungan integritas. data. Saya berbagi pendapat ini, dan uraian di bawah ini berlaku khusus untuk model data master dan data transaksional sistem ERP.

Penjelasan tentang bentuk normal diberikan oleh contoh yang dapat dimengerti di tingkat rumah tangga untuk sebagian besar pembaca. Namun, sebagai ilustrasi ilustrasi, dalam paragraf 4-5, tugas "diciptakan" yang ditekankan digunakan secara sadar. Jika Anda tidak melakukan ini dan mengambil beberapa contoh buku teks, misalnya, model yang sama untuk menyimpan pesanan dari Bagian 2, Anda mungkin menemukan diri Anda dalam situasi di mana perhatian pembaca akan dialihkan dari dekomposisi proses yang diusulkan menjadi sebuah model, menjadi pengalaman pribadi dan persepsi tentang bagaimana proses dan model penyimpanan data dalam IP harus dibangun. Dengan kata lain, ambil dua analis IT yang berkualifikasi, biarkan yang satu memberikan layanan kepada ahli logistik yang mengangkut penumpang, dan yang lainnya kepada ahli logistik yang mengangkut mesin untuk produksi microchip. Tanyakan kepada mereka, tanpa mendiskusikan BP pra-otomatis, untuk membuat model data untuk menyimpan informasi tentang penerbangan kereta api.

Ada probabilitas tidak nol bahwa dalam model yang diusulkan Anda akan menemukan tidak hanya seperangkat atribut yang sangat berbeda, tetapi juga set entitas yang berbeda, karena setiap analis akan bergantung pada proses dan tugasnya yang biasa. Dan mengatakan dalam situasi seperti itu model mana yang "benar" tidak mungkin, karena tidak ada kriteria evaluasi.

2. Bentuk normal

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 menggambarkan objek A Anda menyimpan nilai atribut c, maka bentuk normal pertama dilanggar dalam database. Misalnya, jika spesifikasi pesanan menentukan kuantitas yang unit pengukurannya tergantung pada jenis produk: dalam satu kasus dapat menjadi potongan-potongan, dalam liter lain, dalam paket ketiga yang terdiri dari potongan-potongan (dalam model di atas Good_count_WR), maka atomisitas atribut dilanggar dalam database. Dalam hal ini, untuk mengatakan seperti apa bush dari tabel seharusnya untuk spesifikasi pesanan, Anda memerlukan deskripsi yang ditargetkan dari proses bekerja di IP, dan karena prosesnya bisa berbeda, mungkin ada banyak versi "benar".

Bentuk normal kedua dari databasemembutuhkan kepatuhan dengan formulir pertama dan tabelnya sendiri untuk setiap entitas yang terkait dengan proses bekerja di IP. Jika dalam satu tabel ada dependensi c = f1 (a) dan d = f2 (b) dan tidak ada ketergantungan c = f3 (b), maka bentuk normal kedua dilanggar dalam tabel. Dalam contoh di atas, dalam tabel "Pesan", tidak ada hubungan antara pesanan dan alamat. Ubah nama jalan atau kota dan Anda tidak akan mendapat pengaruh pada atribut penting dari pesanan.

Bentuk normal ketiga dari databasemembutuhkan kepatuhan dengan bentuk normal kedua dan tidak adanya ketergantungan fungsional antara atribut entitas yang berbeda. Aturan ini dapat dirumuskan sebagai berikut: "semua yang dapat dihitung harus dihitung." Dengan kata lain, jika ada dua objek A dan B. Dalam tabel yang menyimpan atribut objek A, atribut C ditampilkan, objek B memiliki atribut b, sehingga c = f4 (b) ada, maka bentuk normal ketiga dilanggar. Dalam contoh di bawah ini, atribut "Jumlah potongan" (Total_count_WR) dalam catatan pesanan jelas mengklaim melanggar bentuk normal ketiga

3. Pendekatan saya untuk menerapkan normalisasi

1. Hanya proses bisnis otomatis target yang dapat memberikan analitik dengan kriteria untuk mengidentifikasi entitas dan atribut saat membuat model penyimpanan data. Membuat model proses adalah prasyarat untuk membuat model data normal.

2. Pencapaian bentuk normal ketiga dalam arti yang ketat mungkin tidak praktis dalam praktik sebenarnya menciptakan sistem ERP ketika sebagian atau semua kondisi berikut ini terpenuhi:

proses otomatis jarang berubah,
tenggat waktu penelitian dan pengembangan sangat ketat,
persyaratan untuk integritas data relatif rendah (potensi kesalahan dalam perangkat lunak industri tidak mengarah pada hilangnya uang atau pelanggan oleh pelanggan perangkat lunak)
dll.

Di bawah kondisi yang dijelaskan, biaya identifikasi, deskripsi siklus hidup beberapa objek dan atributnya mungkin tidak dapat dibenarkan dari sudut pandang efisiensi ekonomi.

3. Segala konsekuensi dari denormalisasi model data dalam IP yang sudah dibuat dapat dihentikan dengan studi pendahuluan menyeluruh terhadap kode dan pengujian.

4. Denormalisasi adalah cara untuk mentransfer biaya tenaga kerja dari tahap penelitian sumber data dan merancang proses bisnis ke tahap pengembangan, dari periode implementasi ke periode pengembangan sistem.

5. Dianjurkan untuk mengusahakan bentuk normal ketiga dari database jika:

Arah perubahan dalam proses bisnis otomatis sulit diprediksi
Ada pembagian kerja yang permeabel dalam tim implementasi dan / atau pengembangan
Sistem yang termasuk dalam rangkaian integrasi sedang mengembangkan sesuai dengan rencana mereka sendiri.
Ketidakkonsistenan data dapat menyebabkan hilangnya pelanggan atau uang oleh perusahaan

6. Desain model data harus dilakukan oleh analis hanya sehubungan dengan model proses bisnis target dan proses dalam IP. Jika seorang pengembang terlibat dalam merancang model data, ia harus terjun ke bidang subjek sedemikian rupa sehingga, khususnya, ia perlu memahami perbedaan antara nilai-nilai atribut - kondisi yang diperlukan untuk membedakan atribut atom. Jadi, mengambil fungsi yang tidak biasa.

4 Tugas untuk ilustrasi

Katakanlah Anda memiliki kedai robot kecil di pelabuhan. Segmen pasar Anda: pelaut dan bajak laut yang menelepon di pelabuhan dan perlu istirahat. Untuk pelaut, Anda menjual teh dengan thyme, dan untuk bajak laut, rum dan sisir tulang untuk menyisir jenggot Anda. Layanan di warung itu sendiri disediakan oleh robot nyonya rumah dan robot bartender. Karena kualitas tinggi dan harga murah, Anda telah memadatkan semua pesaing Anda, sehingga semua orang yang meninggalkan kapal datang ke kedai minuman Anda, yang merupakan satu-satunya di pelabuhan.

Kompleks sistem informasi kedai terdiri dari perangkat lunak berikut:

Sistem peringatan dini klien yang mengenali kategorinya berdasarkan fitur karakteristik
Sistem manajemen untuk robot nyonya rumah dan robot bartender
Gudang dan sistem manajemen pengiriman titik
Sistem Manajemen Hubungan Pemasok (SMS)

Proses:

Sistem peringatan dini mendeteksi orang yang meninggalkan kapal. Jika seseorang dicukur bersih, ia mendefinisikannya sebagai pelaut, jika janggut ditemukan pada seseorang, maka ia didefinisikan sebagai bajak laut.

Memasuki kedai minuman, tamu mendengar salam dari robot nyonya rumah sesuai dengan kategorinya, misalnya: "Ho-ho-ho, bajak laut sayang, pergi ke meja No. ..."

Tamu pergi ke meja yang ditunjukkan, di mana robot-bartender telah bersiap untuk dia barang sesuai kategori. Robot bartender mentransmisikan informasi ke sistem gudang bahwa porsi pengiriman berikutnya harus ditingkatkan, IS gudang, berdasarkan penyimpanan yang tersisa, membentuk aplikasi untuk pembelian dalam sistem kontrol.

Biarkan TI internal Anda mengembangkan sistem peringatan dini, kontraktor eksternal yang dirancang khusus untuk bisnis Anda untuk membuat program manajemen robot bar. Dan sistem untuk manajemen gudang dan hubungan pemasok adalah solusi kotak khusus dari pasar.

5. Contoh denormalisasi dan dampaknya terhadap pengembangan perangkat lunak

Saat merancang proses bisnis, para ahli yang diwawancarai dengan suara bulat menyatakan bahwa para bajak laut di seluruh dunia minum rum dan menyisir janggutnya dengan tulang, dan para pelaut minum teh dengan thyme dan selalu dicukur dengan mulus.

Direktori jenis pelanggan muncul dari dua nilai: 1 - bajak laut, 2 - pelaut, umum untuk seluruh rangkaian informasi perusahaan.

Sistem pemberitahuan pelanggan segera menyimpan hasil pemrosesan gambar sebagai pengidentifikasi (ID) dari pelanggan yang dikenal dan jenisnya: pelaut atau bajak laut.

ID Objek yang Diakui	Kategori pelanggan
100500	Bajak laut
100501	Bajak laut
100502	Pelaut

Sekali lagi, kami mencatat bahwa

1. Para pelaut kami benar-benar orang yang dicukur
2. Perompak kami sebenarnya adalah orang-orang berjanggut.

Masalah apa dalam kasus ini yang perlu ditangani sehingga struktur kami berjuang untuk bentuk normal ketiga:

atribut pelanggaran atom - kategori Klien
pencampuran fakta dan kesimpulan yang dianalisis dalam satu tabel
hubungan fungsional tetap antara atribut entitas yang berbeda.

Dalam bentuk yang dinormalisasi, kita akan mendapatkan dua tabel:

hasil pengakuan dalam bentuk serangkaian fitur yang ditetapkan,

ID Objek yang Diakui	Rambut wajah
100500	Iya
100501	Iya
100502	Tidak

hasil menentukan jenis klien sebagai aplikasi dari logika yang tertanam dalam IS untuk interpretasi tanda-tanda yang ditetapkan

ID Objek yang Diakui	ID identifikasi	Kategori pelanggan
100500	100001	Bajak laut
100501	100002	Bajak laut
100502	100003	Pelaut

Bagaimana organisasi penyimpanan yang dinormalisasi dapat memfasilitasi pengembangan kompleks IP? Katakanlah Anda tiba-tiba memiliki pelanggan baru. Biarlah bajak laut Jepang yang mungkin tidak memiliki janggut, tetapi mereka berjalan dengan burung beo di pundak mereka, dan bajak laut lingkungan, Anda dapat dengan mudah mengenali mereka dengan profil biru Greta di dada kiri mereka.

Bajak laut lingkungan, tentu saja, tidak dapat menggunakan puncak tulang dan memerlukan analog dari plastik laut daur ulang.

Anda perlu mengerjakan ulang algoritme program sesuai dengan pengantar baru. Jika aturan normalisasi dipenuhi, maka Anda hanya perlu menambahkan input untuk beberapa cabang proses dan membuat cabang baru hanya untuk kasus-kasus tersebut dan pada IP tersebut di mana garis rambut pada wajah itu penting. Tetapi, karena aturan tidak diikuti, Anda harus menganalisis seluruh kode, di seluruh rangkaian, di mana nilai-nilai direktori jenis klien digunakan dan jelas menetapkan bahwa dalam satu kasus algoritma harus mempertimbangkan kegiatan profesional klien, dan dalam fitur fisik lainnya.

Dalam pandangan yang cenderung normal, kita akan mendapatkan dua tabel dengan data operasional dan dua direktori:

hasil pengakuan dalam bentuk serangkaian fitur yang ditetapkan,


100510	1	1	1
100511	0	0	1
100512		1	0

( , )

Apakah denormalisasi terdeteksi berarti bahwa sistem tidak dapat dimodifikasi dalam kondisi baru? Tentu saja tidak. Jika Anda membayangkan bahwa semua IP dibuat oleh satu tim dengan nol pergantian staf, pengembangannya didokumentasikan dengan baik dan informasi dalam tim tersebut ditransmisikan tanpa kerugian, maka perubahan yang diperlukan dapat berupa produk dengan upaya rendah yang keliru. Tetapi jika kita kembali ke kondisi awal tugas, hanya 1,5 keyboard dan 0,5 lainnya untuk pendaftaran prosedur pengadaan akan dihapus hanya untuk protokol pencetakan diskusi bersama.

Dalam contoh di atas, ketiga bentuk normal dilanggar, mari kita coba melanggarnya secara individual.

Pelanggaran bentuk normal pertama:

Misalkan barang dikirim ke gudang Anda dari gudang pemasok dengan biaya Anda sendiri menggunakan satu gazelle 1,5 ton milik kedai minuman Anda. Ukuran pesanan Anda sangat kecil dibandingkan dengan omset pemasok sehingga mereka selalu dilakukan satu per satu tanpa menunggu produksi. Apakah Anda memerlukan tabel terpisah untuk PSU seperti itu: kendaraan, jenis kendaraan, apakah Anda perlu memisahkan rencana dan fakta dalam pesanan Anda kepada pemasok yang berangkat?

Bayangkan saja berapa banyak koneksi "ekstra" yang harus ditulis oleh programmer Anda jika Anda menggunakan model di bawah ini untuk mengembangkan program.

Misalkan kita membuat keputusan bahwa struktur yang diusulkan tidak perlu rumit, untuk kasus kami, memisahkan rencana dan fakta dalam catatan pesanan adalah informasi yang berlebihan, dan spesifikasi pesanan yang dihasilkan ditimpa oleh hasil penerimaan barang yang tiba, penyortiran ulang yang jarang dan kedatangan barang dengan kualitas yang tidak memadai diselesaikan di luar IP.
Dan kemudian suatu hari Anda melihat bagaimana seluruh aula kedai dipenuhi dengan bajak laut yang marah dan tidak terawat. Apa yang terjadi?

Ternyata seiring dengan pertumbuhan bisnis Anda, konsumsi juga tumbuh. Suatu keputusan manajemen pernah dibuat bahwa jika seekor rusa kelebihan beban dalam volume dan / atau berat, yang sangat jarang, pemasok memprioritaskan pemuatan untuk minuman.

Barang-barang yang tidak terkirim jatuh ke urutan berikutnya dan berangkat dengan penerbangan baru, dengan adanya keseimbangan tak tereduksi di gudang di kedai minuman itu memungkinkan untuk tidak memperhatikan kasus-kasus yang tertusuk.

Pesaing terakhir ditutup di pelabuhan, dan kasing gazelle yang tertusuk, dielakkan dengan memprioritaskan berdasarkan asumsi kecukupan keseimbangan minimum dan kekurangan muatan kendaraan secara berkala, menjadi praktik umum. Sistem yang dibuat idealnya akan bekerja sesuai dengan algoritma yang ditetapkan di dalamnya dan akan kehilangan kesempatan untuk melacak non-pemenuhan pesanan sistematis yang direncanakan. Hanya reputasi yang rusak dan pelanggan yang tidak puas yang dapat mendeteksi masalah.

Pembaca yang penuh perhatian harus memperhatikan bahwa kuantitas yang dipesan dalam spesifikasi pesanan (T_ORDER_SPEC) di bagian 2 dan bagian 5 mungkin memenuhi atau tidak memenuhi persyaratan formulir normal pertama. Itu semua tergantung pada apakah, untuk bermacam-macam barang yang dipilih, pada dasarnya unit pengukuran yang berbeda dapat jatuh ke bidang yang sama.

Pelanggaran bentuk normal kedua:

Ketika kebutuhan Anda tumbuh, Anda mendapatkan beberapa kendaraan lagi dengan ukuran berbeda. Dalam konteks di atas, pembuatan direktori kendaraan dianggap mubazir, sebagai akibatnya, semua algoritma manipulasi data yang melayani kebutuhan pengiriman dan gudang memandang pergerakan barang dari pemasok ke gudang sebagai penerbangan hanya gazelle 1,5 ton. Jadi, seiring dengan pembelian kendaraan baru, Anda masih membuat direktori kendaraan, tetapi ketika menyelesaikan Anda harus menganalisis seluruh kode yang mengacu pada pergerakan kargo untuk mengetahui apakah referensi ke karakteristik mobil dari mana bisnis dimulai.

Pelanggaran bentuk normal ketiga:

Pada titik tertentu, Anda mulai membuat program loyalitas, catatan pelanggan reguler muncul. Mengapa, misalnya, menghabiskan waktu membuat representasi materi yang menyimpan data penjualan teragregasi untuk pelanggan individu untuk digunakan dalam pelaporan dan mentransfernya ke sistem analitis, jika pada awal program loyalitas segala sesuatu yang menarik pelanggan dapat ditempatkan pada catatan pelanggan sendiri? Dan, memang, tidak masuk akal pada pandangan pertama. Tetapi setiap kali bisnis Anda menghubungkan, misalnya, saluran penjualan baru, harus ada seseorang di antara analis Anda yang ingat bahwa ada atribut agregasi seperti itu.

Ketika merancang setiap proses baru, misalnya, menjual di Internet, menjual melalui distributor yang terhubung ke sistem kesetiaan bersama, seseorang harus ingat bahwa semua proses baru harus memastikan integritas data pada tingkat kode. Untuk database industri dengan seribu tabel, ini sepertinya tugas yang mustahil.

Seorang pengembang yang berpengalaman, tentu saja, tahu cara menghentikan semua masalah yang disebutkan di atas, tetapi, menurut pendapat saya, tugas seorang analis yang berpengalaman bukanlah untuk menarik perhatian mereka.

Saya ingin mengucapkan terima kasih atas umpan balik yang berharga selama persiapan publikasi kepada pengembang terkemuka Evgeny Yarukhin.

literatur

https://habr.com/en/post/254773/
Connolly Thomas, Begg Carolyn. Basis data. Desain, implementasi, dan pemeliharaan. Teori dan praktik