Olap excel küpleri. Microsoft Query kullanarak OLAP küpü oluşturma

Pirinç. 2. OLAP küp dilimi

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

OLAP tek bir yazılım ürünü, bir programlama dili ve hatta belirli bir teknoloji değildir. OLAP'ı tüm tezahürleriyle ele almaya çalışırsanız, bu, analistlerin verilere erişmesini kolaylaştıran yazılım ürünlerinin altında yatan bir dizi kavram, ilke ve gereksinimdir. Hadi bulalım Ne için analistlerin özel bir şeye ihtiyacı var kolaylaştırmak veri erişimi.

Gerçek şu ki, analistler özel tüketicilerdir. şirket bilgisi. Bir analistin görevi, büyük veri setlerinde kalıplar bulmaktır.. Bu nedenle analist, dördüncü gün Perşembe günü karşı taraf Chernov'a bir parti siyah mürekkep satıldığı gerçeğine dikkat etmeyecek - bilgiye ihtiyacı var yaklaşık yüzlerce ve binlerce benzer olaylar. Veritabanındaki tek gerçekler, örneğin, işlemin yetkisinde bulunan bir muhasebeci veya satış departmanı başkanı için ilgi çekici olabilir. Bir analist için bir kayıt yeterli değildir - örneğin, bir şube veya temsilciliğin tüm işlemlerine bir ay veya bir yıl boyunca ihtiyacı olabilir. Aynı zamanda analist atar alıcının VKN'si, tam adresi ve telefon numarası, sözleşme endeksi ve benzeri gibi gereksiz ayrıntılar. Aynı zamanda, bir analistin çalışması gereken veriler mutlaka sayısal değerler içerir - bu, faaliyetinin özünden kaynaklanmaktadır.

Yani bir analistin çok fazla veriye ihtiyacı vardır, bu veri seçicidir ve aynı zamanda " öznitelik kümesi - sayı". İkincisi, analistin aşağıdaki türdeki tablolarla çalıştığı anlamına gelir:

Burada " Bir ülke", "Ürün", "Yıl" özellikler veya ölçümler, A " satış hacmi" - dolayısıyla sayısal bir değer veya ölçüm. Analistin görevi, tekrarlıyoruz, nitelikler ve sayısal parametreler arasındaki kalıcı ilişkileri belirlemektir.. Tabloya baktığınızda, kolayca üç boyuta çevrilebileceğini görebilirsiniz: eksenlerden birine ülkeleri, diğerine - malları, üçüncü yıllara koyuyoruz. Ve bu üç boyutlu dizideki değerler karşılık gelen satış hacimleri olacaktır.

Tablonun 3 boyutlu gösterimi. Gri segment, 1988'de Arjantin için veri olmadığını gösteriyor.

OLAP açısından küp olarak adlandırılan tam olarak böyle bir üç boyutlu dizidir. Aslında, katı matematik açısından, böyle bir dizi her zaman bir küp olmayacaktır: gerçek bir küp için, tüm boyutlardaki öğe sayısı aynı olmalıdır, oysa OLAP küplerinde böyle bir sınırlama yoktur. Ancak bu ayrıntılara rağmen "OLAP küpleri" terimi, kısalığı ve tasviri nedeniyle genel kabul gördü. Bir OLAP küpünün 3B olması gerekmez. Çözülmekte olan probleme bağlı olarak hem iki boyutlu hem de çok boyutlu olabilir. Özellikle deneyimli analistlerin yaklaşık 20 ölçüme ihtiyacı olabilir ve ciddi OLAP ürünleri tam da bu sayı için tasarlanmıştır. Daha basit masaüstü uygulamaları yaklaşık 6 boyutu destekler.

ölçümler OLAP küpleri sözde oluşur işaretler veya üyeler. Örneğin, "Ülke" boyutu "Arjantin", "Brezilya", "Venezuela" vb. etiketlerden oluşur.

Küpün tüm öğeleri doldurulmamalıdır: 1988'de Arjantin'de kauçuk ürünlerinin satışı hakkında bilgi yoksa, karşılık gelen hücredeki değer belirlenmeyecektir. Ayrıca, bir OLAP uygulamasının verileri çok boyutlu bir yapıda depolaması da gerekli değildir - asıl mesele, kullanıcı için bu verilerin tam olarak böyle görünmesidir. Bu arada, küplerdeki "vakum" (doldurulmamış öğeler) tam olarak çok boyutlu verilerin kompakt bir şekilde depolanmasının özel yollarında, bellek israfına yol açmaz.

Ancak küpün kendisi analiz için uygun değildir. Üç boyutlu bir küpü yeterince temsil etmek veya tasvir etmek hala mümkünse, o zaman altı veya on dokuz boyutta durum çok daha kötüdür. Bu yüzden kullanmadan önce sıradan küpler çok boyutlu bir küpten çıkarılır iki boyutlu tablolar. Bu işleme küpün "kesilmesi" denir. Yine, bu terim mecazidir. Analist, küpün boyutlarını ilgilendiği işaretlere göre alır ve "keser". Bu şekilde, analist küpün iki boyutlu bir dilimini alır ve onunla çalışır. Yaklaşık olarak aynı şekilde, oduncular testere kesiminde yıllık halkaları sayarlar.

Buna göre, kural olarak, tablonun boyut sayısına göre yalnızca iki boyut "kesilmemiş" kalır. Sadece boyut "kesilmemiş" olarak kalır - küp birkaç tür sayısal değer içeriyorsa, bunlar tablonun boyutlarından birine göre çizilebilir.

İlk önce tasvir ettiğimiz tabloya daha yakından bakarsanız, içindeki verilerin büyük olasılıkla birincil olmadığını, bunun sonucunda elde edildiğini görebilirsiniz. toplama daha küçük öğeler için. Örneğin, bir yıl çeyreklere, çeyrekler aylara, aylar haftalara, haftalar günlere bölünmüştür. Bir ülke bölgelerden, bölgeler de yerleşim yerlerinden oluşur. Son olarak, şehirlerin kendilerinde, semtler ve belirli perakende satış mağazaları ayırt edilebilir. Ürünler birleştirilebilir emtia grupları ve benzeri. OLAP açısından, bu tür çok düzeyli birleştirmeler oldukça mantıksal olarak hiyerarşiler. OLAP araçları, herhangi bir zamanda hiyerarşinin istenen seviyesine geçmeyi mümkün kılar. Ayrıca, kural olarak, aynı öğeler için çeşitli hiyerarşi türleri desteklenir: örneğin, gün-hafta-ay veya gün-on yıl-çeyrek. Kaynak veriler, hiyerarşilerin alt seviyelerinden alınır ve daha sonra üst seviyelerin değerlerini elde etmek için özetlenir. Geçiş sürecini hızlandırmak için farklı seviyeler için toplanan değerler bir küpte saklanır. Böylece, kullanıcı açısından tek bir küp gibi görünen şey, kabaca konuşursak, çok daha ilkel küplerden oluşur.

Hiyerarşi Örneği

Bu, OLAP'ın ortaya çıkmasına neden olan temel noktalardan biridir - üretkenlik ve verimlilik. Bir analistin bilgi alması gerektiğinde ve kuruluşta OLAP araçları bulunmadığında ne olduğunu hayal edelim. Analist bağımsız olarak (ki bu olası değildir) veya bir programcının yardımıyla uygun bir SQL sorgusu yapar ve ilgilenilen verileri bir rapor biçiminde alır veya bir elektronik tabloya aktarır. Bununla ilgili birçok sorun var. İlk olarak, analist işi dışında bir şey yapmaya (SQL programlama) veya programcıların görevi onun yerine yapmasını beklemeye zorlanır - tüm bunlar emek üretkenliğini, saldırıyı, kalp krizini ve inme düzeyini vb. olumsuz etkiler. . İkincisi, tek bir rapor veya tablo, kural olarak, düşünce devlerini ve Rus analizinin babalarını kurtarmaz - ve tüm prosedürün defalarca tekrarlanması gerekecektir. Üçüncüsü, daha önce öğrendiğimiz gibi, analistler önemsiz şeyler istemezler - her şeye aynı anda ihtiyaçları vardır. Bu, (teknoloji hızla ilerlemesine rağmen) analistin eriştiği kurumsal ilişkisel veritabanı sunucusunun, işlemlerin geri kalanını bloke ederek derinlemesine ve uzun süre düşünebileceği anlamına gelir.

