Merhaba! Adım Andrey Semenov, Sportmaster'da kıdemli analistim. Bu yazıda ERP sistemi veritabanlarının denormalizasyonu konusunu gündeme getirmek istiyorum. Genel koşulların yanı sıra belirli bir örneğe de bakacağız - diyelim ki korsanlar ve denizciler için harika bir tekel meyhanesi olacak. Korsanlara ve denizcilere farklı hizmet verilmesi gereken bir yer çünkü bu iyi beylerin güzellik fikirleri ve tüketim kalıpları önemli ölçüde farklı.
Herkesi nasıl mutlu edebiliriz? Böyle bir sistemi tasarlarken ve sürdürürken çılgına dönmekten nasıl kaçınabilirsiniz? Meyhaneye sadece sıradan korsanlar ve denizciler gelmeye başlamazsa ne yapmalı?
Her şey kesim altında. Ama sırayla gidelim.
1. Sınırlamalar ve varsayımlar
Yukarıdakilerin tümü yalnızca ilişkisel veritabanları için geçerlidir. İnternet de dahil olmak üzere iyi bir şekilde ele alınan değişiklik, silme ve ekleme anormallikleri şeklindeki denormalizasyonun sonuçları dikkate alınmaz. Bu yayının kapsamı dışında denormalizasyonun yaygın olduğu durumlar da vardır; klasik örneklerle: pasaport serisi ve numarası, tarih ve saat vb.
Gönderide, matematiksel terimlere atıfta bulunulmadan, normal formların sezgisel ve pratik olarak uygulanabilir tanımları kullanılıyor. Gerçek iş süreçlerinin (BP) incelenmesine ve endüstriyel yazılım tasarımına uygulanabilecek formdadır.
Veri ambarlarının, raporlama araçlarının ve entegrasyon anlaşmalarının (bilginin tablo halinde gösterimini kullanan) tasarımının, tüketim kolaylığı ve bunu başarmak için bilinçli denormalizasyon kullanımının bütünlükten önce gelebilmesi açısından ERP sistemi veritabanlarının tasarımından farklı olduğu ileri sürülmektedir. koruma verileri. Bu görüşü paylaşıyorum ve aşağıda anlatılanlar yalnızca ERP sistemlerinin ana verileri ve işlemsel veri modelleri için geçerlidir.
Normal formların açıklaması, çoğu okuyucunun günlük düzeyde anlayabileceği bir örnek kullanılarak verilmiştir. Ancak görsel bir örnek olarak 4-5. paragraflarda bilinçli olarak “kurgusal” bir görev kullanılmış. Bunu yapmazsanız ve bazı ders kitabı örneklerini alırsanız, örneğin 2. maddedeki aynı sıralı depolama modelini alırsanız, kendinizi okuyucunun odağının önerilen sürecin ayrıştırılmasından bir modele kaydırılacağı bir durumda bulabilirsiniz. Bilgi Sistemleri'nde veri depolamaya yönelik süreç ve modellerin nasıl oluşturulması gerektiğine ilişkin kişisel deneyim ve algıya. Başka bir deyişle, iki nitelikli BT analistini ele alalım, biri yolcu taşıyan lojistikçilere, diğeri ise mikroçip üretimi için makine taşıyan lojistikçilere hizmet versin. Otomatik BP'leri önceden tartışmadan, bir demiryolu yolculuğu hakkında bilgi depolamak için bir veri modeli oluşturmalarını isteyin.
Önerilen modellerde yalnızca fark edilir derecede farklı nitelikler kümesi değil, aynı zamanda farklı varlık kümeleri de bulma olasılığınız sıfırdan fazladır, çünkü her analist kendisine tanıdık gelen süreçlere ve görevlere güvenecektir. Böyle bir durumda hangi modelin “doğru” olduğunu söylemek de mümkün olmuyor çünkü bir değerlendirme kriteri yok.
2. Normal formlar
Veritabanının ilk normal formu tüm niteliklerin atomikliğini gerektirir.
Özellikle, eğer A nesnesi, c=f(a,b) gibi anahtar olmayan a ve b niteliklerine sahipse ve A nesnesini tanımlayan tabloda c niteliğinin değerini saklıyorsanız, bu durumda veritabanındaki ilk normal form ihlal edilir. . Örneğin, sipariş spesifikasyonunda ölçü birimleri ürünün türüne bağlı olan bir miktar belirtiliyorsa: bir durumda bu adet olabilir, başka bir litrede parçalardan oluşan üçüncü bir pakette olabilir (Good_count_WR'nin üzerindeki modelde) , bu durumda veritabanındaki niteliklerin atomikliği ihlal edilir. Bu durumda, sipariş spesifikasyonunun tablo kümesinin ne olması gerektiğini söylemek için IS'deki iş sürecinin hedeflenen bir açıklamasına ihtiyacınız vardır ve süreçler farklı olabileceğinden birçok "doğru" versiyon olabilir.
Veritabanının ikinci normal formu IS'deki iş süreciyle ilgili her varlık için ilk forma ve kendi tablosuna uyulmasını gerektirir. Eğer bir tabloda c=f1(a) ve d=f2(b) bağımlılıkları varsa ve c=f3(b) bağımlılığı yoksa, tabloda ikinci normal form ihlal edilmiştir. Yukarıdaki örnekte Order tablosunda order ile adres arasında herhangi bir bağımlılık yoktur. Cadde veya şehir adını değiştirdiğinizde düzenin temel nitelikleri üzerinde hiçbir etki yaratmazsınız.
Üçüncü normal form veritabanı ikinci normal forma uygunluğu ve farklı varlıkların nitelikleri arasında işlevsel bağımlılıkların bulunmamasını gerektirir. Bu kural şu şekilde formüle edilebilir: “Hesaplanabilecek her şey hesaplanmalıdır.” Başka bir deyişle, A ve B olmak üzere iki nesne varsa. A nesnesinin özniteliklerini saklayan tabloda, C özniteliği ortaya çıkar ve B nesnesi c=f4(b) olacak şekilde b özniteliğine sahiptir, o zaman üçüncü normal form ihlal edilir. Aşağıdaki örnekte, sipariş kaydındaki Parça Sayısı özelliğinin (Total_count_WR) üçüncü normal formu ihlal ettiği açıkça iddia edilmektedir.
3. Normalleştirmeyi uygulama yaklaşımım
1. Yalnızca hedef otomatikleştirilmiş bir iş süreci, analistlere bir veri depolama modeli oluştururken varlıkları ve nitelikleri tanımlamaya yönelik kriterleri sağlayabilir. Süreç modeli oluşturmak, normal bir veri modeli oluşturmanın ön koşuludur.
2. Aşağıdaki koşulların bir kısmı veya tamamı karşılanırsa, tam anlamıyla üçüncü normal forma ulaşmak, ERP sistemleri oluşturmanın fiili uygulamasında pratik olmayabilir:
- Otomatik süreçler nadiren değişikliğe tabidir,
- Araştırma ve geliştirme için son tarihler kısıtlı,
- veri bütünlüğü gereksinimleri nispeten düşüktür (endüstriyel yazılımdaki olası hatalar, yazılım müşterisinin para veya müşteri kaybına yol açmaz)
- vb
Açıklanan koşullar altında, bazı nesnelerin ve bunların niteliklerinin yaşam döngüsünü tanımlama ve açıklama maliyetleri, ekonomik verimlilik açısından haklı gösterilmeyebilir.
3. Halihazırda oluşturulmuş bir IS'de veri modelinin denormalizasyonunun herhangi bir sonucu, kodun kapsamlı bir ön çalışması ve test edilmesiyle hafifletilebilir.
4. Denormalizasyon, işçilik maliyetlerini veri kaynaklarının araştırılması ve bir iş sürecinin tasarlanması aşamasından geliştirme aşamasına, uygulama döneminden sistem geliştirme dönemine aktarmanın bir yoludur.
5. Aşağıdaki durumlarda veri tabanının üçüncü normal biçimi için çaba gösterilmesi tavsiye edilir:
- Otomatik iş süreçlerindeki değişimin yönünü tahmin etmek zordur
- Uygulama ve/veya geliştirme ekibinde zayıf bir iş bölümü var
- Entegrasyon devresine dahil olan sistemler kendi planlarına göre gelişir
- Veri tutarsızlığı bir şirketin müşteri veya para kaybetmesine neden olabilir
6. Bir veri modelinin tasarımı, bir analist tarafından yalnızca hedef iş sürecinin modelleri ve IS'deki süreçle bağlantılı olarak gerçekleştirilmelidir. Bir geliştirici bir veri modeli tasarlıyorsa, özellikle atomik nitelikleri izole etmek için gerekli bir koşul olan nitelik değerleri arasındaki farkı anlayacak kadar konu alanına kendini kaptırması gerekecektir. Böylece alışılmadık işlevler üstleniyor.
4 Gösterim için problem
Diyelim ki limanda küçük bir robotik tavernanız var. Pazar segmentiniz: limana gelen ve molaya ihtiyaç duyan denizciler ve korsanlar. Denizcilere kekikli çay, korsanlara sakal taramak için rom ve kemik tarakları satıyorsunuz. Meyhanedeki hizmet, bir robot hostes ve bir robot barmen tarafından sağlanıyor. Yüksek kaliteniz ve düşük fiyatlarınız sayesinde rakiplerinizi geride bıraktınız, böylece gemiden inen herkes limandaki tek meyhanenize geliyor.
Meyhane bilgi sistemleri kompleksi aşağıdaki yazılımlardan oluşur:
- Karakteristik özelliklere göre kategorisini tanıyan bir müşteri hakkında erken uyarı sistemi
- Robot hostesler ve robot barmenler için kontrol sistemi
- Satış noktasına depo ve teslimat yönetim sistemi
- Tedarikçi İlişkileri Yönetim Sistemi (SURP)
süreci:
Erken uyarı sistemi gemiden ayrılan kişileri algılıyor. Bir kişinin tıraşlı olması durumunda denizci olduğu, sakallı olduğu tespit edildiğinde ise korsan olduğu tespit ediliyor.
Meyhaneye giren misafir, robot hostesin kendi kategorisine uygun bir selamlama sesini duyar, örneğin: "Ho-ho-ho, sevgili korsan, No'lu masaya git..."
Konuk, robot barmenin kendisi için kategoriye göre ürünler hazırladığı belirtilen masaya gider. Robot barmen, teslimatın bir sonraki kısmının arttırılması gerektiği bilgisini depo sistemine iletir; depo IS, depoda kalan bakiyelere dayanarak yönetim sisteminde bir satın alma talebi oluşturur.
Erken uyarı sistemi dahili BT biriminiz tarafından geliştirilmiş olsa da, çubuk robot yönetim programı harici bir yüklenici tarafından işletmenize özel olarak oluşturulmuş olabilir. Depoları ve tedarikçilerle ilişkileri yönetmeye yönelik sistemler ise pazarın özelleştirilmiş paket çözümleridir.
5. Denormalizasyon örnekleri ve bunun yazılım geliştirme üzerindeki etkisi
Görüşülen konunun uzmanları, bir iş sürecini tasarlarken, tüm dünyada korsanların rom içtiklerini, sakallarını kemik tarakla taradıklarını, denizcilerin kekikli çay içtiklerini ve her zaman tıraşlı olduklarını oybirliğiyle belirttiler.
Müşteri türlerinin bir dizini iki değerle görünür: 1 - korsanlar, 2 - denizciler, şirketin tüm bilgi devresi için ortaktır.
Müşteri bildirim sistemi, görüntü işleme sonucunu, tanınan müşterinin tanımlayıcısı (ID) ve onun türü: denizci veya korsan olarak hemen kaydeder.
Tanınan nesne kimliği
Müşteri kategorisi
100500
Korsan
100501
Korsan
100502
Denizci
Şunu bir kez daha belirtelim
1. Denizcilerimiz aslında tıraşlı insanlardır
2. Korsanlarımız aslında sakallı insanlardır
Yapımızın üçüncü normal form için çabalaması için bu durumda hangi sorunların ortadan kaldırılması gerekiyor:
- öznitelik atomite ihlali - Müşteri Kategorisi
- analiz edilen gerçeği ve sonucu tek bir tabloda karıştırmak
- Farklı varlıkların nitelikleri arasındaki sabit işlevsel ilişki.
Normalleştirilmiş biçimde iki tablo elde ederiz:
- bir dizi yerleşik özellik biçiminde tanınma sonucu,
Tanınan nesne kimliği
Sakal
100500
Evet
100501
Evet
100502
Hayır
- Yerleşik özellikleri yorumlamak için IS'ye gömülü mantığın bir uygulaması olarak istemci tipinin belirlenmesinin sonucu
Tanınan nesne kimliği
Kimlik Kimliği
Müşteri kategorisi
100500
100001
Korsan
100501
100002
Korsan
100502
100003
Denizci
Normalleştirilmiş bir veri depolama organizasyonu, bir fikri mülkiyet kompleksinin geliştirilmesini nasıl kolaylaştırabilir? Diyelim ki aniden yeni müşteriler edindiniz. Sakalı olmasa da omuzlarında papağanla yürüyen Japon korsanlar olsun, çevreci korsanlar ise Greta'nın sol göğsündeki mavi profilinden rahatlıkla tanıyabilirsiniz.
Çevre korsanları doğal olarak kemik taraklarını kullanamıyor ve geri dönüştürülmüş deniz plastiğinden yapılmış bir analoga ihtiyaç duyuyor.
Program algoritmalarını yeni girdilere göre yeniden çalışmanız gerekiyor. Normalleştirme kurallarına uyulsaydı, bazı sistemlerde yalnızca bazı süreç dalları için girdileri tamamlamanız ve yalnızca sakalın önemli olduğu durumlar ve IS'ler için yeni dallar oluşturmanız gerekirdi. Ancak kurallara uyulmadığı için, istemci tipi dizinin değerlerinin kullanıldığı tüm devre boyunca kodun tamamını analiz etmeniz ve bir durumda algoritmanın profesyonelleri dikkate alması gerektiğini açıkça belirlemeniz gerekecektir. müşterinin aktivitesinde ve diğer fiziksel özelliklerde.
Bir formda arıyor normalleştirmek için operasyonel verileri içeren iki tablo ve iki dizin elde ederiz:
- bir dizi yerleşik özellik biçiminde tanınma sonucu,
Tanınan nesne kimliği
Greta sol göğüste
Omuzdaki kuş
Sakal
100510
1
1
1
100511
0
0
1
100512
1
0
- istemci türünü belirlemenin sonucu (dizinlerdeki açıklamaların görüntülendiği özel bir görünüm olmasına izin verin)
Tespit edilen denormalizasyon, sistemlerin yeni koşulları karşılayacak şekilde değiştirilemeyeceği anlamına mı geliyor? Tabii ki değil. Tüm bilgi sistemlerinin tek bir ekip tarafından sıfır personel değişimi ile oluşturulduğunu, gelişmelerin iyi bir şekilde belgelendiğini ve ekip içinde bilginin kayıpsız olarak aktarıldığını hayal edersek, gerekli değişiklikler yok denecek kadar az çabayla yapılabilir. Ancak sorunun orijinal koşullarına dönersek, yalnızca ortak tartışma protokollerinin basılması için 1,5 klavye ve satın alma prosedürlerini işlemek için 0,5 klavye silinecek.
Yukarıdaki örnekte üç normal form da ihlal edilmiştir, hadi bunları ayrı ayrı ihlal etmeye çalışalım.
Birinci normal formun ihlali:
Diyelim ki, meyhanenize ait 1.5 tonluk ceylan kullanılarak mallar tedarikçilerin depolarından alınarak deponuza teslim ediliyor. Siparişlerinizin boyutu, tedarikçilerin cirosuna göre o kadar küçük ki, üretim için beklemeden her zaman bire bir tamamlanıyor. Böyle bir iş süreci için ayrı tablolara mı ihtiyacınız var: Araçlar, araç türleri, ayrılan tedarikçilere verdiğiniz siparişlerde plan ve gerçeği ayırmak gerekli mi?
Bir program geliştirmek için aşağıdaki modeli kullanırsanız programcılarınızın kaç tane "ekstra" bağlantı yazması gerekeceğini bir düşünün.
Diyelim ki önerilen yapının gereksiz derecede karmaşık olduğuna karar verdik; bizim durumumuzda sipariş kaydındaki plan ile gerçeğin ayrılması gereksiz bilgidir ve oluşturulan sipariş spesifikasyonunun gelen malların kabul sonuçlarına göre yeniden yazılması nadir yanlışlıktır. - Yetersiz kalitede malların sınıflandırılması ve gelişi IS dışında halledilir.
Ve sonra bir gün meyhane salonunun tamamının nasıl kızgın ve dağınık korsanlarla dolu olduğunu görüyorsunuz. Ne oldu?
İşletmeniz büyüdükçe tüketiminizin de arttığı ortaya çıktı. Bir zamanlar, bir ceylanın hacim ve/veya ağırlık açısından aşırı yüklenmesi durumunda, ki bu son derece nadir bir durumdu, tedarikçinin yüke içecekler lehine öncelik vermesi yönünde bir yönetim kararı vardı.
Teslim edilmeyen mallar bir sonraki siparişte sona erdi ve yeni bir uçuşa bırakıldı, meyhanedeki depoda minimum bakiyenin bulunması, eksik vakaların fark edilmemesini mümkün kıldı.
Son yarışmacının limanda kapanması ve minimum bakiyenin yeterliliği varsayımına göre önceliklendirme yapılarak aracın periyodik olarak az yüklenmesi ve delinmiş ceylan aşırı yüklenmesi durumu yaygın uygulama haline geldi. Oluşturulan sistem, ideal olarak, içine yerleştirilmiş algoritmalara uygun olarak çalışacak ve planlanan siparişlerin yerine getirilmesindeki sistematik başarısızlığı takip etme fırsatından mahrum kalacaktır. Yalnızca itibarı zarar görmüş ve memnun olmayan müşteriler sorunu tespit edebilir.
Dikkatli bir okuyucu, bölüm 2 ve bölüm 5'teki sipariş spesifikasyonunda (T_ORDER_SPEC) sipariş edilen miktarın, ilk normal formun gerekliliklerini karşılayıp karşılamayabileceğini fark etmiş olabilir. Her şey, seçilen ürün yelpazesi göz önüne alındığında, esasen farklı ölçü birimlerinin aynı alana girip giremeyeceğine bağlıdır.
İkinci normal formun ihlali:
İhtiyaçlarınız arttıkça farklı boyutlarda birkaç araç daha satın alırsınız. Yukarıdaki bağlamda, bir araç rehberinin oluşturulması gereksiz kabul edildi; bunun sonucunda teslimat ve depo ihtiyaçlarına hizmet eden tüm veri işleme algoritmaları, kargonun tedarikçiden depoya hareketini yalnızca 1,5 tonluk bir uçağın uçuşu olarak algılıyor. ceylan. Yani, yeni araçların satın alınmasıyla birlikte yine de bir araç dizini oluşturursunuz, ancak bunu sonlandırırken, her belirli yerde referansların özelliklere ima edilip edilmediğini öğrenmek için kargonun hareketine referans veren tüm kodu analiz etmeniz gerekecektir. işin başladığı aracın kendisi.
Üçüncü normal formun ihlali:
Bir noktada sadakat programı oluşturmaya başladığınızda düzenli bir müşterinin kaydı ortaya çıkıyor. Örneğin, bir sadakat programının başlangıcında müşteriyi ilgilendiren her şey müşterinin kaydına alınabiliyorsa, raporlamada kullanılmak ve analitik sistemlere aktarılmak üzere bireysel bir müşteriye yapılan satışlara ilişkin toplu verileri depolayan malzeme görünümleri oluşturmak için neden zaman harcayasınız ki? ? Ve aslında ilk bakışta hiçbir anlamı yok. Ancak işletmeniz örneğin yeni satış kanallarına her bağlandığında, analistleriniz arasında böyle bir toplama özelliğinin var olduğunu hatırlayacak biri bulunmalıdır.
Her yeni süreci tasarlarken, örneğin internetteki satışlar, ortak sadakat sistemine bağlı distribütörler aracılığıyla yapılan satışlar, tüm yeni süreçlerin kod düzeyinde veri bütünlüğünü sağlaması gerektiğini akılda tutmak gerekir. Binlerce tablodan oluşan endüstriyel bir veritabanı için bu imkansız bir görev gibi görünüyor.
Deneyimli bir geliştirici elbette yukarıda bahsedilen tüm sorunları nasıl durduracağını bilir, ancak bana göre deneyimli bir analistin görevi bunları gün ışığına çıkarmak değildir.
Yayının hazırlanması sırasında verdiği değerli geri bildirimlerden dolayı önde gelen geliştirici Evgeniy Yarukhin'e şükranlarımı sunmak isterim.
Edebiyat
Connolly Thomas, Begg Caroline. Veri tabanı. Tasarım, uygulama ve destek. Teori ve pratik
Kaynak: habr.com