Rublesi döviz kurunun zaman serisini içeren Olap küpü. Olap, kelimenin dar anlamında şu şekilde yorumlanır: olap küpleri

Pirinç. 2. OLAP küp dilimi

Döndürme(Şekil 3) - Bir raporda veya görüntülenen sayfada sunulan ölçümlerin konumunu değiştirme işlemi. Örneğin bir döndürme işlemi, bir tablonun satır ve sütunlarının yeniden düzenlenmesini içerebilir. Ek olarak, bir veri küpünün döndürülmesi tablo dışı boyutları görüntülenen sayfada mevcut olan boyutlara taşır ve bunun tersi de geçerlidir.

/ Kübist bir tarzda. OLAP küplerinin büyük şirketlerin yönetim uygulamalarında uygulanması

Temas halinde

Sınıf arkadaşları

Konstantin Tokmaçev, sistem mimarı

Kübist tarzda.
OLAP küplerinin büyük şirketlerin yönetim uygulamalarında uygulanması

Belki de bir şirketin bilgi işlem kaynaklarının yalnızca bilgi kaydetme ve muhasebe raporlarına harcandığı zaman geçti. Aynı zamanda ofislerde, toplantılarda ve oturumlarda yönetim kararları “gözle” alınıyordu. Belki de Rusya'da kurumsal bilgi işlem sistemlerini eski haline döndürmenin zamanı gelmiştir. ana kaynak– bilgisayarda kaydedilen verilere dayanarak kontrol problemlerinin çözülmesi

İş analitiğinin faydaları hakkında

Kurumsal yönetim döngüsünde, "ham" veriler ile yönetilen nesneyi etkilemenin "kaldıraçları" arasında "performans göstergeleri" - KPI'ler vardır. Kontrol edilen nesnenin çeşitli alt sistemlerinin durumunu yansıtan bir tür "gösterge tablosu" oluştururlar. Şirketi bilgilendirici performans göstergeleri ile donatmak ve bunların hesaplanmasını ve elde edilen değerleri izlemek bir iş analistinin işidir. MS SQL Server Analiz Hizmetleri (SSAS) yardımcı programı ve ana aracı OLAP küpü gibi otomatik analiz hizmetleri, kurumun analitik çalışmasını organize etmede önemli yardım sağlayabilir.

Tam burada bir noktaya daha değinmek gerekiyor. Diyelim ki Amerikan geleneğinde OLAP küpleriyle çalışmaya odaklanan bir uzmanlığa BI (İş Zekası) deniyor. Amerikan BI'sının Rus "iş analistine" karşılık geldiğine dair hiçbir yanılsama olmamalıdır. Kusura bakmayın ama iş analistimiz çoğu zaman bir "muhasebeci" ve "yetersiz programcıdır", belirsiz bilgisi olan ve küçük bir maaşı olan, aslında kendi araç ve metodolojilerinden hiçbirine sahip olmayan bir uzmandır.

Bir BI uzmanı aslında uygulamalı bir matematikçidir, modern matematiksel yöntemleri şirketin cephaneliğine (Yöneylem Araştırması olarak adlandırılan - yöneylem araştırması yöntemleri) koyan yüksek nitelikli bir uzmandır. BI, bir zamanlar SSCB'de olan ve Moskova Devlet Üniversitesi Hesaplamalı Matematik ve Matematik Fakültesi'nden mezun olan "sistem analisti" uzmanlığıyla daha tutarlıdır. M.V. Lomonosov. OLAP küpü ve analiz hizmetleri, belki de Amerikan BI yönünde ileri düzeyde bir eğitimden sonra, bir Rus iş analistinin işyeri için umut verici bir temel haline gelebilir.

Son zamanlarda başka bir zararlı eğilim ortaya çıktı. Uzmanlaşma sayesinde, farklı kategorilerdeki şirket çalışanları arasındaki karşılıklı anlayış kayboldu. I.A.'nın masalındaki "kuğu, kerevit ve turna balığı" gibi bir muhasebeci, yönetici ve programcı. Krylov, şirketi farklı yönlere çekiyor.

Muhasebeci raporlamakla meşguldür; tutarları hem anlam hem de dinamik olarak şirketin iş süreciyle doğrudan ilgili değildir.

Yönetici, iş sürecinin kendi payına düşen kısmıyla meşguldür, ancak eylemlerinin sonuçlarını ve beklentilerini bir bütün olarak şirket düzeyinde küresel olarak değerlendirememektedir.

Son olarak, bir zamanlar (eğitim sayesinde) bilim alanından iş dünyasına ileri teknik fikirlerin iletkeni olan programcı, muhasebeci ve yöneticinin fantezilerinin pasif bir uygulayıcısına dönüştü. Şirketlerin BT departmanlarının muhasebeciler ve genel olarak tembel olmayan herkes tarafından yönetilmesi artık alışılmadık bir durum. İnisiyatif eksikliği, okuma yazma bilmeyen ancak nispeten yüksek maaşlı 1C programcısı, Rus şirketlerinin gerçek bir belasıdır. (Neredeyse yerli futbolcu gibi.) Sözde “ekonomistler ve hukukçular”dan bahsetmiyorum bile, onlar hakkında her şey çok önceden söylendi.

Dolayısıyla, bilgi yoğun bir SSAS cihazı ile donatılmış, programlama ve muhasebenin temelleri konusunda uzman bir iş analistinin pozisyonu, iş sürecinin analizi ve tahmini ile ilgili olarak şirketin çalışmalarını pekiştirme yeteneğine sahiptir.

OLAP küplerinin avantajları