OLAP kavramı tam olarak bu tür sorunları çözmek için ortaya çıktı. OLAP küpleri aslında meta raporlardır. Meta-raporları (yani küpleri) boyutlara göre keserek, analist aslında kendisini ilgilendiren "düzenli" iki boyutlu raporları alır (bunlar, terimin genel anlamıyla raporlar olmak zorunda değildir - veri yapılarından bahsediyoruz) aynı işlevlere sahip). Küplerin avantajları açıktır - bir küp oluşturulurken ilişkisel bir DBMS'den verilerin yalnızca bir kez talep edilmesi gerekir. Analistler, kural olarak, anında eklenen ve değiştirilen bilgilerle çalışmadıklarından, oluşturulan küp oldukça uzun bir süre geçerlidir. Bu sayede, ilişkisel DBMS sunucusunun çalışmasındaki kesintiler ortadan kaldırılmakla kalmaz (binlerce ve milyonlarca yanıt satırı içeren sorgular yoktur), aynı zamanda analistin veri erişim hızı da önemli ölçüde artar. Ek olarak, daha önce belirtildiği gibi, küp yapımı sırasında hiyerarşi alt toplamları ve diğer toplu değerler hesaplanarak performans da iyileştirilir. Yani, başlangıçta verilerimiz tek bir mağazadaki belirli bir ürünün günlük geliri hakkında bilgi içeriyorsa, o zaman küpü oluştururken OLAP uygulaması farklı hiyerarşi seviyeleri (haftalar ve aylar, şehirler ve ülkeler) için toplamları hesaplar.

Elbette, bu şekilde artan üretkenlik için ödeme yapmanız gerekiyor. Bazen veri yapısının basitçe "patladığı" söylenir - bir OLAP küpü, orijinal verilerden onlarca hatta yüzlerce kat daha fazla yer kaplayabilir.

Soruları cevapla:

Ne oldu küp OLAP mı?

Ne oldu etiketler belirli boyut? Örnekler ver.

Yapabilirler mi miktar v OLAP küpü, sayısal olmayan değerler içerir.

Dipnot: Bu ders, OLAP veri ambarları için veri küpü tasarlamanın temellerini kapsar. Örnek, CASE aracını kullanarak bir veri küpünün nasıl oluşturulacağını gösterir.

dersin amacı

Bu dersin materyalini inceledikten sonra şunları bileceksiniz:

• veri küpü nedir OLAP veri ambarı ;
• için bir veri küpü nasıl tasarlanır? OLAP veri ambarları ;
• veri küpü boyutu nedir;
• gerçeğin veri küpü ile nasıl ilişkili olduğu;
• boyut nitelikleri nelerdir;
• hiyerarşi nedir;
• veri küpü metriği nedir;

ve öğren:

• inşa etmek çok boyutlu çizelgeler ;
• basit tasarım çok boyutlu çizelgeler.

giriiş

OLAP teknolojisi tek başına değildir yazılım, Olumsuz Programlama dili. OLAP'ı tüm tezahürleriyle ele almaya çalışırsanız, bu, analistlerin verilere erişmesini kolaylaştıran yazılım ürünlerinin altında yatan bir dizi kavram, ilke ve gereksinimdir.

Analistler, kurumsal bilgilerin ana tüketicileridir. Bir analistin görevi, büyük veri kümelerinde kalıplar bulmaktır. Bu nedenle analist, belirli bir günde alıcı Ivanov'a bir toplu tükenmez kalem satıldığı gerçeğine dikkat etmeyecek - yüzlerce ve binlerce benzer olay hakkında bilgiye ihtiyacı var. Veri ambarındaki tek gerçekler, örneğin, yetkinliği belirli bir sözleşmeyi desteklemek olan bir muhasebeci veya satış departmanı başkanı için ilgi çekici olabilir. Bir analist için bir kayıt yeterli değildir - örneğin, bir aylık, üç aylık veya yıllık tüm satış noktası sözleşmeleri hakkında bilgiye ihtiyacı olabilir. Analytics, alıcının VKN'si veya telefon numarasıyla ilgilenmeyebilir - profesyonel faaliyetinin özü olan belirli sayısal verilerle çalışır.

Merkezileştirme ve uygun yapılanma, bir analistin ihtiyaç duyduğu her şeyden uzaktır. Bilgileri görüntülemek, görselleştirmek için bir araca ihtiyacı var. Bununla birlikte, tek bir veri ambarı temelinde oluşturulan geleneksel raporlar bile belirli bir esneklikten yoksundur. Verilerin istenen görünümünü elde etmek için "bükülemez", "genişletilemez" veya "daraltılamaz". Bir analist ne kadar çok "dilim" ve "dilim" keşfedebilirse, o kadar çok fikre sahip olur ve bu da doğrulama için giderek daha fazla "dilim" gerektirir. Veri keşfi için böyle bir araç olarak, analist OLAP'tır.

OLAP, bir veri ambarının gerekli bir özelliği olmamasına rağmen, bu veri ambarında biriken bilgileri analiz etmek için giderek daha fazla kullanılmaktadır.

Operasyonel veriler çeşitli kaynaklardan toplanır, temizlenir, entegre edilir ve veri ambarına eklenir. Aynı zamanda, çeşitli raporlama araçları kullanılarak analiz için hazırdırlar. Daha sonra veriler (tamamen veya kısmen) OLAP analizi için hazırlanır. Özel bir OLAP veritabanına yüklenebilir veya ilişkisel bir veri ambarında bırakılabilirler. OLAP kullanmanın en önemli unsuru meta verilerdir, yani yapı, konum ve veri dönüşümü. Onlar sayesinde çeşitli depolama bileşenlerinin etkin etkileşimi sağlanır.

Böylece, OLAP, bir veri ambarında biriken verilerin çok boyutlu analizi için bir dizi araç olarak tanımlanabilir.. Teorik olarak, OLAP araçları doğrudan operasyonel verilere uygulanabilir veya tam kopyalar. Ancak bu analize uygun olmayan verilerin analize tabi tutulma riski vardır.

İstemci ve sunucuda OLAP

OLAP'ın merkezinde çok boyutlu veri analizi vardır. Koşullu olarak istemci ve sunucu OLAP araçlarına bölünebilen çeşitli araçlar kullanılarak üretilebilir.

İstemci tarafı OLAP araçları, birleştirilmiş verileri (toplamlar, ortalamalar, maksimumlar veya minimumlar) hesaplayan ve görüntüleyen uygulamalardır ve toplanan verilerin kendisi OLAP aracının adres alanında önbelleğe alınır.

Kaynak veriler bir masaüstü DBMS'de bulunuyorsa, toplu veriler OLAP aracının kendisi tarafından hesaplanır. Kaynak verilerin kaynağı bir sunucu DBMS ise, istemci OLAP araçlarının çoğu sunucuya GROUP BY yan tümcesini içeren SQL sorguları gönderir ve sonuç olarak sunucuda hesaplanan toplu verileri alır.

Kural olarak, OLAP işlevselliği araçlarda uygulanır istatistiksel işleme veriler (Rusya pazarındaki bu sınıftaki ürünler için, Stat Soft ve SPSS ürünleri yaygın olarak kullanılmaktadır) ve bazı elektronik tablolarda. Özellikle, Microsoft Excel 2000 iyi çok boyutlu analiz araçlarına sahiptir.Bu ürünü kullanarak, küçük bir yerel çok boyutlu OLAP küpü oluşturabilir ve bir dosya olarak kaydedebilir ve iki veya üç boyutlu bölümlerini görüntüleyebilirsiniz.

