Başarılı Bir LuckyTemplates Uygulaması İçin İpuçları

LuckyTemplates proje planlama ve uygulama serimize devam edeceğiz. Bu kez, veri kümesi tasarımı , profil oluşturma ve modlar hakkında tartışacağız . Dağıtım modlarıyla ilgilenen proje planlama serimizin ilk bölümüne ve keşif ve alımdan bahseden ikinci bölümüne göz atın .

İçindekiler

• LuckyTemplates Proje Uygulaması İçin Veri Kümesi Tasarımı
  • 4 Adımda Veri Kümesi Tasarımı
  • İş sürecini seçin.
    • LuckyTemplates Uygulamasında Kaçınılması Gereken Anti-Pattern
  • Tahıl ilan edin.
  • Boyutları tanımlayın.
  • Gerçekleri tanımlayın.
• LuckyTemplates Proje Uygulaması İçin Veri Yolu Matrisi
• LuckyTemplates Uygulaması İçin Veri Profili Oluşturma
  • SQL Server Entegrasyon Hizmetleri
  • DAX Stüdyosu
  • LuckyTemplates Masaüstü
• LuckyTemplates Uygulaması İçin Veri Kümesi Planlaması
  • Veri Kümesi Modu Seçme
  • Veri Kümesi Modlarını Seçerken Sorulacak Bazı Sorular
• Çözüm

LuckyTemplates Proje Uygulaması İçin Veri Kümesi Tasarımı

Veri kümesi tasarım sürecinden bahsedelim ve bir süredir ortalıkta dolaşan bir araç olan veri ambarı veri yolu matrisini tartışalım.

LuckyTemplates veri kümelerini tasarlamak, veri ambarlarını tasarlamaya benzer. Bu nedenle, hem veri kümeleri hem de veri ambarları, olgu ve boyut tabloları, yıldız şemaları, yavaş değişen boyutlar, olgu tablosu ayrıntı düzeyi ve tablolar arasında ilişki kurmak için yerel bilgilendirilmiş anahtarlar gibi benzer kavramlara sahiptir.

4 Adımda Veri Kümesi Tasarımı

Veri kümesi tasarım sürecinin dört adımı vardır: iş sürecini seçin , olgu tablolarınızın yapısını belirtin , boyutları belirleyin ve ardından olguları tanımlayın .

İş sürecini seçin.

İlk adım için, her bir iş süreci, boyutlarla çoktan bire ilişkin bir yıldız şemasına sahip bir olgu tablosuyla temsil edilir .

Bir keşif veya gereksinim toplama süreci sırasında, kullanıcılar birden çok iş sürecini aynı anda düzenli olarak analiz ettiğinden, tek bir iş sürecine tek başına odaklanmak zordur.

LuckyTemplates Uygulamasında Kaçınılması Gereken Anti-Pattern

LuckyTemplates projelerinde kaçınmak istediğiniz yaygın ters kalıp (genellikle etkisiz ve potansiyel olarak verimsiz olan, tekrar eden bir soruna yanıttır) , iş süreçleri yerine belirli projeler veya ekipler için veri kümelerinin geliştirilmesidir .

Örneğin, yalnızca pazarlama ekibi için bir veri seti ve satış organizasyonu için başka bir veri seti geliştirmek. Bu yaklaşım doğal olarak kaynakların israf edilmesine yol açmaktadır çünkü aynı satış verileri her iki veri setinde de iki kez sorgulanıp yenilenmektedir. Bunlar, LuckyTemplates hizmetindeki depolama kaynaklarını da tüketir.

bunlar, veri kümesi tasarımı için iyi bir süreçten geçmek istemenizin nedenlerinden bazılarıdır. Yalıtılmış bir yaklaşım, veri kümeleri varyasyonlar ve dönüşümler içerebileceğinden yönetilebilirlik ve sürüm kontrolü sorunlarına yol açar.

Kullanıcıların veya ekiplerin analitik ihtiyaçları LuckyTemplates projelerinin önceliği olsa da, sonuçta ekipler arasında paylaşılabilecek sürdürülebilir çözümler planlamak da önemlidir.

Tahıl ilan edin.