OLAP küpü modern çare hiyerarşinin her seviyesindeki çalışanlara şirketin üretim sürecini karakterize eden gerekli göstergeler setini sağlamayı mümkün kılan kurumsal bilgisayar sistemi veri tabanının analizi. Sadece bu değil Kullanıcı dostu arayüz ve MDX küpü için esnek bir sorgulama dili (Çok Boyutlu ifadeler), gerekli analitik göstergeleri formüle etmenize ve hesaplamanıza olanak tanır, ancak bunu bir OLAP küpünün olağanüstü hız ve kolaylığı ile yapar. Üstelik bu hız ve kolaylık, belirli sınırlar dahilinde, hesaplamaların karmaşıklığına ve veritabanının boyutuna bağlı değildir.

OLAP'a bazı girişler
küp verebilir " Pivot tablo»MSExcel. Bu nesnelerin benzer mantığı ve benzer arayüzleri vardır. Ancak makaleden de anlaşılacağı gibi, OLAP işlevselliği kıyaslanamayacak kadar zengin ve performans kıyaslanamayacak kadar yüksek, dolayısıyla "pivot tablo" yerel bir masaüstü ürünü olarak kalırken OLAP kurumsal düzeyde bir ürün.

OLAP küpü analitik problemleri çözmek için neden bu kadar uygundur? OLAP küpü, olası tüm bölümlerdeki tüm göstergelerin önceden hesaplanacağı (tamamen veya kısmen) ve kullanıcının yalnızca gerekli göstergeleri (ölçüleri) ve boyutları (boyutları) "çekebileceği" şekilde tasarlanmıştır. fare ve program tabloları yeniden çizebilir.

Tüm bölümlerdeki olası tüm analitikler devasa bir alan oluşturur, daha doğrusu bir alan değil, yalnızca çok boyutlu bir OLAP küpüdür. Kullanıcının (yönetici, iş analisti, yönetici) analiz hizmetine yönelttiği talep ne olursa olsun, yanıt verme hızı iki şeyle açıklanır: birincisi, gerekli analizler kolaylıkla formüle edilebilir (ya bir listeden isme göre seçilebilir ya da bir MDX dilindeki formül ), ikincisi, kural olarak zaten hesaplanmıştır.

Analitik formülasyonu üç seçenekte mümkündür: ya bir veritabanı alanıdır (ya da daha doğrusu bir depo alanıdır), ya da küp tasarımı düzeyinde tanımlanmış bir hesaplama alanıdır ya da küp ile etkileşimli olarak çalışırken bir MDX dil ifadesidir.

Bu, OLAP küplerinin birçok çekici özelliği anlamına gelir. Esas itibarıyla kullanıcı ile veri arasındaki bariyer ortadan kalkıyor. Engel, öncelikle sorunu açıklaması (bir görev belirlemesi) gereken bir uygulama programcısı şeklindedir. İkinci olarak, uygulama programcısının bir algoritma oluşturmasını, programı yazıp hata ayıklamasını ve ardından muhtemelen onu değiştirmesini beklemeniz gerekecektir. Çok sayıda çalışan varsa ve onların gereksinimleri çeşitli ve değişkense, o zaman bütün bir ekibe ihtiyaç vardır. Uygulama programları ist. Bu anlamda, bir OLAP küpü (ve nitelikli bir iş analisti), tıpkı bir ekskavatör operatörüne sahip güçlü bir ekskavatörün, bir hendek kazarken tüm göçmen işçiler ekibinin yerini küreklerle değiştirmesi gibi, analitik çalışma açısından tüm uygulama programcıları ekibinin yerini alır!

Aynı zamanda elde edilen analitik verilerin çok önemli bir niteliği daha elde edilir. Şirketin tamamı için yalnızca bir OLAP küpü olduğundan; Bu, verilerdeki can sıkıcı tutarsızlıkları ortadan kaldıran herkes için analistlerin bulunduğu aynı alandır. Bir yöneticinin öznellik faktörünü ortadan kaldırmak için aynı görevi birkaç bağımsız çalışana sormak zorunda kalması, ancak yine de herkesin bir şekilde açıklamayı üstlendiği farklı cevaplar getirmesi vb. OLAP küpü, kurumsal hiyerarşinin farklı seviyelerinde analitik verilerin tekdüzeliğini sağlar; Bir yönetici belirli bir ilgi göstergesini detaylandırmak isterse, o zaman kesinlikle astının çalıştığı alt düzey verilere gelecektir ve bu, tam olarak üst düzey göstergenin hesaplandığı temeldeki veriler olacaktır. ve başka bir şekilde, başka bir zamanda vb. alınan başka veriler değil. Yani, şirketin tamamı aynı analitiği görüyor ancak farklı toplama düzeylerinde.

Bir örnek verelim. Bir yöneticinin alacak hesaplarını kontrol ettiğini varsayalım. Vadesi geçmiş alacaklara ilişkin KPI yeşil olduğu sürece her şey normaldir ve herhangi bir yönetim eylemi gerekmemektedir. Renk sarıya veya kırmızıya dönüştüyse bir şeyler ters gidiyor: KPI'ları satış departmanları tarafından kesiyoruz ve departmanları hemen "kırmızı" olarak görüyoruz. Bir sonraki bölümde yöneticiler ve müşterileri ödemeleri geciktiren satıcılar tarafından belirlenir. (Ayrıca vadesi geçmiş tutar müşterilere, şartlara vb. göre bölünebilir.) Kurumun başkanı ihlalde bulunanlarla her düzeyde doğrudan iletişime geçebilir. Ancak genel olarak aynı KPI (hiyerarşi düzeylerinde) hem departman başkanları hem de satış yöneticileri tarafından görülür. Bu nedenle durumu düzeltmek için "halıya çağrı" beklemelerine bile gerek yok... Elbette KPI'nin kendisinin vadesi geçmiş ödemelerin tutarı olması gerekmez - bu olabilir vadesi geçmiş ödemelerin ağırlıklı ortalama süresi veya genel olarak alacakların devir hızı.

