Bütçe Dostu Veri Madenciliği Rehberi

API işlevlerinin her gün değiştiği geleneksel uygulama programlamasının aksine, veritabanı programlama temelde aynı kalır. Microsoft Visual Studio .NET'in ilk sürümü Şubat 2002'de yayınlandı ve Service Pack sürümleri hariç her iki yılda bir yeni bir sürüm yayınlandı. Bu hızlı değişim hızı, BT personelini, en son teknikler ve teknoloji ile güncel kalmak için uygulamalarının işlevselliğini bozulmadan ancak tamamen farklı bir kaynak koduyla bırakarak, şirketlerinin uygulamalarını birkaç yılda bir değerlendirmeye zorlar.

Aynı şey veritabanı kaynak kodunuz için söylenemez. SQL'in ilk günlerinde yazılmış standart bir SELECT / FROM / WHERE / GROUP BY sorgusu bugün hala çalışıyor. Elbette bu, ilişkisel veritabanı programlamasında hiçbir ilerleme olmadığı anlamına gelmez; vardı ve teknikten daha mantıklıydılar .

Bill Inmon ve Ralph Kimball'un veri ambarı tasarımı üzerine teorilerini yayınladıkları günlerden itibaren, veri tabanı programlamasındaki gelişmeler, değerli bilgilerin kaybını önlemeye ve verilerden tüm değerli bilgileri çıkarmaya odaklandı. Inmon ve Kimball veri ambarı dünyasını veri ambarıyla tanıştırdıktan sonra, veri tabanı geliştiricilerine meta verilere ve ilişkisel olmayan veri tabanı kaynaklarından gelen verilere kolay erişim sağlayan ETL (Çıkarma/Dönüştürme/Yükleme) araçlarında büyük değişiklikler yapıldı. geçmişte. Bu, değerli bilgilerin çıkarılabileceği mevcut veri miktarını artırdı ve mevcut verilerdeki bu artış, OLAP küpleri ve veri madenciliği algoritmaları aracılığıyla veri işlemede ilerlemelere yol açtı.

Veritabanı mimarinize bir veri ambarı, OLAP küpleri ve veri madenciliği algoritmaları eklemek, iş süreçlerini önemli ölçüde düzene sokabilir ve verilerinizdeki, aksi takdirde var olduğunu asla bilemeyeceğiniz kalıpları aydınlatabilir. Otomasyonun iş zekası yetenekleri üzerinde de derin bir etkisi olabilir.

Ancak, yeni araçlar ve teknolojiler eklemeye başlamadan önce, işlem veritabanının düzgün bir şekilde oluşturulduğundan emin olmalısınız.

İşlem Veritabanı

İşlem veritabanı temeldir ve işlem veritabanınız güvenilir ve doğru değilse, üstüne herhangi bir şey eklemek felaket için bir reçetedir.

Veritabanınıza ek katmanlar eklerken akılda tutulması gereken önemli bir nokta, tüm projelerin bir yatırım getirisi göstermesi gerektiğidir ; bu nedenle, başka katmanlar eklemeden önce mevcut mimarinizden en iyi şekilde yararlanmanız en iyisidir. Tüm bu katmanlar, bir işlem veritabanından kaynaklanan verileri kullanır. Birçok durumda aynı çıktıyı sadece işlem veritabanınızı sorgulayarak elde edebilirsiniz. Elbette, tüm raporlarınızın bir veri ambarından veya OLAP küpünden okunması ideal yöntemdir, ancak bir kuruluş bu karmaşıklık düzeyine hazır değilse, öncelikle raporlama ihtiyaçlarının karşılanması daha önemlidir. Temel raporlama ihtiyaçları karşılandıktan sonra, uygun bir veri ambarının ve muhtemelen bir OLAP küpünün işine nasıl fayda sağlayabileceğine dair bir tartışmaya başlamak çok daha kolaydır.

