Hiyerarşiler – Nimet mi Felaket mi? – veritabanimimari.com

Bu, geçen çeyreğin devamı olan “Bir Adım İleri: Kategoriler – Nimet mi Felaket mi?.”

“Çekiç için her şey çiviye benzer” diyen eski bir klişe vardır. Bunun veriler ve onu nasıl gördüğümüz konusunda çok doğru olduğunu düşünüyorum. Paradigmamıza ve veri dünya görüşümüze alıştığımızda kalıplarımızın dışına çıkıp verilere farklı bir şekilde bakmak zordur. Ancak verilerin ayrıntılarını araştırdığımızda düşüncemizin sınırlarıyla karşı karşıya kalabiliriz ve eğer dikkatli olmazsak sınırları görmezden gelip yolumuza devam ederiz. Bu yazımda paradigma uyumsuzluklarıyla nasıl başa çıkacağımıza ve çözüm önereceğimize biraz daha yakından bakacağım. Birden fazla paradigma barış içinde bir arada var olabilir mi?

Verileri kategorilere ayırmada en az sevdiğim konulardan biri hiyerarşi kavramıdır. Gerçekten bir bakış açısını temsil ediyor. Hiyerarşi ve ilişkiler arasındaki çatışma, birkaç yıl önceki nesne/ilişkisel veri tabanı tartışmasında görülebilir. İlişkisel, veri modelleyicinin paradigmasıydı ve nesne yönelimli ise geliştiricinin paradigmasıydı. Verileri görüntülemenin iki yolu çatıştı: Nesneler tablo/varlık değildir. Nesneler doğası gereği hiyerarşiktir ve ilişkisel teoride hiyerarşiyi temsil etmenin iyi bir yolu yoktur. İlginç olan şu ki, ilişkisel teori, değiştirilmesi son derece zor olan hiyerarşik veritabanlarına karşı bir isyandan doğmuştur. Bir özellik eklemek isterseniz tüm yapıyı yeniden tasarlamanız gerekir.

Sorun nedir? Hiyerarşilerde, iki varlığı hiyerarşi dışında herhangi bir şekilde ilişkilendirmenin yolu yoktur. İlişkisel olarak hiyerarşiyi uygulamanın güzel bir yolu yoktur. Grafikler veya ontoloji ile bu ikisinin bir arada var olabilmesinin bir yolu var, ancak bu başka bir sütunun başka bir tartışması. Bu sütunda hiyerarşilerle birlikte ortaya çıkan birkaç zorluğa ve dikkat edilmesi gereken hususlara bakacağız.

Hiyerarşiler Ne İşe Yarar?

Hiyerarşiler, organizasyon şemaları, ürün grupları ve web sitesi tasarımları gibi her türlü kategori yapısında kendini gösterir. Hiyerarşiler genellikle nitelik değerlerinin ebeveynden çocuklara aktarılmasını sağlayan kalıtımı ima eder. Ürün hiyerarşisi buna iyi bir örnektir. Bir ana kategori, tekerlek sayısı özelliğinin değerini 4 olarak belirtebilir ve bu ana kategori içindeki tüm alt kategorilerin tümü aynı sayıda tekerlek içerir.

Muhasebe, çeşitli maliyetleri ayrıştırmak için bu tür bir yapıyı kullanır. Bir mağaza çeşitli departmanlarda ne kadar satıldığını sorabilir: Ev eşyaları mı? Bayan giyimi? Makyaj ve Güzellik? Vb. Bir zamanlar veri ambarı tasarlayanlarımız bunu çok iyi hatırlıyor. Bölümleriniz ve ardından alt bölümleriniz olabilir. Ev Eşyaları’nda pişirme gereçleri satışlarının ne kadarını temsil ediyordu? Bu tür bir analiz, stokları ve mağaza raf tasarımını belirleyen satış tahminleri açısından kritik öneme sahipti.

Ne Zaman Dikkatli Olmalı?

Hiyerarşiler aynı zamanda web sitesi tasarımı ve bilgi yönetimi için de kullanılır. Web siteleri genellikle sınıflandırmaları omurgaları olarak kullanır. Taksonomi, hiyerarşiyi dayatan bir sınıflandırma sistemidir. Yaygın bir örnek organizmaların sınıflandırmasıdır.