MDX dilinin karmaşıklığı ve esnekliğinin, hızlı (bazen anlık) sonuçlarla birlikte, aksi takdirde hiç ortaya çıkmayabilecek karmaşık kontrol görevlerini çözmemize (geliştirme ve hata ayıklama aşamalarını dikkate alarak) olanak tanıdığını belirtelim. uygulama programcıları için karmaşıklık ve formülasyondaki başlangıçtaki belirsizlik nedeniyle. (Uygulama programcılarının analitik problemleri çözmeleri için, yetersiz anlaşılan formülasyonlar ve koşullar değiştiğinde programlarda yapılan uzun değişiklikler nedeniyle pratikte sıklıkla karşılaşılan uzun son teslim tarihleri.)

Ayrıca şirketin her çalışanının, bir OLAP analistinin işi için ihtiyaç duyduğu hasatı genel sahadan toplayabildiğine ve toplumsal olarak kendisi için kesilen "şerit" ile yetinmemesine dikkat edelim. “standart raporlar”.

İstemci-sunucu modunda bir OLAP küpüyle çalışmaya yönelik çok kullanıcılı arayüz, her çalışanın, diğerlerinden bağımsız olarak, kendi (hatta biraz beceriyle kendi kendine oluşturduğu) analiz bloklarına (raporlarına) sahip olmasına olanak tanır; bu bloklar, tanımlandıktan sonra otomatik olarak oluşturulur. güncellendi - başka bir deyişle, her zaman güncel durumdalar.

Yani, OLAP küpü, analitik çalışmayı (aslında sadece resepsiyon analistleri tarafından değil, aslında şirketin hemen hemen tüm çalışanları, hatta dengeleri ve sevkiyatları kontrol eden lojistikçiler ve yöneticiler tarafından bile gerçekleştirilir) daha seçici hale getirmenize olanak tanır, "genel anlamda değil" işin iyileştirilmesi ve verimliliğin artırılması için koşullar yaratır.

Girişimizi özetlemek gerekirse, OLAP küplerinin kullanımının bir şirketin yönetimini daha yüksek bir seviyeye çıkarabileceğini belirtiyoruz. Hiyerarşinin her seviyesinde analitik verilerin tekdüzeliği, güvenilirliği, karmaşıklığı, göstergeleri oluşturma ve değiştirme kolaylığı, bireysel ayarlar, yüksek hız veri işleme ve son olarak, alternatif analitik yollarını (uygulama programcıları, çalışanların bağımsız hesaplamaları) desteklemek için harcanan para ve zamandan tasarruf, büyük Rus şirketlerinin uygulamalarında OLAP küplerinin kullanılması için fırsatlar yaratıyor.

OLTP + OLAP: taslak geri bildirimşirket yönetim zincirinde

Şimdi OLAP küplerinin genel fikrine ve bunların kurumsal yönetim zincirindeki uygulama noktalarına bakalım. OLAP (OnLine Analytical Processing) terimi, daha önce tanıttığı OLTP (OnLine Transactions Processing) terimine ek olarak İngiliz matematikçi Edgar Codd tarafından tanıtıldı. Bu daha sonra tartışılacak, ancak E. Codd elbette sadece terimleri değil, aynı zamanda OLTP ve OLAP'ın matematiksel teorilerini de önerdi. Ayrıntılara girmeden, modern yorumda OLTP, bilginin kaydedilmesi, saklanması ve alınması için bir mekanizma olarak kabul edilen ilişkisel bir veritabanıdır.

Çözüm metodolojisi

1C7, 1C8, MS Dynamics AX gibi ERP sistemleri (Kurumsal Kaynak Planlama), günümüzde sunulan bilgilerin depolanması ve alınması için kullanıcı odaklı yazılım arayüzlerine (belgelerin girilmesi ve düzenlenmesi vb.) ve ilişkisel bir veritabanına (DB) sahiptir. yazılım ürünleri MS SQL Server (SS) yazın.

ERP sistemi veritabanında kayıtlı bilgilerin gerçekten çok değerli bir kaynak olduğunu unutmayın. Önemli olan, yalnızca kayıtlı bilgilerin şirketin mevcut belge akışını (belgelerin çıkarılması, düzeltilmesi, yazdırılması ve uzlaştırılması yeteneği vb.) Sağlanması ve yalnızca hesaplama olasılığının sağlanması değildir. mali tablolar(vergiler, denetim vb.). Yönetim açısından bakıldığında, OLTP sisteminin (ilişkisel veritabanı) aslında şirketin faaliyetlerinin gerçek boyutlu bir dijital modeli olması çok daha önemlidir.

Ancak süreci yönetmek için süreçle ilgili bilgilerin kaydedilmesi yeterli değildir. Süreç, ilerlemesini karakterize eden bir sayısal göstergeler (KPI) sistemi biçiminde sunulmalıdır. Ayrıca göstergeler için kabul edilebilir değer aralıkları tanımlanmalıdır. Ve yalnızca göstergenin değeri izin verilen aralığın dışına çıkarsa bir kontrol eylemi uygulanmalıdır.

Bu kontrol mantığı (veya mitolojisi) (“sapma yoluyla kontrol”) ile ilgili olarak, hem tekne rotadan saptığında küreğe yaslanan dümenci (siberburun) imajını yaratan antik Yunan filozofu Platon hem de Bilgisayar çağının arifesinde sibernetik bilimini yaratan Amerikalı matematikçi Norbert Wiener.

OLTP yöntemini kullanarak bilgilerin kaydedilmesine yönelik olağan sisteme ek olarak, başka bir sisteme ihtiyaç vardır - toplanan bilgilerin analiz edilmesi için bir sistem. Kontrol döngüsünde yönetim ile kontrol nesnesi arasında geri bildirim görevi gören bu eklenti, bir OLAP sistemi veya kısaca OLAP küpüdür.

Gibi yazılım uygulaması OLAP olarak, MS SQL Server'ın standart sunumunun bir parçası olan ve SSAS olarak kısaltılan MS Analiz Hizmetleri yardımcı programını ele alacağız. E. Codd'un planına göre, analitikteki OLAP küpünün, OLTP sistemi ve ilişkisel veritabanının (SQL Server) bilgi depolama ve alma konusunda sağladığı aynı kapsamlı eylem özgürlüğünü vermesi gerektiğini unutmayın.

OLAP Lojistik

Şimdi OLAP küpünün otomatik çalışmasının dayandığı harici cihazların, uygulama programlarının ve teknolojik operasyonların özel konfigürasyonuna bakalım.

Kurumun, bilgilerin her zamanki gibi kaydedildiği bir ERP sistemi (örneğin 1C7 veya 1C8) kullandığını varsayacağız. Bu ERP sisteminin veri tabanı belirli bir sunucu üzerinde bulunmakta ve MS SQL Server tarafından desteklenmektedir.

Ayrıca başka bir sunucuda, MS Analiz Hizmetleri (SSAS) yardımcı programına sahip MS SQL Server'ın yanı sıra MS SQL Server Management Studio, MS C#, MS Excel ve MS Visual Studio dahil olmak üzere yazılımın kurulu olduğunu varsayacağız. Bu programlar birlikte gerekli bağlamı oluşturur: OLAP küplerinin geliştiricisi için araçlar ve gerekli arayüzler.

SSAS sunucusu, blat adında (parametrelerle birlikte) ücretsiz olarak dağıtılan bir programa sahiptir. Komut satırı ve posta hizmeti sağlamak.

