Aile Ağacı Verileri

Aile Ağacı Verileri

Aile Ağacı hakkında bazı gözlemler aşağıda verilmiştir ve bunlardan bazıları, yinelemeye ihtiyaç duyduğumuz yerle ilgili kararlarınızı etkileyecektir:

■■ Gayrimenkul, Veri Öğesi Soy Ağacında çok değerli olduğundan, metnin bir sonraki satıra kaydırılarak okunmasını zorlaştırdığı zamanlar olacaktır. Örneğin, hedef taraftaki ad sütununun altındaki CUST_REF_DB_ID gibi bazı adlara bakın. Bu veri öğesi birkaç satıra yayılarak okumayı zorlaştırır. Okunabilirliği en üst düzeye çıkarmak için sütun uzunluğu ve yazı boyutuyla oynayın.

■■ Kaynak ve hedef için ayrı bir ad sütununun değerini not edin. Müşteri Referans Veritabanındaki kaynak adları, kurumsal olmayan standart adlar gibi görünüyor. Bu nedenle, hem F-NAME veri öğesi adını kaynaktan hem de CUST_FRST_NAM standart adını hedeften yakalayabiliyoruz. Aynısı müşteri tanımlayıcı için de geçerlidir.

Müşteri Referans Veritabanı, yalnızca müşteri tanımlayıcı kimliğini çağırır. Ancak hedef tarafında, bu tanımlayıcıyı data mart ortamımızdaki diğer tanımlayıcılardan ayırmamız gerekecek. Bu nedenle, uygulama adını bu veri öğesinin adına yerleştirdik. Not Müşteri Referans Veritabanından geldiğini ayırt etmek için hedef taraftaki tanımı da güncelledim.

■■ Ad sütunu yalnızca fiziksel veri öğesi adını içerir, bir iş veya mantıksal ad içermez. Ağaçlarınızda hem mantıksal hem de fiziksel adlara sahip olmak isteyebilirsiniz. En azından fiziksel isme ihtiyacınız var. Bu örnek için boşluk nedenlerinden dolayı fiziksel adı seçtim.

■■ Müşteri adı veri öğelerinde kaynak ve hedef arasında biçim farklılıkları vardır. Müşteri adı kaynak tarafında karakter(15), hedef tarafta karakter(20) olarak tanımlanır. Burası, data mart kullanıcılarına geri dönmem ve ilk ad veri öğesindeki 20 karakterlik uzunluğu sorgulamam gereken bir yerdir.

Hedef taraf kaynak taraftan daha büyük olduğu için değerler kesilmeyecektir. Ancak, çok büyük bir müşteri tablosuyla sonuçlanabilecek ve biçim tutarsızlığına neden olabilecek ek alan kaplıyoruz. Müşterinin soyadı daha çok bir sorundur. Kaynakta, hedef veri pazarından daha büyüktür.

Bir müşterinin soyadını 10 karaktere kadar kısaltıyor olabiliriz, bu da ciddi veri kalitesi sorunlarına ve kaynak uygulamaya kadar tutarsızlıklara neden olabilir. Örneğin, kaynak uygulama bize “Rumplestilstonshomaganon” soyadı değerini gönderirse, veri marketimiz yalnızca “Rumplestilstonshomaganon”u depolayabilir.

Herhangi bir tür kesmenin olacağı nadir bir durum olsa da, bunun olduğu zamanlar olacaktır. Bu nedenle, data mart kullanıcılarıyla bir sonraki toplantınızda bunu yüksek öncelikli bir öğe haline getirin.

■■ Ürün Kategorisi veri öğesi, kaynak uygulama tarafında boştur, ancak veri pazarı tarafında boş değildir. Kaynak tarafında neden boş? Bu bir gözden kaçırma mıydı? Gerçekten boş değerleri var mı, yoksa bu veri öğesi her zaman dolduruluyor, ancak kaynak uygulamada uygulanmıyor mu? Ürün Kategorisi gibi bir düzey veri öğesi, her zaman doldurulması gereken bir veri öğesi gibi görünmektedir.

Bu konuda kaynak uzmanlara geri dönmeniz gerekecek. Kaynak uygulamadan boş değerlerle karşılaşırsak, onu bir boş veri öğesi olarak tanımlamamız ve bu Aile Ağacını güncellememiz gerekir. Ayrıca Sorular sütununa, bu kadar önemli bir veri öğesinin neden boş olabileceğine dair bir soru eklemek isteyebiliriz.

