hello! Nama saya Andrey Semenov, saya seorang penganalisis kanan di Sportmaster. Dalam catatan ini saya ingin membangkitkan isu denormalisasi pangkalan data sistem ERP. Kami akan melihat keadaan umum, serta contoh khusus - katakan ia akan menjadi kedai monopoli yang indah untuk lanun dan kelasi. Di mana lanun dan kelasi mesti dilayan secara berbeza, kerana idea-idea kecantikan dan corak pengguna lelaki yang baik ini berbeza dengan ketara.
Bagaimana untuk membuat semua orang gembira? Bagaimanakah anda boleh mengelakkan menjadi gila mereka bentuk dan mengekalkan sistem sedemikian? Apa yang perlu dilakukan jika bukan sahaja lanun dan kelasi biasa mula datang ke kedai?
Semuanya berada di bawah pemotongan. Tetapi mari kita pergi dalam urutan.
1. Had dan andaian
Semua di atas hanya digunakan untuk pangkalan data hubungan. Akibat penyahnormalan dalam bentuk pengubahsuaian, pemadaman, dan anomali sisipan, yang dilindungi dengan baik, termasuk di Internet, tidak dipertimbangkan. Di luar skop penerbitan ini terdapat kes di mana penyahnormalan adalah tempat biasa, dengan contoh klasik: siri dan nombor pasport, tarikh dan masa, dsb.
Catatan itu menggunakan takrifan bentuk biasa yang intuitif dan boleh digunakan secara praktikal, tanpa merujuk kepada istilah matematik. Dalam bentuk di mana ia boleh digunakan untuk pemeriksaan proses perniagaan sebenar (BP) dan reka bentuk perisian industri.
Dihujahkan bahawa reka bentuk gudang data, alat pelaporan dan perjanjian penyepaduan (yang menggunakan perwakilan jadual maklumat) berbeza daripada reka bentuk pangkalan data sistem ERP dalam kemudahan penggunaan dan penggunaan penyahnormalan sedar untuk mencapainya mungkin diutamakan daripada integriti data perlindungan. Saya berkongsi pendapat ini, dan perkara yang diterangkan di bawah terpakai semata-mata untuk data induk dan model data transaksi sistem ERP.
Penjelasan tentang bentuk biasa diberikan menggunakan contoh yang boleh difahami pada peringkat harian untuk kebanyakan pembaca. Walau bagaimanapun, sebagai ilustrasi visual, dalam perenggan 4-5, tugasan "fiksyen" yang sengaja digunakan dengan sengaja. Jika anda tidak melakukan ini dan mengambil beberapa contoh buku teks, sebagai contoh, model penyimpanan pesanan yang sama dari titik 2, anda mungkin mendapati diri anda berada dalam situasi di mana tumpuan pembaca akan dialihkan daripada penguraian proses yang dicadangkan kepada model, kepada pengalaman peribadi dan persepsi bagaimana proses dan model untuk menyimpan data dalam IS mesti dibina. Dalam erti kata lain, ambil dua penganalisis IT yang berkelayakan, biarkan seorang menyediakan perkhidmatan kepada ahli logistik yang mengangkut penumpang, yang lain kepada ahli logistik yang mengangkut mesin untuk pengeluaran cip mikro. Minta mereka, tanpa membincangkan BP automatik terlebih dahulu, untuk mencipta model data untuk menyimpan maklumat tentang perjalanan kereta api.
Terdapat kebarangkalian bukan sifar bahawa dalam model yang dicadangkan anda akan mendapati bukan sahaja set atribut yang ketara berbeza, tetapi juga set entiti yang berbeza, kerana setiap penganalisis akan bergantung pada proses dan tugas yang biasa baginya. Dan dalam keadaan sedemikian adalah mustahil untuk mengatakan model mana yang "betul", kerana tidak ada kriteria penilaian.
2. Bentuk biasa
Bentuk biasa pertama pangkalan data memerlukan atomicity semua sifat.
Khususnya, jika objek A mempunyai atribut bukan kunci a dan b, supaya c=f(a,b) dan dalam jadual yang menerangkan objek A anda menyimpan nilai atribut c, maka bentuk normal pertama dilanggar dalam pangkalan data . Sebagai contoh, jika spesifikasi pesanan menunjukkan kuantiti, unit ukuran yang bergantung pada jenis produk: dalam satu kes ia boleh menjadi kepingan, dalam liter lain, dalam pakej ketiga yang terdiri daripada kepingan (dalam model di atas Good_count_WR) , maka atomicity atribut dilanggar dalam pangkalan data. Dalam kes ini, untuk menyatakan kumpulan jadual spesifikasi pesanan, anda memerlukan perihalan disasarkan proses kerja dalam IS, dan memandangkan proses boleh berbeza, mungkin terdapat banyak versi "betul".
Bentuk normal kedua pangkalan data memerlukan pematuhan dengan borang pertama dan jadualnya sendiri untuk setiap entiti yang berkaitan dengan proses kerja dalam IS. Jika dalam satu jadual terdapat kebergantungan c=f1(a) dan d=f2(b) dan tiada kebergantungan c=f3(b), maka bentuk normal kedua dilanggar dalam jadual. Dalam contoh di atas, tiada pergantungan antara pesanan dan alamat dalam jadual Pesanan. Tukar nama jalan atau bandar dan anda tidak akan mempunyai kesan ke atas sifat penting pesanan itu.
Pangkalan data bentuk normal ketiga memerlukan pematuhan dengan bentuk normal kedua dan ketiadaan kebergantungan fungsi antara atribut entiti yang berbeza. Peraturan ini boleh dirumuskan seperti berikut: "segala yang boleh dikira mesti dikira." Dalam erti kata lain, jika terdapat dua objek A dan B. Dalam jadual yang menyimpan atribut objek A, atribut C dimanifestasikan, dan objek B mempunyai atribut b, supaya c=f4(b) wujud, maka bentuk normal ketiga dilanggar. Dalam contoh di bawah, atribut Quantity of Pieces (Total_count_WR) pada rekod pesanan dengan jelas mendakwa melanggar bentuk normal ketiga
3. Pendekatan saya untuk menggunakan normalisasi
1. Hanya proses perniagaan automatik sasaran yang boleh memberikan penganalisis dengan kriteria untuk mengenal pasti entiti dan atribut semasa mencipta model storan data. Mencipta model proses adalah prasyarat untuk mencipta model data biasa.
2. Mencapai bentuk normal ketiga dalam erti kata yang ketat mungkin tidak praktikal dalam amalan sebenar mencipta sistem ERP jika beberapa atau semua syarat berikut dipenuhi:
- proses automatik jarang tertakluk kepada perubahan,
- tarikh akhir untuk penyelidikan dan pembangunan adalah ketat,
- keperluan untuk integriti data adalah agak rendah (kemungkinan ralat dalam perisian industri tidak membawa kepada kehilangan wang atau pelanggan oleh pelanggan perisian)
- dan lain-lain
Di bawah keadaan yang diterangkan, kos untuk mengenal pasti dan menerangkan kitaran hayat sesetengah objek dan sifatnya mungkin tidak wajar dari sudut kecekapan ekonomi.
3. Sebarang akibat daripada penyahnormalan model data dalam IS yang telah dibuat boleh dikurangkan dengan kajian awal yang menyeluruh terhadap kod dan ujian.
4. Denormalisasi ialah satu cara untuk memindahkan kos buruh daripada peringkat menyelidik sumber data dan mereka bentuk proses perniagaan ke peringkat pembangunan, daripada tempoh pelaksanaan kepada tempoh pembangunan sistem.
5. Adalah dinasihatkan untuk berusaha untuk bentuk normal ketiga pangkalan data jika:
- Arah perubahan dalam proses perniagaan automatik sukar untuk diramalkan
- Terdapat pembahagian kerja yang lemah dalam pasukan pelaksanaan dan/atau pembangunan
- Sistem yang termasuk dalam litar penyepaduan dibangunkan mengikut rancangan mereka sendiri
- Ketidakkonsistenan data boleh mengakibatkan syarikat kehilangan pelanggan atau wang
6. Reka bentuk model data hendaklah dijalankan oleh penganalisis hanya berkaitan dengan model proses perniagaan sasaran dan proses dalam IS. Jika pembangun sedang mereka bentuk model data, dia perlu melibatkan diri dalam kawasan subjek sehingga ke tahap yang, khususnya, dia memahami perbezaan antara nilai atribut - syarat yang diperlukan untuk mengasingkan atribut atom. Oleh itu, mengambil fungsi yang luar biasa.
4 Masalah untuk ilustrasi
Katakan anda mempunyai kedai robotik kecil di pelabuhan. Segmen pasaran anda: pelayar dan lanun yang datang ke pelabuhan dan memerlukan rehat. Anda menjual teh dengan thyme kepada kelasi, dan rum dan sikat tulang untuk menyikat janggut kepada lanun. Perkhidmatan di kedai minuman itu sendiri disediakan oleh pelayan robot dan pelayan bar robot. Terima kasih kepada kualiti tinggi dan harga rendah anda, anda telah menghalau pesaing anda, supaya semua orang yang turun dari kapal datang ke kedai minuman anda, yang merupakan satu-satunya di pelabuhan.
Kompleks sistem maklumat kedai terdiri daripada perisian berikut:
- Sistem amaran awal tentang pelanggan yang mengenali kategorinya berdasarkan ciri ciri
- Sistem kawalan untuk pelayan robot dan pelayan bar robot
- Sistem pengurusan gudang dan penghantaran ke tempat jualan
- Sistem Pengurusan Perhubungan Pembekal (SURP)
Proses:
Sistem amaran awal mengiktiraf orang yang meninggalkan kapal. Jika seseorang itu dicukur bersih, dia mengenal pasti dia sebagai kelasi; jika seseorang didapati mempunyai janggut, maka dia dikenal pasti sebagai lanun.
Memasuki kedai minuman, tetamu mendengar ucapan dari pelayan robot sesuai dengan kategorinya, sebagai contoh: "Ho-ho-ho, lanun sayang, pergi ke meja No..."
Tetamu pergi ke meja yang ditentukan, di mana pelayan bar robot telah menyediakan barang untuknya mengikut kategori. Pelayan bar robot menghantar maklumat kepada sistem gudang bahawa bahagian penghantaran seterusnya perlu ditingkatkan; IS gudang, berdasarkan baki baki dalam storan, menjana permintaan pembelian dalam sistem pengurusan.
Walaupun sistem amaran awal mungkin telah dibangunkan oleh IT dalaman anda, program pengurusan robot bar mungkin telah dibuat oleh kontraktor luaran khusus untuk perniagaan anda. Dan sistem untuk menguruskan gudang dan hubungan dengan pembekal adalah penyelesaian berpakej tersuai dari pasaran.
5. Contoh denormalisasi dan kesannya terhadap pembangunan perisian
Semasa mereka bentuk proses perniagaan, pakar subjek yang ditemu bual sebulat suara menyatakan bahawa lanun di seluruh dunia minum rum dan menyikat janggut mereka dengan sikat tulang, dan kelasi minum teh dengan thyme dan sentiasa dicukur bersih.
Direktori jenis pelanggan muncul dengan dua nilai: 1 - lanun, 2 - kelasi, biasa untuk keseluruhan litar maklumat syarikat.
Sistem pemberitahuan pelanggan segera menyimpan hasil pemprosesan imej sebagai pengecam (ID) pelanggan yang diiktiraf dan jenisnya: kelasi atau lanun.
ID objek yang dikenali
Kategori pelanggan
100500
Lanun
100501
Lanun
100502
Pelaut
Mari kita perhatikan sekali lagi bahawa
1. Pelayar kita sebenarnya adalah orang yang dicukur
2. Lanun kita sebenarnya adalah orang berjanggut
Apakah masalah dalam kes ini yang perlu dihapuskan supaya struktur kami berusaha untuk bentuk normal ketiga:
- pelanggaran atomicity atribut - Kategori Klien
- mencampurkan fakta yang dianalisis dan kesimpulan dalam satu jadual
- hubungan fungsi tetap antara atribut entiti yang berbeza.
Dalam bentuk normal, kami akan mendapat dua jadual:
- hasil pengiktirafan dalam bentuk satu set ciri yang telah ditetapkan,
ID objek yang dikenali
Rambut muka
100500
Ya
100501
Ya
100502
Tiada
- hasil penentuan jenis klien sebagai aplikasi logik yang tertanam dalam IS untuk mentafsir ciri yang ditetapkan
ID objek yang dikenali
ID Pengenalan
Kategori pelanggan
100500
100001
Lanun
100501
100002
Lanun
100502
100003
Pelaut
Bagaimanakah organisasi storan data yang dinormalkan memudahkan pembangunan kompleks IP? Katakan anda tiba-tiba mendapat pelanggan baharu. Biarkan lanun Jepun yang mungkin tidak mempunyai janggut, tetapi mereka berjalan dengan burung kakak tua di bahu mereka, dan lanun alam sekitar, anda boleh dengan mudah mengenali mereka dengan profil biru Greta di dada kiri.
Lanun alam sekitar, secara semula jadi, tidak boleh menggunakan sikat tulang dan memerlukan analog yang diperbuat daripada plastik laut kitar semula.
Anda perlu mengolah semula algoritma program mengikut input baharu. Jika peraturan penormalan dipatuhi, maka anda hanya perlu menambah input untuk beberapa cawangan proses dalam sesetengah sistem dan membuat cawangan baharu hanya untuk kes tersebut dan dalam IS yang mana rambut muka penting. Tetapi, kerana peraturan tidak dipatuhi, anda perlu menganalisis keseluruhan kod, di seluruh litar, di mana nilai direktori jenis klien digunakan dan dengan jelas menetapkan bahawa dalam satu kes algoritma harus mengambil kira profesional aktiviti klien, dan dalam ciri fizikal yang lain.
Dalam bentuk yang mencari untuk dinormalkan, kami akan mendapat dua jadual dengan data operasi dan dua direktori:
- hasil pengiktirafan dalam bentuk satu set ciri yang telah ditetapkan,
ID objek yang dikenali
Greta di dada kiri
Burung di bahu
Rambut muka
100510
1
1
1
100511
0
0
1
100512
1
0
- hasil penentuan jenis klien (biarkan ia menjadi paparan tersuai di mana penerangan daripada direktori dipaparkan)
Adakah penyahnormalan yang dikesan bermakna sistem tidak boleh diubah suai untuk memenuhi syarat baharu? Sudah tentu tidak. Jika kita membayangkan bahawa semua sistem maklumat dicipta oleh satu pasukan dengan sifar pusing ganti kakitangan, perkembangan didokumentasikan dengan baik dan maklumat dipindahkan dalam pasukan tanpa kehilangan, maka perubahan yang diperlukan boleh dibuat dengan sedikit usaha. Tetapi jika kita kembali kepada keadaan asal masalah, 1,5 papan kekunci akan dipadamkan hanya untuk mencetak protokol perbincangan bersama dan 0,5 lagi untuk memproses prosedur perolehan.
Dalam contoh di atas, ketiga-tiga bentuk biasa dilanggar, mari kita cuba melanggarnya secara berasingan.
Pelanggaran bentuk normal pertama:
Katakan barang dihantar ke gudang anda dari gudang pembekal dengan mengambil menggunakan satu gazelle 1.5 tan kepunyaan kedai anda. Saiz pesanan anda adalah sangat kecil berbanding perolehan pembekal yang sentiasa disiapkan satu-satu tanpa menunggu pengeluaran. Adakah anda memerlukan jadual berasingan dengan proses perniagaan sedemikian: kenderaan, jenis kenderaan, adakah perlu mengasingkan pelan dan fakta dalam pesanan anda kepada pembekal yang telah berlepas?
Bayangkan berapa banyak sambungan "tambahan" yang perlu ditulis oleh pengaturcara anda jika anda menggunakan model di bawah untuk membangunkan atur cara.
Katakan kami memutuskan bahawa struktur yang dicadangkan adalah tidak perlu rumit; dalam kes kami, memisahkan pelan dan fakta dalam rekod pesanan adalah maklumat yang berlebihan, dan spesifikasi pesanan yang dijana ditulis semula berdasarkan hasil penerimaan barang yang tiba, jarang berlaku. -penggredan dan ketibaan barangan yang tidak berkualiti diselesaikan di luar IS.
Dan kemudian suatu hari anda melihat bagaimana seluruh dewan kedai dipenuhi dengan lanun yang marah dan tidak terawat. Apa yang berlaku?
Ternyata apabila perniagaan anda berkembang, begitu juga penggunaan anda. Pada suatu masa dahulu, keputusan pengurusan telah dibuat bahawa jika gazelle dibebankan dalam jumlah dan/atau berat, yang sangat jarang berlaku, pembekal akan mengutamakan muatan berbanding minuman.
Barangan yang tidak dihantar berakhir dalam pesanan seterusnya dan pergi dengan penerbangan baharu; kehadiran baki minimum di gudang di kedai minuman itu memungkinkan untuk tidak melihat kes yang hilang.
Pesaing terakhir ditutup di pelabuhan, dan kes tusukan lebihan gazelle, dilangkau oleh keutamaan berdasarkan andaian kecukupan baki minimum dan kurang muatan berkala kenderaan, menjadi amalan biasa. Sistem yang dibuat secara idealnya akan berfungsi mengikut algoritma yang tertanam di dalamnya dan akan kehilangan sebarang peluang untuk menjejaki kegagalan sistematik untuk memenuhi pesanan yang dirancang. Hanya reputasi yang rosak dan pelanggan yang tidak berpuas hati akan dapat mengesan masalah tersebut.
Pembaca yang penuh perhatian mungkin menyedari bahawa kuantiti yang dipesan dalam spesifikasi pesanan (T_ORDER_SPEC) dalam bahagian 2 dan bahagian 5 mungkin memenuhi atau mungkin tidak memenuhi keperluan bentuk biasa pertama. Semuanya bergantung pada sama ada, memandangkan pelbagai jenis barang yang dipilih, pada dasarnya unit ukuran yang berbeza boleh jatuh ke dalam bidang yang sama.
Pelanggaran bentuk normal kedua:
Apabila keperluan anda semakin meningkat, anda membeli beberapa lagi kenderaan dengan saiz yang berbeza. Dalam konteks di atas, penciptaan direktori kenderaan dianggap berlebihan; akibatnya, semua algoritma pemprosesan data yang memenuhi keperluan penghantaran dan gudang menganggap pergerakan kargo dari pembekal ke gudang sebagai penerbangan 1,5 tan secara eksklusif kijang. Jadi, bersama-sama dengan pembelian kenderaan baharu, anda masih mencipta direktori kenderaan, tetapi apabila memuktamadkannya, anda perlu menganalisis semua kod yang merujuk pergerakan kargo untuk mengetahui sama ada di setiap tempat tertentu rujukan tersirat kepada ciri-ciri daripada kenderaan dari mana perniagaan bermula.
Pelanggaran bentuk normal ketiga:
Pada satu ketika anda mula membuat program kesetiaan, rekod pelanggan tetap muncul. Mengapa, sebagai contoh, meluangkan masa untuk membuat paparan material yang menyimpan data agregat mengenai jualan kepada pelanggan individu untuk digunakan dalam pelaporan dan pemindahan ke sistem analisis, jika pada permulaan program kesetiaan semua yang menarik minat pelanggan boleh diletakkan pada rekod pelanggan ? Dan, sememangnya, pada pandangan pertama, tidak ada gunanya. Tetapi setiap kali perniagaan anda berhubung, contohnya, saluran jualan baharu, mesti ada seseorang dalam kalangan penganalisis anda yang akan ingat bahawa atribut pengagregatan sedemikian wujud.
Apabila mereka bentuk setiap proses baru, sebagai contoh, jualan di Internet, jualan melalui pengedar yang disambungkan kepada sistem kesetiaan biasa, seseorang mesti ingat bahawa semua proses baharu mesti memastikan integriti data pada tahap kod. Untuk pangkalan data industri dengan seribu jadual, ini kelihatan seperti tugas yang mustahil.
Pemaju yang berpengalaman, tentu saja, tahu bagaimana untuk menghapuskan semua masalah yang disebutkan di atas, tetapi, pada pendapat saya, tugas seorang penganalisis yang berpengalaman bukanlah untuk membawanya kepada cahaya.
Saya ingin mengucapkan terima kasih kepada pemaju terkemuka Evgeniy Yarukhin atas maklum balas yang berharga semasa penyediaan penerbitan.
Kesusasteraan
Connolly Thomas, Begg Caroline. Pangkalan data. Reka bentuk, pelaksanaan dan sokongan. Teori dan amalan
Sumber: www.habr.com