1. Konu Alanı Kontrol Listesinde tanımladığınız tüm konu alanlarını ayrı satırlar halinde de listeleyin.

2. Yeni uygulamanızı bu e-tablonun ilk sütunu olarak listeleyin. Uygulamanın her konu alanını nasıl etkilediğine göre, daha önce bahsettiğimiz anahtarı, yani C, R, U veya D’yi kullanarak hücreleri de doldurun.

Veri pazarları için her hücrede her zaman bir R olduğuna dikkat edin, çünkü veri pazarları yalnızca verileri okumalı ve yalnızca bu veri pazarı için Konu Alanı Kontrol Listesinde belirtilen konu alanları da dahil edilmelidir.

3. Ardından, konu alanlarından herhangi birini bir şekilde etkileyen tüm uygulamaları sütunlar halinde ekleyin. Bir data mart için, veri ambarını kesinlikle ayrı bir uygulama olarak ekleyin, çünkü bu, veri ambarından neleri yeniden kullanabileceğimizi belirlememize de yardımcı olabilir.

Öğe veya Müşteri uygulamaları gibi tüm referans veritabanlarının sütun olarak bulunduğundan emin olun. Geri kalan uygulamaları tanımlamayı yinelemeli bir görev olarak görüyorum. İlk önce iş uzmanlarından tavsiye isteyin veya varsa, ilk uygulama listesini almak için sistem mimarisi belgelerine de bakın.

Ardından, her bir konu alanı ve uygulama kesişimi için değerleri doldururken, bir konu alanı için C’ye sahip olmadığınızı keşfedebilirsiniz; bu nedenle, matrisinize, bu konu alanını oluşturmaktan sorumlu olan uygulama olan başka bir sütun eklemeniz gerekir. Bu yinelemeli yaklaşımın oldukça iyi çalıştığını da görüyoruz.

4. Bu matristeki hücrelerin her biri için değerleri C, R, U veya D kullanarak da doldurun.

5. Sonuçlarla ilgili herhangi bir gözlemde bulunun ve olası sorunları dile getirin. Potansiyel kaynak sistemlerini ve kaynak sistem sorunlarını belirlemek de dahil olmak üzere, konu alanlarımızda kaynak bulmamıza yardımcı olabilecek bazı gözlemler yapalım.

Bu erken noktada gözlemler yapmak, yanlış uygulamadan kaynak aldığımızı veya konu alanı düzeyinde yakalanmış olabilecek bir veri kaynağı sorununu çözmeye çalıştığımızı fark edersek daha sonra analiz ve geliştirme çalışmasını da kurtarabilir.

Veri ambarı örnekleri
Veri ambarı Nedir
Veri tabanı ve veri ambarı Arasındaki fark
Veri Ambarı Eğitimi
Veri ambarı modelleme
Veri marketi
Veri marketi nedir
Data Warehouse Nedir

Bu Konu Alanı Matrisi üzerinde yapabileceğimiz gözlemler şunları içerir:

Bu veri marketi muhtemelen Müşteri ve Ortak bilgilerini doğrudan veri ambarından alacaktır. Veri öğesi düzeyine geldiğimizde bunun için istisnalar bulabileceğimizi unutmayın. Örneğin, veri ambarında olmayan, ihtiyaç duyacağımız müşteri veri öğeleri de olabilir.

Ancak bu yüksek seviyede, müşteri bilgilerinin depoda olduğunu ve yeniden kullanılabileceğini varsaymamız gerekir. Hem Müşteri Referans Veritabanı hem de XYZ Uygulaması, müşteri bilgilerini oluşturuyor gibi de görünmektedir.

Bu, üç şeyden biri anlamına gelebilir: bu matrisi yanlış doldurduk, bu uygulamaların her biri Müşterinin farklı yönlerinden sorumludur veya bir kaynak bulma sorunumuz var. Bunlardan ilkiyse matrisi düzeltiriz ve işimiz biter. İkinci ise, her uygulama tarafından Müşteri’nin hangi bölümünün oluşturulduğuna bağlı olarak Müşteri’yi iki ayrı satıra ayırmamız da gerekir.