■■ Ürünün bildirilebileceği farklı düzeylerle ilgili bir ürün sorusu vardır. Maxwell muhtemelen data mart iş kullanıcılarından biridir. Bu örnekteki data mart kullanıcılarının sınırlı deneyime sahip olduğunu, ancak Maxwell’in sorusunun yine de ele alınması gerektiğini unutmayın. Bu ek ürün seviyesini daha net anlamak için önce konuşmanız gerekecek. O zaman varlığını sorgulamak için kaynak sistem uzmanlarına gitmeniz gerekecektir.

Soy ağacı Örnekleri
Ayrıntılı soy ağacı
Codeman soy ağacı isimleri
Codeman soy ağacı türkçe
Basit soy ağacı Örnekleri
t.c. ile soy ağacı sorgulama
Resimli soy ağacı Örnekleri
Soy Ağacı

■■ Sosyal Güvenlik Numarasının neden veri marketi tarafında bir gereklilik olarak listelenmediğini merak ediyorum. İlişkilendirme konu alanı şu anda veri ambarında mevcuttur ve bu nedenle bu veri öğesine zaten kolayca erişilebilir. Data mart belgelerine bakın veya data mart kullanıcılarına bu data öğesine ihtiyaçları olup olmadığını sorun. Kaynak sistem uzmanı Francis, bu veri öğesine veri pazarının ihtiyaç duyup duymadığına dair bir soru yazdı.

■■ Sipariş bilgisi altında, siparişin ton cinsinden ağırlığı, pound cinsinden kaynak uygulama veri öğesinin bölünmesiyle hesaplanan türetilmiş bir veri öğesidir. Tüm türetilmiş veri öğelerinin Veri Öğesi Aile Ağacında görünmesi gerektiğini unutmayın. Data mart kullanıcılarının ağırlığı ton olarak mı yoksa pound olarak mı görmeleri gerektiğini sorgularız.

Bir sonraki adım, bu Veri Öğesi Aile Ağacını ekiple birlikte gözden geçirmektir ve umarız bu incelemeyi, herkesin kaynak bilgileri üzerinde hemfikir olduğu ve tüm sorularınızın yanıtlandığı ve sorunların çözülmüş olduğu bir şekilde bırakırsınız. Bu incelemeye hem iş hem de kaynak sistem uzmanlarını dahil etmenin önemli olduğunu unutmayın.

Son gözden geçirmeyi bitirdiğimizde, tamamlanmış Data Element Aile Ağacınızı korumanız çok önemlidir. Bu belge, geri kalan veri öğesi analizi ve mantıksal veri modelleme için kaynak olacaktır. Ayrıca, muhtemelen gelecek birçok proje için değerli bir referans olacaktır. Bu bilgiler genellikle başka bir yerde saklanmadığından, burada tutulması önemlidir.

Veri Öğesi Matrisi Nedir?

Data Element Family Tree’nizi tamamladınız ve data mart’ınızın raporlama gereklilikleri hakkında daha fazla bilgi edinmek için can atıyorsunuz. Data Element Family Tree’de tanımlanan olguların her biri için raporlama düzeylerini belgelemek için net bir yola ihtiyacınız var.

Konu Alanı Tahıl Matrisini zaten tamamladınız ve bu nedenle, her konu alanı için raporlama düzeylerini iyi anlıyorsunuz. Şimdi ayrıntılara daha fazla girmeniz ve bu konu alanı analizini ve Veri Öğesi Tahıl Matrisini oluşturmak için Veri Öğesi Aile Ağacını kullanmanız gerekiyor.

Veri Öğesi Matrisi, her olgu veya ölçüm için raporlama düzeylerini yakalayan bir elektronik tablodur. Bir yıldız şeması tasarımının elektronik tablo görünümüdür. Hem iş kullanıcıları hem de proje ekibi, bu elektronik tabloyu kullanarak raporlama gereksinimlerini anlayabilir ve doğrulayabilir.

İş kullanıcıları raporların dilini konuşabilirken, teknik kişiler veri modellerinin veya yıldız şeması tasarımlarının dilini konuşabilir. Veri Öğesi Tahıl Matrisi, hem kullanıcıların hem de teknik kişilerin ilişki kurabilecekleri ve bir iletişim ortamı olarak kullanabilecekleri ortak bir zemin, bir elektronik tablodur. Bunun yalnızca veri pazarları gibi raporlama uygulamaları için olduğunu unutmayın. Bu e-tablo tamamlandığında, onu ilk yıldız şeması tasarımına dönüştürmek çok basit bir işlemdir.

akademi222 takımı

Biyografinin Tamamını Gör