Gerçek tabloları, nihayetinde analitik sorgular için mevcut olan ayrıntı düzeyinin yanı sıra erişilebilen veri miktarını da kapsar.

Yani daha yüksek gren, daha fazla ayrıntı anlamına gelirken daha düşük gren, daha az ayrıntı anlamına gelir. Buna bir örnek olarak, satış siparişi satır düzeyini almak istediğinizde veya projenin yalnızca her satış siparişinin özet düzeyini içermesini ve o satışın parçası olarak sipariş edilen belirli ürünlere inmemesini istediğinizde gösterilebilir.

Bazen bu tahıl, zaman diliminize bağlı olarak değişebilir. İçinde bulunduğumuz çeyrek için çok ayrıntılı olgu tabloları isteyen birkaç müşteriyle karşılaştım, ancak önceki çeyrekler için, sadece çeyrek için toplam satışın ne olduğunu bilmeleri gerekiyordu.

Bu adımda, farklı iş süreçlerinin her satırının neyi temsil ettiğini belirlemek istiyorsunuz . Örneğin, veri ambarımızdaki satış olgusu tablosunun her satırı, bir müşteriden gelen bir satış siparişinin satırını temsil eder.

Tersine, bir satış ve marj planının satırları bir takvim ayı, ürün alt kategorisi ve satış bölgesi bölgesinde toplanacaktır. yani bu durumda, iki farklı olgu tablonuz ve iki farklı greniniz var. ikisini karşılaştırmak isterseniz, bazı veri modelleme çalışmaları yapılacaktır.

Boyutları tanımlayın.

Boyutlar, bir önceki tasarım adımında seçilen tahılın doğal yan ürünüdür.

Bu nedenle, olgu tablosundan tek bir örnek satır, bireysel bir projeyi, ürünü belirli bir tarihte ve belirli bir zamanda satın alan müşteri gibi, verilen süreçle ilişkili ticari varlığın boyutlarını açıkça belirtmelidir. Daha düşük taneleri temsil eden olgu tabloları daha az boyuta sahiptir.

Örneğin, bir satın alma siparişinin başlık seviyesini temsil eden bir olgu tablosu, satıcıyı tanımlayabilir, ancak satıcıdan satın alınan bireysel ürünü tanımlayamaz. bu durumda, bir ürün kategorisine veya bir ürün alt kategorisi boyutuna ihtiyacınız olmaz.

Gerçekleri tanımlayın.

Olgular, olgu tablolarında yer alan sayısal sütunları temsil eder. Bu nedenle, 3. adımdaki boyut sütunları ilişkiler için kullanılırken, olgu sütunları, bir miktar sütununun toplamı veya bir fiyat sütununun ortalaması gibi toplama mantığını içeren ölçümlerde kullanılır.

LuckyTemplates Proje Uygulaması İçin Veri Yolu Matrisi

Veri ambarı veri yolu matrisi, veri ambarı tasarımına artımlı ve entegre bir yaklaşım sağlayan Ralph Kimball veri ambarı mimarisinin temelini oluşturur.

Burada gördüğünüz mimari, Ralph Kimball tarafından yazılan The Data Warehouse Toolkit , 3. baskıdan. Birden çok iş ekibinin veya işlevin genellikle aynı iş süreçlerine ve boyutlarına erişmek için ihtiyaç duyduğu ölçeklenebilir veri modellerine olanak tanır.

Etrafında bir veri ambarı veri yolu matrisi bulundurmak faydalıdır. doldurduğunuzda, benzer internet olgu tabloları ve boyut tabloları içeren başka veri kümeleri olup olmadığını öğreneceksiniz. bu, projenin yeniden kullanılabilirliğini teşvik eder ve proje iletişimini geliştirir.

Dolayısıyla her satır, defteri kebirin aylık kapanışı gibi önemli ve yinelenen bir iş sürecini yansıtır. gölgeli satırlar, projeye dahil edilen iş sürecini temsil ederken, her sütun bir veya daha fazla iş süreciyle ilgili olabilen bir ticari varlığı temsil eder.

LuckyTemplates Uygulaması İçin Veri Profili Oluşturma