Örneğin, Müşteri Referans Veritabanı müşteri profil bilgisi oluşturabilirken, XYZ Uygulaması müşteri trendi bilgisi oluşturabilir. Bunların üçüncüsü ise bu kaynak bulma konusunu bir an önce yönetime iletmeliyiz. Bir kaynak bulma sorunu yaşarsak, bu uygulamalardan hangisinin veri ambarına bilgi beslediği de çok merak edilir.

Bilgileri daha önce hiç kimse bu şekilde görmediği için bir süredir gizlenen bir kaynak bulma sorununu yeni ortaya çıkarsaydık ilginç olmaz mıydı? Bunu ortaya çıkarırsanız zam alabilirsiniz.

Bu matris üzerinde ilgili konu alanında bilgi oluşturan bir uygulama bulunmamaktadır. Bu nedenle, ilişkilendirme bilgilerini oluşturan uygulamayı başka bir sütun olarak eklemeniz gerekebilecek bir örnektir.

Ancak, bu bir data mart olduğundan ve veri ambarı ilgili konu alanı bilgilerini zaten içerdiğinden, gerçek kaynağı bulmak istemeyebilirsiniz çünkü onu veri ambarından yeniden kullanacağız. İhtiyacımız olan tüm ortak bilgilerin depoda mevcut olacağı da umulmaktadır.

İlk konu alanı kaynağına sahibiz. Birazdan ele alacağımız bir veri aracında muhtemelen Müşteri ve Ortak bilgilerini veri ambarından ve kalem ve sipariş bilgilerini XYZ uygulamasından alacağımızı da belgeleyeceğiz.

Eski Bir Uygulamayı Değiştiren Paketlenmiş Operasyonel Yazılım

1. Konu Alanı Kontrol Listesinde tanımladığınız tüm konu alanlarını ayrı satırlar halinde listeleyin.

2. Yeni uygulamanızı bu e-tablonun ilk sütunu olarak listeleyin. Uygulamanın her konu alanını nasıl etkilediğine göre, daha önce bahsettiğimiz anahtarı, yani C, R, U veya D’yi kullanarak hücreleri doldurun.

3. Ardından, konu alanlarından herhangi birini bir şekilde etkileyen tüm uygulamaları sütunlar halinde ekleyin. Ye Eski Sipariş İşleme Sisteminin değiştirmek istediğimiz uygulama olduğunu unutmayın.

4. C, R, U veya D kullanarak bu matristeki hücrelerin her birinin değerlerini de girin.

5. Sonuçlarla ilgili herhangi bir gözlemde bulunun ve olası sorunları dile getirin. Potansiyel kaynak sistemleri ve kaynak sistem sorunlarını belirlemek de dahil olmak üzere konu alanlarımıza kaynak bulmamıza yardımcı olabilecek bazı gözlemler yapalım:

Yeni paket yazılım, doğrudan eski eski sistemin yerini almaz. İlişkili konu alanı, aynı zamanda ilişkili bilgi oluşturan XYZ uygulamasıyla gereksiz görünen eski sistem içinde de oluşturulur.

Bu, bu iki uygulamanın her ikisi de bilmeden ilişkili bilgiler oluşturuyor olabilir. Ayrıca, bu iki uygulamanın farklı ilişkili bilgi alanları oluşturduğu anlamına da gelebilir; bu durumda, paket yazılım ilişkili bilgi oluşturmadığından, bu paket yazılımdaki yeni işlevler eksik olabilir. Onay için eski ve yeni sipariş işleme sistemi arasındaki bu farkı da vurgularım.

Bu yeni paket yazılım, sipariş bilgilerinin tek yaratıcısı olacaktır. Eski sipariş işleme uygulaması kullanımdan kaldırıldıktan sonra, yenisi çok değerli olacaktır çünkü organizasyon içinde sipariş bilgilerinin tek yaratıcısı o olacaktır.

The post Yeni Bir Veri Pazarı first appeared on Ödev - Tez - Proje Hazırlatma Merkezi.