Ancak iki farklı hiyerarşi türü vardır: Özel ve Kapsayıcı. Ayrıcalıklı hiyerarşi, tek bir öğenin yalnızca bir üst öğeye ait olabileceği anlamına gelir. Kapsayıcı hiyerarşi, tek bir öğenin birden fazla üst öğeye ait olabileceği anlamına gelir. Nesne yönelimli kişiler “çoklu kalıtım”dan söz eder ve bu durum zorluklara neden olabilir; bazı nesne yönelimli sistemler buna izin vermez.

İşte nasıl dağınık olabileceği.

Web sitesinin bir kadın giyim markasına ait olduğunu varsayalım. Şirket üstler, elbiseler, etekler ve pantolonlar satıyor. Alt kategorilere ayrılan alt kategoriler de vardır; örneğin pantolonlar şort, kapri ve pantolon (uzun pantolon) olarak alt bölümlere ayrılabilir ve etekler uzunluğa göre sınıflandırılabilir: mini, midi ve tam boy.

Peki “skortlarla” ne yaparsınız? Skortlar eteğe benzeyen şortlardır. Her ikisi de olarak sınıflandırılabilirler.

Taksonomi tasarımcısı her zaman şunu sormalıdır: “Hiyerarşinin amacı nedir?” Web sitesi tarayıcısına yardımcı olmak ve bir öğenin bulunabilirliğini en üst düzeye çıkarmaksa, öğenin sitede maksimum sayıda yerde bulunmasına izin vermek istersiniz. Ancak satışları toplayıp departman başına toplam satışları sunmak gerekirse, skort satışlarının iki kez sayılması olasılığı vardır: biri etek, diğeri şort olarak. Bu, her bir öğeyi tek ve yalnızca bir kategoride sayan Özel hiyerarşileri kullanmanız gerektiği anlamına gelir.

Geçen çeyreğin sütununda kağıtların sınıflandırılması ikilemi tartışıldı: Bu fiziksel bir gerçeklik olduğundan, her kağıt yalnızca tek bir klasörde bulunabilir. Birden fazla kategoride görünebilen ürünlerin satışlarının sayılması durumu da benzer bir konudur. Ne yapıyorsun? Çözümün kağıt dosyalama sorununun tam tersi olduğunu düşünüyorum. Kağıt söz konusu olduğunda çözüm genellikle özetlemektir: Daha genel bir kategori oluşturun ve kağıtları bu şekilde saklayın. Ürün muhasebesinde çözüm muhtemelen alternatiftir: Özetleyin ve daha ayrıntılı kategoriler oluşturun. Örneğin, çoğu giyim mağazasında “üstler” ve “altlar” bulunur; ikincisi pantolon, şort, etek ve iç etek olarak ayrılır; iç etekler ise kendi kategorileridir. Ancak, skortların bulunmasını isteyeceğiniz web sitesinde bulunabilirlik ikisi birden şort ve eteklerin yanı sıra kendi şortt kategorisi de bulunmaktadır.

Bu hiyerarşi sorunu birçok veri ambarında ortaya çıkıyordu. Kategorileri tasarlarken ve hiyerarşik bir yapı kullanırken kapsayıcı ve dışlayıcı hiyerarşiyi belirttiğinizden emin olmalısınız.

Hiyerarşileri özellikle önemsememin birçok nedeninden biri de bu. Diğer bir neden ise hiyerarşiye tam olarak uymayan çok fazla veri olmasıdır. Şunu söylemeyi seviyorum: “Her şey bir hiyerarşi değildir!” Bu yüzden grafikleri seviyorum. Belki grafiklerin bu soruna neden yardımcı olduğuna dair başka bir makale yazmaya ikna edilebilirim!


©2024 MITRE Şirketi. HER HAKKI SAKLIDIR. Kamuya Açıklanması Onaylandı; Sınırsız Dağıtım. Kamuya Açıklanan Vaka Numarası 23-01095-5.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir