Hiyerarşik Veriyi Görselleştirmenin Yolları ve Sınırları

Hiyerarşik veri, kayıtların birbirine eşit ilişkiyle değil kapsayıcılıkla bağlandığı bir yapıdır: dosya sistemi, organizasyon şeması, ürün kategorileri. Aynı ağacı ekranda göstermenin birden çok yolu var, ama hepsi aynı büyüklükte okunur kalmıyor. Ayırt edici soru yöntemin adı değil ölçek: ağaç kaç düğüme çıktığında hangi gösterim çöküyor.

Kök, çocuk, yaprak

Yapının sözlüğü küçük. En üstte tek bir kök var. Kökün altındaki her düğüm bir ebeveyne bağlıdır ve kendisi de başka düğümlerin ebeveyni olabilir; altında hiçbir şey kalmayanlara yaprak denir. Aynı ebeveyni paylaşan düğümler kardeştir. Bir düğümün kökten kaç adım uzakta olduğu ise derinliğidir, ve aşağıdaki her hesap bu iki sayıya, dallanma miktarına ve derinliğe dayanıyor.

Ağaç diyagramı nerede kırılıyor

Kutuların çizgilerle bağlandığı klasik gösterim, ilişkiyi en doğrudan anlatan biçim. Kimin kime bağlı olduğunu tek bakışta okursunuz. Sorun, yatay alanın derinlikle birlikte doğrusal değil üstel büyümesi.

Her yöneticinin sekiz doğrudan raporu olduğu bir şirketi düşünün. Kökten üç seviye aşağıda 8³, yani 512 düğüm olur. Bunları yan yana dizmek, kutu başına iyimser bir tahminle 60 piksel verseniz bile 30 bin pikselden geniş bir tuval ister. Ekran o kadar geniş değil, o yüzden ya yatay kaydırma ya da katlama gelir. Katlama gelince de diyagramın tek gerçek üstünlüğü, bütünü aynı anda görmek, ortadan kalkar.

Pratik sınır şu: iki, en fazla üç seviyeye kadar ağaç diyagramı en iyi seçenek. Ötesinde başka bir şey lazım.

Treemap ve alan algısı

Treemap, her alt kümeyi iç içe dikdörtgenlere çevirir; kutunun alanı o düğümün büyüklüğüyle orantılıdır. Ekranın tamamını kullandığı için binlerce yaprağı tek görüntüye sığdırabilir. Disk doluluğunu gösteren araçların yıllardır bu biçimi kullanmasının sebebi bu.

Karşılığında bir şey kaybedersiniz. İnsan gözü alanları, uzunlukları karşılaştırdığı hassasiyetle karşılaştıramaz. İki kutudan hangisinin büyük olduğunu görürsünüz, ama "iki katı mı, bir buçuk katı mı" sorusuna treemap iyi cevap vermez. Dikdörtgenler inceldikçe iş daha da zorlaşır: uzun ve dar bir kutuyla kareye yakın bir kutuyu gözle eşitlemek neredeyse imkânsızdır. Squarified yerleşim algoritmaları tam bu yüzden var, kutuların en-boy oranını 1'e yaklaştırmayı hedeflerler.

Yani treemap büyüklük sıralaması ve aykırı değer avı için iyi, kesin oran okuması için değil. Kullanıcının sayıyı bilmesi gerekiyorsa kutunun üstüne sayıyı yazın.

Üç boyutlu gösterimler

Konik ağaç, düğümleri derinlik ekseninde koni biçiminde dizerek daha çok veriyi aynı ekrana sığdırma fikri. Kâğıt üzerinde makul görünüyor. Uygulamada arkadaki düğümler öndekilerin arkasında kalıyor ve yapıyı okumak için modeli döndürmek gerekiyor.

Konik ağacı gerçek bir yönetim ekranına koymam. Döndürme etkileşimi olmadan yarısı görünmüyor, döndürmeyle birlikte de kullanıcı veriyi okumak yerine kamerayı sürüyor. Bitkisel ağaç diyagramları da benzer yerde duruyor: sunum görseli olarak etkileyici, günlük kullanılan bir arayüz bileşeni olarak değil.

Ağacı ekrana getirmeden önce veritabanından çıkarmak

Görselleştirme yazılarında atlanan kısım burası. Ekranda ne çizeceğinize karar vermeden önce, bütün alt ağacı tek seferde alabiliyor olmanız gerekiyor.

En yaygın şema, her satırda bir parent_id tutan komşuluk listesidir. Yazması kolay, okuması pahalı: bir düğümün bütün torunlarını bulmak için ya özyinelemeli sorgu yazarsınız ya da her seviye için ayrı sorgu atarsınız. İkincisi, klasik N+1'in ağaç hali. 500 düğümlük bir kategori ağacını çizmek için 500 sorgu atan bir sayfa, tek başına veritabanını meşgul eder.

İki alternatif işi kolaylaştırıyor. Materialized path yaklaşımında her satır kökten kendisine kadar olan yolu bir metin alanında taşır (1/14/37/ gibi); alt ağacın tamamı tek bir prefix sorgusuyla gelir. Nested set ise her düğüme sol ve sağ sayı verir, alt ağaç bu iki sayı arasındaki aralıktır; okuması çok hızlı, ama araya düğüm eklerken sonraki bütün satırların sayılarını güncellemek gerekir.

Seçim erişim desenine bakar. Kategori ağacı gibi nadiren değişip sık okunan yapılarda materialized path rahat çalışır. Sürekli düğüm eklenen bir yapıda komşuluk listesi ve özyinelemeli sorgu daha az baş ağrıtır.

Hangi durumda hangisi

Az sayıda düğüm ve ilişkinin kendisi önemliyse ağaç diyagramı. Çok sayıda yaprak ve büyüklük karşılaştırması varsa treemap. Kullanıcı asıl olarak tek bir dalda geziniyorsa, hiçbir diyagram klasik açılır klasör listesini yenmiyor; dosya yöneticilerinin kırk yıldır aynı bileşeni kullanması tesadüf değil.

Bir de görselleştirmeye hiç ihtiyaç olmayan durum var. Kullanıcının sorusu "bu ağaçta X nerede" ise, cevap arama kutusudur. Hiyerarşiyi çizmek, sorunun "bu yapı nasıl duruyor" olduğu yerlerde işe yarar.