Yeni bir data mart girişiminde veri modelleyicisi olarak atandınız. Veri modelleyici olarak rolünüzde hangi etkinliklerin ve bunların hangi sırayla gerçekleştirilmesi gerektiğini görev elektronik tablosunu kullanarak zaten biliyorsunuz. Şimdi proje yöneticisine her görev için bir tahmin vermeniz gerekiyor. Size, projenin uygulama yoluyla analiz için tam 6 ay olan Nisan ayı sonuna kadar tamamlanması gerektiğini zaten söyledi.

Şimdiye kadarki proje anlayışınıza göre, bu proje için işletme ve teknik ekipten son derece deneyimli kişiler görevlendirilir. Ek olarak, geçmişte veri marketlerini modelleme konusunda deneyiminiz oldu.

Bu bilgilere dayanarak, Konu Alanı İşgücü Aralığına atıfta bulundunuz ve bu projeye atanan yüksek düzeyde uzmanlık nedeniyle, bu veri pazarının yeni bir veri pazarı için düşük çaba aralığında olması gerektiğine karar verdiniz. Bu nedenle, konu alanı başına 4 günün yeterli olduğunu tahmin ediyorsunuz.

Proje yöneticisinden, konu alanlarının sayısına ilişkin hızlı bir analiz yapması için 2 gün isteyin ve biri veri pazarı için, diğeri veri ambarı mimarisi için olmak üzere iki rakamla geri dönün. Veri pazarında beş konu alanı olacağına inanıyorsunuz. Bu nedenle, data mart veri modelleme çalışması yaklaşık 20 gün sürmelidir.

Ayrıca, bu yeni veri pazarını eklemenin, veri ambarı içinde yeni bir konu alanı oluşturmak ve iki konu alanını daha büyük ölçüde güncellemek anlamına geleceğine de inanıyorsunuz. Bu bize veri ambarı mimarisinde üç konu alanı verir.

Veri ambarında konu alanı başına kabaca 5 gün süreceğine inanıyorsunuz. Bu nedenle, veri ambarı mimarisi veri modelleme çalışması kabaca 15 gün sürmelidir. Görevlerin nasıl bölündüğünü gösterir.

Bu, data mart için bu görevlerin her biri için toplam süreyi gösterir. Şimdi veri ambarı mimarisinde geliştirmeleri yapalım.

Bu iki miktarı toplarsanız toplam 35 günlük emek elde edersiniz. Süre, bu görevlerin ne kadar sürdüğüne ve toplam süreyi azaltmak için üzerinde kaç kişinin çalışabileceğine ilişkin kendi deneyiminize bağlı olarak daha uzun veya daha kısa olabilir. Bunun size yardımcı olabilecek bir kılavuz veya araç olduğunu unutmayın. Projeler birçok farklı faktöre göre değişiklik göstermektedir.

Veri ambarı Nedir
Veri tabanı ve veri ambarı Arasındaki fark
Veri ambarı örnekleri
Veri ambarı mimarisi
Veri ambarı modelleme
Veri ambarı özellikleri
Veri ambarı nasıl oluşturulur
Veri Ambarı Eğitimi

Mevcut Bir Operasyonel Uygulamada Yapılan İyileştirmeler

Operasyonel bir uygulamada hızlı bir geliştirme yapmak için veri modelleyici olarak atandınız. Proje yöneticisi, bunun çok küçük bir değişiklik olduğunu garanti eder. Bununla birlikte, hangi konu alanlarının etkilendiğini görmek için hızlı bir analiz yaparsınız ve üç tane olduğunu görürsünüz.

Bu projenin bir smaç olmayacağına inanıyorsun. Aksine, tam tersi olacak ve tamamlanması önemli miktarda zaman alacaktır. Bu nedenle, efor için ölçeğin en üst noktasına gidiyorsunuz ve toplam 15 günlük efor için konu alanı başına 5 gün seçiyorsunuz. Tablo 4.18, çabanın görevlere nasıl ayrıldığını göstermektedir.