Çalışan iş istasyonlarında, yerel ağ, diğer şeylerin yanı sıra, MS Excel programları da kuruludur (2003'ten daha az olmayan sürümler) ve ayrıca muhtemelen, özel sürücü MS Excel'in MS Analiz Hizmetleri ile çalışmasını sağlamak için (ilgili sürücü MS Excel'de zaten mevcut değilse).

Kesinlik sağlamak için, çalışanların iş istasyonlarının işletim sistemi Windows XP ve sunucularda - Windows Server 2008. Ayrıca, MS SQL Server 2005'in SQL Server olarak kullanılmasına ve OLAP küpüyle birlikte sunucuya Enterprise Edition (EE) veya Developer Edition'ın (DE) kurulmasına izin verin. Bu basımlarda sözde kullanmak mümkündür. “yarı ilave önlemler”, yani olağan toplamlar (örneğin, ekstremum veya ortalama) dışındaki ek toplam işlevler (istatistikler).

OLAP küp tasarımı (OLAP kübizm)

OLAP küpünün tasarımı hakkında birkaç söz söyleyelim. İstatistik dilinde bir OLAP küpü, gerekli tüm bölümlerde hesaplanan bir dizi performans göstergesidir; örneğin müşterilere, mallara, tarihlere vb. bölümlerdeki sevkiyat göstergesi. OLAP küpleri üzerine Rus literatüründe İngilizceden doğrudan çeviri yapılması nedeniyle göstergelere “ölçüler”, bölümlere ise “boyutlar” adı verilmektedir. Bu matematiksel olarak doğru ancak sözdizimsel ve anlamsal olarak pek başarılı olmayan bir çeviri. Rusça "ölçü", "boyut", "boyut" kelimeleri anlam ve yazılış açısından hemen hemen aynıyken, İngilizce "ölçü" ve "boyut" kelimeleri hem yazılış hem de anlam bakımından farklıdır. Bu nedenle, anlam bakımından benzer olan geleneksel Rus istatistik terimleri “gösterge” ve “kesim” i tercih ediyoruz.

Verilerin kaydedildiği OLTP sistemiyle ilişkili olarak bir OLAP küpünün yazılım uygulamasına yönelik çeşitli seçenekler vardır. En basit, en güvenilir ve en hızlı olan yalnızca bir şemayı ele alacağız.

Bu tasarımda OLAP ve OLTP tablo paylaşımı yapmamakta olup, kullanım aşamasından önce gelen küp güncelleme (İşlem) aşamasında OLAP analitiği mümkün olduğunca detaylı olarak hesaplanmaktadır. Bu şemaya MOLAP (Çok Boyutlu OLAP) denir. Dezavantajları ERP ile uyumsuzluk ve yüksek bellek maliyetleridir.

Resmi olarak bir OLAP küpü, ERP sistemi ilişkisel veritabanı tablolarının tamamını (binlerce) veri kaynağı olarak ve bunların tüm (yüzlerce) alanını gösterge veya bölüm olarak kullanarak oluşturulabilse de, gerçekte bu yapılmamalıdır. Tersine. Bir küpe yüklemek için "vitrin" veya "depo" adı verilen ayrı bir veritabanı hazırlamak daha doğrudur.

Çeşitli nedenler bizi bunu yapmaya zorluyor.

• İlk önce, bir OLAP küpünü gerçek veritabanı tablolarına bağlamak kesinlikle teknik problemler. Bir tablodaki verileri değiştirmek küpün yenilenmesini tetikleyebilir ve bir küpün yenilenmesi her zaman hızlı bir süreç olmayabilir; dolayısıyla küp sürekli olarak yeniden oluşturulma durumunda olacaktır; Aynı zamanda, küp güncelleme prosedürü, veritabanı tablolarının verilerini engelleyebilir (okurken), kullanıcıların ERP sistemine veri kaydetme çalışmalarını yavaşlatabilir.
• ikinci olarak, Çok fazla gösterge ve kesimin olması, küpün sunucudaki depolama alanını önemli ölçüde artıracaktır. OLAP küpünün, OLTP sisteminde olduğu gibi yalnızca kaynak verileri değil, aynı zamanda olası tüm bölümler (ve hatta tüm bölümlerin tüm kombinasyonları) üzerinden özetlenen tüm göstergeleri de sakladığını unutmayalım. Ek olarak, küpün güncellenme hızı ve sonuçta bunlara dayalı analitik ve kullanıcı raporlarının oluşturulma ve güncellenme hızı da buna göre yavaşlayacaktır.
• Üçüncü, çok fazla çok sayıda alanlar (göstergeler ve bölümler) OLAP geliştirici arayüzünde sorunlar yaratacaktır çünkü elementlerin listesi muazzam hale gelecektir.
• Dördüncüsü, OLAP küpü veri bütünlüğü ihlallerine karşı çok hassastır. Anahtar verileri küp alanı bağlantılarının yapısında belirtilen bağlantıda bulunmuyorsa küp oluşturulamaz. Geçici veya kalıcı bütünlük ihlalleri, boş alanlar bir ERP sistemi veritabanında sık görülür ancak bu OLAP için kesinlikle uygun değildir.

Ayrıca ERP sisteminin ve OLAP küpünün şu adreste bulunması gerektiğini de ekleyebilirsiniz: farklı sunucular yükü paylaşmak için. Ancak OLAP ve OLTP için ortak tablolar varsa başka bir sorun ortaya çıkar ağ trafiği. Bu durumda, birkaç farklı ERP sistemini (1C7, 1C8, MS Dynamics AX) tek bir OLAP küpünde birleştirmek gerektiğinde pratik olarak çözülemeyen sorunlar ortaya çıkar.

Muhtemelen teknik sorunları birikmeye devam edebiliriz. Ancak en önemlisi, OLTP'den farklı olarak OLAP'ın verileri kaydetme ve depolama aracı değil, bir analiz aracı olduğunu unutmayın. Bu, "kirli" verileri "her ihtimale karşı" ERP'den OLAP'a yüklemeye ve indirmeye gerek olmadığı anlamına gelir. Tam tersine, önce en azından KPI sistemi düzeyinde şirketi yönetmek için bir konsept geliştirmeli, ardından OLAP küpüyle aynı sunucuda bulunan ve küçük bir veri ambarı içeren bir uygulama veri ambarı (depo) tasarlamalısınız. Yönetim için gerekli olan ERP'den gelen rafine edilmiş veri miktarı.

Kötü alışkanlıkları teşvik etmeden, OLTP ile ilgili olarak OLAP küpü, gerçek kaydın "fermente edilmiş kütlesinden" "saf bir ürünün" çıkarıldığı iyi bilinen "damıtıcıya" benzetilebilir.

Böylece OLAP'ın veri kaynağının, OLAP ile aynı sunucuda bulunan özel bir veritabanı (depo) olduğunu anladık. Genellikle bu iki anlama gelir. Öncelikle ERP veritabanlarından depo oluşturacak özel prosedürlerin olması gerekir. İkincisi, OLAP küpü ERP sistemleriyle eşzamansızdır.

Yukarıdakileri dikkate alarak, hesaplama süreci mimarisinin aşağıdaki versiyonunu öneriyoruz.

Çözüm mimarisi

Belirli bir şirketin (holdingin) farklı sunucularda bulunan birçok ERP sisteminin bulunduğunu ve analitik verilerinin tek bir OLAP küpünde birleştirildiğini görmek istediğimizi varsayalım. Açıklanan teknolojide, ERP sistemlerinden gelen verileri depo düzeyinde birleştirdiğimizi ve OLAP küpünün tasarımını değiştirmeden bıraktığımızı vurguluyoruz.

OLAP sunucusunda tüm bu ERP sistemlerinin veritabanlarının görüntülerini (boş kopyalarını) oluşturuyoruz. İlgili aktif ERP veritabanlarının bu boş kopyalara periyodik olarak (geceleri) kısmi replikasyonunu gerçekleştiriyoruz.

Daha sonra, ağ trafiği olmayan aynı OLAP sunucusunda, ERP sistemi veritabanlarının kısmi kopyalarına dayanarak, OLAP küpünün veri kaynağı olan bir depo (depo) oluşturan (veya dolduran) SP (saklı prosedür) başlatılır.

Daha sonra ambar verilerine dayalı olarak bir küpün güncellenmesi/oluşturulması için standart prosedür başlatılır (SSAS arayüzünde süreç operasyonu).

Teknolojinin bazı yönleri hakkında yorum yapalım. SP'ler ne tür işler yapar?

Kısmi çoğaltma sonucunda güncel veriler OLAP sunucusundaki bazı ERP sistemlerinin görüntüsünde görünür. Bu arada kısmi çoğaltma iki şekilde gerçekleştirilebilir.

Kısmi replikasyon sırasında öncelikle ERP sistemi veritabanındaki tüm tablolardan yalnızca depo oluşturmak için gerekli olanlar kopyalanır. Bu, sabit bir tablo adları listesi tarafından kontrol edilir.

İkinci olarak, kısmi çoğaltma, tablodaki tüm alanların kopyalanmadığı, yalnızca deponun oluşturulmasında yer alan alanların kopyalandığı anlamına da gelebilir. Kopyalanacak alanların listesi SP'de kopyanın görüntüsünde belirtilir veya dinamik olarak oluşturulur (tablonun kopyasında başlangıçta tüm alanlar mevcut değilse).

Elbette tablo satırlarının tamamını kopyalamak değil, yalnızca yeni kayıtlar eklemek mümkündür. Ancak bu durum, gerçek hayattaki sistemlerde sıklıkla görülen ERP revizyonlarının "geriye dönük" olarak muhasebeleştirilmesinde ciddi sıkıntılar yaratır. Böylece, daha fazla uzatmadan tüm kayıtları kopyalamak (veya belirli bir tarihten itibaren "kuyruğu" güncellemek) daha kolaydır.

Daha sonra SP'nin asıl görevi ERP sistem verilerini depo formatına dönüştürmektir. Yalnızca bir ERP sistemi varsa, dönüştürme görevi esas olarak gerekli verilerin kopyalanması ve muhtemelen yeniden biçimlendirilmesinden ibarettir. Ancak farklı yapılara sahip birkaç ERP sistemini aynı OLAP küpünde birleştirmek gerekiyorsa dönüşümler daha karmaşık hale gelir.

Birkaç farklı ERP sistemini bir küpte birleştirme görevi, nesnelerin kümeleri (mal dizinleri, müteahhitler, depolar vb.) kısmen örtüşüyorsa, nesneler aynı anlama sahipse ancak doğal olarak dizinlerde farklı şekilde tanımlanıyorsa özellikle zordur. farklı sistemler(kodlar, tanımlayıcılar, adlar vb. anlamında).

Gerçekte böyle bir tablo, büyük bir holding şirketinde, aynı türdeki kurucu özerk şirketlerin birçoğunun yaklaşık olarak aynı bölgede yaklaşık olarak aynı tür faaliyetleri yürüttüğü, ancak kendi ve üzerinde anlaşmaya varılmamış kayıt sistemlerini kullandığı durumlarda ortaya çıkar. Bu durumda verileri ambar düzeyinde konsolide ederken yardımcı eşleme tabloları olmadan yapamazsınız.

Depo depolama mimarisine biraz dikkat edelim. Tipik olarak bir OLAP küp şeması bir "yıldız" biçiminde temsil edilir; dizinlerin “ışınları” ile çevrelenmiş bir veri tablosu olarak - ikincil anahtar değer tabloları. Bir tablo “göstergelerin” bir bloğudur; bunların bölümleridir. Bu durumda, dizin, keyfi olarak dengesiz bir ağaç veya dengeli bir hiyerarşi, örneğin malların veya yüklenicilerin çok düzeyli bir sınıflandırması olabilir. Bir OLAP küpünde, bir depodaki veri tablosunun sayısal alanları otomatik olarak "göstergeler" (veya ölçümler) haline gelir ve bölümler (veya boyutlar) ikincil anahtar tablolar kullanılarak tanımlanabilir.

Bu görsel bir “pedagojik” açıklamadır. Aslında bir OLAP küpünün mimarisi çok daha karmaşık olabilir.

İlk olarak, bir depo muhtemelen ortak dizinler aracılığıyla birbirine bağlanan birkaç "yıldızdan" oluşabilir. Bu durumda OLAP küpü birkaç küpün (birkaç veri bloğunun) birleşimi olacaktır.

İkincisi, yıldız işaretinin "ışını" yalnızca bir dizin değil, bütün (hiyerarşik) bir dosya sistemi olabilir.

Üçüncüsü, mevcut boyut bölümlerine dayanarak, OLAP geliştirici arayüzü araçları kullanılarak yeni hiyerarşik bölümler tanımlanabilir (örneğin, daha az düzeyle, farklı düzeyde düzey sırasıyla vb.).

Dördüncüsü, mevcut göstergeler ve bölümler temel alınarak MDX dili ifadeleri kullanılarak yeni göstergeler (hesaplamalar) tanımlanabilir. Yeni küplerin, yeni göstergelerin, yeni bölümlerin otomatik olarak orijinal öğelerle tamamen entegre olduğunu unutmamak önemlidir. Ayrıca, kötü formüle edilmiş hesaplamaların ve hiyerarşik bölümlerin OLAP küpünün çalışmasını önemli ölçüde yavaşlatabileceği de unutulmamalıdır.

OLAP ile arayüz olarak MS Excel

OLAP küplerine sahip kullanıcı arayüzü özellikle ilgi çekicidir. Doğal olarak, en eksiksiz arayüz SSAS yardımcı programının kendisi tarafından sağlanır. Buna bir OLAP küp geliştirici araç seti, etkileşimli bir rapor tasarımcısı ve MDX dilindeki sorguları kullanan bir OLAP küpüyle etkileşimli çalışma için bir pencere dahildir.

SSAS'nin kendisine ek olarak, OLAP'a bir arayüz sağlayan ve işlevlerini az ya da çok kapsayan birçok program vardır. Ancak bunların arasında bize göre yadsınamaz avantajlara sahip olan bir tane var. Bu MS Excel'dir.

MS Excel ile arayüz, ayrı olarak indirilebilen veya Excel dağıtımına dahil edilen özel bir sürücü tarafından sağlanır. OLAP'ın tüm işlevlerini kapsamaz, ancak MS Excel sürüm numaralarının artmasıyla birlikte bu kapsam da genişler (örneğin, MS Excel 2007'de, MS Excel 2003'te olmayan KPI'nın grafiksel bir temsili görünür, vb.). ).