Birçok Geliştirme araçları en basit OLAP işlevselliğini (Borland Delphi ve Borland C++Builder'daki Decision Cube bileşenleri gibi) uygulayan uygulamalar oluşturmanıza izin veren sınıf veya bileşen kitaplıkları içerir. Ayrıca birçok firma teklif veriyor. kontroller ActiveX ve benzer işlevleri uygulayan diğer kitaplıklar.

İstemci OLAP araçlarının, kural olarak, az sayıda boyutla (genellikle altıdan fazla olmaması önerilir) ve bu parametreler için az çeşitli değerlerle kullanıldığını unutmayın - sonuçta, alınan toplu veriler sığmalıdır. Böyle bir aracın adres uzayı ve sayısı, ölçüm sayısındaki artışla katlanarak artar. Bu nedenle, en ilkel müşteri OLAP araçları bile, kural olarak, gerekli miktarın bir ön hesaplamasını yapmanıza izin verir. rasgele erişim belleği içinde çok boyutlu bir küp oluşturmak için.

Çoğu (hepsi değil) istemci tarafı OLAP araçları, toplu veri önbelleğinin içeriğini bir dosya olarak saklamanıza izin verir ve bu da bunların yeniden hesaplanmasını engeller. Bu fırsatın genellikle toplu verileri başka kuruluşlara aktarmak veya yayınlamak üzere yabancılaştırmak için kullanıldığını unutmayın. Tipik bir örnek bu tür yabancılaştırılmış toplu veriler, farklı bölgelerdeki ve farklı ülkelerdeki insidans istatistikleridir. yaş grupları, hangisi açık bilgiçeşitli ülkelerin sağlık bakanlıkları ve Dünya Sağlık Örgütü tarafından yayınlanan Aynı zamanda, belirli hastalık vakaları hakkında bilgiler olan orijinal verilerin kendisi, tıp kurumlarının gizli verileridir ve kamuya açıklanması şöyle dursun, hiçbir durumda sigorta şirketlerinin eline geçmemelidir.

Birleştirilmiş verilerin bir önbelleğini bir dosyada saklama fikri, toplu verilerin depolanması ve değiştirilmesinin yanı sıra bunları içeren depolamanın bakımının gerçekleştirildiği sunucu tarafı OLAP araçlarında daha da geliştirilmiştir. OLAP sunucusu adı verilen ayrı bir uygulama veya işlem. İstemci uygulamaları, bu tür çok boyutlu depolamayı talep edebilir ve yanıt olarak bazı verileri alabilir. Bazı istemci uygulamaları da bu tür depolar oluşturabilir veya bunları değişen kaynak verilerine göre güncelleyebilir.

İstemci OLAP araçlarına kıyasla sunucu OLAP araçlarını kullanmanın avantajları, masaüstü araçlara kıyasla sunucu DBMS kullanmanın avantajlarına benzer: sunucu araçlarının kullanılması durumunda, toplu verilerin hesaplanması ve depolanması sunucuda ve istemci uygulamasında gerçekleşir. yalnızca onlara yapılan sorguların sonuçlarını alır, bu da genel olarak ağ trafiğini azaltır, kurşun zamanı istemci uygulaması tarafından tüketilen istekler ve kaynak gereksinimleri. Analiz araçlarının ve kurumsal ölçekte veri işlemenin, kural olarak, tam olarak örneğin Oracle Express Server gibi sunucu OLAP araçlarına dayalı olduğuna dikkat edin. Microsoft SQL Server 2000 Analiz Hizmetleri, Hyperion Essbase, Crystal Decisions, Business Objects, Cognos, SAS Institute ürünleri. Sunucu DBMS'nin tüm önde gelen üreticileri belirli sunucu OLAP araçlarını ürettikleri (veya diğer şirketlerden lisans aldıkları) için, seçenekleri oldukça geniştir ve hemen hemen her durumda, veritabanı sunucusunun kendisiyle aynı üreticiden bir OLAP sunucusu satın alabilirsiniz.

Pek çok istemci OLAP aracının (özellikle Microsoft Excel 2003, Seagate Analysis, vb.), sunucu OLAP depolarına erişmenize izin verdiğini ve bu durumda istemci uygulamaları yürüten istemci uygulamaları olarak hareket ettiğini unutmayın. benzer istekler. Ayrıca, çeşitli üreticilerin OLAP araçları için istemci uygulamaları olan birçok ürün vardır.

Çok boyutlu veri depolamanın teknik yönleri

Çok boyutlu veri ambarları, örneğin güne, aya, yıla, ürün kategorisine göre satış hacimleri gibi farklı derecelerde ayrıntıya sahip toplu veriler içerir. Toplu verilerin saklanmasının amacı, kurşun zamanı talepler, çünkü çoğu durumda analiz ve tahminler için ayrıntılı değil, ilgilenilen özet verilerdir. Bu nedenle, çok boyutlu bir veritabanı oluştururken, bazı toplu veriler her zaman hesaplanır ve saklanır.

Tüm toplu verileri kaydetmenin her zaman haklı olmadığını unutmayın. Gerçek şu ki, yeni boyutlar eklerken, küpü oluşturan veri miktarı katlanarak artıyor (bazen veri miktarının "patlayıcı büyümesi" hakkında söyleniyor). Daha spesifik olarak, toplam veri büyümesinin miktarı, küpteki boyutların sayısına ve bu boyutların hiyerarşilerinin farklı düzeylerindeki boyutların üyelerine bağlıdır. "Patlayıcı büyüme" sorununu çözmek için, olası tüm toplu verilerden uzakta hesaplanırken kabul edilebilir bir sorgu yürütme hızı elde etmeyi sağlayan çeşitli şemalar kullanılır.

Hem kaynak hem de toplu veriler, ilişkisel veya çok boyutlu yapılarda saklanabilir. Bu nedenle, şu anda verileri depolamanın üç yolu vardır.

• MOLAP(Çok boyutlu OLAP) - kaynak ve birleştirilmiş veriler çok boyutlu bir veritabanında saklanır. Verileri çok boyutlu yapılarda depolamak, verileri çok boyutlu bir dizi olarak değiştirmenize olanak tanır, böylece toplam değerleri hesaplama hızı boyutların herhangi biri için aynıdır. Ancak bu durumda, çok boyutlu veri tabanı orijinal ilişkisel verileri tamamen içerdiğinden, çok boyutlu veri tabanı gereksizdir.
• ROLAP(İlişkisel OLAP) - Orijinal veriler, orijinal olarak bulunduğu aynı ilişkisel veritabanında kalır. Toplu veriler, aynı veritabanında saklanmaları için özel olarak oluşturulan hizmet tablolarına yerleştirilir.
• HOLAP(Hibrit OLAP) - Orijinal veriler, orijinal olarak bulunduğu aynı ilişkisel veritabanında kalırken, toplam veriler çok boyutlu bir veritabanında depolanır.

Bazı OLAP araçları, veri depolamayı yalnızca ilişkisel yapılarda, bazıları ise yalnızca çok boyutlu olanlarda destekler. Ancak, modern OLAP sunucu araçlarının çoğu üç veri depolama yöntemini de destekler. Depolama yönteminin seçimi, kaynak verilerin hacmine ve yapısına, sorgu yürütme hızı gereksinimlerine ve OLAP küplerini güncelleme sıklığına bağlıdır.

Ayrıca, modern OLAP araçlarının büyük çoğunluğunun "boş" değerleri saklamadığını da not ediyoruz ("boş" değere bir örnek, sezon dışı mevsimlik ürünlerin satışının olmaması olabilir).

Temel OLAP Kavramları

FAMSI testi

Karmaşık çok boyutlu veri analizi teknolojisine OLAP (Çevrimiçi Analitik İşleme) denir. OLAP, bir veri ambarı organizasyonunun önemli bir bileşenidir. OLAP kavramı, 1993 yılında tanınmış bir veri tabanı araştırmacısı ve ilişkisel veri modelinin yazarı Edgar Codd tarafından tanımlanmıştır. 1995 yılında, Codd tarafından belirlenen gerekliliklere dayanarak, sözde FASMI testi(Paylaşılan Çok Boyutlu Bilginin Hızlı Analizi) - çok boyutlu analiz uygulamaları için aşağıdaki gereksinimler dahil olmak üzere, paylaşılan çok boyutlu bilgilerin hızlı analizi:

• Hızlı(Hızlı) - daha az ayrıntılı analiz pahasına olsa bile, kullanıcıya analiz sonuçlarını makul bir sürede (genellikle en fazla 5 saniye) sağlamak;
• Analiz(Analiz) - herhangi bir mantıksal ve istatistiksel analiz özelliğini gerçekleştirme olasılığı bu başvuru ve son kullanıcının erişebileceği bir biçimde saklanması;
• paylaşılan(Paylaşılan) - uygun kilitleme mekanizmaları ve yetkili erişim araçları desteği ile verilere çok kullanıcılı erişim;
• Çok boyutlu(Çok boyutlu) - Hiyerarşiler ve çoklu hiyerarşiler için tam destek dahil olmak üzere verilerin çok boyutlu kavramsal temsili (bu, önemli bir OLAP gereksinimidir);
• bilgi(Bilgi) - uygulama, hacmi ve depolama konumu ne olursa olsun gerekli tüm bilgilere erişebilmelidir.

OLAP işlevselliğinin uygulanabileceğine dikkat edilmelidir. Farklı yollar, ofis uygulamalarındaki en basit veri analiz araçlarından sunucu ürünlerine dayalı dağıtılmış analitik sistemlere kadar.

Bilginin çok boyutlu gösterimi

Küba

OLAP, iş bilgilerine erişmek, bunları görüntülemek ve analiz etmek için uygun, yüksek hızlı bir yol sağlar. Kullanıcı doğal, sezgisel bir veri modeli, onları çok boyutlu küpler (Küpler) şeklinde organize eder. Çok boyutlu koordinat sisteminin eksenleri, analiz edilen iş sürecinin ana nitelikleridir. Örneğin, satış için bir ürün, bölge, alıcı türü olabilir. Ölçümlerden biri olarak zaman kullanılır. Ölçüm eksenlerinin kesişme noktalarında (Boyutlar), süreci nicel olarak karakterize eden veriler vardır - ölçümler (Ölçüler). Bunlar, parça veya para cinsinden satış hacimleri, stok bakiyeleri, maliyetler vb. Bilgileri analiz eden bir kullanıcı, küpü farklı yönlerde "kesebilir", özet alabilir (örneğin, yıllara göre) veya tersine ayrıntılı ( haftalık) bilgi ve analiz sürecinde aklına gelen diğer manipülasyonları gerçekleştirir.

Şekil l'de gösterilen üç boyutlu küpün ölçüleri olarak. 26.1'de satış miktarları, ölçüm olarak ise zaman, ürün ve mağaza kullanılmıştır. Ölçümler belirli gruplama seviyelerinde sunulur: ürünler kategoriye göre gruplanır, mağazalar ülkeye göre gruplanır ve işlem süreleri aya göre gruplanır. Biraz sonra gruplandırma seviyelerine (hiyerarşilere) daha detaylı bakacağız.

Pirinç. 26.1.

Küpü "kesmek"

Üç boyutlu bir küpün bile bilgisayar ekranında görüntülenmesi, ilgilenilen ölçülerin değerlerinin görülebilmesi için zordur. Üçten fazla boyutu olan küpler hakkında ne söyleyebiliriz? Bir küpte depolanan verileri görselleştirmek için, kural olarak, karmaşık hiyerarşik satır ve sütun başlıklarına sahip olağan iki boyutlu, yani tablo gösterimleri kullanılır.

Bir küpün iki boyutlu bir temsili, onu bir veya daha fazla eksen (boyut) boyunca "keserek" elde edilebilir: ikisi hariç tüm boyutların değerlerini sabitleriz ve normal bir iki boyutlu elde ederiz. masa. Tablonun yatay ekseni (sütun başlıkları) bir boyutu, dikey eksen (satır başlıkları) başka bir boyutu ve tablo hücreleri ölçü değerlerini temsil eder. Bu durumda, ölçüler kümesi aslında boyutlardan biri olarak kabul edilir: ya görüntülemek için bir ölçü seçeriz (ve sonra satırların ve sütunların başlıklarına iki boyut yerleştirebiliriz) ya da birkaç ölçü (ve sonra bir tane) gösteririz. tablonun eksenlerinin her biri, ölçülerin adları ve diğer - tek bir "kesilmemiş" boyutun değerleri tarafından işgal edilecektir).