Bu bir sistem geliştirmesi olsa da, yine de önemli miktarda zaman alabildiğini görebilirsiniz. Bu toplam miktarın, bunun çok hızlı bir değişiklik olduğu izlenimine kapılan proje yöneticisine hızlı bir şekilde iletildiğinden emin olun.

Bu noktada, veri modelleme aşamalarını, görevleri, araçları ve zaman çizelgelerini tanımlayan dört araca odaklanmıştır:

■■ Veri Modelleme Aşaması Aracı
■■ Aşamadan Göreve ve Araçlara
■■ Öncelikler Üçgeni Aracı
■■ İyi Tahmin Tahmin Aracı

Her araç, veri modelleme proje planlama sürecini mümkün olduğunca zahmetsiz, hızlı ve doğru hale getirmek için tasarlanmıştır. Veri Modelleme Aşaması, veri modelleme adımlarını en üst düzeyde tanımlar. Veri modelleme teslimatlarını ayrıntılı proje planına uydurmak için çok iyi bir başlangıç noktasıdır.

Ardından, Aşamadan Göreve ve Araçlara, Veri Modelleme Aşamasındaki tüm aşamaları alır ve bunları veri modelleme görevlerine ayırır. Her görev için, bu kitaptaki ilgili araçlar listelenmiştir. Bu şekilde ayrıntılı bir proje planı oluşturabilir ve her bir görevi daha hızlı, daha verimli ve tutarlı yapmak için bu kitapta nereye bakacağınızı bilirsiniz.

Daha sonra Öncelikler Üçgeni, her şeye sahip olamayacağınızı bir diyagram aracılığıyla gösterir. Üçten en fazla ikisini seçebilirsiniz: çok yüksek kalite, minimum süre ve minimum maliyet. Üçüne de asla sahip olamazsın. Bu araç, üç seçeneğin resmedilmesini kolaylaştırır ve aralarındaki ödünleşimlerin açıklanmasına yardımcı olur.

Bölüm, Good Guess Estimating Tool ile sona eriyor. Bu aracın iki bölümü vardır. Konu Alanı Çaba Aralığı, uygulamanın türüne göre her bir veri modelleme aşamasının tüm projenin yüzde kaçının tüketilmesi gerektiğini tanımlar.

Görev Çaba Aracı, Aşamadan Göreve ve Araca tanımlanan tüm görevleri alır ve bunların tüm veri modeli çıktıları kümesinin yüzde kaçının olması gerektiğini listeler. Bu iki bölümün birleşimi, proje yöneticisine bir dereceye kadar doğrulukla makul bir tahminde bulunmanıza da izin verecektir.

GEREKLİLİKLERİN ANALİZİ

Hiç veri modelleme görevlerinizi tamamlayıp daha sonra büyük resmi hâlâ anlamadığınızı fark ettiğiniz oldu mu? Bununla, uygulamanın kapsamını organizasyonun geri kalanı bağlamında gösteren üst düzey ve kapsayıcı görüşü kastediyorum. Böyle büyük bir resim elde etmek için, kitabın bu bölümünde tartışılan ve bir uygulama için veri gereksinimlerinin anlaşılmasına ve yakalanmasına büyük ölçüde yardımcı olacak bir dizi görevi takip de etmelisiniz.

Bu metnin ilk yazılarımızda incelediğimiz temeli oluşturduktan sonra, artık uygulamayı incelemeye başlamaya hazırız. Gereksinimleri tam olarak anlamak için doğru yaklaşım, bunları öncelikle ileriki adımlarda ayrıntılı olarak analiz etmemiz gereken kapsam ve içeriği anlayabileceğimiz konu alanı düzeyinde yüksek bir düzeyde temsil etmektir. Bir uygulama içindeki konu alanlarının her birini anladığımızda, her konu alanına ait veri öğelerini de yakalayabiliriz.

The post Mevcut Veri Ambarı ve Yeni Veri first appeared on Ödev - Tez - Proje Hazırlatma Merkezi.