Elbette, oldukça eksiksiz işlevselliğine ek olarak, MS Excel'in temel avantajı, bu programın yaygın dağıtımı ve çok sayıda ofis kullanıcısının ona yakın aşinalığıdır. Bu anlamda diğer arayüz programlarından farklı olarak firmanın ek bir şey satın almasına ve ayrıca kimseyi eğitmesine gerek yoktur.

OLAP ile bir arayüz olarak MS Excel'in en büyük avantajı, OLAP raporunda elde edilen verileri daha da bağımsız olarak işleyebilme yeteneğidir (yani, OLAP'tan elde edilen verileri aynı Excel'in diğer sayfalarında, artık OLAP araçlarını kullanmadan, ancak normal Excel araçlarını kullanarak).

Facubi gecelik tedavi döngüsü

Şimdi OLAP işleminin günlük (gecelik) hesaplama döngüsünü açıklayacağız. Hesaplama, C# 2005 ile yazılmış ve depo ve SSAS bulunan bir sunucu üzerinde Görev Zamanlayıcı aracılığıyla başlatılan facubi programının kontrolünde gerçekleştirilir. Başlangıçta facubi internete gider ve güncel döviz kurlarını okur (bir para birimindeki çeşitli göstergeleri temsil etmek için kullanılır). Daha sonra aşağıdaki adımları gerçekleştirin.

