Bunu çok duyuyoruz. Bunu çok akıllı insanlardan duyuyoruz. Geçen gün birisinin RDF’yi önceki şirketlerde iki kez denediğini ve ikisinde de başarısız olduğunu söylediğini duyduk. (RDF, Kaynak Açıklama Çerçevesi anlamına gelir,[1] birçok grafik veritabanının temelini oluşturan açık bir standarttır). Böyle birini tekrar denemesi gerektiğine ikna etmek zordur.
Bu nakarat, Neo4j kullanıcısı olan (LPG (Etiketli Özellik Grafiği) kampının önde gelen yarışmacısı) birinden gelmişti. Aynı şeyi üç kampın herhangi birinden duyuyoruz: ilişkisel kamp, JSON kampı ve yukarıda bahsedilen LPG kampı.
Her birinin bu RDF işinin çok zor olduğuna inanmak için farklı bir nedeni var. Aksiliklerle karşılaşanları RDF’ye bir şans daha vermeye ikna etmek de zordur. Bu makalede, kurumsal entegrasyon ve uygulama geliştirme bağlamındaki zorluklara ve güçlü yönlere ışık tutarak RDF’nin nüanslarını inceleyeceğim.
Pek çok problem için ilişkisel tabloların iki boyutlu dünyası çekicidir. Sütun başlıklarını öğrendikten sonra her şeye nasıl ulaşacağınızı hemen hemen bilirsiniz. Her masa için tam olarak tek bir form değil, ama bundan çok da uzak değil. Bazı satırların ek sütunlara sahip olması konusunda endişelenmenize gerek yok, bazı hücrelerin dizi olması veya ek derinliğe sahip olması konusunda endişelenmenize gerek yok. Her şey düz, iki boyutlu masalardan ibaret. Raporlamaların çoğu yalnızca birkaç katılım uzaktadır.
JSON biraz daha ilginç. Bir noktada veri kümenizin bir yapıya sahip olduğunu keşfedersiniz veya bunu oluşturup oluşturmadığınıza karar verirsiniz. İlişkiseldeki gibi iki boyutlu bir yapı değil, daha çok ağaç benzeri bir yapı. Daha spesifik olarak, bunun bir sözlük dizisi mi yoksa diziler sözlüğü mü olduğunu belirlemekle ilgilidir. Veya bir sözlük sözlüğü. Veya bir dizi dizi. Veya bu basit yapıların derinlemesine iç içe geçmiş herhangi bir kombinasyonu. Anahtarlar statik mi, yani kodlama sırasında özel olarak bilinebiliyor mu, yoksa dinamik olarak verinin kendisinden mi türetiliyorlar? Açıkçası bu karmaşık bir hal alabilir ama en azından yalnızca yerel olarak karmaşıktır. JSON programlamanın büyük bir kısmı, başka birinin yapısını, eldeki soruna uygun bir yapıya dönüştürmekle ilgilidir.
LPG’yi düşünmenin bir yolu, grafik veritabanının üstünde JSON’dur. JSON’un esnekliğinin yanı sıra grafik geçişleri ve grafik analitiğinin esnekliğine sahiptir. İlişkisel veya yalnızca JSON ile çözülmesi zor sorunları çözer ve kutudan çıktığı haliyle güzel grafiklere sahiptir. Belki eğitim tekerleği olarak LPG’ler hakkındaki blog yazınıza bağlantı verebilirsiniz?
Bu yaklaşımların her biri çok çeşitli sorunları çözebilir. Aslında neredeyse tüm uygulamalar, tükettikleri verileri yapılandırmak için bu üç yaklaşımdan birini kullanır.
Ve itiraf etmeliyim ki son zamanlarda çok etkileyici Neo4j uygulamaları gördüm. Arada bir kendimi sorguluyorum ve yüksek sesle Neo4j kullanmalı mıyız diye merak ediyorum. RDF çok zor olduğu için değil, bu konuda uzmanlaştığımız için ve istemci sitelerinde ve dahili olarak çalışan birçok başarılı uygulamaya sahiptir. Ama belki, eğer gerçekten daha kolaysa, değişmeliyiz. Ve belki de beklentilerimizle aynı fikirde olmamaya değmez.
Kurumsal Entegrasyon Zordur
Sonra aklıma geldi. Temel soru aslında “RDF vs LPG (veya JSON veya ilişkisel)” değil, “uygulama geliştirme vs. kurumsal entegrasyon”dur.
AllegroGraph’ın yaratıcıları Franz’ın CEO’su Jans Aasman’ın şu gözlemi defalarca yaptığını duydum: “Çoğu uygulama geliştiricisi, üzerinde çalıştıkları şeyin geri kalana nasıl uyacağını düşünmeye nöronlarının yaklaşık 0’ını ayırdı. RDF ile derinlemesine ilgilenen kişiler zihinsel döngülerinin yarısını, eldeki görev ve verilerin genel kurumsal modele nasıl uyduğunu düşünerek geçirebilirler.”
Bana göre meselenin özü budur. Kurumsal entegrasyonla ilgilenmiyorsanız, kurumsal entegrasyonun yarattığı rahatsızlıkları gideren özellikler, ilave zahmete değmeyebilir.
Kurumsal entegrasyonun doğası gereği zor olan yönlerine, RDF’nin neden bu iş için doğru araç olabileceğine ve geleneksel uygulama geliştirme için neden gereksiz olabileceğine bir göz atalım.
Karmaşıklığın Azaltılması
Kurumsal entegrasyonla ilgili en büyük sorunlardan biri karmaşıklıktır. Orta ve büyük ölçekli işletmelerin çoğu binlerce uygulamayı barındırır. Her uygulamada, uygulamayı kullanma ve/veya hata ayıklama ve genişletme konusunda yetkin olmak için öğrenilmesi gereken binlerce kavram (tablolar ve sütunlar veya sınıflar ve nitelikler veya formlar ve alanlar) bulunur. Hiçbir iki uygulama veri modeli birbirine benzemez. Aynı alandaki iki uygulama bile (örneğin, iki envanter sistemi) komik derecede farklı terimlere, yapılara ve hatta soyutlama düzeylerine sahip olacaktır.
Her uygulama, sıradan ölümlülerin çoğunun üstesinden gelebileceği karmaşıklık düzeyindedir. Tüm bu modellerin birleşimi bireylerin kavrayışının çok ötesindedir.
Kurumsal Kaynak Planlama uygulamaları ve Kurumsal Veri Modelleme projeleri, bir kuruluşun tüm verilerini modellemeye çalışmanın ne kadar karmaşık olabileceğine ışık tuttu. ERP sistemleri artık onbinlerce tabloya ve yüzbinlerce sütuna sahip. Kurumsal Veri Modelleme de aynı tuzağa düştü. Çoğu çaba, kullanımda olan tüm uygulama modellerinin birleşimini tanımlamaya çalıştı. Karmaşıklık onları kullanılamaz hale getirdi.
Noktasal çözümü çözmeye odaklanan çok az kişinin bildiği şey, her işletmenin merkezinde tek bir basit modelin olduğudur. Motivasyona sahip analistlerin ve geliştiricilerin sınırlı bir süre içinde bu konuya kafa yorabilmeleri yeterince basittir. Ve mevcut karmaşık şemalara kayıpsız bir şekilde eşlenebilir.
Bu basit modelleri ortaya koyma yeteneği, RDF (ve onun büyük kardeşleri OWL ve SHACL) tarafından sağlanmaktadır. RDF, basit veya anlaşılır bir model oluşturacağınızı garanti etmez (ortada pek çok karşı örnek vardır), ancak en azından sorunu çözümlenebilir hale getirir.
Konsept Paylaşımı
RDF tabanlı bir sistem çoğunlukla yapıdan bağımsızdır, dolayısıyla sistemler arasındaki yapısal farklılıklarla ilgilenmemize gerek yok ancak kavramları paylaşmanın bir yoluna ihtiyacımız var. “Çalışan”, “işçi”, “kullanıcı” ve “operatör” kelimelerinin aynı kavrama atıfta bulunduğunu bilmenin bir yolunu bulmamız gerekiyor. Veya eğer değilseler, hangi yönlerden örtüşüyorlar?
RDF tabanlı bir sistemde, tüm uygulama sistemlerinde kullanılan kavramları anlamak ve ardından kavramın hem anlamının hem de kimliğinin kuruluş genelinde kolayca paylaşılabileceği bir yol oluşturmak için çok zaman harcıyoruz. Mevcut uygulama şeması öğeleri ile paylaşılan kavramlar arasındaki haritanın da iyi bilindiğini ve bulunabileceğini.
Buna yardımcı olan mekanizmalardan biri, kavramların çözülebilecek genel tanımlayıcılara (URI’ler /IRI’ler) sahip olduğu fikridir. Hangi uygulamanın bir kavramı tanımladığını bilmenize gerek yok; alan adı (ve dolayısıyla kaynak yetkilisi) tanımlayıcının tam oradadır ve kavram hakkında bilinen her şeyi ortaya çıkarmak için bir URL’ye benzer şekilde kullanılabilir. Bu, kurumsal entegrasyonun önemli bir özelliğidir.
Örnek Düzeyinde Entegrasyon
Sadece kavramlar değil. Uygulama sistemlerinde adı geçen tüm örneklerin tanımlayıcıları vardır. Ancak çoğu zaman tanımlayıcılar yereldir. Yani “007” Gizli Ajan masasında James Bond’u, şirket kafeterya sisteminde ise “Jambonlu Sandviç”i ifade ediyor.
Sistemlerin onlarca yıldır kimlik takma adları oluşturduğu gerçeği, kurumsal düzeyde ele alınması gereken bir başka sorundur. Çözüm, geçmişte birçok kişinin yaptığı gibi, etkilenen binlerce sisteme bir “evrensel tanımlayıcı” sıkıştırmaya çalışmak değil. Bu çok fazla iş ve zaten bununla başa çıkamıyorlar. Ayrıca, sistemlerin oluşturulduğu dönemde öngörülemeyen (tedarikçilerimizden bazılarının müşteri haline geleceğini kim düşünebilirdi?) ve çözülmesi daha da zor olan pek çok kimlik sorunu mevcut.
Çözüm, kafa karışıklığı yaratmadan birden fazla tanımlayıcıyı barındırabilen esnek bir veri yapısıyla birleştirilmiş bir miktar varlık çözümlemesi içeriyor.
Veri Ambarı, Veri Gölü ve Veri Kataloğu hepsi bir arada
Kurumsal entegrasyon sorununu kısmen çözmek için son otuz yılda üç çözüm öne sürüldü: veri ambarları, göller ve kataloglar. Veri ambarları verilerin balkanlaştığını kabul etti. Bunu paylaşılan boyutlu bir modele uygun hale getirerek ve verileri aynı yerde konumlandırarak birleştirilmiş raporlama elde edebiliriz. Ancak veri ambarı pek çok açıdan eksikti: Kuruluşun verilerinin yalnızca bir kısmına sahipti, işlemsel güncellemelere izin vermeyecek şekilde yapılandırılmıştı ve tamamen onu besleyen eski sistemlere bağımlıydı. Üstelik çok fazla iş vardı.
Veri gölü yaklaşımı ortak yerleşimin iyi olduğunu söylüyor; her şeyi tek bir yere koyalım ve tüketicilerin halletmesine izin verelim. Hala çözmeye çalışıyorlar.
Son olarak, veri kataloğu yaklaşımı şunları söyledi: Verileri aynı yerde bulmaya çalışmayın, sadece bir katalog oluşturun, böylece tüketiciler ihtiyaç duyduklarında onu bulabilirler.
RDF modeli, üç yaklaşımın en iyilerini karıştırıp eşleştirmemize olanak tanır. Kurumsal verilerin bir kısmına uyum sağlayabiliriz (genellikle MDM ve benzeri gibi tüm varlık verilerinin yanı sıra bazı önemli işlem verilerini de öneririz). Bir R2RML veya RML stili haritasıyla birleştirilmiş bir RDF kataloğu, tüketicinin yalnızca ilgilenilen veri kümelerini bulmasına olanak sağlamakla kalmaz, çoğu durumda bunlara çekirdek grafikle aynı sorgu dilini kullanarak erişilebilir. Bu, yalnızca istisna temelinde erişilmesi gereken büyük miktarda verinin bulunduğu IoT gibi şeyler için harika bir çözüm haline geliyor.
Sorgu Federasyonu
Yukarıdaki paragrafta sorgu birleşiminden bahsetmiştik. Sorgu federasyonunun (RDF için tercih edilen sorgulama dili olan ve aynı zamanda federasyon protokolü olarak da görev yapan SPARQL’in) spesifikasyonuna yerleşik olması, verilerin sorgu zamanında farklı veritabanı örnekleri, farklı satıcılar ve farklı sağlayıcılar arasında birleştirilmesine olanak tanır. hatta farklı türdeki veritabanları bile (gerçek zamanlı haritalamayla ilişkisel ve belge veritabanları SPARQL sorgularıyla birleştirilebilir).
RDF’nin Aşırı Olabildiği Yerler
Kurumsal entegrasyona yardımcı olma yeteneğinin bir maliyeti vardır. Geçerli, çözülebilir tanımlayıcılara sahip olduğunuzdan emin olmak çok fazla iş gerektirir. Veri modelinizi başkasınınkiyle uyumlu hale getirmek de çok fazla iş gerektirir. Öncelikle grafiklerle düşünmek bir paradigma değişimidir. Şema-sonraki modellemenin esnekliğini öngörmek ve bununla uğraşmak çok fazla yük getirir. Açık dünya mantığının tuhaflıklarıyla uğraşmak büyük bir beyin kırıcıdır.
Kurumsal entegrasyonun karmaşıklığıyla uğraşmak zorunda değilseniz ve elinizdeki sorunu çözmekle meşgulseniz, RDF’nin ek karmaşıklığı size göre olmayabilir.
Ancak size az önce ücretsiz geçiş izni verdiğimi düşünmeden önce şunu düşünün: Çoğu BT mağazasındaki işlerin yarısı, bağımsız bir sorunu çözdüklerine inanan kişiler tarafından uygulanan verileri bir araya getirmektir.
Özet
Kurumsal entegrasyon sorununun, RDF tabanlı çözümlere uygun birçok yönü vardır. Kurumsal entegrasyon düzeyinde yardımcı olan özellikler, nokta çözüm düzeyinde gerçekten de yolunuza çıkabilir.
Ve evet, teorik olarak yukarıdaki sorunların her birine (ve daha fazlasına, menşei ve ayrıntılı yetkilendirme dahil) çözümlerini ilişkisel, JSON veya LPG’ye aşılamak mümkün olacaktır. Ancak bu çok fazla iş gerektiriyor ve bu kamplardaki geliştiricilerin çok zor bulduğu özelliklerin yeniden uygulanması anlamına geliyor.
Kurumsal entegrasyon sorunlarını çözmeye çalışıyorsanız, RDF’yi değerlendirmenizi önemle tavsiye ederiz. Bunu öğrenmek ve iyi bir şekilde uygulamak için biraz adım işlevi var, ancak bunun iş için doğru araç olduğunu düşünüyoruz.
[1] https://www.w3.org/TR/rdf11-concepts/