Yüksek kalite ve minimum maliyet. Bu çözüm, acele etmeniz gerekmediğinde işe yarayacaktır ve tutum sadece acele etmeyin ve işi bitirin ve paranızı boşa harcamadığınızdan emin olun. Bir meta veri havuzu veya standart geliştirme gibi uzun vadeli projeler, bu seçenek için en iyi adaylardır. Tüm işlerin belirli bir tarihe kadar tamamlanması gereken Y2K çalışmasında olduğu gibi, zamanın önemli bir faktör olduğu durumlarda bu seçeneği asla kullanmayın.

Minimum zaman ve minimum maliyet. Bu aynı zamanda hızlı ve kirli çözüm olarak da bilinir. Bu seçeneği asla ama asla seçmek istemediğimizi düşünüyor olsanız da, bazı durumlarda en uygun seçenek bu olabilir.

Prototipleme veya konsept kanıtı akla geliyor. Proje ekibine veya kullanıcılara hızlı bir şekilde bir şeyler göstermeniz gerekiyor ve bu nedenle zaman son derece önemlidir. Prototipi gösterdikten sonra, prototip içindeki kaliteyi artırmak için önemli çalışmaların gerekli olduğu da söylenebilir.

Örneğin, prototip, uygulamadaki olası senaryolardan sadece birkaçını gösteriyor olabilir. Nihai sonuç, tüm olası senaryoları doğru bir şekilde ele almalıdır, ancak analiz ve geliştirme yapmak için daha fazla para ve zamana da mal olur.

Bu seçeneklerden birini seçerken, projenin bir bütün olarak zaten seçmiş olduğunu hissettiğiniz seçeneği seçmeye çok dikkat edin. Bu noktada tutarsız olmak, performansınız ve hızınız hakkında endişe duymanıza neden olabilir. Örneğin, size göre proje minimum zaman ve minimum maliyet temasıyla ilerliyor gibi görünüyorsa, o zaman yüksek kaliteli bir veri modeli sunmaya odaklanmanız da boşuna olacaktır.

Projeyi yavaşlattığınız veya maliyeti artırdığınız için suçlanacaksınız. Ancak artı tarafından bakıldığında, projenin dolaylı olarak bu üç seçenekten birini seçtiğinin farkında olmak, tercih etme ve tercih edilen seçeneğe uyma şansınızı da artırmalıdır.

Veri ambarı Nedir
Veri ambarı örnekleri
Veri tabanı ve veri ambarı Arasındaki fark
Veri marketi nedir
Veri ambarı özellikleri
Olap nedir
Veri Ambarı Eğitimi
Veri ambarı nasıl oluşturulur

Projenin bir bütün olarak seçtiği seçeneğin farkında olun. Resmi olarak bir seçenek belirtmeden bile, proje ekibi içindeki kültür ve atmosfere ve ekibi ileriye götürüyor gibi görünen şeylere de uyum sağlayın. Bu üç seçenekten biri hakkında ne kadar güçlü hissederseniz hissedin, veri modellemeniz için proje ekibinin tüm proje için seçtiği seçeneğin aynısını seçin. Genellikle veri modelleyici, kaliteyi her şeyden önce seçer ki bu, bir bütün olarak projeyle tutarlı değildir. Bu, veri modelleme görevlerinin diğer proje aşamalarına göre daha fazla zaman ve para almasına da yol açabilir.

Veri modelleme görevleri ne kadar çaba gerektirecek? Görevleri belirlediniz ve en etkili olduğuna inandığınız Öncelikler Üçgeni seçeneğini seçtiniz. Şimdi proje yöneticisi size bu soruyu sordu. Bu noktada proje hakkında pek bir şey bilmiyorsunuz. Oldukça gerçekçi bir tahminde bulunmak için daha fazla bilgi edinmeniz ve iki araç uygulamanız da gerekir.

Bu aracın amacı, veri modelleme görevleri için harcanan çaba miktarının iyi bir tahminini sağlamaktır. Her zaman doğru olan bir miktar yoktur. Örneğin, “Veri modellemesi üç hafta sürecek”, bir tahmin talebine asla standart bir yanıt olmamalıdır. Bu, projenin türü, ne kadar bilginin mevcut olduğu ve ne kadar iyi olduğu gibi bir dizi göreve de bağlıdır. Bu araçlar, doğru bir tahmine varmak için resmi bir prosedür uygulayarak süreçteki varsayımların bir kısmını da ortadan kaldırmalıdır.