OLAP Uygulama Mimarisi

OLAP hakkında yukarıda söylenen her şey aslında verilerin çok boyutlu sunumuna atıfta bulunuyordu. Kabaca söylemek gerekirse, müşterinin kullandığı aracın ne son kullanıcısı ne de geliştiricileri, verilerin nasıl depolandığını önemsemez.

OLAP uygulamalarında çok boyutluluk üç seviyeye ayrılabilir.

• Çok boyutlu veri temsili - çok boyutlu görselleştirme ve veri işleme sağlayan son kullanıcı araçları; çok boyutlu temsil katmanı, verinin fiziksel yapısından soyutlar ve veriyi çok boyutlu olarak ele alır.
• Çok boyutlu işleme, çok boyutlu sorguları formüle etmek için bir araçtır (dil). SQL dili burada kullanılamaz olduğu ortaya çıkıyor) ve böyle bir talebi işleyebilen ve yürütebilen bir işlemci.
• Çok Boyutlu Depolama - Araçlar fiziksel organizasyonçok boyutlu sorguların verimli bir şekilde yürütülmesini sağlayan veriler.

İlk iki düzey, tüm OLAP araçlarında zorunludur. Üçüncü seviye, yaygın olarak kullanılmasına rağmen gerekli değildir, çünkü çok boyutlu temsil için veriler sıradan ilişkisel yapılardan da elde edilebilir; bu durumda çok boyutlu sorgu işlemcisi, çok boyutlu sorguları ilişkisel bir DBMS tarafından yürütülen SQL sorgularına çevirir.

Belirli OLAP ürünleri genellikle çok boyutlu bir veri sunum aracıdır (OLAP istemcisi - örneğin, Microsoft'tan Excel 2000'deki Pivot Tablolar veya Knosys'ten ProClarity) veya çok boyutlu bir arka uç DBMS'dir (OLAP sunucusu - örneğin Oracle Express Server veya Microsoft OLAP) Hizmetler).

Çok boyutlu işleme katmanı genellikle OLAP istemcisinde ve/veya OLAP sunucusunda bulunur, ancak Microsoft'un Pivot Tablo Hizmeti bileşeni gibi en saf haliyle izole edilebilir.

/ Kübist bir tarzda. Büyük şirketlerin yönetim uygulamalarında OLAP küplerinin kullanımı

Temas halinde

sınıf arkadaşları

Konstantin Tokmaçev, sistem mimarı

kübist bir şekilde.
Büyük şirketlerin yönetim uygulamalarında OLAP küplerinin kullanımı

Belki de şirketin bilgi işlem kaynaklarının yalnızca bilgi ve muhasebe raporlarının kaydedilmesine harcandığı zaman çoktan geçmiştir. Aynı zamanda ofislerde, toplantılarda ve toplantılarda yönetsel kararlar “gözle” alındı. Belki de Rusya'da kurumsal bilgi işlem sistemlerine dönme zamanı gelmiştir. ana kaynak– bilgisayarda kayıtlı verilere dayalı olarak kontrol problemlerini çözme

İş zekasının 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'lar vardır. Kontrol edilen nesnenin çeşitli alt sistemlerinin durumunu yansıtan bir "gösterge panosu" oluştururlar. Şirketi bilgilendirici performans göstergeleri ile donatmak ve hesaplamalarını ve elde edilen değerleri kontrol etmek bir iş analistinin işidir. Bir şirketin analitik çalışmasını organize etmede önemli yardım, MS gibi otomatik analiz hizmetleri tarafından sağlanabilir. SQL Server Analysis Services (SSAS) ve ana aracısı bir OLAP küpüdür.

Burada yapılması gereken bir not daha var. Örneğin, Amerikan geleneğinde OLAP küpleriyle çalışmaya odaklanan bir uzmanlığa BI (İş Zekası) adı verilir. Amerikan BI'sinin Rus "iş analistine" karşılık geldiği yanılsaması olmamalıdır. Alınma ama çoğu zaman iş analistimiz "yetersiz muhasebeci" ve "yetersiz programcı", belirsiz bilgiye ve küçük bir maaşa sahip, gerçekte kendi araçlarına ve metodolojisine sahip olmayan bir uzmandır.

Bir BI uzmanı, aslında, uygulamalı bir matematikçidir, modern matematiksel yöntemleri firmaların hizmetine sokan birinci sınıf bir uzmandır (Yönetim Araştırması - yöneylem araştırması yöntemleri olarak adlandırılır). BI, daha önce SSCB'de bulunan ve Moskova Devlet Üniversitesi VMK fakültesi tarafından üretilen “sistem analisti” uzmanlığı ile daha uyumludur. M.V. Lomonosov. OLAP küpü ve analiz hizmetleri, belki de Amerikan İş Zekası'na yönelik niteliklerinde bir miktar iyileştirme yaptıktan 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, şirketin farklı çalışan kategorileri arasındaki karşılıklı anlayış kaybolmuştur. I.A.'nın masalındaki "kuğu, yengeç ve turna" gibi bir muhasebeci, yönetici ve programcı. Krylov, şirketi farklı yönlere çekiyor.

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

Yönetici, iş sürecinin kendi bölümüyle meşgul, ancak eylemlerinin sonuçlarını ve beklentilerini küresel olarak, bir bütün olarak şirket düzeyinde değerlendiremiyor.

Son olarak, bir zamanlar (eğitim sayesinde) bilim alanından iş alanına kadar ileri teknik fikirlerin iletkeni olan programcı, bir muhasebeci ve yöneticinin fantezilerinin pasif bir uygulayıcısına dönüştü, bu yüzden artık öyle değil. muhasebeciler ve genel olarak tembel olmayan herkes nadirdir. Başlatılmamış, okuma yazma bilmeyen, ancak nispeten yüksek ücretli 1C programcısı, Rus şirketlerinin gerçek bir belasıdır. (Neredeyse yerli bir futbolcu gibi.) Sözde "ekonomistler ve hukukçular" dan bahsetmiyorum, uzun zamandır onlar hakkında her şey söylendi.

Dolayısıyla, programlama ve muhasebenin temellerini bilen, yüksek teknoloji ürünü bir SSAS aparatı ile donatılmış bir iş analistinin konumu, şirketin iş sürecinin analizi ve tahmini ile ilgili çalışmalarını pekiştirebilir.

OLAP küplerinin faydaları

