Pareto prensibi, Vilfredo Pareto'nun İtalya'daki arazi mülkiyetiyle ilgili gözlemlerinden ortaya çıkmış ve daha sonra Joseph Juran'ın çalışmaları sayesinde kalite kontrol ve envanter yönetiminin temel taşlarından biri haline gelmiştir. İlişkisel veritabanlarında bu, analistlerin dışsal istatistiksel araçlara başvurmadan, iş değerinin çoğunluğunu yönlendiren kritik azınlığı tanımlamaları gereken ABC analizi ihtiyacına dönüşmektedir.
Problem, azalan sıralı bir metrik ile mutlak toplam arasındaki kesintisiz yüzde hesaplamayı, ardından %80 eşik değerinde kesmeyi gerektirir. Çünkü ANSI SQL, yinelemeli imleçler yerine küme üzerinde çalıştığı için, pencere fonksiyonları açıkladıkça uygulama mekanizmasını sağlar. Çözüm, tüm sonuç kümesi üzerinde sıraya göre düzenlenmiş bir kümülatif toplam kullanır, ardından aynı satır bağlamında genel toplamla bölerek, bir yüzde sıralaması sağlar.
Kritik olarak, çerçeve spesifikasyonu ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, row-by-row deterministik birikimi sağlar. Eğer sınır değerini paylaşan tüm kayıtların bir bütün olarak dahil edilmesi veya hariç tutulması gerekiyorsa, RANGE ROWS'ın yerini alır. Nihai filtreleme, pencere fonksiyonlarının WHERE ifadesinden sonra mantıksal olarak hesaplandığı için dış sorguda gerçekleştirilmelidir.
WITH ranked_products AS ( SELECT product_id, product_name, annual_revenue, SUM(annual_revenue) OVER ( ORDER BY annual_revenue DESC ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS cumulative_revenue, SUM(annual_revenue) OVER () AS total_revenue FROM inventory ), pareto_subset AS ( SELECT product_id, product_name, annual_revenue, CAST(cumulative_revenue AS DECIMAL) / total_revenue AS cumulative_pct FROM ranked_products ) SELECT product_id, product_name, annual_revenue, cumulative_pct FROM pareto_subset WHERE cumulative_pct <= 0.80;
Ulusal bir elektronik perakendeci, çeyrek envanter denetimleri sırasında artan maliyetlerle karşılaştı ve döngü sayımını önceliklendirmek için toplam depo sermayesinin (%80, 50 milyon $'lık 40.000 ürün) yüksek değerli SKU'larını izole etmeyi gerektirdi.
Çözüm 1: Elektronik Tablodan Çıkarma analistlerin CSV dosyalarını Excel'e aktararak birim maliyetine göre sıralayıp, eşiği aşana kadar manuel toplamalarını içeriyordu. Profesyoneller için sıfır geliştirme süresi gerektiriyordu. Ancak, büyük veri setlerinde uygulama çökmesi, saatlik yeniden hesaplama gereklilikleri ve depo yönetim sistemi ile gerçek zamanlı entegrasyonu engelleme gibi dezavantajlar vardı.
Çözüm 2: Uygulama Katmanı Hesaplama bir Python betiği kullanarak satırları akıtarak birikim sağladı. Avantajları esnek mantık ve kolay hata ayıklama sundu. Ancak, milyonlarca satırın iletiminde önemli bir ağ gecikmesi, tek iş parçacıklı yürütme, analitik kontrol panelini engelledi ve istemci makinedeki bellek kısıtlamaları gibi dezavantajları vardı.
Çözüm 3: ANSI SQL Set-Tabanlı Yaklaşım pencere fonksiyonu sorgusunu doğrudan PostgreSQL deposu içinde uyguladı. Avantajları milisaniye düzeyinde gecikme, veri hareketinin ortadan kaldırılması ve gece güncellemeleriyle otomatik yenileme içeriyordu. Ancak, bakım için ileri düzey SQL bilgisi gerektiriyordu.
Seçilen Çözüm ve Sonuç: Çözüm 3 bir görünüm olarak uygulandı ve yalnızca %12'nin, değerin %80'ini oluşturduğunu ortaya çıkardı. Denetim kapsamı %88 oranında azaltıldı ve böylece her çeyrek 340 iş saati tasarruf sağlandı ve malzeme değerinin tam kapsamı korundu.
Teyitli değerlerin bulunduğu durumlarda ROWS ve RANGE çerçeve spesifikasyonları arasındaki seçim, %80 eşik değerini nasıl etkiler?
RANGE, aynı ORDER BY değerlerine sahip eşit satırları tek bir grup olarak kabul eder; eğer %80 sınırı bir bağlılık içinde düşerse, RANGE tüm grubu içerir, bu da %80'i aşma riski taşır. ROWS, bağlamayı önemsemeksizin fiziksel ofsetler işler, bu da mantıksal bir iş birimini bölebilir. Adaylar genellikle ANSI SQL'nin bu davranışı açıkça ayarlamasına izin verdiğini kaçırır; mali raporlama için RANGE, tutarlı dönemlerin bölünmemesini sağlarken, ROWS eşsiz öğeler için daha ince ayrıntı sağlar.
Kümülatif yüzdelik hesaplamanın neden türetilmiş bir tabloda veya CTE'de yapılması gerekiyor, doğrudan WHERE ifadesinde değil?
Pencere fonksiyonları, satırları filtreleyen WHERE ifadesinden sonra gerçekleşen SELECT aşamasında mantıksal olarak değerlendirilir. cumulative_revenue / total_revenue <= 0.8 şeklinde direkt olarak WHERE'de filtreleme denemesi bir sözdizim hatası verir çünkü pencere sonucu henüz oluşturulmamıştır. Adaylar genellikle ANSI SQL'nin mantıksal işleme sırasını kavramakta zorluk çeker: FROM → WHERE → GROUP BY → HAVING → WINDOW → SELECT → ORDER BY. Çözüm, pencere fonksiyonunu bir iç sorguda hesaplamak ve ardından sonuç sütununu bir dış sorguda filtrelemek için iç içe geçmeyi gerektirir.
Eğer envanter tablosu milyarlarca satır içeriyorsa ve %80 alt kümesi çok küçükse, bu sorguyu nasıl optimize edersiniz?
Adaylar genellikle Top-N optimizasyon modelini gözden kaçırır. Tüm tabloda bir pencere fonksiyonu hesaplamak yerine, en önemli adayları sınırlamak için DENSE_RANK() veya NTILE() ile bir alt sorguda ön filtreleme yapılabilir. Alternatif olarak, eğer analiz kategoriye göre bölünmüşse, PARTITION BY kullanmak tam tablo taramalarını engelleyebilir. Pencere fonksiyonlarının bir sıralama işlemi zorunlu kıldığını ve gelir sütununda azalan şekilde indekslemenin sıralama maliyetini ortadan kaldırabileceğini anlamak kritik öneme sahiptir.