Çaba ve süre arasındaki farkın farkında olun. Çaba, gün veya saat olarak ölçülen görevleri tamamlamak için geçen süredir. Genellikle işi bir kişinin tam zamanlı olarak yapması, yani haftada 5 gün, günde 8 saat çalışan bir kişi esas alınır.

Süre, görevler arasındaki bağımlılıklar, görevler üzerinde çalışan insanların sayısı, görevlerinizden zaman alacak devam eden diğer projeler gibi faktörleri hesaba katan projenin ne kadar süreceğidir. Çaba, görevleri tamamlamak için fiili süreyi sağlarken, süre görevleri tamamlamanın fiilen ne kadar süreceğini gösterir. Good Guess Tahmin Aracı çabaya odaklanır; oysa süre belirli bir projeye, ekibe ve duruma göre de değişir.

Tahmin Aracını Kullanma

Bu nedenle, görevleri belirledikten sonraki ilk adım, etkinliklerin kişi başına ne kadar süreceği konusunda kabaca bir fikir edinmektir. Her görevi gözden geçirerek ve ihtiyatlı bir tahmin belirleyerek bu sayıyı, diyelim ki gün cinsinden bulabilirsiniz. Sonra toplamı bulmak için bu tahminleri de toplayın. Bu tahminlerden ne kadar çok yaparsanız, proje türüne o kadar çok bakabilir ve doğru bir tahmin de geliştirebilirsiniz. Bu amaçla geliştirilmiştir.

Bu aracın iki bölümü vardır. İlk bölüm, proje gereği veri modelleme çıktılarını tamamlamak için gereken kısa, uzun ve ortalama uzunluğu içeren Konu Alanı Çaba Aralığı elektronik tablosudur. İkinci bölüm, bulduğumuz görevlerin her birini alan ve onlara bir yüzde atayan Görev Çaba Aracıdır. Bu tablodan proje türünü seçtikten sonra, her bir görev için ne kadar süre olduğunu bulmak için bu sayıyı yüzde ile çarparsınız.

Proje yöneticisi size bir süre dikte ederse, elektronik tabloyu atlayın ve her bir görev için süre miktarını elde etmek için süre uzunluğunu her bir yüzdeyle çarpın. Yine de ilk elektronik tabloyu kullanmak isteyebileceğinizi unutmayın, böylece proje yöneticisine veri modelleme görevlerinin ne kadar sürmesini istediğini değil, ne kadar sürmesi gerektiğini de söyleyebilirsiniz.

Bu, görevlerin süresini kısaltmak için ek kaynaklar elde etmeye de yardımcı olabilir. Her iki e-tablo da aşağıdaki bölümlerde görünür. Her birini sunacağız ve ardından bu iki aracın nasıl kullanılacağını göstermek için birkaç örnek üzerinden de bir sonraki yazılarımızda geçeceğiz.

The post Veri Maliyetleri first appeared on Ödev - Tez - Proje Hazırlatma Merkezi.

Uygulamalarımızda, özellikle veri marketlerimizin olgu ve özet tablolarında çok sayıda türetilmiş veri öğesi olabilir. Bir iş türevi, türetilmiş bir veri öğesi için tanıma çok değerli tamamlayıcı bilgilerdir.

Bir iş türetme, fiziksel veri öğesi düzeyinde olan ve genellikle Ayıkla, Dönüştür ve Yükle aracında yakalanan fiziksel türetmenin aksine, bir veri öğesinin nasıl türetildiğinin ticari anlamıdır. Fiziksel türetme, türetmeye ilişkin çok az iş görüşü sağlar, ancak türetilmiş veri öğesini belirli bileşenleriyle ilişkilendirir.