Neredeyse her programcı, veritabanı normalleştirmenin üç kuralını bilir. İşlem veritabanından okunan saklı yordamlar, optimizasyona giden yoldur. Aranacak konular okunabilirlik, aynı veritabanı tablosuna birden çok çağrı ve değişkenlerin gereksiz kullanımıdır.

Tüm seçkin veritabanı programcıları, saklı prosedürlerinin okunabilirliği konusunda seçicidir. Bir uygulama geliştiricisinden farklı olarak, veritabanı uzmanlarının sorgularını biçimlendirme biçiminde birkaç ortak nokta vardır. Tipik olarak, anahtar sözcükler ve toplama işlevleri büyük harflerle yazılırken, tablo ve alan adları ya camelcase ya da alt çizgi kullanır. Tablo takma adları, gerçek tablo adıyla bir miktar korelasyona sahiptir. Saklı yordamın bölümlerinin hizalanması, bir tür blok desenine sahiptir.

Aşağıda, okunabilir bir biçim kullanan bir sorgu örneği verilmiştir.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Aranacak bir sonraki şey, bir sorgunun bir tabloya birden fazla isabet edip etmediğidir. Çoğu sorguda, başka bir toplama işlevini toplamanız gereken nadir zamanlar dışında, bir tabloya yalnızca bir kez erişilmesi gerekir. Bu, bazı uygulama programcılarının, belki de bir uygulama programcısının nesne yönelimli tasarım açısından düşündüğü için yaptığı başka bir hatadır.

Nesne yönelimli tasarım, her benzersiz veri öğesi için ayrı nesneler oluşturur, ancak bir veritabanı programcısının küme mantığı açısından düşünmesi gerekir. Bir sorgunun bir tabloya gereğinden fazla erişmesi, sorgunun hatalı veri ürettiği anlamına gelmez, ancak sorgunun performansı etkilenir.

Başka bir endişe, bir katılımınız olduğunda, sorgunuzun doğruluğundan ödün vererek, kayıtlar bırakılır veya çoğaltılır. Değişkenlerin gereksiz kullanımı, bir sorgunun bir uygulama geliştiricisi tarafından geliştirildiğinin bir başka işaretidir. Uygulama geliştiricileri, kodları boyunca değişkenler kullanırken, bir sorgunun saklı yordam için bir parametre olarak bildirildiği durumlar dışında çok nadiren değişkenleri kullanması gerekir. Bir kez daha, geliştiricinin küme mantığı açısından düşünmediğinin bir işaretidir.

ETL (Extract Transform Load) ve Raporlama

Bir müşterinin işlem veritabanında düzgün işleyen sorgular olduğunda, bir sonraki adım iş süreçlerini düzene koymaktır.

Bir işletmenin ETL süreçleri veya otomatik raporlama ihtiyacını belirlemenin en kolay yolu, kimin bir işlem veritabanından veri okuduğunu bulmak ve ardından bir elektronik tablo kullanarak verileri manipüle etmektir. Elektronik tablo, veritabanı tablosuyla aynı yapıdır. Her ikisi de satır ve sütun içerir. Verileri kendi başlarına manipüle eden son kullanıcılarınız varsa, kendinize “Bu süreç neden otomatikleştirilemiyor?” diye sormalısınız.

İş süreçlerini otomatikleştirmek, anında yatırım getirisi sağlar ve veri ambarı gibi daha pahalı projelere geçmeden önce her zaman düşünülmelidir. Bir elektronik tablo aracılığıyla verileri manipüle eden son kullanıcıları belirlemek kulağa basit gelebilir ancak bu işlem için bir uyarı var.

Geliştiriciler süreçleri otomatikleştirmeyi sever; yaptıkları bu. Son kullanıcılar, özellikle işlerini tehdit ediyorlarsa, otomatikleştirilmiş süreçleri sevmezler. Bu nedenle, saf olmayın ve son kullanıcıların size koşacağını ve otomatikleştirilebilecek günlük görevleri belirleyeceğini düşünmeyin. Düzenleyici fırsatları belirlemede gerçekten öncülük etmeniz gerekiyor.