OLAP küpü modern tesis hiyerarşinin her seviyesindeki çalışanlara şirketin üretim sürecini karakterize eden gerekli göstergeler setinin sağlanmasına izin veren kurumsal bilgisayar sistemi veri tabanının analizi. mesele sadece bu değil Kullanıcı dostu arayüz ve MDX küpü için esnek bir sorgulama dili (MultiDimensional eXpressions), gerekli analitik göstergeleri formüle etmenize ve hesaplamanıza olanak tanır, ancak bunun bir OLAP küpü tarafından yapıldığı dikkate değer bir hız ve kolaylıkla yapılır. Üstelik bu hız ve kolaylık, belirli sınırlar dahilinde, hesaplamaların karmaşıklığına ve veri tabanının hacmine bağlı değildir.

OLAP hakkında biraz bilgi
küp verebilir " Pivot tablo» MS Excel. Bu nesnelerin benzer mantığı ve benzer arayüzleri vardır. Ancak, makaleden de görüleceği gibi, OLAP'ın işlevselliği kıyaslanamayacak kadar zengindir ve performansı kıyaslanamayacak kadar yüksektir, böylece "pivot tablo" yerel bir masaüstü ürünü olarak kalırken, OLAP kurumsal düzeyde bir üründür.

Bir 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 ölçer) ve bölümleri (boyutlar boyutları) "çıkarması" gerektiği şekilde tasarlanmıştır. ) fare ile ve program plakaları yeniden çizer.

Tüm bölümlerdeki tüm olası analizler, büyük bir alan veya daha doğrusu bir alan değil, yalnızca çok boyutlu bir OLAP küpü oluşturur. Bir kullanıcının (yönetici, iş analisti, yönetici) analitik hizmetine yaptığı talep ne olursa olsun, yanıt hızı iki şeye bağlıdır: ilk olarak, gerekli analitik kolayca formüle edilebilir (listeden adıyla seçilebilir veya bir formülle verilebilir). MDX dilinde ) ve ikincisi, kural olarak zaten hesaplanmıştır.

Analitiğin formülasyonu üç versiyonda mümkündür: ya bir veritabanı alanı (daha doğrusu bir ambar alanı) ya da küp tasarım seviyesinde tanımlanmış bir hesaplama alanı ya da küple etkileşimli olarak çalışırken bir MDX dil ifadesidir.

Bu, aynı anda OLAP küplerinin birkaç çekici özelliği anlamına gelir. Aslında, kullanıcı ile veri arasındaki engel ortadan kalkar. Öncelikle sorunu açıklaması (bir görev belirlemesi) gereken bir uygulama programcısı biçimindeki bir engel. İkinci olarak, uygulama programcısı algoritmayı oluşturana, programı yazana ve hata ayıklayana kadar beklemeniz gerekecek, ardından program değiştirilebilir. Çok sayıda çalışan varsa ve gereksinimleri çeşitli ve değişken ise, uygulamalı programcılardan oluşan bütün bir ekibe ihtiyaç vardır. Bu anlamda, analitik çalışma açısından bir OLAP küpü (ve nitelikli bir iş analisti), tıpkı bir hendek kazarken beko sürücüsü olan güçlü bir ekskavatörün tüm bir misafir işçi tugayının yerini küreklerle değiştirmesi gibi, tüm uygulama programcıları ekibinin yerini alır!

Bu durumda, elde edilen analitik verilerin çok önemli bir niteliği daha elde edilir. OLAP küpü tüm şirket için bir küp olduğundan, yani. Bu, analistler için herkes için aynı alan olduğundan, verilerde can sıkıcı bir tutarsızlık söz konusu değildir. Bir yönetici, öznellik faktörünü ortadan kaldırmak için aynı görevi birkaç bağımsız çalışana vermek zorunda kaldığında, ancak yine de farklı cevaplar getirirler ve herkes bir şekilde açıklamayı taahhüt eder vb. OLAP küpü, kurumsal hiyerarşinin farklı seviyelerinde analitik verilerin tekdüzeliğini sağlar, örn. yönetici kendisini ilgilendiren belirli bir göstergeyi detaylandırmak isterse, o zaman kesinlikle astının birlikte çalıştığı alt düzey verilere gelecektir ve bu sadece üst düzey göstergenin hesaplandığı temelde veriler olacaktır. ve başka bir şekilde, başka bir zamanda vb. alınan diğer bazı veriler değil. Yani, tüm şirket aynı analitiği görüyor, ancak farklı konsolidasyon seviyelerinde.

Bir örnek alalım. Bir yöneticinin alacak hesaplarını kontrol ettiğini varsayalım. Vadesi geçmiş alacakların KPI'sı yeşil olduğu sürece, her şey normaldir, herhangi bir yönetim eylemi gerekmez. Renk sarıya veya kırmızıya döndüyse, bir sorun vardır: KPI'yi satış departmanına göre keseriz ve hemen bölümleri "kırmızı" olarak görürüz. Yöneticiler ve müşterileri ödemelerinde geciken satıcı ile ilgili bir sonraki bölüm tanımlanır. (Ayrıca, gecikme miktarı alıcılara, şartlara vb. göre ayrılabilir.) Şirket başkanı, herhangi bir düzeyde ihlal edenlere doğrudan hitap edebilir. 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ı üzerinde arama" beklemelerine bile gerek yok ... Tabii ki, KPI'nin kendisinin ille de ihmal miktarı olması gerekmez - ağırlıklı bir ortalama olabilir temerrüt süresi veya genel olarak alacakların devir hızı.

Hızlı (bazen anlık) sonuçlarla birlikte MDX dilinin karmaşıklığı ve esnekliğinin (geliştirme ve hata ayıklama aşamalarını dikkate alarak) çözmenize izin verdiğini unutmayın. zorlu görevler uygulamalı programcılar için karmaşıklık ve formülasyondaki ilk belirsizlik nedeniyle başka koşullar altında belki de hiç ayarlanmayan kontroller. (Uygulama programcılarının, tam olarak anlaşılamayan bir formülasyon nedeniyle analitik sorunları çözmesi için uzun zaman dilimleri ve pratikte sıklıkla koşullar değiştiğinde uzun program değişiklikleriyle karşılaşılır.)

Ayrıca şirketin her çalışanının, OLAP analistinin genel alanından tam olarak çalışması için ihtiyaç duyduğu mahsulü toplayabileceğine ve ortak "standart raporlarda" kestiği "şerit" ile yetinmeyeceğine de dikkat edelim. ”.

İstemci-sunucu modunda bir OLAP küpüyle çalışmak için çok kullanıcılı bir arabirim, her çalışanın diğerlerinden bağımsız olarak kendi (hatta biraz beceriyle kendi üretimleri) analitik bloklarına (raporlarına) sahip olmasına olanak tanır; güncellendi - başka bir deyişle, her zaman güncel durumdadırlar.

Yani, OLAP küpü, analitik çalışmayı (aslında yalnızca not analistleri tarafından değil, aslında şirketin neredeyse tüm çalışanları, hatta dengeleri ve sevkiyatları kontrol eden lojistikçiler ve yöneticiler tarafından yapılır) daha seçici yapmanıza olanak tanır, " genel bir ifadeyle değil, işi iyileştirmek ve üretkenliği artırmak için koşullar yaratan.

Girişimizi özetlersek, OLAP küplerinin kullanımının bir şirketin yönetimini daha yüksek bir seviyeye çıkarabileceğini not ediyoruz. Hiyerarşinin tüm seviyelerinde analitik verilerin tekdüzeliği, güvenilirlikleri, karmaşıklıkları, göstergeleri oluşturma ve değiştirme kolaylığı, bireysel ayarlar, yüksek veri işleme hızı ve son olarak, alternatif analitik yollarını desteklemek için harcanan paradan ve zamandan tasarruf (uygulama programcıları, bağımsız bir çalışanın hesaplamaları), büyük Rus şirketlerinin uygulamalarında OLAP küplerinin kullanımı için açık beklentiler.

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

Şimdi OLAP küplerinin genel fikrini ve kurumsal yönetim zincirindeki uygulama noktalarını düşünün. OLAP (Çevrimiçi Analitik İşleme) terimi, daha önceki terimi olan OLTP'ye (Çevrimiçi İşlemler İşleme) ek olarak İngiliz matematikçi Edgar Codd tarafından tanıtıldı. Bu daha sonra tartışılacak, ancak E. Codd elbette OLTP ve OLAP'ın yalnızca terimlerini değil, aynı zamanda matematiksel teorilerini de önerdi. Ayrıntılara girmeden, OLTP'nin modern yorumunda, bilgilerin kaydedilmesi, saklanması ve alınması için bir mekanizma olarak kabul edilen ilişkisel bir veritabanı vardır.

Çözüm metodolojisi