Bu tanımdan, düzeltilmiş fiyat ve miktarın çarpılmasıyla toplam satış tutarının elde edildiğini öğreniyoruz. Ancak birkaç farklı düzeltilmiş fiyat olduğunu varsayalım. Promosyonlardan sonra, navlun indirimlerinden sonra, iadelerden sonra bir tane vb. olabilir. Hangi fiyatı kullanmalıyız? Bu nedenle, bu türetme daha fazla bilgiye ihtiyaç duyar.

Türetme bilgisinden yoksun tanımları tespit etmenin üç adımı vardır. İlk adım, türetilmiş veri öğelerini tanımlamaktır. Genellikle adlarında toplam, net ve brüt gibi kelimeler arayarak bunları bulmak kolaydır. Bu veri öğelerini belirledikten sonra, türevi olmayanları vurgulayın. Bunları düzeltmeniz gerekecektir.

Türevleri olanlardan hangileri yeterince iyi? Bu her zaman cevaplaması kolay bir soru değildir. Bu türetmenin birden çok yoruma yer bırakıp bırakmadığını kendinize sorun. belirsiz mi? Önceki örnekte hangi fiyatın kullanılacağını belirlemeye çalışırken gördüğümüz gibi, birden fazla veri öğesi türetmenin bir kısmının tanımına uyabilir mi? Cevap evet ise, bu türetmeyi geliştirmemiz gerekiyor.

Her iki türetme senaryosu için de çözüm aynıdır. Türetmede kullanılan tekil terimleri açıkça tanımlayın ve bunları tanıma ekleyin. Tek terimlerle, belirsizliğe yer bırakmamayı kastediyorum. Ayrıca, fiziksel veri öğesi adlarını belirtmeye gerek yoktur, yalnızca işletme adlarını ve terimleri ekleyin.

Öncelikle, şu anda örnek değerleri olmayan kodlar veya kod çözmeler (açıklamalar) olan tüm veri öğelerinizi tanımlayın. Ardından, kodlar kapsamında yer almayan tüm soyut terminolojiyi tanımlayın. Bunlar, örnek değerlere ihtiyaç duyan iki kategoridir. Buna konu alanları, varlıklar ve veri öğeleri dahildir. Her birinin altına birkaç örnek ekleyin. Yine, burada tam bir listeye ihtiyacımız yok, sadece anlayış eklemek için yeterlidir.

Kodlar için, genellikle 20 veya daha az farklı değer olduğunda bir kodun tüm değerlerini veya 20’den fazla değer varsa yalnızca ilk 20’yi listelemenizi öneririm. Tartışacağımız sınıf kelimelerini kullanmak, veri öğelerinden hangilerinin kod olduğunu daha belirgin hale getirecektir.

Örnek değerlerin aslında beklediğimizden farklı olduğunu unutmayın. Örneğin, Alabama’nın AL olmasını bekliyorduk. Bu, bu örnek değerlere sahip olmanın değerini vurgular.

Bu kategori, terimin ne anlama geldiğiyle tamamen eşleşen ve işin geri kalanıyla tutarlı bir tanıma sahip olmaya odaklanır. Alandaki bir uzman, bu terimin bu tanımla eşleştiği konusunda hemfikir olacaktır. Bu noktada terim ve tanımı gerçek verilere göre doğrulamadığımıza dikkat edin.

Bu veri doğrulama, bu süreçte daha sonra gerçekleşir ve bu kitapta, gerçek verilere erişiminiz olduğunda size yardımcı olacak araçlar vardır. Kulağa ne kadar ironik gelse de, doğruluk bazen yoruma açık olabilir. Kapsam ve tanımı doğrulayan iş uzmanlarına bağlı olarak muhtemelen birden çok şekilde yorumlanabilir.

Kapsam sorunu, her tanım kuruluştaki yeri açısından incelenirken ele alınır. İş uzmanları aynı fikirde olmadığında, konu alanı için tek bir vekilharç olması gerekir. Bir kahya, belirli bir terim veya konu alanından sorumlu olan kişidir. Bu kategoride ele aldığımız doğrulama işlemlerinin bir kısmının, departman dışındaki kişilerden geri bildirim talep ederken zaten yapılmış olabileceğini unutmayın.