İlk olarak facubi, yerel ağda mevcut olan çeşitli ERP sistemlerinin (tutma elemanları) veritabanlarının kısmi replikasyonunu gerçekleştiren SP'leri başlatır. Çoğaltma, söylediğimiz gibi, önceden hazırlanmış "arka planlara" - SSAS sunucusunda bulunan uzak ERP sistemlerinin görüntülerine - gerçekleştirilir.

İkinci olarak, SP aracılığıyla, ERP kopyalarından ambar depolama alanına (OLAP küp verilerinin kaynağı olan ve SSAS sunucusunda bulunan özel bir veritabanı) bir eşleme gerçekleştirilir. Bu durumda üç ana görev çözülür:

• ERP verileri gerekli küp formatlarına göre ayarlanmış; Hem tablolardan hem de tablo alanlarından bahsediyoruz. (Bazen gerekli tablonun, örneğin birkaç MS Excel sayfasından "biçimlendirilmesi" gerekir.) Benzer veriler, farklı ERP'lerde farklı formatlara sahip olabilir; örneğin, 1C7 dizinlerindeki anahtar kimlik alanları, 8 uzunluğunda 36 haneli bir karakter koduna sahiptir. 1S8 dizinlerindeki ve _idrref alanları – onaltılı sayılar uzunluk 32;
• işlem sırasında mantıksal veri kontrolü gerçekleştirilir (mümkün olduğunda eksik verilerin yerine "varsayılanların" yazılması dahil) ve bütünlük kontrolü, yani; ilgili sınıflandırıcılarda birincil ve ikincil anahtarların varlığının kontrol edilmesi;
• kod birleştirme Farklı ERP'lerde aynı anlama gelen nesneler. Örneğin, farklı ERP'lerin dizinlerinin karşılık gelen öğeleri aynı anlama sahip olabilir; örneğin bunlar aynı karşı taraftır. Kodları birleştirme sorunu, eşleme tabloları oluşturularak çözülür. çeşitli kodlar aynı nesneler bir araya getirilir.

Üçüncü olarak, facubi, İşlem küpü verilerini güncellemek için standart prosedürü başlatır (SSAS yardımcı programının prosedürlerinden).

Facubi, kontrol listelerine dayanarak işleme adımlarının ilerleyişi hakkında e-postalar gönderir.

Facubi'yi çalıştırdıktan sonra Görev Zamanlayıcı birkaç tane başlatır excel dosyaları Raporların OLAP küp göstergelerine göre önceden oluşturulduğu. Söylediğimiz gibi, MS Excel'in OLAP küpleriyle (SSAS ile) çalışmak için özel bir yazılım arayüzü (ayrı olarak indirilebilir veya yerleşik sürücü) vardır. MS Excel'i başlattığınızda, raporlardaki verilerin güncellenmesini sağlayan MS VBA programları (makrolar gibi) etkinleştirilir; Raporlar gerektiğinde değiştirilmekte ve kontrol listelerine göre kullanıcılara mail (blat programı) ile gönderilmektedir.

SSAS sunucusuna erişimi olan yerel ağ kullanıcıları, OLAP küpü için yapılandırılmış "canlı" raporlar alacaktır. (Prensip olarak, herhangi bir postaya ihtiyaç duymadan, MS Excel'deki OLAP raporlarını kendileri güncelleyebilirler. yerel bilgisayarlar.) Yerel ağ dışındaki kullanıcılar ya orijinal raporları alacak, ancak sınırlı işlevselliğe sahip olacak ya da onlar için (MS Excel'de OLAP raporlarını güncelledikten sonra) SSAS sunucusuna erişemeyen özel "ölü" raporlar hesaplanacak.

Sonuçların değerlendirilmesi

Yukarıda OLTP ve OLAP'ın eşzamansızlığından bahsetmiştik. Söz konusu teknoloji varyantında, OLAP küp güncelleme döngüsü gece gerçekleştirilir (örneğin sabah 1'de başlar). Bu, kullanıcıların mevcut çalışma gününde dünün verileriyle çalıştığı anlamına gelir. OLAP bir kayıt aracı değil (belgenin en son revizyonuna bakın), ancak bir yönetim aracı (sürecin eğilimini anlayın) olduğundan, bu tür bir gecikme genellikle kritik değildir. Ancak gerekirse küp mimarisinin açıklanan versiyonunda (MOLAP) bile günde birkaç kez güncelleme yapılabilir.

Güncelleme prosedürlerinin yürütme süresi, OLAP küpünün tasarım özelliklerine (daha fazla veya daha az karmaşıklık, göstergelerin ve bölümlerin az çok başarılı tanımları) ve harici OLTP sistemlerinin veritabanlarının hacmine bağlıdır. Deneyimlere göre, depo inşaatı prosedürü birkaç dakikadan iki saate kadar, küp güncelleme prosedürü (Süreç) 1 ila 20 dakika kadar sürmektedir. Hakkında düzinelerce yıldız tipi yapıyı birleştiren karmaşık OLAP küpleri, onlar için yaklaşık düzinelerce ortak "ışın" (dizin bölümleri), yaklaşık yüzlerce gösterge hakkında. Harici ERP sistemlerinin veritabanlarının hacmini nakliye belgelerine dayanarak tahmin ettiğimizde, yılda yüzbinlerce belgeden ve buna bağlı olarak milyonlarca ürün grubundan bahsediyoruz. Kullanıcının ilgisini çeken tarihsel işleme derinliği üç ila beş yıldı.

