İlişkisel Veritabanları – Ödev Hazırlatma – Proje Yaptırma – Tez Yaptırma Fiyatları – Sunum Örnekleri – Ücretli Ödev Yaptırma – Ödev Yaptırma Ücretleri
İlişkisel Veritabanlarında Hiyerarşileri ve Taksonomileri Yönetme
Kavram hiyerarşilerine dayanan sınıflandırma ve erişim mekanizmalarını sürdürme ihtiyacı, dilin kendisi kadar eskidir. Bilinen örnekler arasında kütüphanelerde kullanılan Dewey ondalık sınıflandırma sistemi ve 1700’lerde Carolus Linnaeus tarafından geliştirilen yaşam formlarını sınıflandırma sistemi yer alır. Daha yeni bir örnek, Yahoo’nun konu sınıflandırmasıdır.
Bilgi teknolojisi, dijital belgelerde, kayıtlarda, çoklu ortam dosyalarında ve Web sitelerinde patlayıcı bir büyümeye yol açmıştır. Bu kaynaklara son kullanıcı erişimini kolaylaştırmak için, belirli kategorilerle ilgili kaynakları sezgisel gezinmeye ve aramaya izin vermek için konu hiyerarşileri sıklıkla korunur.
İlişkisel veritabanlarında bu tür belge, Web sitesi ve bilgi sınıflandırmalarının sürdürülmesi önemsiz değildir, çünkü ilişkisel veri tabanlarında herhangi bir hiyerarşik verinin yönetimi önemli zorluklar doğurur. Taksonomiler, tek bir belgeyi, kavramı veya Web sitesini birden çok konu altında sınıflandırmaya yönelik tipik ihtiyaç ve tipik olarak akıllı anahtarlara güvenme nedeniyle ek bir zorluk teşkil eder.
Bazı görüşlere göre, ilişkisel olmayan veri tabanı teknolojileri ve dinamik sınıflandırma şemaları hedeflerimize ulaşmak için daha iyi yollar sunabilirken, ilişkisel veri tabanı teknolojisi ve kavram sınıflandırmalarının kullanımı çağdaş bir uygulama ve zorluk olmaya devam etmektedir.
Her belgenin gösterilen bir konu hiyerarşisine göre sınıflandırıldığı bir belge veritabanı düşünün. Her belge birden fazla ana konuya ait olabileceğinden, her bir konu kaydında onun üstündeki konuyu belirterek bu hiyerarşi için verileri kaydedemeyiz.
Bu durum için bir veri modeli gösterir. Sınıflandırma tablosunun birden çok konuya tek bir belge atamamıza izin verdiğini unutmayın. Bir konu hiyerarşisi yerine, her bir alt konuyu birden fazla ana konuya atamamız gerekirse, bu tür taksonomileri temsil etmek için bir konu atama tablosu ekleriz.
Normalleştirilmiş veri modeline göre hiyerarşik veri alımının zorluğunu göstermek için aşağıdaki istekleri göz önünde bulundurun:
- Konu 1 altında tüm belgelerin (tüm seviyelerde) bir listesini gösterin.
- Hiyerarşinin 1. seviyesinde her bir konu altında kaç belgenin (tüm seviyelerde) sınıflandırıldığını gösterin.
SQL kullanarak, sınıflandırma kayıtları aracılığıyla her konuyu kendisiyle ilişkili tüm belgelere kolayca birleştirebiliriz. Ancak, bir konu ile dolaylı olarak ilişkilendirilen dokümanları, onun alt konuları üzerinden (her düzeyde) kolaylıkla tespit edemeyiz. Herhangi bir düzeyde üst veya alt düğümleri bulmadaki bu zorluk, sorunun merkezinde yer alır.
SQL TABANLI ÇÖZÜMLER
Aşağıdaki tüm alt konular da dahil olmak üzere her bir ana konuya kaç belgenin ait olduğunu gösteren bir istek, gösterilen SQL:1999 sorgusu kullanılarak işlenebilir. Bu sorgu, tüm ana konularla doldurulmuş bir tablo ifadesi oluşturarak başlar.
Konu, kendilerinin ebeveyni olarak kaydeder ve bu düğümlerden doğrudan altındaki konulara bir uzunluktaki tüm yollar için (UNION) kayıtları ekler. RECURSIVE seçeneği, her konudan tüm alt öğelerine kadar tüm dolaylı yolları oluşturma sürecini sürdürür.
Sorgu daha sonra TOPIC_PATHS sonuç kümesindeki tüm yolların bitiş noktalarını (Topic_Below) bu konulara atanan belgelerle birleştirir. Bu yolların başlangıç noktalarını ana konularla (1. seviyedeki konular) sınırlandırarak ve sonuçları bu konulara göre gruplayarak istenen bilgileri elde ederiz.
İlişkisel veritabanı örnekleri
NoSQL veritabanı örnekleri
Veritabanı Türleri
İlişkisel veritabanı yönetim Sistemleri
İlişkisel veritabanı Nedir
İlişkisel veritabanı SQL
Veritabanı Nedir
Oracle veritabanı
Birden çok konuya atanmış belgelerin geçersiz sayılması, Count(Classify.Doc_ID) yerine DistinctCount(Classify.Doc_ID) kullanılarak elde edilir.
Bu kadar karmaşık SQL’e güvenmek, muhtemelen birçok BT uzmanının erişiminin ötesindedir. Bu, bu SQL ifadelerinin karmaşık kısımlarının veritabanı görünümleri olarak uygulanmasıyla çözülebilir. Ancak, birinin bu görünümler için SQL yazması gerekir ve gerekli işlemenin yoğun yapısı, büyük hiyerarşileri ve sık sorguları olan raporlama uygulamalarında performansın düşmesine neden olabilir.
Celko, hiyerarşi verilerini ebeveyn-çocuk ilişkileri olarak değil, biraz karmaşık bir numaralandırma şeması kullanarak “iç içe kümeler” olarak depolayarak sorgu hızlarında önemli gelişmelere yol açan bir teknik hakkında rapor veriyor. Ancak alternatif yaklaşımlar, sezgisel veri depolama ve SQL sözdizimini korurken çok önemli sorgu performansı kazanımları sağlayabilir.
YOL TABLOSU YAKLAŞIMI
Yol tablosu yaklaşımı, kendisi de dahil olmak üzere, her bir düğümden başlayarak üstündeki daldaki tüm düğümlere kadar tüm yolları numaralandıran kayıtları içeren bir “gezinme köprüsü tablosu” kullanır. Bu yaklaşım, her bir alt konu düğümünün birden çok doğrudan ana konuya ait olabileceği ve sınıflandırmadaki düzey sayısında bir sınırlama olmadığı anlamında esneklik sağlar.
Gösterildiği gibi, konu 1.1.1, yol tablosunda kendisine giden yolları, konu 1.1’i, konu 1’i ve konu 0’ı (hiyerarşinin en üst düğümü) yansıtan dört kayıt gerektirir. Bunlar, örnek hiyerarşi için tüm yolları yakalamak için gereken 37 kayıttan sadece 4’üdür.
Yol tablosunun veri alımını nasıl basitleştirebileceğini göstermek için, altındaki tüm alt konular dahil olmak üzere her bir ana konuya kaç belgenin ait olduğunu gösterme konusundaki aynı zorluğu düşünün.
Tabloları gösterildiği gibi birleştirerek her bir ana konunun altındaki konulara ait tüm dokümanları kolaylıkla seçebiliyoruz. Yol tablosu, her konu ile kendisi arasında sıfır uzunlukta bir yol içerdiğinden, doğrudan bir ana konuya ait belgeler sonuç kümesine dahil edilecektir. Yine sınıflandırma tablosu, aynı belgeyi birden çok konu ile ilişkilendirmemizi sağlar.
Diğer bilgi talepleri, yol tablosundaki Konu_Kimliği sütunu aracılığıyla konu tablosuna bağlanma veya yol tablosuna yol uzunluğu ve terminal düğüm bilgilerini ekleme gibi aynı yaklaşımı veya varyasyonları kullanabilir.
Yol tablosu yaklaşımının bir sınırlaması, yol tablosundaki kayıt sayısının derin hiyerarşiler için oldukça fazla büyüyebilmesidir. Aşağıdaki bölüm, bu sorunu önleyen başka bir yaklaşımı açıklamaktadır.
DENORMALİZE KONU TABLOSU YAKLAŞIMI
Normalleştirilmemiş konu tablosu yaklaşımı, her bir konu kaydındaki tüm üst düzey konular hakkında bilgi tutar. Sınıflandırma tablosu yine de her belgenin birden çok konuya atanmasına izin verir, ancak bu yaklaşım konu sınıflandırmasını her alt konunun yalnızca bir doğrudan ana konuya sahip olabileceği katı bir hiyerarşiyle sınırlar.
Gösterildiği gibi, konu hiyerarşimizin altı seviyeyi geçmeyeceğini varsayarsak, bu bilgiyi korumak için altı sütuna daha ihtiyacımız var. Her düğüm, kendi düzeyinde kendi ebeveyni olarak belirtilecektir.
Normalleştirilmemiş konu tablosunun veri alımını nasıl basitleştirebileceğini göstermek için, altındaki tüm alt konular dahil olmak üzere her bir ana konuya kaç belgenin ait olduğunu gösterme zorluğunu tekrar düşünün.
Tabloları gösterildiği gibi birleştirerek tüm konuları Topic_Level_2’ye göre kolayca seçip gruplayabiliriz. Doğrudan o konu altında sınıflandırılan belgeler, her bir konu kendi seviyesinde kendi ebeveyni olduğu için sonuç kümesine dahil edilecektir. Bu yaklaşımı kullanarak, basit bir SQL ifadesinin istenen bilgileri üretebileceğini göstermektedir.
İlişkisel Veritabanı Nedir İlişkisel veritabanı örnekleri İlişkisel veritabanı SQL İlişkisel veritabanı yönetim sistemleri NoSQL veritabanı örnekleri Oracle veritabanı Veritabanı Nedir Veritabanı Türleri