İyi yapılandırılmış bir ETL sistemi, bir işlem veritabanına yüklenen tüm verileri orijinal kaynak dosyaya geri izleme yeteneği de sağlamalıdır. Bu, veritabanı mimarisinin kritik bir parçasıdır. Her kaydın eklendiği tarihi/saati ve kayıtları ekleyen kaynağın adını (kullanıcı adı veya dosya adı) tam olarak bilmiyorsanız, işlem veritabanınıza yüklenen hatalı verileri işlemeye hazır değilsiniz. Kendinize, "Ya biri bize kötü bir dosya gönderirse?" diye sormalısınız. Ondan gelen kayıtları tanımlamanız ne kadar sürer?

Veri deposu

Veri ambarı tasarımı için iki teori vardır. Inmon ve Kimball teorileri arasındaki fark şu şekilde özetlenebilir:

Inmon teorisi, önce bir veri ambarı geliştirmek ve ardından veri ambarından raporlama için boyutlu veri pazarları oluşturmaktır. Kimball teorisi, önce raporlama için boyutlu veri marketleri geliştirmek ve ardından veri ambarını oluşturmak için bunları bir araya getirmektir.

Müşterilere her zaman en hızlı yatırım getirisini sağlamak istersiniz. Veri marketleri oluşturmak basit bir işlemdir. Raporlarınızın arkasındaki sorguları alarak başlayın ve bunları sonuç kümelerini döndürmekten, sonuç kümelerini kalıcı tablolarda saklamaya dönüştürün. TRUNCATE TABLE adını eklemeniz yeterlidir ; Orijinal SELECT anahtar sözcüğünden önce tablo adına INSERT INTO . Birkaç işlevsel data mart tablonuz olduğunda, datamartları birleştirme fırsatlarının belirlenmesi devreye girmelidir; aynı tablo listesini kullanan rapor sorgularını arayın ve ardından alan listesini birleştirin. Bu, özellikle tablo listesi arttığında daha karmaşık bir sorgu gerektirir. Ancak, sorguyu baştan sona test ettiğiniz sürece, normal iş süreçlerinde herhangi bir kesinti olmaksızın her artımlı değişiklik yapılabilir.

Kimball veri ambarı tasarımında her geliştirme yaptığınızda, müşteriye bir yatırım getirisi gösterme fırsatınız olur. Bunun nedeni, önce veri ambarının oluşturulması ve raporlama veri pazarlarının statik bir veri ambarından oluşturulmasıdır. Bu nedenle, maliyetlerinizin çoğunu veri ambarı projesinde erkenden üstlenirsiniz.

OLAP Küpü

Bir OLAP küpü, hızlı yanıt süresi, son kullanıcılar için geçici inceleme yetenekleri ve veri madenciliği ile toplu veriler sağlayarak bir kuruluşa fayda sağlayabilir. Uygun bir OLAP küpünüz olduğunda, verilerinizden her bit değeri çıkarabilirsiniz. Bir OLAP küpü, bir veri ambarının üzerine inşa edilmiştir, ancak standart bir SQL veritabanından farklı bir dil olan MDX'i kullanır. Ayrıca, bir veritabanı sunucusundan daha kapsamlı bir yapılandırma çabası gerektirir. Bu karmaşıklık, bir OLAP projesini pahalı hale getirir ve ayrıca deneyimli MDX geliştiricileri bulmak da zordur.

Veri mimarları bazen, bir SQL sorgusu, veri ambarı veya hazır raporla değiştirilemeyecek tek bir işlem olmaksızın, küpü kullanan basit bir gösterge panosundan başka bir şey olmayan mevcut OLAP küplerini görürler. Bir OLAP küpü, hazır bir rapordan daha hızlı yanıt süresi sağlayabilir, ancak çoğu durumda fark önemsizdir. Ayrıca, detaya gitme yeteneklerinden de yararlanabilirsiniz, ancak son kullanıcılara detaya gitme yetenekleri sağlamadan önce, benzer bir geçici arabirim sağlayan hazır raporları kullanmak iyi bir fikirdir.