1C7, 1C8, MS Dynamics AX gibi ERP sistemleri (Kurumsal Kaynak Planlaması), kullanıcı odaklı yazılım arayüzlerine (belgelerin girişi ve düzeltilmesi vb.) ve bugün sunulan bilgileri depolamak ve almak için bir ilişkisel veritabanına (DB) sahiptir. yazılım ürünleri MS SQL Server (SS) yazın.

ERP sisteminin veritabanında kayıtlı olan bilgilerin gerçekten çok değerli bir kaynak olduğunu unutmayın. Önemli olan, kayıtlı bilgilerin yalnızca kurumun mevcut iş akışını (belge düzenleme, düzeltme, yazdırma ve mutabakat imkanı vb.) Sağlaması ve sadece hesaplama imkanı sağlaması değildir. finansal tablolar(vergiler, denetim vb.) Yönetim açısından, bir OLTP sisteminin (ilişkisel veri tabanı) aslında bir şirketin faaliyetlerinin tam boyutlu gerçek bir dijital modeli olması çok daha önemlidir.

Ancak süreci yönetmek için sadece bununla ilgili bilgilerin kaydedilmesi yeterli değildir. Süreç, seyrini karakterize eden bir sayısal göstergeler (KPI) sistemi olarak sunulmalıdır. Ek olarak, göstergeler için izin verilen değer aralıkları tanımlanmalıdır. Ve sadece göstergenin değeri izin verilen aralığın dışına çıkarsa, bunu bir kontrol eylemi takip etmelidir.

Böyle bir kontrol mantığı (veya mitolojisi) (“sapma yoluyla yönetim”) ile ilgili olarak, hem tekne rotasından saptığında küreğe yaslanan dümenci (sibernos) imajını yaratan eski Yunan filozofu Platon hem de Bilgisayar çağının eşiğinde sibernetik bilimini yaratan Amerikalı matematikçi Norbert Wiener.

OLTP yöntemini kullanarak bilgi kaydetmek için olağan sisteme ek olarak, bir sisteme daha ihtiyaç vardır - toplanan bilgileri analiz etmek için bir sistem. Kontrol döngüsünde yönetim ile kontrol nesnesi arasındaki geri bildirim rolünü oynayan bu eklenti, bir OLAP sistemi veya kısaca bir OLAP küpüdür.

Gibi yazılım uygulaması OLAP, SSAS olarak kısaltılan MS SQL Server'ın standart teslimatının bir parçası olan MS Analiz Hizmetleri yardımcı programını ele alacağız. E. Codd'un fikrine göre, analitikteki OLAP küpünün, OLTP sisteminin ve ilişkisel veritabanının (SQL Server) bilgi depolama ve alma konusunda verdiği aynı kapsamlı hareket ö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, uygulamaların ve teknolojik işlemlerin özel yapılandırmasını ele alalım.

Kurumun, bilgilerin olağan şekilde kaydedildiği 1C7 veya 1C8 gibi bir ERP sistemi kullandığını varsayacağız. Bu ERP sisteminin veri tabanı belirli bir sunucuda bulunur ve MS SQL Server tarafından korunur.

Ayrıca yazılımın, MS Analysis Services (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 programları da dahil olmak üzere başka bir sunucuya yüklendiğini varsayacağız. Bu programlar birlikte gerekli bağlamı oluşturur: OLAP küp geliştiricisi için araçlar ve gerekli arayüzler.

SSAS sunucusunda, (parametrelerle birlikte) adı verilen ücretsiz yazılım blat kuruludur. Komut satırı ve posta hizmetleri sağlamak.

Çalışan iş istasyonlarında, içinde yerel ağ, diğer şeylerin yanı sıra, MS Excel programları (en az 2003 sürümleri) yüklenir ve ayrıca muhtemelen özel sürücü MS Excel'in MS Analysis Services ile çalışmasını sağlamak için (ilgili sürücü zaten MS Excel'e dahil değilse).

Kesinlik için, çalışanların iş istasyonlarının sahip olduğunu varsayacağız. işletim sistemi Windows XP ve sunucularda - Windows Server 2008. Ayrıca SQL Server olarak MS SQL Server 2005 kullanıldığını ve OLAP küpü ile sunucuda Enterprise Edition (EE) veya Developer Edition (DE) kurulu olduğunu varsayalım. Bu baskılarda sözde kullanmak mümkündür. "yarı ek önlemler", yani ek olarak toplama işlevleri(istatistikler) olağan toplamlar dışında (örneğin, aşırı veya ortalama değer).

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

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, alıcılara, mallara, tarihlere göre bölümlerde bir sevkiyat göstergesi. OLAP küpleri ile ilgili Rusça literatürde İngilizce'den doğrudan çeviri nedeniyle, göstergelere "ölçüler" ve kesimlere "boyutlar" adı verilir. Bu matematiksel olarak doğru, ancak sözdizimsel ve anlamsal olarak pek başarılı olmayan bir çeviri. Rusça "ölçü", "ölçme", "boyut" kelimeleri anlam ve yazım bakımından neredeyse farklılık göstermezken, İngilizce "ölçü" ve "boyut" hem yazım hem de anlam bakımından farklıdır. Bu nedenle, anlam olarak "gösterge" ve "kes" e benzer geleneksel Rus istatistiksel terimlerini tercih ediyoruz.

Verilerin kaydedildiği OLTP sistemiyle ilişkili olarak OLAP küpünün yazılım uygulaması için birkaç seçenek vardır. En basit, en güvenilir ve en hızlı olan tek bir şemayı ele alacağız.

Bu şemada OLAP ve OLTP'nin ortak tabloları yoktur ve OLAP analitikleri, kullanım aşamasından önce Cube Update (Process) aşamasında olabildiğince ayrıntılı olarak hesaplanır. Bu şemaya MOLAP (Çok boyutlu OLAP) denir. Dezavantajları, ERP ile eşzamansızlık ve yüksek bellek maliyetleridir.

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

Bunun böyle olmasının birkaç nedeni var.

• İlk önce, bir OLAP küpünü gerçek bir veritabanındaki tablolara bağlamak kesinlikle teknik problemler. Bir tablodaki verileri değiştirmek, küpün yenilenmesini tetikleyebilir ve bir küpün yenilenmesi mutlaka hızlı bir işlem değildir, bu nedenle küp, kalıcı olarak yeniden oluşturulma durumunda olacaktır; aynı zamanda, küpü güncelleme prosedürü, veritabanı tablolarının verilerini bloke edebilir (okuma sırasında), kullanıcıların ERP sistemine veri kaydetme çalışmalarını yavaşlatabilir.
• ikincisi, çok fazla gösterge ve kesintinin varlığı, 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 ilk verileri değil, aynı zamanda tüm olası bölümlerde (ve hatta tüm bölümlerin tüm kombinasyonlarında) özetlenen tüm göstergeleri de sakladığını unutmayalım. Ek olarak, küpü güncelleme hızı ve nihayetinde, analizleri ve bunlara dayalı kullanıcı raporlarını oluşturma ve güncelleme hızı buna göre yavaşlayacaktır.
• Üçüncü, çok fazla çok sayıda alanlar (ölçüler ve yönler), OLAP geliştirici arayüzünde sorunlar yaratacaktır, çünkü öğelerin listeleri sonsuz hale gelecektir.
• Dördüncü, Bir OLAP küpü, veri bütünlüğü ihlallerine karşı çok hassastır. Anahtar veriler, küp alanlarının bağlantı yapısında belirtilen bir bağlantı tarafından yerleştirilmemişse, bir küp oluşturulamaz. Bir ERP sisteminin veritabanında bütünlüğün geçici veya kalıcı olarak ihlali, boş alanlar yaygındır, ancak bu kategorik olarak OLAP için uygun değildir.

Yükü paylaşmak için ERP sistemi ile OLAP küpünün farklı sunucularda bulunması gerektiğini de ekleyebilirsiniz. Ancak, OLAP ve OLTP için ortak tablolar varsa, bir sorun da vardır. ağ trafiği. Birkaç heterojen ERP sistemini (1C7, 1C8, MS Dynamics AX) bir OLAP küpünde birleştirmek gerekirse, bu durumda pratik olarak çözülemeyen sorunlar ortaya çıkar.

Muhtemelen teknik sorunları daha da üst üste yığmak mümkündür. Ancak en önemlisi, OLTP'den farklı olarak OLAP'ın bir veri kaydetme ve depolama aracı değil, bir analiz aracı olduğunu unutmayın. Bu, "her ihtimale karşı" ERP'den OLAP'a "kirli" veri yüklemeye ve yüklemeye gerek olmadığı anlamına gelir. Aksine, önce en azından KPI sistem düzeyinde bir şirketi yönetmek için bir konsept geliştirmeli ve ardından OLAP küpü ile aynı sunucuda bulunan ve az miktarda rafine edilmiş ERP içeren bir uygulama veri ambarı (depo) tasarlamanız gerekir. yönetimi için gerekli veriler.