Taneyi belirledikten ve dört adımlı veri kümesi tasarım süreci tamamlandıktan sonra, bunun hemen ardından olgu ve boyut tablolarının kaynak verilerinin teknik analizi yapılmalıdır .

Veri tabanı diyagramları ve veri profili oluşturma sonuçları dahil olmak üzere teknik meta veriler, proje planlama aşaması için çok önemlidir.

Bu bilgiler, power BI veri kümesinin amaçlanan iş tanımlarını yansıtmasını ve sağlam ve güvenilir bir kaynak üzerine inşa edilmesini sağlamak için kullanılır.

Yani üçü, insanların tasarım sürecinden çıktıktan sonra yapacakları ilk adım olması gereken profil oluşturma bilgilerini toplamanın üç farklı yoludur.

SQL Server Entegrasyon Hizmetleri

Bunu yapmanın birkaç yolu var. Yöntemlerden biri, bir SQL Server Entegrasyon Hizmetleri (SSIS) paketi içinde bir veri profili oluşturma görevi kullanmaktır .

Veri profil oluşturma görevi, bir ADO.NET bağlantısı gerektirir ve çıktısını bir XML dosyasına veya bir SSIS değişkenine yazabilir.

Bu örnekte, ADO.NET kaynak verileri bir AdventureWorks veri ambarı, veritabanı ve SQL sunucusudur ve hedef bir XML dosyasıdır.

Böylece, görev yürütüldüğünde, XML dosyası bir SQL sunucusu veri profili görüntüleyici aracılığıyla okunabilir. Sonuçları boş sayım ve boş sayım yüzdeleri olarak görebilirsiniz.

DAX Stüdyosu

Veri profili oluşturmanın başka bir yolu da DAX Studio aracılığıyladır. DAX Studio'ya giderek, gelişmiş sekmeye giderek ve VertiPaq Analyzer'ı çalıştırarak verileri bir LuckyTemplates veri kümesine fiilen almanız gerekir .

Sütunlarınızın kardinalitesiyle ilgili aynı türden bilgileri size gösterecek, böylece veri modelinizde hangilerinin en fazla alanı kapladığını bileceksiniz. verilerle ilgili tüm çeşitli istatistikleri içerir.

LuckyTemplates Masaüstü

veri profili oluşturma, LuckyTemplates masaüstündeki güç sorgusunda da mevcuttur. Görünüm sekmesine giderseniz sütun kalitesi, sütun dağılımı ve sütun profili gibi şeyleri açabilirsiniz. En azından ilk bin satır kadar hatalar, boş değerler, ortalamalar ve standart sapmalar gibi bilgileri görebilirsiniz.

LuckyTemplates Uygulaması İçin Veri Kümesi Planlaması

Kaynak verilerin profili çıkarıldıktan ve dört adımlı veri kümesi tasarım sürecinde belirlenen gereksinimlere göre değerlendirildikten sonra, BI ekibi veri kümesi için uygulama seçeneklerini daha fazla analiz edebilir.

Neredeyse tüm power BI projelerinde, kurumsal verilere, ambarlara, mimariye ve ETL araçlarına ve süreçlerine önemli yatırımları olanlar bile, kaynak verilerin kalitesini ve değerini artırmak için bir düzeyde ek mantık, entegrasyon veya dönüşüm gerekir.

Veri kümesi planlama aşaması, veri kümesini desteklemek için belirlenen veri dönüştürme sorunlarının nasıl ele alınacağını belirler. Ek olarak, proje ekibinin bir içe aktarma modu veri kümesi mi , doğrudan sorgu veri kümesi mi yoksa bileşik bir veri kümesi mi geliştireceğine karar vermesi gerekir .

Veri kümesi planlama sürecini netleştirmek için bu diyagram, veri ambarının ve LuckyTemplates veri kümesinin dönüşüm ve iş mantığının uygulanabileceği farklı katmanlarını tanımlar.

bazı projelerde minimum dönüşüm gerekir ve bu, power BI veri kümesine kolayca dahil edilebilir. Örneğin, bir boyut tablosu için yalnızca birkaç ek sütuna ihtiyaç duyuluyorsa ve bu sütunların nasıl hesaplanacağına ilişkin doğrudan kılavuzluk varsa, BT kuruluşu veri ambarını revize etmek yerine bu dönüşümleri M güç sorguları içinde uygulamayı seçebilir.