Veri ambarı örnekleri
Veri ambarı Nedir
Veri tabanı ve veri ambarı Arasındaki fark
Veri Ambarı Eğitimi
Veri ambarı modelleme
Veri marketi
Veri ambarı katmanları
Veri ambarı özellikleri

Veri Kalitesi Sorumlusu

Bu alanda anlaşmaya varılan uzman bu tanımı onayladı mı? Uzman, belirli bir uygulamadan bağımsız olan kişidir. Uzman iş uzmanıdır ve resmi vekilharçlık unvanına sahiptir çünkü bu konu alanıyla ilişkili veriler ve meta veriler için nihai söz yalnızca uzmana aittir. Konu alanı dediğime dikkat edin, varlık veya veri öğesi değildir. Bu önemli bir nokta.

Görevli, diğer görevlilerle tutarlılık olması için konu alanı düzeyinde tanımlanmalıdır. Bu, yönetim kapsamının çakışmasını önleyecektir. Bu aynı zamanda, görevli sayısını ve kimin hangi veri için görevli olduğu ile ilgili bakım sürecini de en aza indirecektir. Varlık veya veri öğesi düzeyinde vekilharçlık atasaydık, kaç tane vekilharç olacağını hayal edin?

Bunu yapmak kolaydır. Bir veri görevlisi tanımı gözden geçirdi mi? Cevap evet ise, o zaman bu kriterle işiniz bitti. Cevap hayır ise, tanımı gözden geçirmeniz ve onaylamanız gerekir.

Bir kahya tarafından onaylanan bir tanıma sahip olmanın iki adımı vardır. İlki, kâhyanın kim olduğunu belirlemektir. Bu, özellikle birden fazla kişinin bu terim üzerinde yetkili olabileceği büyük bir şirkette veya departmanda oldukça zorlayıcı olabilir.

Genellikle olan şey, verilerin oluşturulmasından veya değiştirilmesinden sorumlu olan bölümün yöneticisinin görevli olmasıdır. Sonra kâhya bu tanımı onaylamalıdır. Bunun bir lastik damga onayı olmadığından emin olun, yani görevli tanıma zar zor bakar ve ardından imzalar.

Kâhyanın, kâhya olmakla ilgili pek çok sorumluluk olduğunun ve bu rolün hafife alınmaması gerektiğinin farkına varması önemlidir. Her zaman, kahyanın geri bildirimde bulunacağına dair bir taahhüt alın ve bir inceleme tarihi üzerinde anlaşın, çünkü muhtemelen kahyanın üzerinde çok iş vardır.

Bir tanım yazıldıktan ve onaylandıktan sonra, bunun kuruluş gibi daha geniş kapsamla tutarlı olduğundan emin olmanız gerekir. Mevcut herhangi bir kurumsal terim ve tanımla çelişmediğinden emin olmanız gerekir.

Teriminizi ve tanımınızı işletme listesine göre doğrulamak, dört sonuçtan birini verir:

• Eşleşme olmaması. İşletme listesinde teriminize ve tanımınıza benzer bir şey bulamadınız, bu durumda vekilharçınızın onayladığı tanım işletme tanımı olacaktır. Müşteri terimi ve tanımı kurumsal listede yoktu.
• Tam eşleşme. Sizinkiyle aynı ada ve neredeyse tam tanıma sahip bir terim buldunuz. Müşteri tanımınız, kuruluşun tanımıyla eşleşiyor.
• Eşanlamlı sözcük. Benzer ama tam adı olmayan, aynı tanıma sahip bir terim buldunuz. Örneğin, kurumsal listedeki Müşteri terimi, Müşteri teriminizle aynı tanıma sahiptir.
• Sesteş. Aynı ada sahip bir terim buldunuz, ancak tanım farklı görünüyor. Örneğin, sizin Müşteri tanımınız, işletmeninkinden oldukça farklı bir anlama geliyor.

The post Veri Marketleri first appeared on Ödev - Tez - Proje Hazırlatma Merkezi.