Bu, son kullanıcıların çalıştırdığı geçici sorguları kaydetmenize olanak tanır, ardından son kullanıcıların oluşturulabileceğini fark etmedikleri yeni hazır raporları belirleyebilirsiniz. Bir OLAP küpü geliştirirken hem yanıt süresi hem de detaya inme iyileştirmeleri genellikle minimum düzeyde olduğundan, ilgili veri madenciliğini işleyebilecek bir veritabanı mimarisine ihtiyaç duyana kadar bir müşteriye önermek gerekli değildir. Bu, müşterilerinizi gerçekten etkileyebileceğiniz ve işleriyle ilgili sağlam bir veritabanı mimarisi olmadan asla bilmeyecekleri bir şey gösterebileceğiniz zamandır.

Daha önce de belirtildiği gibi, bir OLAP küpü oluşturmak zor olabilir. Hibrit bir OLAP küpü düşünmek iyi bir politikadır. Microsoft Excel'in PowerPivot'u, tam gelişmiş bir OLAP küpünün karmaşıklığı olmadan kullanımı kolay veri madenciliği araçları sağlar. Bir hibritin ana dezavantajı, aynı tepki süresine sahip olmamasıdır. Ancak büyük bir avantaj, MDX kullanmaya kıyasla Excel kullanarak veri madenciliği raporları oluşturmanın daha kolay olmasıdır. Veri madenciliği yaparken, faydalı olan üç rapor vardır. Bazı gerçek dünya örneklerine ve bunların nasıl yorumlanacağına bakabiliriz.

Bu raporların tümü, yazar tarafından oluşturulan otomatik bir günlük işlem uygulamasından alınmıştır.

Görsel Raporlama

Dağılım Grafiği Raporu

Dağılım grafiği raporu, iki değişkeni karşılaştıran ayrıntı düzeyinde bir rapordur. Gerçek noktalara renk ve boyut eklemek, bu değişkenlerle ilgili gerçek sonuçların görselleştirilmesine yardımcı olur.

Kutu ve Bıyık Raporu

Bu rapor, dağılım grafiği raporundaki x ve y değerlerini özetler. X ekseni değerleri bir dizi grup halinde ayrıklaştırılır.

Her bir çizginin (çizginin) uçları aykırı değerleri temsil eder. Sarı ve açık mavi çubuklar, üst ve alt bir standart sapma aralıklarını temsil eder.

Doğrusal Regresyon Modeli

Bu rapor, matematiksel bir formülle temsil edilebilen çizginin yumuşatılmasıyla birlikte x ve y ekseni değerleri arasındaki korelasyonu gösterir. R kare değeri, korelasyonun ne kadar güvenilir olduğunu göstermek için dahil edilmiştir.

Çözüm

Şirketiniz büyüdükçe, genellikle veritabanınız da büyür.

Çoğu kuruluş, başlangıçta ihtiyaçlarını karşılayan bir veritabanı uzmanına veya özel veri bilimi şirketine ihtiyaç duymaz. Bunun yerine, BT personelinin birden fazla sorumluluğu üstlenmesini sağlarlar veya deyim yerindeyse “birçok şapka takarlar”. Bu belirli bir noktaya kadar işe yarar, ancak sonunda uzmanları getirmeniz gerekir.

Bu belgede listelenen öğeler, farkında olmayabileceğiniz veritabanı sorunlarını belirlemenin hızlı ve kolay bir yoludur. Umarım, pahalı yazılım lisanslarına çok fazla harcamadan birinci sınıf veri madenciliği araçlarını nasıl oluşturabileceğinizi de kapsar. Bu şekilde, BT ekibinize bir veritabanı uzmanı ekleyerek kuruluşunuzun ne kadar fayda sağlayabileceği konusunda daha iyi bir fikir edineceksiniz.