Kötü alışkanlıkları teşvik etmeden, OLTP ile ilgili olarak OLAP küpü, "fermente kütleden" iyi bilinen "alembik" e benzetilebilir. gerçek kayıt"saf ürün" geri kazanılır.

Böylece, OLAP için veri kaynağının, OLAP ile aynı sunucuda bulunan özel bir veritabanı (depo) olduğunu anladık. Temel olarak, bu iki anlama gelir. Öncelikle, ERP veritabanlarından bir ambar oluşturacak özel prosedürler olmalıdır. İkincisi, OLAP küpü, ERP sistemleriyle eşzamansızdır.

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

Çözüm mimarisi

Analitik verileri tek bir OLAP küpü içinde konsolide görmek istediğimiz farklı sunucularda belirli bir şirketin (holding) birçok ERP sistemi olsun. Açıklanan teknolojide, ERP sistemlerinden gelen verileri depo düzeyinde birleştirerek 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. Bu boş kopyalara karşılık gelen aktif olarak çalışan ERP'lerin veritabanlarının periyodik olarak (gece) kısmi replikasyonunu gerçekleştiriyoruz.

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

Ardından ambar verilerine göre bir küpü güncellemek / oluşturmak için standart prosedür başlatılır (SSAS arayüzünde İşlem işlemi).

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

Kısmi çoğaltmanın bir sonucu olarak, OLAP sunucusundaki bazı ERP sistemlerinin görüntüsünde gerçek veriler görünür. Bu arada, kısmi çoğaltma iki şekilde yapılabilir.

İlk olarak, kısmi çoğaltma sırasında ERP sisteminin veritabanındaki tüm tablolardan yalnızca depoyu oluşturmak için gerekli olanlar kopyalanır. Bu, sabit bir tablo adları listesi tarafından kontrol edilir.

İkinci olarak, kısmi çoğaltma aynı zamanda tablonun tüm alanlarının kopyalanmadığı, ancak yalnızca ambarın oluşturulmasında yer alanların kopyalandığı anlamına gelebilir. Kopyalanacak alanların listesi ya belirtilir ya da SP'de kopya görüntüden dinamik olarak oluşturulur (tablonun kopyası başlangıçta tüm alanları içermiyorsa).

Tabii ki, tüm tablo satırlarını kopyalamak değil, sadece yeni kayıtlar eklemek mümkündür. Ancak bu, genellikle gerçek hayattaki sistemlerde bulunan ERP revizyonları "geriye dönük tarihleme"yi hesaba katarken ciddi bir rahatsızlık yaratır. Bu nedenle, daha fazla uzatmadan tüm kayıtları kopyalamak (veya bir tarihten başlayarak "kuyruğu" güncellemek) daha kolaydır.

Ayrıca, SP'nin ana görevi, ERP sistemlerinden gelen verileri depo formatına dönüştürmektir. Yalnızca bir ERP sistemi varsa, dönüştürme görevi temel olarak gerekli verileri kopyalamaya ve muhtemelen yeniden biçimlendirmeye indirgenir. Ancak, farklı yapıdaki birkaç ERP sistemini aynı OLAP küpünde birleştirmek gerekirse, dönüşümler daha karmaşık hale gelir.

Birkaç farklı ERP sistemini bir küpte birleştirme görevi özellikle zordur, eğer nesne kümeleri (mal dizinleri, yükleniciler, depolar vb.) kısmen kesişirse, nesneler aynı anlama gelir, ancak doğal olarak farklı şekillerde tanımlanırlar. dizinler farklı sistemler(kodlar, tanımlayıcılar, adlar vb. anlamında).

Gerçekte, böyle bir resim, büyük bir holding şirketinde, onu oluşturan aynı türdeki birkaç özerk şirket yaklaşık olarak aynı bölgede yaklaşık olarak aynı türde faaliyetler yürüttüğünde, ancak kendi ve koordinasyonsuz kayıt sistemlerini kullandığında ortaya çıkar. Bu durumda, verileri ambar düzeyinde konsolide ederken, yardımcı eşleme tabloları olmadan yapamazsınız.

Ambar depolama mimarisine biraz dikkat edelim. Tipik olarak, bir OLAP küp şeması bir "yıldız" olarak temsil edilir, örn. dizinlerin "ışınları" ile çevrili bir veri tablosu olarak - ikincil anahtar değerlerin tabloları. Tablo bir "göstergeler" bloğudur, referans kitapları onların kesikleridir. Aynı zamanda, dizin, örneğin, malların veya karşı tarafların çok seviyeli bir sınıflandırması gibi, keyfi bir dengesiz ağaç veya dengeli bir hiyerarşi olabilir. Bir OLAP küpünde, ambardaki veri tablosunun sayısal alanları otomatik olarak "göstergeler" (veya ölçü ölçüleri) haline gelir ve bölümler (veya boyutlar) ikincil anahtar tabloları aracılığıyla 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 (birden çok veri bloğu) birleşimi olacaktır.

İkinci olarak, yıldız işaretinin "ışını" bir dizin değil, tüm (hiyerarşik) bir dosya sistemi olabilir.

Üçüncüsü, mevcut boyut kesimlerine dayalı olarak, OLAP geliştirici arabirimi kullanılarak yeni hiyerarşik kesimler tanımlanabilir (örneğin, daha az düzeyle, farklı bir düzey sırası ile vb.)

Dördüncüsü, MDX dilinin ifadesi kullanılarak mevcut göstergeler ve bölümler temelinde yeni göstergeler (hesaplamalar) tanımlanabilir. Yeni küplerin, yeni göstergelerin, yeni bölümlerin orijinal öğelerle otomatik olarak tamamen entegre olduğuna dikkat etmek önemlidir. Kötü formüle edilmiş hesaplamaların ve hiyerarşik kesintilerin bir OLAP küpünün çalışmasını önemli ölçüde yavaşlatabileceğine de dikkat edilmelidir.

OLAP ile arayüz olarak MS Excel

OLAP küpleri ile kullanıcı arabirimi özellikle ilgi çekicidir. Doğal olarak, SSAS yardımcı programının kendisi en eksiksiz arabirimi sağlar. Bu bir OLAP küpü geliştirici araç seti, etkileşimli bir rapor tasarımcısı ve MDX dilinde sorgular kullanarak bir OLAP küpüyle etkileşimli çalışmaya yönelik bir penceredir.

SSAS'ın kendisine ek olarak, OLAP'a bir arabirim sağlayan ve işlevlerini az ya da çok kapsayan birçok program vardır. Ancak aralarında, bize göre yadsınamaz avantajları olan biri var. Bu MS Excel'dir.

MS Excel ile arayüz, ayrı olarak indirilebilen veya Excel'e dahil edilebilen ö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 bu kapsam daha da genişler (örneğin, MS Excel 2007'de MS Excel 2003'te olmayan bir KPI grafiği görünür, vb.).

Tabii ki, oldukça eksiksiz bir işlevselliğe ek olarak, MS Excel'in ana avantajı, bu programın her yerde dağıtılması ve ofis kullanıcılarının büyük çoğunluğunun onu yakından tanımasıdır. Bu anlamda diğer arayüz programlarından farklı olarak firmanın ek olarak herhangi bir şey edinmesine ve ayrıca kimseyi eğitmesine gerek yoktur.

OLAP ile bir arayüz olarak MS Excel'in en büyük avantajı, bir OLAP raporunda elde edilen verilerin bağımsız olarak daha fazla işlenmesi olasılığıdır (yani, OLAP'tan elde edilen verilerin aynı Excel'in diğer sayfalarında artık kullanılmadan çalışmasına devam edilmesi) OLAP araçları, ancak sıradan Excel araçları kullanılarak).

Gecelik facubi tedavi döngüsü

Şimdi OLAP işleminin günlük (gecelik) bilgi işlem döngüsünü açıklayalım. Hesaplama, C# 2005 ile yazılmış ve depo ve SSAS'lı bir sunucu üzerinde Görev Zamanlayıcı kullanılarak başlatılan facubi programının kontrolünde yapılır. Facubi başlangıçta internete girer ve güncel döviz kurlarını okur (bir para birimindeki bir dizi göstergeyi temsil etmek için kullanılır). Ardından, aşağıdaki adımlar gerçekleştirilir.

İlk olarak facubi, yerel ağda bulunan çeşitli ERP sistemlerinin (tutma öğeleri) kısmi veritabanı çoğaltmasını gerçekleştiren SP'leri başlatır. Çoğaltma, daha önce de söylediğimiz gibi, önceden hazırlanmış "bahçelerde" - SSAS sunucusunda bulunan uzak ERP sistemlerinin görüntüleri üzerinde gerçekleştirilir.