Açıklanan teknoloji bir dizi büyük şirkette kullanılmaktadır: 2008'den beri Rus Balık Şirketi'nde (RRK) ve Rus Deniz Şirketi'nde (RM), 2012'den beri Santa Bremor şirketinde (SB). Bazı şirketler öncelikle ticaret ve satın alma firmaları (PPC'ler), diğerleri ise üretim şirketleridir (Moldova Cumhuriyeti ve Belarus Cumhuriyeti'ndeki balık ve deniz ürünleri işleme tesisleri). Tüm şirketler, 1C7 ve 1C8 gibi standart ERP sistemlerinden DBF ve Excel'e dayalı "kalıntı" muhasebe sistemlerine kadar çeşitli bağımsız ve çeşitli bilgisayar muhasebe sistemlerine sahip birkaç şirketi birleştiren büyük holdinglerdir. OLAP küplerini çalıştırmak için açıklanan teknolojinin (geliştirme aşamasını hesaba katmadan) ya özel çalışanlar gerektirmediğini ya da tam zamanlı bir iş analistinin sorumluluğunda olduğunu ekleyeceğim. Görev yıllardır otomatik olarak yürütülüyor ve çeşitli kategorilerdeki kurumsal çalışanlara günlük olarak güncel raporlama sağlıyor.

Çözümün artıları ve eksileri

Deneyimler, önerilen çözümün oldukça güvenilir ve kullanımı kolay olduğunu göstermektedir. Facubi kontrol programının değişmezliği ile kolayca değiştirilebilir (yeni ERP'lerin bağlanması/bağlantısının kesilmesi, yeni gösterge ve bölümlerin oluşturulması, Excel raporlarının ve posta listelerinin oluşturulması ve değiştirilmesi).

OLAP ile arayüz olarak MS Excel, yeterli ifade gücü sağlar ve farklı kategorilerdeki OLAP teknolojisini hızlı bir şekilde tanımanıza olanak tanır ofis çalışanları. Kullanıcı günlük "standart" OLAP raporlarını alır; OLAP ile MS Excel arayüzünü kullanarak, MS Excel'de bağımsız olarak OLAP raporları oluşturabilirsiniz. Ek olarak kullanıcı, MS Excel'in olağan yeteneklerini kullanarak OLAP raporlarının bilgilerini bağımsız olarak incelemeye devam edebilir.

Birkaç heterojen ERP sisteminin (küpün oluşturulması sırasında) konsolide edildiği "rafine edilmiş" depo veritabanı, herhangi bir OLAP olmadan bile çözmenize olanak tanır (SSAS sunucusunda, dilde sorgulama yöntemini kullanarak) SQL'de işlem yapın veya SP yöntemi vb.) uygulanan birçok kontrol problemi. Depo veritabanı yapısının, orijinal ERP'nin veritabanı yapılarına göre birleşik ve çok daha basit (tablo sayısı ve tablo alanı sayısı açısından) olduğunu hatırlatalım.

Önerilen çözümümüzde çeşitli ERP sistemlerini tek bir OLAP küpünde birleştirme olanağının bulunduğunu özellikle not ediyoruz. Bu, bir şirket başka bir muhasebe ERP sistemine geçtiğinde, örneğin 1C7'den 1C8'e geçerken, tüm holding için analitik elde etmenize ve analitikte uzun vadeli sürekliliği korumanıza olanak tanır.

MOLAP küp modelini kullandık. Bu modelin avantajları, kullanımda güvenilirlik ve kullanıcı isteklerinin yüksek hızda işlenmesidir. Dezavantajları: OLAP ve OLTP eşzamansızdır ve OLAP'ı depolamak için büyük miktarda bellek vardır.

Sonuç olarak, Orta Çağ'da daha uygun olabilecek OLAP lehine başka bir argüman var. Çünkü onun delil gücü otoriteye dayanmaktadır. Mütevazı ve açıkça küçümsenen İngiliz matematikçi E. Codd, 60'ların sonlarında ilişkisel veritabanları teorisini geliştirdi. Bu teorinin gücü o kadar büyüktü ki, aradan 50 yıl geçtikten sonra SQL dışında ilişkisel olmayan bir veritabanı ve veritabanı sorgulama dili bulmak zaten zor.

İlişkisel veritabanları teorisine dayanan OLTP teknolojisi, E. Codd'un ilk fikriydi. Aslında OLAP küpleri kavramı onun 90'lı yılların başında ifade ettiği ikinci fikridir. Matematikçi olmasanız bile ikinci fikrin de birincisi kadar etkili olmasını bekleyebilirsiniz. Yani, bilgisayar analitiği açısından OLAP fikirleri yakında dünyayı ele geçirecek ve diğerlerinin yerini alacak. Çünkü analitik konusu kapsamlı matematiksel çözümünü OLAP'ta buluyor ve bu çözüm, analitiklerin pratik sorununa "yeterli" (B. Spinoza'nın terimi). "Yeterince", Spinoza'da Tanrı'nın kendisinin daha iyi bir şey düşünemeyeceği anlamına gelir...

1. Larson B. Microsoft SQL Server 2005'te iş analitiğinin geliştirilmesi. – St. Petersburg: “Peter”, 2008.
2. Codd E. Veri Tabanı Alt Dillerinin İlişkisel Tamlığı, Veri Tabanı Sistemleri, Courant Computer Science Sumposia Serisi 1972, v. 6, Englwood kayalıkları, N.Y., Prentice – Hall.

Temas halinde