Salam! Mənim adım Andrey Semenov, mən Sportmaster-də baş analitikəm. Bu yazıda mən ERP sistem verilənlər bazalarının normallaşdırılması məsələsini qaldırmaq istəyirəm. Biz ümumi şərtlərə, eləcə də konkret bir nümunəyə baxacağıq - deyək ki, quldurlar və dənizçilər üçün gözəl bir monopoliya meyxanası olardı. Hansı quldurlara və dənizçilərə fərqli xidmət göstərilməlidir, çünki bu yaxşı cənabların gözəllik ideyaları və istehlakçı nümunələri əhəmiyyətli dərəcədə fərqlidir.
Hər kəsi necə xoşbəxt etmək olar? Belə bir sistemi dizayn etmək və saxlamaq üçün çılğınlıqdan necə qaçınmaq olar? Meyxanaya təkcə adi quldurlar və dənizçilər gəlməyə başlasa nə etməli?
Hər şey kəsik altındadır. Amma gəlin qaydada gedək.
1. Məhdudiyyətlər və fərziyyələr
Yuxarıda göstərilənlərin hamısı yalnız əlaqəli verilənlər bazalarına aiddir. İnternet də daxil olmaqla yaxşı işıqlandırılan modifikasiya, silmə və daxiletmə anomaliyaları şəklində denormalizasiyanın nəticələri nəzərə alınmır. Bu nəşrin əhatə dairəsindən kənarda klassik nümunələrlə denormalizasiyanın adi bir yer olduğu hallar var: pasport seriyası və nömrəsi, tarix və vaxt və s.
Yazı riyazi terminlərə istinad etmədən normal formaların intuitiv və praktiki olaraq tətbiq olunan təriflərindən istifadə edir. Onlar real biznes proseslərinin (BP) yoxlanılmasına və sənaye proqram təminatının dizaynına tətbiq oluna biləcək formada.
İddia olunur ki, məlumat anbarlarının, hesabat alətlərinin və inteqrasiya müqavilələrinin dizaynı (məlumatların cədvəl şəklində təqdim edilməsindən istifadə edən) ERP sistem verilənlər bazalarının dizaynından onunla fərqlənir ki, istehlak asanlığı və buna nail olmaq üçün şüurlu denormalizasiyadan istifadə bütövlükdən üstün ola bilər. mühafizə məlumatları. Mən bu fikri bölüşürəm və aşağıda təsvir olunanlar yalnız ERP sistemlərinin əsas məlumatlarına və əməliyyat məlumat modellərinə aiddir.
Normal formaların izahı əksər oxucular üçün gündəlik səviyyədə başa düşülən bir nümunədən istifadə etməklə verilir. Bununla belə, əyani illüstrasiya kimi 4-5-ci bəndlərdə bilərəkdən “uydurma” tapşırığından istifadə edilmişdir. Bunu etməsəniz və bəzi dərslik nümunəsini götürsəniz, məsələn, 2-ci bənddən eyni sifariş saxlama modelini götürsəniz, oxucunun diqqətinin prosesin təklif olunan parçalanmasından bir modelə çevriləcəyi bir vəziyyətdə tapa bilərsiniz, şəxsi təcrübəyə və İS-də məlumatların saxlanması üçün proseslərin və modellərin necə qurulacağına dair qavrayışa. Başqa sözlə, iki ixtisaslı İT analitikini götürün, biri sərnişin daşıyan logistlərə, digəri mikroçip istehsalı üçün maşın daşıyan logistikalara xidmət göstərsin. Onlardan əvvəlcədən avtomatlaşdırılmış BP-ləri müzakirə etmədən dəmir yolu səfəri haqqında məlumat saxlamaq üçün məlumat modeli yaratmağı xahiş edin.
Təklif olunan modellərdə nəinki nəzərəçarpacaq dərəcədə fərqli atributlar dəstini, həm də fərqli obyektlər dəstlərini tapa biləcəyiniz sıfırdan fərqli bir ehtimal var, çünki hər bir analitik ona tanış olan proseslərə və tapşırıqlara etibar edəcəkdir. Və belə bir vəziyyətdə hansı modelin “düzgün” olduğunu söyləmək mümkün deyil, çünki qiymətləndirmə meyarı yoxdur.
2. Normal formalar
Verilənlər bazasının ilk normal forması bütün atributların atomlu olmasını tələb edir.
Xüsusilə, əgər A obyektində əsas olmayan a və b atributları varsa, belə ki, c=f(a,b) və A obyektini təsvir edən cədvəldə c atributunun dəyərini saxlayırsınız, onda verilənlər bazasında birinci normal forma pozulur. . Məsələn, əgər sifarişin spesifikasiyası kəmiyyəti göstərirsə, ölçü vahidləri məhsulun növündən asılıdır: bir halda bu, ədəd, başqa bir halda litr, üçüncü hissədən ibarət paketlər ola bilər (yuxarıda Good_count_WR modelində) , onda verilənlər bazasında atributların atomluğu pozulur. Bu vəziyyətdə, sifariş spesifikasiyasının cədvəl klasterinin nə olduğunu söyləmək üçün İS-də iş prosesinin məqsədyönlü təsvirinə ehtiyacınız var və proseslər fərqli ola biləcəyi üçün çoxlu "düzgün" versiyalar ola bilər.
Verilənlər bazasının ikinci normal forması İS-də iş prosesi ilə bağlı hər bir qurum üçün birinci formaya və öz cədvəlinə uyğunluğu tələb edir. Əgər bir cədvəldə c=f1(a) və d=f2(b) asılılıqları varsa və c=f3(b) asılılığı yoxdursa, cədvəldə ikinci normal forma pozulmuşdur. Yuxarıdakı nümunədə Sifariş cədvəlində sifariş və ünvan arasında heç bir asılılıq yoxdur. Küçə və ya şəhər adını dəyişdirin və sifarişin əsas atributlarına heç bir təsiriniz olmayacaq.
Üçüncü normal forma verilənlər bazası ikinci normal formaya uyğunluğu və müxtəlif obyektlərin atributları arasında funksional asılılığın olmamasını tələb edir. Bu qaydanı belə formalaşdırmaq olar: “hesablana bilən hər şey hesablanmalıdır”. Başqa sözlə, iki A və B obyekti varsa. A obyektinin atributlarının saxlandığı cədvəldə C atributu təzahür edir və B obyektində b atributu var ki, c=f4(b) mövcuddur, onda üçüncü normal forma pozulur. Aşağıdakı misalda, sifariş qeydindəki Parçaların Kəmiyyəti atributu (Total_count_WR) açıq şəkildə üçüncü normal formanı pozduğunu iddia edir.
3. Normallaşdırmanın tətbiqinə yanaşmam
1. Yalnız məqsədyönlü avtomatlaşdırılmış biznes prosesi analitikə verilənlərin saxlanması modelini yaratarkən obyektlərin və atributların müəyyən edilməsi üçün meyarlar təqdim edə bilər. Normal məlumat modelinin yaradılması üçün proses modelinin yaradılması ilkin şərtdir.
2. Aşağıdakı şərtlərdən bəziləri və ya hamısı yerinə yetirildikdə, ciddi mənada üçüncü normal formaya nail olmaq ERP sistemlərinin yaradılması praktikasında praktiki olmaya bilər:
- avtomatlaşdırılmış proseslər nadir hallarda dəyişikliyə məruz qalır,
- tədqiqat və inkişaf üçün son tarixlər sıxdır,
- məlumatların bütövlüyünə dair tələblər nisbətən aşağıdır (sənaye proqramında potensial səhvlər proqram təminatı müştərisi tərəfindən pul və ya müştərilərin itirilməsinə səbəb olmur)
- və s.
Təsvir edilən şəraitdə bəzi obyektlərin və onların atributlarının həyat dövrünün müəyyən edilməsi və təsviri xərcləri iqtisadi səmərəlilik baxımından əsaslandırılmaya bilər.
3. Artıq yaradılmış İS-də verilənlər modelinin normallaşdırılmasının istənilən nəticələri kodun hərtərəfli ilkin tədqiqi və sınaq vasitəsilə azalda bilər.
4. Denormalizasiya əmək məsrəflərinin məlumat mənbələrinin tədqiqi və biznes prosesinin layihələndirilməsi mərhələsindən inkişaf mərhələsinə, tətbiqetmə dövründən sistemin inkişaf dövrünə köçürülməsi üsuludur.
5. Verilənlər bazasının üçüncü normal formasına cəhd etmək məqsədəuyğundur, əgər:
- Avtomatlaşdırılmış biznes proseslərində dəyişiklik istiqamətini proqnozlaşdırmaq çətindir
- Tətbiq və/və ya inkişaf komandası daxilində zəif əmək bölgüsü mövcuddur
- İnteqrasiya sxeminə daxil olan sistemlər öz planlarına uyğun olaraq inkişaf edir
- Məlumatların uyğunsuzluğu şirkətin müştərilərini və ya pullarını itirməsi ilə nəticələnə bilər
6. Məlumat modelinin dizaynı analitik tərəfindən yalnız hədəf biznes prosesinin modelləri və İS-də gedən proseslə əlaqədar aparılmalıdır. Tərtibatçı bir məlumat modelini tərtib edərsə, o, mövzu sahəsinə elə bir şəkildə daxil olmalı olacaq ki, xüsusən də atribut dəyərləri arasındakı fərqi başa düşsün - atom atributlarını təcrid etmək üçün zəruri şərt. Beləliklə, qeyri-adi funksiyaları qəbul edir.
4 İllüstrasiya üçün problem
Tutaq ki, limanda kiçik bir robot meyxananız var. Bazar seqmentiniz: limana gələn və fasiləyə ehtiyacı olan dənizçilər və quldurlar. Dənizçilərə kəklikotu ilə çay, dəniz quldurlarına saqqal daramaq üçün rom və sümük darağı satırsan. Meyxananın özündə xidmət robot sahibə və robot barmen tərəfindən həyata keçirilir. Yüksək keyfiyyətiniz və aşağı qiymətləriniz sayəsində siz rəqiblərinizi qovmuşsunuz ki, gəmidən düşən hər kəs limanda yeganə olan meyxananıza gəlir.
Meyxananın informasiya sistemləri kompleksi aşağıdakı proqram təminatından ibarətdir:
- Xarakterik xüsusiyyətlərə görə kateqoriyasını tanıyan müştəri haqqında erkən xəbərdarlıq sistemi
- Robot sahibə və robot barmenlər üçün idarəetmə sistemi
- Anbar və satış nöqtəsinə çatdırılma idarəetmə sistemi
- Təchizatçı Münasibətləri İdarəetmə Sistemi (SURP)
Proses:
Erkən xəbərdarlıq sistemi gəmini tərk edən insanları tanıyır. Bir şəxs təmiz qırxılmışdırsa, onu dənizçi kimi tanıyır; bir adamın saqqalı olduğu aşkar edilərsə, o, pirat kimi tanınır.
Meyxanaya girən qonaq öz kateqoriyasına uyğun olaraq robot sahibənin salamını eşidir, məsələn: “Ho-ho-ho, əziz pirat, get №-li masaya...”
Qonaq göstərilən masaya gedir, burada robot-barmen artıq onun üçün kateqoriyaya uyğun mallar hazırlayıb. Robot barmen anbar sisteminə çatdırılmanın növbəti hissəsinin artırılması barədə məlumat ötürür; anbar İS, anbarda qalan qalıqlara əsaslanaraq, idarəetmə sistemində satınalma sorğusu yaradır.
Erkən xəbərdarlıq sistemi daxili İT-niz tərəfindən hazırlanmış olsa da, bar robotunun idarə olunması proqramı biznesiniz üçün xüsusi olaraq xarici podratçı tərəfindən yaradılmış ola bilər. Anbarların idarə edilməsi sistemləri və təchizatçılarla əlaqələr bazardan fərdiləşdirilmiş paketlənmiş həllərdir.
5. Denormalizasiya nümunələri və onun proqram təminatının inkişafına təsiri
Müsahibə olunan mövzu üzrə ekspertlər bir iş prosesini tərtib edərkən yekdilliklə bildirdilər ki, bütün dünyada dəniz quldurları rom içir və saqqallarını sümük darağı ilə darayırlar, dənizçilər isə kəklikotu ilə çay içirlər və həmişə təraşlıdırlar.
Müştəri növlərinin kataloqu iki dəyərlə görünür: 1 - quldurlar, 2 - dənizçilər, şirkətin bütün məlumat dövrəsi üçün ümumi.
Müştəri bildiriş sistemi dərhal təsvirin işlənməsinin nəticəsini tanınan müştərinin identifikatoru (ID) və onun növü kimi saxlayır: dənizçi və ya pirat.
Tanınmış obyekt identifikatoru
Müştəri kateqoriyası
100500
Pirat
100501
Pirat
100502
dənizçi
Bunu bir daha qeyd edək
1. Dənizçilərimiz əslində qırxılmış insanlardır
2. Piratlarımız əslində saqqallı insanlardır
Bu vəziyyətdə hansı problemləri aradan qaldırmaq lazımdır ki, quruluşumuz üçüncü normal formaya can atsın:
- atribut atomikliyinin pozulması - Müştəri Kateqoriyası
- təhlil edilən fakt və nəticənin bir cədvəldə qarışdırılması
- müxtəlif obyektlərin atributları arasında sabit funksional əlaqə.
Normallaşdırılmış formada iki cədvəl alacağıq:
- müəyyən edilmiş əlamətlər toplusu şəklində tanınma nəticəsi,
Tanınmış obyekt identifikatoru
Üz tükü
100500
Bəli
100501
Bəli
100502
Heç bir
- müəyyən edilmiş xüsusiyyətləri şərh etmək üçün İS-ə daxil edilmiş məntiqin tətbiqi kimi müştəri növünün müəyyən edilməsinin nəticəsi
Tanınmış obyekt identifikatoru
İdentifikasiya ID
Müştəri kateqoriyası
100500
100001
Pirat
100501
100002
Pirat
100502
100003
dənizçi
Normallaşdırılmış məlumat saxlama təşkilatı IP kompleksinin inkişafını necə asanlaşdıra bilər? Deyək ki, siz birdən-birə yeni müştərilər qazandınız. Saqqalı olmayan, lakin çiynində tutuquşu ilə gəzən Yapon quldurları və ekoloq quldurları olsun, onları Gretanın sol sinəsindəki mavi profilindən asanlıqla tanıya bilərsiniz.
Ekoloji quldurlar təbii olaraq sümük daraqlarından istifadə edə bilmir və təkrar emal edilmiş dəniz plastikindən analoq tələb edirlər.
Proqram alqoritmlərini yeni girişlərə uyğun olaraq yenidən işləməlisiniz. Əgər normallaşdırma qaydalarına əməl edilsəydi, onda siz yalnız bəzi sistemlərdə bəzi proses filialları üçün girişləri əlavə etməli və yalnız üz tüklərinin vacib olduğu hallar və İS-lər üçün yeni filiallar yaratmalı olacaqsınız. Lakin, qaydalara əməl edilmədiyi üçün, müştəri tipli kataloqun dəyərlərinin istifadə olunduğu bütün dövrə boyunca bütün kodu təhlil etməli və bir halda alqoritmin peşəkarı nəzərə almalı olduğunu aydın şəkildə müəyyənləşdirməli olacaqsınız. müştərinin fəaliyyəti və digər fiziki xüsusiyyətləri.
Belə bir formada axtarır normallaşdırmaq üçün əməliyyat məlumatları və iki kataloqu olan iki cədvəl alacağıq:
- müəyyən edilmiş əlamətlər toplusu şəklində tanınma nəticəsi,
Tanınmış obyekt identifikatoru
Greta sol sinə üzərində
Çiynində quş
Üz tükü
100510
1
1
1
100511
0
0
1
100512
1
0
- müştəri növünün müəyyən edilməsinin nəticəsi (bu, kataloqlardan təsvirlərin göstərildiyi xüsusi bir görünüş olsun)
Aşkar edilmiş normallaşma o deməkdirmi ki, sistemlər yeni şərtlərə cavab vermək üçün dəyişdirilə bilməz? Əlbəttə yox. Təsəvvür etsək ki, bütün informasiya sistemləri heç bir kadr dəyişikliyi olmayan bir komanda tərəfindən yaradılıb, inkişaflar yaxşı sənədləşdirilib və məlumat itkisiz komanda daxilində ötürülür, onda lazımi dəyişiklikləri əhəmiyyətsiz dərəcədə az səylə etmək olar. Ancaq problemin ilkin şərtlərinə qayıtsaq, 1,5 klaviatura yalnız birgə müzakirələrin protokollarının çapı üçün, digər 0,5 isə satınalma prosedurlarının işlənməsi üçün silinəcək.
Yuxarıdakı misalda hər üç normal forma pozulub, onları ayrı-ayrılıqda pozmağa çalışaq.
Birinci normal formanın pozulması:
Deyək ki, mallar tədarükçülərin anbarlarından meyxananıza məxsus 1.5 tonluq ceyrandan götürməklə anbarınıza çatdırılır. Sifarişlərinizin həcmi tədarükçülərin dövriyyəsinə nisbətən o qədər kiçikdir ki, onlar həmişə istehsalı gözləmədən təkbətək tamamlanır. Belə bir iş prosesi ilə ayrıca cədvəllərə ehtiyacınız varmı: nəqliyyat vasitələri, nəqliyyat vasitələrinin növləri, ayrılmış təchizatçılara sifarişlərinizdə plan və faktları ayırmaq lazımdırmı?
Təsəvvür edin ki, proqram hazırlamaq üçün aşağıdakı modeldən istifadə etsəniz, proqramçılarınız nə qədər “əlavə” əlaqə yazmalı olacaqlar.
Tutaq ki, biz qərara gəldik ki, təklif olunan struktur lazımsız dərəcədə mürəkkəbdir; bizim vəziyyətimizdə sifariş qeydində plan və faktın ayrılması lazımsız məlumatdır və yaradılan sifariş spesifikasiyası gələn malların qəbulunun nəticələrinə əsasən yenidən yazılır, nadir səhvlər -qeyri-adekvat keyfiyyətə malik olmayan malların çeşidlənməsi və gəlişi İS-dən kənarda həll edilir.
Və sonra bir gün bütün meyxananın qəzəbli və səliqəsiz quldurlarla necə dolu olduğunu görürsən. Nə olub?
Belə çıxır ki, biznesiniz böyüdükcə istehlakınız da artıb. Bir vaxtlar idarəetmə qərarı verildi ki, ceyranın həcmi və/və ya çəkisi həddən artıq yüklənərsə, bu olduqca nadirdir, tədarükçü içkilərin xeyrinə yükə üstünlük verəcək.
Çatdırılmamış mallar növbəti sifarişlə başa çatdı və yeni reyslə yola düşdü; meyxanadakı anbarda minimum balansın olması itkin halları görməməyə imkan verdi.
Sonuncu rəqib limanda bağlandı və avtomobilin minimum balansının kifayət qədər olması və vaxtaşırı az yüklənməsi fərziyyəsinə əsaslanaraq prioritetləşdirmə ilə yan keçərək ceyran yüklənməsinin deşilmiş halı adi hala çevrildi. Yaradılan sistem ideal şəkildə ona daxil edilmiş alqoritmlərə uyğun işləyəcək və planlaşdırılmış sifarişlərin sistematik şəkildə yerinə yetirilməməsini izləmək imkanından məhrum olacaq. Yalnız zədələnmiş reputasiya və narazı müştərilər problemi aşkar edə biləcəklər.
Diqqətli oxucu 2-ci bölmə və 5-ci bölmədəki sifariş spesifikasiyasındakı (T_ORDER_SPEC) sifariş miqdarının birinci normal formanın tələbinə cavab verə və ya cavab verməyə bilər. Hamısı malların seçilmiş çeşidini nəzərə alaraq, mahiyyətcə fərqli ölçü vahidlərinin eyni sahəyə düşə biləcəyindən asılıdır.
İkinci normal formanın pozulması:
Ehtiyaclarınız artdıqca, müxtəlif ölçülü bir neçə daha çox avtomobil alırsınız. Yuxarıdakı kontekstdə nəqliyyat vasitələrinin kataloqunun yaradılması lazımsız hesab edildi, nəticədə çatdırılma və anbar ehtiyaclarına xidmət edən bütün məlumatların işlənməsi alqoritmləri yükün tədarükçüdən anbara hərəkətini yalnız 1,5 tonluq bir təyyarənin uçuşu kimi qəbul edir. ceyran. Beləliklə, yeni nəqliyyat vasitələrinin alınması ilə yanaşı, siz hələ də bir nəqliyyat vasitəsi kataloqu yaradırsınız, lakin onu yekunlaşdırarkən, hər bir konkret yerdə istinadların xüsusiyyətlərə aid olub olmadığını öyrənmək üçün yükün hərəkətinə istinad edən bütün kodu təhlil etməli olacaqsınız. biznesin başladığı nəqliyyat vasitəsidir.
Üçüncü normal formanın pozulması:
Bir anda loyallıq proqramı yaratmağa başlayırsınız, daimi müştərinin qeydi görünür. Əgər loyallıq proqramının başlanğıcında müştərini maraqlandıran hər şey müştərinin qeydinə yerləşdirilə bilərsə, məsələn, hesabat vermək və analitik sistemlərə ötürmək üçün istifadə etmək üçün fərdi müştəriyə satışlar haqqında məcmu məlumatları saxlayan maddi görünüşlərin yaradılmasına niyə vaxt sərf etmək lazımdır? ? Və həqiqətən də, ilk baxışdan heç bir mənası yoxdur. Ancaq biznesiniz hər dəfə, məsələn, yeni satış kanallarını birləşdirəndə, analitikləriniz arasında belə bir toplama atributunun mövcud olduğunu xatırlayacaq kimsə olmalıdır.
Hər bir yeni prosesi dizayn edərkən, məsələn, İnternetdə satış, ümumi loyallıq sisteminə qoşulmuş distribyutorlar vasitəsilə satış, kimsə yadda saxlamalıdır ki, bütün yeni proseslər kod səviyyəsində məlumatların bütövlüyünü təmin etməlidir. Min cədvəli olan sənaye verilənlər bazası üçün bu, qeyri-mümkün bir iş kimi görünür.
Təcrübəli tərtibatçı, əlbəttə ki, yuxarıda qeyd olunan bütün problemləri necə dayandıracağını bilir, amma mənim fikrimcə, təcrübəli analitikin vəzifəsi onları üzə çıxarmaq deyil.
Nəşrin hazırlanması zamanı dəyərli rəyinə görə aparıcı tərtibatçı Evgeni Yaruxinə minnətdarlığımı bildirmək istərdim.
Ədəbiyyat
Connolly Tomas, Begg Caroline. Verilənlər bazası. Dizayn, tətbiq və dəstək. Nəzəriyyə və təcrübə
Mənbə: www.habr.com