BI ihtiyaçları ile kurumsal veri ambarı arasındaki önemli farkın sürmesine izin verilirse, LuckyTemplates veri kümelerinin oluşturulması ve bakımı daha karmaşık hale gelir.

Veri kümesi tasarımcıları, daha yüksek düzeyde karmaşıklık varsa, veri kümelerinin sonuçlarını düzenli olarak analiz etmeli ve iletmelidir.

Bununla birlikte, gerekli dönüştürme mantığı, çoklu ortak işlemler, satır filtreleri ve veri türü değişiklikleri ile karmaşık veya kapsamlıysa, BT organizasyonu, yeni veri kümesini ve gelecekteki BI projelerini desteklemek için veri ambarında temel değişiklikleri uygulamayı seçebilir.

Örneğin, süreci desteklemek, gözden geçirmek ve güncellemek için bir hazırlama tablosuna ve bir SQL depolama prosedürüne ihtiyaç duyulabilir veya DirectQuery veri kümeleri için sorgu performansını iyileştirmek için bir indeks oluşturulması gerekebilir.

Veri Kümesi Modu Seçme

Veri kümesi planlamasıyla yakından ilgili bir sonraki adım, varsayılan içe aktarma modu, DirectQuery/canlı mod veya bileşik mod arasında seçim yapmaktır.

Bazı projelerde bu, bilinen gereksinimler göz önüne alındığında yalnızca bir seçeneğin uygulanabilir veya gerçekçi olduğu basit bir kararken, diğer projeler her bir tasarımın artılarının ve eksilerinin önemli ölçüde analiz edilmesini gerektirecektir.

Bu nedenle, bir veri kaynağının yüksek hacimli analitik sorguları işlemek için yavaş veya yetersiz donanımlı olduğu düşünülüyorsa, o zaman bir içe aktarma modu veri kümesi büyük olasılıkla tercih edilen seçenektir.

Aynı şekilde, bir veri kaynağının gerçek zamanlıya yakın görünürlüğü önemliyse, bunu başarmak için tek seçenek DirectQuery veya canlı moddur. DirectQuery ve canlı modlar birbirine çok benzer. Her iki yöntem de verileri veri kümesinin kendisinde depolamaz ve her ikisi de kullanıcı eylemine dayalı olarak verileri almak için doğrudan kaynak sistemleri sorgular. Artık LuckyTemplates veri kümeleri için DirectQuery'ye ve Analiz Hizmetleri için DirectQuery'ye sahibiz.

Veri Kümesi Modlarını Seçerken Sorulacak Bazı Sorular

Hangi modun kullanılacağına karar verirken sorulacak bazı sorular aşağıda verilmiştir. veri setimiz için tek bir kaynak var mı? Tek bir kaynak yoksa, geçmişte DirectQuery/Live kaynağını kullanamıyordunuz.

Artık bileşik mod veri setlerine sahip olsak da, başlangıçta sormak için iyi bir soru çünkü tek bir kaynak yoksa, o zaman ya içe aktarma ya da bileşik olacaktır.

DirectQuery/Live kaynağı bir seçenekse, kaynak analitik sorguları destekleyebilir mi? Milyarlarca veya trilyonlarca satırla çalışıyorsanız, içe aktarma modu veri kümesi uygun olmayabilir ve veri kümesinin kullanılabilir olduğundan emin olmak için DirectQuery veya bileşik moda geçmeniz gerekebilir.

DirectQuery/Live kaynağı iş yükünü destekleyebiliyorsa, DirectQuery/Live bağlantısı bir içe aktarma modelinin sağladığı performans ve esneklikten daha mı değerlidir?

Çözüm

Bu gönderi, LuckyTemplates projelerini planlamayla ilgili bu diziyi tamamlıyor. bence bunlar üzerinde çalıştığınız her power BI projesi için gerekli adımlar. Bu adımlar, özellikle bir kurumsal iş zekası ortamında durum tespiti yapılırken önemlidir.

Herşey gönlünce olsun,

Greg Deckler