İkinci olarak, SP aracılığıyla, ERP kopyalarından ambar depolamasına - OLAP küp verilerinin kaynağı olan ve SSAS sunucusunda bulunan özel bir veritabanına - bir eşleme gerçekleştirilir. Bu, üç ana görevi yerine getirir:

• ERP verileri gerekli küp biçimleri altında getirilir; tablolardan ve tablo alanlarından bahsediyoruz. (Bazen gerekli tablonun, örneğin birkaç MS Excel sayfasından "kalıplanması" gerekir.) Benzer veriler, farklı ERP'lerde farklı bir biçime sahip olabilir, örneğin, 1C7 dizinlerindeki anahtar kimliği alanlarının 36 karakter uzunluğunda 8 kodu vardır. 1C8 dizinlerindeki _idrref ve _idrref alanları - 32 uzunluğunda onaltılık sayılar;
• işleme sırasında verilerin mantıksal kontrolü (mümkünse eksik verilerin yerine "varsayılanların" atanması dahil) ve bütünlük kontrolü, örn. karşılık gelen 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 gelebilir, örneğin bu aynı karşı taraftır. Kod birleştirme sorunu, eşleme tabloları oluşturarak çözülür; burada çeşitli kodlar aynı nesneler birliğe getirilir.

Üçüncü olarak, facubi, standart Process cube veri güncelleme prosedürünü (SSAS yardımcı program prosedürlerinden) başlatır.

Facubi, kontrol listelerine göre işlem adımlarının ilerleyişi hakkında e-posta mesajları gönderir.

Facubi'yi çalıştırdıktan sonra, Görev Zamanlayıcı birkaç tane çalıştırır. excel dosyaları OLAP küp ölçümlerine dayalı olarak önceden oluşturulmuş raporlara sahip olan. Söylediğimiz gibi, MS Excel'in OLAP küpleriyle (SSAS ile) çalışmak için özel bir programlama arayüzü (ayrı olarak indirilebilir veya yerleşik sürücü) vardır. MS Excel'i başlattığınızda, MS VBA üzerinde yer alan programlar (makrolar gibi), raporlardaki verilerin güncellenmesini sağlayan; raporlar gerektiğinde değiştirilir ve kontrol listelerine göre kullanıcılara posta (blat programı) ile gönderilir.

SSAS sunucusuna erişimi olan yerel ağ kullanıcıları, OLAP küpü için yapılandırılmış "canlı" raporlar alacaktır. (Prensipte, herhangi bir posta olmaksızın kendileri, yerel bilgisayarlarında bulunan MS Excel'deki OLAP raporlarını güncelleyebilirler.) Yerel ağ dışındaki kullanıcılar, sınırlı işlevselliğe sahip orijinal raporlar veya onlar için (OLAP raporlarını güncelledikten sonra) alacaklardır. MS Excel'de) SSAS sunucusuyla bağlantı kurmayan özel "ölü" raporlar hesaplanacaktır.

Sonuçların değerlendirilmesi

Yukarıda OLTP ve OLAP'ın eşzamansızlığından bahsetmiştik. Teknolojinin dikkate alınan versiyonunda, OLAP küp güncelleme döngüsü gece gerçekleştirilir (örneğin, sabah 1'de başlar). Bu, mevcut çalışma gününde kullanıcıların dünün verileriyle çalıştığı anlamına gelir. OLAP bir günlük kaydı aracı (belgenin en son sürümüne bakın) değil, bir yönetim aracı (sürecin eğilimini anlayın) olduğundan, bu birikmiş iş listesi genellikle kritik değildir. Ancak gerekirse, küp mimarisinin açıklanan sürümünde (MOLAP) bile günde birkaç kez güncelleme yapmak mümkündür.

Güncelleme prosedürlerinin yürütme süresi, OLAP küpünün tasarım özelliklerine (az ya da çok karmaşıklık, göstergelerin ve bölümlerin az ya da çok başarılı tanımları) ve harici OLTP sistemlerinin veritabanlarının hacmine bağlıdır. Deneyime göre, bir ambar inşa etme prosedürleri birkaç dakikadan iki saate kadar sürerken, bir küpü güncelleme prosedürü (İşlem) 1 ila 20 dakika sürer. Hakkında"yıldız" tipi düzinelerce yapıyı birleştiren karmaşık OLAP küpleri hakkında, onlar için yaklaşık düzinelerce ortak "ışın" (referans kesintileri), yaklaşık yüzlerce gösterge. Harici ERP sistemlerinin veritabanlarının hacmini sevkıyat belgelerine göre tahmin ederek, yılda yüzbinlerce belgeden ve buna bağlı olarak milyonlarca ürün hattından bahsediyoruz. Kullanıcının ilgisini çeken işlemenin tarihsel 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 Şirketi'nde (SB). Bazı şirketler ağırlıklı olarak ticari satın alma firmaları (RRK), diğerleri ise üretim firmalarıdır (Moldova Cumhuriyeti'ndeki balık ve deniz ürünleri işleme tesisleri ve Güvenlik Konseyi). Tüm şirketler, 1C7 ve 1C8 gibi standart ERP sistemlerinden DBF ve Excel'e dayalı "kalıntı" muhasebe sistemlerine kadar değişen, 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 hiç özel çalışanlar gerektirmediğini ya da bir tam zamanlı iş analistinin sorumlulukları arasında yer aldığını ekleyeceğim. Görev yıllardır dönüyor otomatik modçeşitli kategorilerdeki kurumsal çalışanlara günlük olarak güncel raporlama sağlar.

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

Deneyimin gösterdiği gibi, önerilen çözümün varyantı oldukça güvenilir ve kullanımı kolaydır. 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östergeler ve bölümlerin oluşturulması, Excel raporları ve bunların posta listelerinin oluşturulması ve değiştirilmesi).

OLAP ile bir arayüz olarak MS Excel, yeterli ifade sağlar ve OLAP teknolojisine farklı kategorilerde hızlı bir şekilde katılmanıza izin verir. Ofis çalışanları. Kullanıcı günlük "standart" OLAP raporları alır; OLAP ile MS Excel arayüzünü kullanarak, bağımsız olarak MS Excel'de OLAP raporları oluşturabilir. Ek olarak, kullanıcı, MS Excel'in olağan yeteneklerini kullanarak bağımsız olarak OLAP raporlarının bilgilerini keşfetmeye devam edebilir.

Birkaç heterojen ERP sisteminin konsolide edildiği (küp inşası sırasında) herhangi bir OLAP olmadan bile "rafine edilmiş" bir ambar veritabanı, (SSAS sunucusunda, Transact SQL sorgulama yöntemi veya SP yöntemi vb. kullanılarak) bir çok sayıda uygulamalı yönetim görevi. Ambar veritabanı yapısının birleşik olduğunu ve orijinal ERP'nin veritabanı yapılarından çok daha basit olduğunu (tablo sayısı ve tablo alanı sayısı açısından) hatırlayın.

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

MOLAP küp modelini kullandık. Bu modelin avantajları, operasyonda güvenilirlik ve kullanıcı isteklerinin yüksek hızda işlenmesidir. Eksileri - eşzamansız OLAP ve OLTP'nin yanı sıra OLAP'ı depolamak için büyük miktarda bellek.

Sonuç olarak, belki de Orta Çağ'da daha uygun olan OLAP lehine bir argüman daha verelim. Çünkü kanıtlayıcı gücü otoriteye dayanmaktadır. Mütevazı, 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 güçlüydü ki, 50 yıl sonra, ilişkisel olmayan bir veritabanı ve SQL dışında bir veritabanı sorgulama dili bulmak zaten zor.

İlişkisel veritabanları teorisine dayanan OLTP teknolojisi, E. Codd'un ilk fikriydi. Aslında, OLAP küpleri kavramı, 90'ların başında kendisi tarafından ifade edilen ikinci fikridir. Bir 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. Basitçe, analitik konusu kapsamlı matematiksel çözümünü OLAP'ta bulduğu ve bu çözümün pratik analitik görevi için "yeterli" (B. Spinoza'nın terimi) olduğu için. "Yeterince", Spinoza'da, Tanrı'nın kendisinin bile daha iyi bir fikir bulamamış olduğu anlamına gelir...

1. Larson B. Microsoft SQL Server 2005'te iş zekasının geliştirilmesi. - St. Petersburg: "Piter", 2008.
2. Codd E. Veri Tabanı Alt Dillerinin İlişkisel Tamlığı, Veri Tabanı Sistemleri, Courant Computer Science Sumposia Series 1972, v. 6, Englwood uçurumları, N.Y., Prentice–Hall.

Temas halinde