Veri Ambarlama - Hızlı Kılavuz

"Veri Ambarı" terimi ilk olarak 1990 yılında Bill Inmon tarafından icat edildi. Inmon'a göre, bir veri ambarı konu odaklı, entegre, zamana göre değişen ve uçucu olmayan bir veri koleksiyonudur. Bu veriler, analistlerin bir organizasyonda bilinçli kararlar almasına yardımcı olur.

Bir operasyonel veri tabanı, gerçekleşen işlemler nedeniyle günlük olarak sık sık değişikliklere uğrar. Bir iş yöneticisinin bir ürün, tedarikçi veya herhangi bir tüketici verisi gibi herhangi bir veriyle ilgili önceki geri bildirimi analiz etmek istediğini varsayalım, o zaman yöneticinin analiz edecek hiçbir verisi olmayacaktır çünkü önceki veriler işlemler nedeniyle güncellendi.

Veri ambarları bize çok boyutlu görünümde genelleştirilmiş ve birleştirilmiş veriler sağlar. Veri ambarları, genelleştirilmiş ve birleştirilmiş veri görünümünün yanı sıra bize Çevrimiçi Analitik İşleme (OLAP) araçları da sağlar. Bu araçlar, çok boyutlu bir alanda verilerin interaktif ve etkili analizinde bize yardımcı olur. Bu analiz, veri genelleme ve veri madenciliği ile sonuçlanır.

İlişkilendirme, kümeleme, sınıflandırma, tahmin gibi veri madenciliği işlevleri, çoklu soyutlama düzeyinde etkileşimli bilgi madenciliğini geliştirmek için OLAP işlemleriyle entegre edilebilir. Bu nedenle veri ambarı artık veri analizi ve çevrimiçi analitik işleme için önemli bir platform haline geldi.

Veri Ambarını Anlamak

Veri ambarı, kuruluşun operasyonel veritabanından ayrı tutulan bir veritabanıdır.
Bir veri ambarında sık sık güncelleme yapılmaz.
Kuruluşun işini analiz etmesine yardımcı olan konsolide geçmiş verilere sahiptir.
Bir veri ambarı, yöneticilerin stratejik kararlar almak için verilerini düzenlemelerine, anlamalarına ve kullanmalarına yardımcı olur.
Veri ambarı sistemleri, uygulama sistemlerinin çeşitliliğinin entegrasyonuna yardımcı olur.
Bir veri ambarı sistemi, konsolide geçmiş veri analizine yardımcı olur.

Veri Ambarı Neden Operasyonel Veritabanlarından Ayrılır?

Bir veri ambarları, aşağıdaki nedenlerden dolayı operasyonel veritabanlarından ayrı tutulur:

Belirli kayıtların aranması, indeksleme, vb. Gibi iyi bilinen görevler ve iş yükleri için bir operasyonel veritabanı oluşturulur. Sözleşmede, veri ambarı sorguları genellikle karmaşıktır ve genel bir veri biçimi sunarlar.
Operasyonel veritabanları, birden çok işlemin eşzamanlı olarak işlenmesini destekler. Veritabanının sağlamlığını ve tutarlılığını sağlamak için operasyonel veritabanları için eşzamanlılık kontrolü ve kurtarma mekanizmaları gereklidir.
Operasyonel bir veritabanı sorgusu işlemleri okumaya ve değiştirmeye izin verirken bir OLAP sorgusu yalnızca read only saklanan verilere erişim.
Operasyonel bir veritabanı güncel verileri korur. Öte yandan, bir veri ambarı geçmiş verileri tutar.

Veri Ambarı Özellikleri

Bir veri ambarının temel özellikleri aşağıda tartışılmaktadır -

Subject Oriented- Bir veri ambarı, kuruluşun devam eden işlemlerinden ziyade bir konu etrafında bilgi sağladığı için konu odaklıdır. Bu konular ürün, müşteriler, tedarikçiler, satışlar, gelir vb. Olabilir. Bir veri ambarı, devam eden işlemlere odaklanmaz, daha ziyade karar verme için verilerin modellenmesine ve analizine odaklanır.
Integrated - İlişkisel veritabanları, düz dosyalar, vb. Gibi heterojen kaynaklardan gelen verilerin entegre edilmesiyle bir veri ambarı oluşturulur. Bu entegrasyon, verilerin etkili analizini geliştirir.
Time Variant- Bir veri ambarında toplanan veriler, belirli bir süre ile tanımlanır. Bir veri ambarındaki veriler, tarihsel bakış açısından bilgi sağlar.
Non-volatile- Uçucu olmayan, yeni veri eklendiğinde önceki verilerin silinmediği anlamına gelir. Bir veri ambarı, operasyonel veritabanından ayrı tutulur ve bu nedenle operasyonel veritabanındaki sık değişiklikler, veri ambarına yansıtılmaz.

Note - Bir veri ambarı, fiziksel olarak depolandığı ve operasyonel veritabanından ayrı olduğu için işlem işleme, kurtarma ve eşzamanlılık kontrolleri gerektirmez.

Veri Ambarı Uygulamaları

Daha önce tartışıldığı gibi, bir veri ambarı, işletme yöneticilerinin karar vermede verilerini düzenlemelerine, analiz etmelerine ve kullanmalarına yardımcı olur. Bir veri ambarı, kurumsal yönetim için planla-yürüt-değerlendir "kapalı döngü" geri bildirim sisteminin tek bir parçası olarak hizmet eder. Veri ambarları aşağıdaki alanlarda yaygın olarak kullanılmaktadır -

Finansal hizmetler
Banka hizmetleri
Tüketim malları
Perakende sektörleri
Kontrollü imalat

Veri Ambarı Türleri

Bilgi işleme, analitik işleme ve veri madenciliği, aşağıda tartışılan üç tür veri ambarı uygulamasıdır:

Information Processing- Bir veri ambarı, içinde depolanan verileri işlemeye izin verir. Veriler, sorgulama, temel istatistiksel analiz, çapraz tablolar, tablolar, çizelgeler veya grafikler kullanılarak raporlama yoluyla işlenebilir.
Analytical Processing- Bir veri ambarı, içinde depolanan bilgilerin analitik olarak işlenmesini destekler. Veriler, dilim ve zar, detaya inme, detaya gitme ve döndürme dahil olmak üzere temel OLAP işlemleri aracılığıyla analiz edilebilir.
Data Mining- Veri madenciliği, gizli kalıpları ve ilişkileri bularak, analitik modeller oluşturarak, sınıflandırma ve tahmin gerçekleştirerek bilgi keşfini destekler. Bu madencilik sonuçları görselleştirme araçları kullanılarak sunulabilir.

Sr.No.	Veri Ambarı (OLAP)	Operasyonel Veritabanı (OLTP)
1	Bilginin tarihsel olarak işlenmesini içerir.	Günlük işlemeyi içerir.
2	OLAP sistemleri, yöneticiler, yöneticiler ve analistler gibi bilgi çalışanları tarafından kullanılır.	OLTP sistemleri, katipler, DBA'lar veya veritabanı uzmanları tarafından kullanılır.
3	İşi analiz etmek için kullanılır.	İşi yürütmek için kullanılır.
4	Bilgiye odaklanır.	Veri girişine odaklanır.
5	Star Schema, Snowflake Schema ve Fact Constellation Schema'ya dayanmaktadır.	Varlık İlişki Modeline dayanmaktadır.
6	Bilgiye odaklanır.	Uygulama odaklıdır.
7	Geçmiş verileri içerir.	Güncel verileri içerir.
8	Özetlenmiş ve birleştirilmiş veriler sağlar.	İlkel ve oldukça detaylı veriler sağlar.
9	Verilerin özetlenmiş ve çok boyutlu görünümünü sağlar.	Verilerin ayrıntılı ve düz ilişkisel görünümünü sağlar.
10	Kullanıcı sayısı yüzlerce.	Kullanıcı sayısı binlerdedir.
11	Erişilen kayıt sayısı milyon cinsindendir.	Erişilen kayıt sayısı onlarcadır.
12	Veritabanı boyutu 100 GB ile 100 TB arasındadır.	Veritabanı boyutu 100 MB ile 100 GB arasındadır.
13	Bunlar oldukça esnektir.	Yüksek performans sağlar.

Veri Ambarlama nedir?

Veri ambarı, bir veri ambarı oluşturma ve kullanma sürecidir. Bir veri ambarı, analitik raporlamayı, yapılandırılmış ve / veya geçici sorguları ve karar vermeyi destekleyen birden çok heterojen kaynaktan gelen verileri entegre ederek oluşturulur. Veri ambarlama, veri temizleme, veri entegrasyonu ve veri konsolidasyonlarını içerir.

Veri Ambarı Bilgilerini Kullanma

Bir veri ambarında bulunan verileri kullanmaya yardımcı olan karar destek teknolojileri vardır. Bu teknolojiler, yöneticilerin depoyu hızlı ve etkili bir şekilde kullanmalarına yardımcı olur. Depoda bulunan bilgilere dayanarak veri toplayabilir, analiz edebilir ve kararlar alabilirler. Bir depoda toplanan bilgiler aşağıdaki alan adlarından herhangi birinde kullanılabilir -

Tuning Production Strategies - Üç aylık veya yıllık satışları karşılaştırarak ürünleri yeniden konumlandırarak ve ürün portföylerini yöneterek ürün stratejileri iyi bir şekilde ayarlanabilir.
Customer Analysis - Müşterinin satın alma tercihleri, satın alma süresi, bütçe döngüleri vb. Analiz edilerek müşteri analizi yapılır.
Operations Analysis- Veri ambarı, müşteri ilişkileri yönetimine ve çevresel düzeltmelerin yapılmasına da yardımcı olur. Bilgiler aynı zamanda iş operasyonlarını analiz etmemize olanak tanır.

Heterojen Veritabanlarının Entegre Edilmesi

Heterojen veritabanlarını entegre etmek için iki yaklaşımımız var -

Sorguya Dayalı Yaklaşım
Güncellemeye Dayalı Yaklaşım

Sorguya Dayalı Yaklaşım

Bu, heterojen veritabanlarını entegre etmek için geleneksel yaklaşımdır. Bu yaklaşım, birden çok heterojen veritabanının üzerine sarmalayıcılar ve entegratörler oluşturmak için kullanıldı. Bu entegratörler aynı zamanda arabulucular olarak da bilinir.

Sorgu Odaklı Yaklaşım Süreci

İstemci tarafına bir sorgu gönderildiğinde, bir meta veri sözlüğü sorguyu ilgili bireysel heterojen siteler için uygun bir biçime çevirir.
Artık bu sorgular eşlenir ve yerel sorgu işlemcisine gönderilir.
Heterojen sitelerden elde edilen sonuçlar küresel bir cevap setine entegre edilmiştir.

Dezavantajları

Sorgu odaklı yaklaşım, karmaşık entegrasyon ve filtreleme süreçleri gerektirir.
Bu yaklaşım çok verimsiz.
Sık sorgular için çok pahalıdır.
Bu yaklaşım, toplama gerektiren sorgular için de çok pahalıdır.

Güncelleme Odaklı Yaklaşım

Bu, geleneksel yaklaşıma bir alternatiftir. Günümüzün veri ambarı sistemleri, daha önce tartışılan geleneksel yaklaşımdan ziyade güncelleme odaklı yaklaşımı takip etmektedir. Güncelleme odaklı yaklaşımda, birden çok heterojen kaynaktan gelen bilgiler önceden entegre edilir ve bir depoda saklanır. Bu bilgiler doğrudan sorgulama ve analiz için mevcuttur.

Avantajlar

Bu yaklaşım aşağıdaki avantajlara sahiptir -

Bu yaklaşım, yüksek performans sağlar.
Veriler, anlamsal veri deposunda önceden kopyalanır, işlenir, entegre edilir, notlandırılır, özetlenir ve yeniden yapılandırılır.
Sorgu işleme, verileri yerel kaynaklarda işlemek için bir arayüz gerektirmez.

Veri Ambarı Araçlarının ve Yardımcı Programlarının İşlevleri

Aşağıdakiler, veri ambarı araçlarının ve yardımcı programlarının işlevleridir -

Data Extraction - Birden çok heterojen kaynaktan veri toplamayı içerir.
Data Cleaning - Verilerdeki hataları bulmayı ve düzeltmeyi içerir.
Data Transformation - Verilerin eski formattan ambar formatına dönüştürülmesini içerir.
Data Loading - Sıralama, özetleme, birleştirme, bütünlük denetimi ve indisler ve bölümler oluşturmayı içerir.
Refreshing - Veri kaynaklarından depoya güncelleme içerir.

Note - Veri temizleme ve veri dönüştürme, veri kalitesinin ve veri madenciliği sonuçlarının iyileştirilmesinde önemli adımlardır.

Bu bölümde, veri ambarında en sık kullanılan terimlerden bazılarını tartışacağız.

Meta veriler

Meta veriler, basitçe verilerle ilgili veriler olarak tanımlanır. Diğer verileri temsil etmek için kullanılan veriler, meta veriler olarak bilinir. Örneğin, bir kitabın dizini kitabın içeriği için bir meta veri görevi görür. Yani üst verinin bizi detaylı verilere götüren özetlenmiş veriler olduğunu söyleyebiliriz.

Veri ambarı açısından meta verileri aşağıdaki gibi tanımlayabiliriz -

Meta veriler, veri ambarına giden bir yol haritasıdır.
Veri ambarındaki meta veriler, ambar nesnelerini tanımlar.
Meta veriler bir dizin görevi görür. Bu dizin, karar destek sisteminin bir veri ambarının içeriğini bulmasına yardımcı olur.

Meta Veri Havuzu

Meta veri havuzu, bir veri ambarı sisteminin ayrılmaz bir parçasıdır. Aşağıdaki meta verileri içerir -

Business metadata - Veri sahipliği bilgilerini, iş tanımını ve değişen politikaları içerir.
Operational metadata- Veri para birimini ve veri kökenini içerir. Veri para birimi, etkin, arşivlenmiş veya temizlenmiş verileri ifade eder. Veri kökenleri, taşınan verilerin geçmişi ve ona uygulanan dönüşüm anlamına gelir.
Data for mapping from operational environment to data warehouse - Metadata, kaynak veritabanları ve içerikleri, veri çıkarma, veri bölümü, temizleme, dönüştürme kuralları, veri yenileme ve temizleme kurallarını içerir.
The algorithms for summarization - Boyut algoritmalarını, ayrıntı düzeyi, toplama, özetleme vb. Verileri içerir.

Veri Küpü

Veri küpü, verileri birden çok boyutta temsil etmemize yardımcı olur. Boyutlar ve gerçeklerle tanımlanır. Boyutlar, bir işletmenin kayıtları sakladığı varlıklardır.

Veri Küpü Gösterimi

Bir şirketin satış veri ambarı yardımıyla zaman, kalem, şube ve konuma göre satış kayıtlarını takip etmek istediğini varsayalım. Bu boyutlar, aylık satışları ve ürünlerin hangi şubede satıldığını takip etmeyi sağlar. Her boyutla ilişkili bir tablo var. Bu tablo boyut tablosu olarak bilinir. Örneğin, "öğe" boyut tablosu, öğe_adı, öğe_türü ve öğe_brand gibi özelliklere sahip olabilir.

Aşağıdaki tablo, zaman, öğe ve konum boyutlarına göre bir şirket için Satış Verilerinin 2 boyutlu görünümünü temsil etmektedir.

Ancak burada bu 2 boyutlu tabloda, yalnızca zaman ve madde ile ilgili kayıtlarımız var. Yeni Delhi için yapılan satışlar zamana göre ve satılan ürünlerin türüne göre ürün boyutlarına göre gösterilir. Satış verilerini bir boyut daha, mesela konum boyutu ile görüntülemek istersek, 3 boyutlu görünüm faydalı olacaktır. Satış verilerinin zamana, kaleme ve konuma göre 3 boyutlu görünümü aşağıdaki tabloda gösterilmektedir -

Yukarıdaki 3 boyutlu tablo, aşağıdaki şekilde gösterildiği gibi 3 boyutlu veri küpü olarak gösterilebilir -

Data Mart

Veri reyonları, bir kuruluştaki belirli insan grupları için değerli olan, kuruluş çapında verilerin bir alt kümesini içerir. Başka bir deyişle, bir veri pazarı yalnızca belirli bir gruba özgü verileri içerir. Örneğin, pazarlama veri pazarı yalnızca öğeler, müşteriler ve satışlarla ilgili verileri içerebilir. Veri reyonları öznelerle sınırlıdır.

Data Marts Hakkında Hatırlanması Gereken Noktalar

Veri pazarlarını uygulamak için Windows tabanlı veya Unix / Linux tabanlı sunucular kullanılır. Düşük maliyetli sunucularda uygulanırlar.
Bir veri pazarının uygulama döngüsü kısa zaman aralıklarında, yani aylar veya yıllar yerine haftalar halinde ölçülür.
Planlama ve tasarımları kuruluş çapında değilse, veri reyonlarının yaşam döngüsü uzun vadede karmaşık olabilir.
Veri pazarları küçüktür.
Veri reyonları departmanlara göre özelleştirilir.
Bir veri pazarının kaynağı, departmana göre yapılandırılmış veri ambarlarıdır.
Veri reyonları esnektir.

Aşağıdaki şekil, veri reyonlarının grafik temsilini göstermektedir.

Sanal Depo

Operasyonel veri ambarı üzerindeki görünüm, sanal ambar olarak bilinir. Sanal bir ambar oluşturmak kolaydır. Bir sanal ambar oluşturmak, operasyonel veritabanı sunucularında fazla kapasite gerektirir.

Bir veri ambarı asla durağan değildir; iş genişledikçe gelişir. İş geliştikçe, gereksinimleri de değişmeye devam ediyor ve bu nedenle bir veri ambarı bu değişikliklere ayak uyduracak şekilde tasarlanmalıdır. Dolayısıyla bir veri ambarı sisteminin esnek olması gerekir.

İdeal olarak, bir veri ambarını teslim etmek için bir teslimat süreci olmalıdır. Bununla birlikte, veri ambarı projeleri normalde, şelale yönteminin gerektirdiği katı ve düzenli şekilde görevleri ve teslim edilecekleri tamamlamayı zorlaştıran çeşitli sorunlardan muzdariptir. Çoğu zaman gereksinimler tam olarak anlaşılmamaktadır. Mimariler, tasarımlar ve yapı bileşenleri ancak tüm gereksinimleri toplayıp inceledikten sonra tamamlanabilir.

Teslimat Yöntemi

Teslimat yöntemi, bir veri ambarının teslimi için benimsenen ortak uygulama geliştirme yaklaşımının bir çeşididir. Riskleri en aza indirmek için veri ambarı teslim sürecini aşamalı hale getirdik. Burada tartışacağımız yaklaşım, genel teslimat süresi ölçeklerini azaltmaz, ancak iş faydalarının geliştirme süreci boyunca aşamalı olarak sunulmasını sağlar.

Note - Proje ve teslimat riskini azaltmak için teslimat süreci aşamalara ayrılır.

Aşağıdaki şema teslimat sürecindeki aşamaları açıklamaktadır -

BT Stratejisi

Veri ambarı, fayda sağlamak için bir iş süreci gerektiren stratejik yatırımlardır. Proje için finansmanı temin etmek ve korumak için BT Stratejisi gereklidir.

İş durumu

İş senaryosunun amacı, bir veri ambarı kullanarak elde edilmesi gereken ticari faydaları tahmin etmektir. Bu faydalar ölçülebilir olmayabilir ancak öngörülen faydaların açıkça belirtilmesi gerekir. Bir veri ambarının net bir iş vakası yoksa, işletme teslimat sürecinin bir aşamasında güvenilirlik sorunlarından muzdarip olma eğilimindedir. Bu nedenle, veri ambarı projelerinde, yatırım için iş durumunu anlamamız gerekir.

Eğitim ve Prototipleme

Kuruluşlar veri analizi kavramını dener ve bir çözüme karar vermeden önce bir veri ambarına sahip olmanın değeri konusunda kendilerini eğitirler. Bu, prototipleme ile ele alınır. Bir veri ambarının fizibilitesini ve faydalarını anlamaya yardımcı olur. Küçük ölçekte prototip oluşturma faaliyeti, eğitim sürecini şu şartlarda destekleyebilir:

Prototip, tanımlanmış bir teknik hedefe yöneliktir.
Prototip, fizibilite konsepti gösterildikten sonra atılabilir.
Etkinlik, veri ambarının nihai veri içeriğinin küçük bir alt kümesini ele alır.
Etkinlik zaman ölçeği kritik değildir.

Erken bir sürüm oluşturmak ve ticari faydalar sağlamak için aşağıdaki noktalar akılda tutulmalıdır.

Gelişebilen mimariyi tanımlayın.
İş gereksinimlerine ve teknik plan aşamalarına odaklanın.
İlk geliştirme aşamasının kapsamını, ticari avantajlar sağlayan minimum düzeyde sınırlayın.
Veri ambarının kısa vadeli ve orta vadeli gereksinimlerini anlayın.

İş gereksinimleri

Kaliteli çıktılar sağlamak için, genel gereksinimlerin anlaşıldığından emin olmalıyız. Hem kısa vadeli hem de orta vadeli iş gereksinimlerini anlarsak, kısa vadeli gereksinimleri karşılayacak bir çözüm tasarlayabiliriz. Kısa vadeli çözüm daha sonra tam bir çözüme dönüştürülebilir.

Bu aşamada aşağıdaki hususlar belirlenir -

Verilere uygulanacak iş kuralı.
Veri ambarındaki bilgiler için mantıksal model.
Acil gereksinim için sorgu profilleri.
Bu verileri sağlayan kaynak sistemler.

Teknik Taslak

Bu aşamanın uzun vadeli gereksinimleri karşılayan genel bir mimari sunması gerekir. Bu aşama aynı zamanda herhangi bir ticari fayda sağlamak için kısa vadede uygulanması gereken bileşenleri de sağlar. Planın aşağıdakileri tanımlaması gerekir.

Genel sistem mimarisi.
Veri saklama politikası.
Yedekleme ve kurtarma stratejisi.
Sunucu ve veri pazarı mimarisi.
Donanım ve altyapı için kapasite planı.
Veritabanı tasarımının bileşenleri.

Sürümü Oluşturmak

Bu aşamada ilk üretim çıktısı üretilir. Bu üretim çıkışı, bir veri ambarının en küçük bileşenidir. Bu en küçük bileşen, iş açısından fayda sağlar.

Geçmiş Yükü

Bu, gerekli geçmişin geri kalanının veri ambarına yüklendiği aşamadır. Bu aşamada, yeni varlıklar eklemiyoruz, ancak artan veri hacimlerini depolamak için muhtemelen ek fiziksel tablolar oluşturulacaktır.

Bir örnek ele alalım. Derleme sürümü aşamasının 2 aylık geçmişe sahip bir perakende satış analizi veri ambarı sağladığını varsayalım. Bu bilgiler, kullanıcının yalnızca son eğilimleri analiz etmesine ve kısa vadeli sorunları ele almasına izin verecektir. Bu durumda kullanıcı, yıllık ve mevsimsel eğilimleri belirleyemez. Bunu yapmasına yardımcı olmak için son 2 yılın satış geçmişi arşivden yüklenebilir. Şimdi 40GB veri 400GB'a genişletildi.

Note - Yedekleme ve kurtarma prosedürleri karmaşık hale gelebilir, bu nedenle bu aktivitenin ayrı bir aşamada gerçekleştirilmesi önerilir.

Ad hoc Sorgu

Bu aşamada, bir veri ambarını çalıştırmak için kullanılan geçici bir sorgu aracı yapılandırıyoruz. Bu araçlar veritabanı sorgusunu oluşturabilir.

Note - Veritabanı büyük ölçüde değiştirilirken bu erişim araçlarının kullanılmaması önerilir.

Otomasyon

Bu aşamada operasyonel yönetim süreçleri tamamen otomatiktir. Bunlar şunları içerir -

Verilerin analize uygun hale getirilmesi.
Sorgu profillerini izleme ve sistem performansını korumak için uygun toplamaları belirleme.
Farklı kaynak sistemlerden veri çıkarma ve yükleme.
Veri ambarındaki önceden tanımlanmış tanımlardan toplamalar oluşturmak.
Verileri yedekleme, geri yükleme ve arşivleme.

Kapsam Genişletme

Bu aşamada, veri ambarı yeni bir dizi iş gereksinimlerini karşılamak için genişletilir. Kapsam iki şekilde genişletilebilir -

Veri ambarına ek veri yükleyerek.
Mevcut bilgileri kullanarak yeni veri reyonları sunarak.

Note - Bu aşama, önemli çaba ve karmaşıklık içerdiğinden ayrı olarak gerçekleştirilmelidir.

Gereksinimlerin Gelişimi

Teslimat süreci açısından, gereksinimler her zaman değiştirilebilir. Statik değiller. Teslimat süreci bunu desteklemeli ve bu değişikliklerin sisteme yansıtılmasına izin vermelidir.

Bu sorun, veri ambarının, mevcut sorguların veri gereksinimlerinin aksine, iş süreçlerinde veri kullanımı etrafında tasarlanmasıyla giderilir.

Mimari, iş ihtiyaçlarına uyacak şekilde değişmek ve büyümek için tasarlanmıştır; süreç, yeni gereksinimlerin sürekli olarak geliştirme faaliyetlerine beslendiği ve kısmi çıktıların üretildiği sözde uygulama geliştirme süreci olarak çalışır. Bu kısmi teslimatlar, kullanıcılara geri beslenir ve daha sonra, iş ihtiyaçlarını karşılamak için genel sistemin sürekli olarak güncellenmesini sağlamak için yeniden çalışılır.

Operasyonel veri tabanlarına uygulanacak sabit sayıda operasyonumuz var ve aşağıdaki gibi iyi tanımlanmış tekniklerimiz var. use normalized data, keep table small, vb. Bu teknikler, bir çözüm sunmak için uygundur. Ancak karar destek sistemleri söz konusu olduğunda, gelecekte hangi sorgu ve işlemin yapılması gerektiğini bilmiyoruz. Bu nedenle operasyonel veri tabanlarında uygulanan teknikler veri ambarları için uygun değildir.

Bu bölümde, Unix ve ilişkisel veritabanları gibi en iyi açık sistem teknolojilerinde veri ambarlama çözümlerinin nasıl oluşturulacağını tartışacağız.

Veri Ambarında Süreç Akışı

Bir veri ambarına katkıda bulunan dört ana süreç vardır -

Verileri çıkarın ve yükleyin.
Verilerin temizlenmesi ve dönüştürülmesi.
Verileri yedekleyin ve arşivleyin.
Sorguları yönetmek ve uygun veri kaynaklarına yönlendirmek.

Çıkarma ve Yükleme İşlemi

Veri çıkarma, verileri kaynak sistemlerden alır. Veri yükleme, çıkarılan verileri alır ve veri ambarına yükler.

Note - Verileri veri ambarına yüklemeden önce, dış kaynaklardan çıkarılan bilgiler yeniden yapılandırılmalıdır.

Süreci Kontrol Etmek

Süreci kontrol etmek, veri çıkarmaya ne zaman başlanacağını ve veriler üzerinde tutarlılık kontrolünün yapılmasını içerir. Kontrol süreci, araçların, mantık modüllerinin ve programların doğru sırada ve doğru zamanda yürütülmesini sağlar.

Ayıklama Ne Zaman Başlatılmalı

Verilerin çıkarılırken tutarlı bir durumda olması gerekir, yani veri ambarı, bilginin kullanıcıya tek ve tutarlı bir sürümünü sunmalıdır.

Örneğin, telekomünikasyon sektöründeki bir müşteri profili veri ambarında, bir müşteri veri tabanından Çarşamba günü saat 20.00'de müşteri listesini Salı günü saat 20.00'ye kadar olan müşteri aboneliği etkinlikleriyle birleştirmek mantıksızdır. Bu, ilişkili abonelikleri olmayan müşterileri bulduğumuz anlamına gelir.

Verilerin Yüklenmesi

Verileri çıkardıktan sonra, temizlendiği ve tutarlı hale getirildiği geçici bir veri deposuna yüklenir.

Note - Tutarlılık kontrolleri, yalnızca tüm veri kaynakları geçici veri deposuna yüklendiğinde yürütülür.

Temizleme ve Dönüştürme Süreci

Veriler çıkarılıp geçici veri deposuna yüklendikten sonra, Temizleme ve Dönüştürme işleminin zamanı gelmiştir. İşte Temizleme ve Dönüştürme ile ilgili adımların listesi -

Yüklenen verileri temizleyin ve bir yapıya dönüştürün
Verileri bölümlere ayırın
Aggregation

Yüklenen Verileri Temizleyin ve Bir Yapıya Dönüştürün

Yüklenen verilerin temizlenmesi ve dönüştürülmesi, sorguların hızlandırılmasına yardımcı olur. Verileri tutarlı hale getirerek yapılabilir -

kendi içinde.
aynı veri kaynağı içindeki diğer verilerle.
diğer kaynak sistemlerdeki verilerle.
depoda bulunan mevcut verilerle.

Dönüştürme, kaynak verilerin bir yapıya dönüştürülmesini içerir. Verilerin yapılandırılması, sorgu performansını artırır ve operasyonel maliyeti düşürür. Bir veri ambarında bulunan veriler, performans gereksinimlerini desteklemek ve devam eden operasyonel maliyetleri kontrol etmek için dönüştürülmelidir.

Verileri Bölün

Donanım performansını optimize edecek ve veri ambarının yönetimini basitleştirecektir. Burada her olgu tablosunu birden çok ayrı bölüme ayırıyoruz.

Toplama

Genel sorguları hızlandırmak için toplama gereklidir. Toplama, en yaygın sorguların ayrıntılı verilerin bir alt kümesini veya bir toplamasını analiz edeceği gerçeğine dayanır.

Verileri Yedekleyin ve Arşivleyin

Veri kaybı, yazılım arızası veya donanım arızası durumunda verileri kurtarmak için düzenli yedeklemeler yapmak gerekir. Arşivleme, eski verilerin sistemden, gerektiğinde hızlı bir şekilde geri yüklenmesine olanak tanıyan bir biçimde kaldırılmasını içerir.

Örneğin, bir perakende satış analizi veri ambarında, en son 6 aylık verilerin çevrimiçi tutulmasıyla verilerin 3 yıl boyunca tutulması gerekebilir. Böyle bir senaryoda, genellikle bu yıl ve geçen yıl için aydan aya karşılaştırmalar yapabilme zorunluluğu vardır. Bu durumda, bazı verilerin arşivden geri yüklenmesini istiyoruz.

Sorgu Yönetimi Süreci

Bu işlem aşağıdaki işlevleri yerine getirir -

sorguları yönetir.
queris'in yürütme süresini hızlandırmaya yardımcı olur.
sorguları en etkili veri kaynaklarına yönlendirir.
tüm sistem kaynaklarının en verimli şekilde kullanılmasını sağlar.
gerçek sorgu profillerini izler.

Bu süreçte üretilen bilgiler, hangi toplamaların üretileceğini belirlemek için depo yönetimi süreci tarafından kullanılır. Bu işlem, genellikle bilgilerin veri ambarına düzenli olarak yüklenmesi sırasında çalışmaz.

Bu bölümde, bir veri ambarının veri ambarı tasarımı ve mimarisi için iş analizi çerçevesini tartışacağız.

İş Analizi Çerçevesi

İş analisti, piyasadaki diğer iş sahiplerini kazanmak için performansı ölçmek ve kritik ayarlamalar yapmak için veri ambarlarından bilgi alır. Bir veri ambarına sahip olmak aşağıdaki avantajları sunar:

Bir veri ambarı, bilgileri hızlı ve verimli bir şekilde toplayabildiğinden, iş üretkenliğini artırabilir.
Bir veri ambarı bize müşteriler ve öğeler hakkında tutarlı bir görünüm sağlar, bu nedenle müşteri ilişkilerini yönetmemize yardımcı olur.
Bir veri ambarı, uzun bir süre boyunca eğilimleri, kalıpları tutarlı ve güvenilir bir şekilde izleyerek maliyetleri düşürmeye de yardımcı olur.

Etkili ve verimli bir veri ambarı tasarlamak için iş ihtiyaçlarını anlamamız ve analiz etmemiz ve bir veri ambarı oluşturmamız gerekir. business analysis framework. Her kişinin bir veri ambarının tasarımına ilişkin farklı görüşleri vardır. Bu görüşler aşağıdaki gibidir -

The top-down view - Bu görünüm, bir veri ambarı için gereken ilgili bilgilerin seçilmesine olanak tanır.
The data source view - Bu görünüm, operasyonel sistem tarafından yakalanan, depolanan ve yönetilen bilgileri sunar.
The data warehouse view- Bu görünüm olgu tablolarını ve boyut tablolarını içerir. Veri ambarında depolanan bilgileri temsil eder.
The business query view - Verilerin son kullanıcı açısından görünümüdür.

Üç Katmanlı Veri Ambarı Mimarisi

Genellikle bir veri ambarları üç katmanlı bir mimari benimser. Veri ambarı mimarisinin üç katmanı aşağıdadır.

Bottom Tier- Mimarinin en alt katmanı, veri ambarı veritabanı sunucusudur. İlişkisel veritabanı sistemidir. Verileri alt kademeye beslemek için arka uç araçlarını ve yardımcı programlarını kullanıyoruz. Bu arka uç araçlar ve yardımcı programlar Çıkartma, Temizleme, Yükleme ve yenileme işlevlerini gerçekleştirir.
Middle Tier - Orta kademede, aşağıdaki yollardan biriyle uygulanabilecek OLAP Sunucumuz var.
- Genişletilmiş bir ilişkisel veritabanı yönetim sistemi olan İlişkisel OLAP (ROLAP) ile. ROLAP, çok boyutlu veriler üzerindeki işlemleri standart ilişkisel işlemlerle eşler.
- Çok boyutlu verileri ve işlemleri doğrudan uygulayan Çok Boyutlu OLAP (MOLAP) modeli ile.
Top-Tier- Bu katman, ön uç istemci katmanıdır. Bu katman, sorgu araçlarını ve raporlama araçlarını, analiz araçlarını ve veri madenciliği araçlarını içerir.

Aşağıdaki şema, veri ambarının üç katmanlı mimarisini göstermektedir -

Veri Ambarı Modelleri

Veri ambarı mimarisi perspektifinden bakıldığında, aşağıdaki veri ambarı modellerine sahibiz -

Sanal Depo
Veri pazarı
Kurumsal Depo

Sanal Depo

Data Mart

Data mart, kuruluş çapında verilerin bir alt kümesini içerir. Bu veri alt kümesi, bir kuruluşun belirli grupları için değerlidir.

Başka bir deyişle, veri pazarlarının belirli bir gruba özgü verileri içerdiğini iddia edebiliriz. Örneğin, pazarlama veri pazarı ürünler, müşteriler ve satışlarla ilgili verileri içerebilir. Veri reyonları öznelerle sınırlıdır.

Veri pazarları hakkında hatırlanması gereken noktalar -

Veri pazarlarını uygulamak için pencere tabanlı veya Unix / Linux tabanlı sunucular kullanılır. Düşük maliyetli sunucularda uygulanırlar.
Uygulama veri mart döngüleri, kısa zaman aralıklarında, yani aylar veya yıllar yerine haftalar halinde ölçülür.
Planlama ve tasarımı kuruluş çapında değilse, bir veri pazarının yaşam döngüsü uzun vadede karmaşık olabilir.
Veri pazarları küçüktür.
Veri reyonları departmanlara göre özelleştirilir.
Bir veri pazarının kaynağı, departmana göre yapılandırılmış veri ambarlarıdır.
Data mart esnektir.

Kurumsal Depo

Bir kurumsal depo, tüm organizasyona yayılan tüm bilgileri ve konuları toplar
Bize kurumsal çapta veri entegrasyonu sağlar.
Veriler, operasyonel sistemlerden ve harici bilgi sağlayıcılardan entegre edilmiştir.
Bu bilgiler birkaç gigabayttan yüzlerce gigabayt, terabayt veya ötesine kadar değişebilir.

Yük Yöneticisi

Bu bileşen, işlemi çıkarmak ve yüklemek için gerekli işlemleri gerçekleştirir.

Yük yöneticisinin boyutu ve karmaşıklığı, bir veri ambarından diğerine belirli çözümler arasında farklılık gösterir.

Yük Yöneticisi Mimarisi

Yük yöneticisi aşağıdaki işlevleri yerine getirir -

Verileri kaynak sistemden çıkarın.
Hızlı Çıkarılan verileri geçici veri deposuna yükleyin.
Veri ambarındakine benzer yapıya basit dönüşümler gerçekleştirin.

Kaynaktan Verileri Çıkarın

Veriler, operasyonel veri tabanlarından veya harici bilgi sağlayıcılardan alınır. Ağ geçitleri, verileri ayıklamak için kullanılan uygulama programlarıdır. Temel DBMS tarafından desteklenir ve istemci programının bir sunucuda çalıştırılmak üzere SQL oluşturmasına izin verir. Açık Veritabanı Bağlantısı (ODBC), Java Veritabanı Bağlantısı (JDBC), ağ geçidi örnekleridir.

Hızlı Yükleme

Toplam yük penceresini en aza indirmek için verilerin mümkün olan en hızlı zamanda depoya yüklenmesi gerekir.
Dönüşümler, veri işlemenin hızını etkiler.
Verileri, dönüşümleri ve kontrolleri uygulamadan önce ilişkisel veritabanına yüklemek daha etkilidir.
Ağ geçidi teknolojisi, büyük veri hacimleri söz konusu olduğunda performans gösterme eğiliminde olmadıkları için uygun değildir.

Basit Dönüşümler

Yükleme sırasında basit dönüşümler yapmak gerekebilir. Bu tamamlandıktan sonra karmaşık kontrolleri yapabilecek konumdayız. Aşağıdaki kontrolleri yapmamız gereken EPOS satış işlemini yüklediğimizi varsayalım:

Depo içinde gerekli olmayan tüm sütunları çıkarın.
Tüm değerleri gerekli veri türlerine dönüştürün.

Depo yöneticisi

Depo yönetimi sürecinden depo yöneticisi sorumludur. Üçüncü taraf sistem yazılımı, C programları ve kabuk komut dosyalarından oluşur.

Depo yöneticilerinin boyutu ve karmaşıklığı belirli çözümlere göre değişir.

Depo Yöneticisi Mimarisi

Bir depo yöneticisi aşağıdakileri içerir -

Kontrol süreci
Saklanan prosedürler veya SQL ile C
Yedekleme / Kurtarma aracı
SQL Komut Dosyaları

Depo Yöneticisi Tarafından Yapılan İşlemler

Bir depo yöneticisi, tutarlılık ve referans bütünlüğü kontrolleri gerçekleştirmek için verileri analiz eder.
Temel verilere göre dizinler, iş görünümleri, bölüm görünümleri oluşturur.
Yeni toplamalar oluşturur ve mevcut toplamaları günceller. Normalleştirmeler üretir.
Kaynak verileri yayınlanmış veri ambarına dönüştürür ve birleştirir.
Veri ambarındaki verileri yedekleyin.
Yakalanan ömrünün sonuna gelen verileri arşivler.

Note - Bir ambar yöneticisi ayrıca indeksi ve toplamaların uygun olup olmadığını belirlemek için sorgu profillerini analiz eder.

Sorgu Yöneticisi

Sorgu yöneticisi, sorguların uygun tablolara yönlendirilmesinden sorumludur.
Sorguları uygun tablolara yönlendirerek sorgulama ve yanıt oluşturma hızı artırılabilir.
Sorgu yöneticisi, kullanıcı tarafından sorulan sorguların yürütülmesini planlamaktan sorumludur.

Sorgu Yöneticisi Mimarisi

Aşağıdaki ekran görüntüsü bir sorgu yöneticisinin mimarisini göstermektedir. Aşağıdakileri içerir:

C aracı veya RDBMS aracılığıyla sorgu yeniden yönlendirme
Saklanan prosedürler
Sorgu yönetimi aracı
C aracı veya RDBMS aracılığıyla sorgu planlama
Üçüncü taraf yazılım aracılığıyla sorgu planlama

Detaylı bilgi

Ayrıntılı bilgi çevrimiçi olarak tutulmaz, bunun yerine bir sonraki ayrıntı düzeyine toplanır ve ardından banda arşivlenir. Veri ambarının ayrıntılı bilgi bölümü, ayrıntılı bilgileri starflake şemasında tutar. Birleştirilmiş verileri desteklemek için veri ambarına ayrıntılı bilgiler yüklenir.

Aşağıdaki şema, ayrıntılı bilgilerin nerede depolandığı ve nasıl kullanıldığına dair resimli bir izlenimi göstermektedir.

Note - Disk depolamasını en aza indirmek için ayrıntılı bilgi çevrimdışı tutulursa, arşivlenmeden önce verilerin çıkarıldığından, temizlendiğinden ve yıldız şemasına dönüştürüldüğünden emin olmalıyız.

Özet bilgi

Özet Bilgi, önceden tanımlanmış toplamaları depolayan veri ambarının bir parçasıdır. Bu toplamalar, depo yöneticisi tarafından oluşturulur. Özet Bilgi geçici olarak ele alınmalıdır. Değişen sorgu profillerine yanıt vermek için hareket halindeyken değişir.

Özet bilgilerle ilgili dikkat edilmesi gereken noktalar aşağıdaki gibidir -

Özet bilgiler, genel sorguların performansını hızlandırır.
Operasyonel maliyeti artırır.
Veri ambarına her yeni veri yüklendiğinde güncellenmesi gerekir.
Ayrıntılı bilgilerden yeni oluşturulabildiğinden yedeklenmemiş olabilir.

Çevrimiçi Analitik İşleme Sunucusu (OLAP), çok boyutlu veri modeline dayanır. Yöneticilerin ve analistlerin bilgiye hızlı, tutarlı ve etkileşimli erişim yoluyla bilgi edinmesine olanak tanır. Bu bölüm OLAP türlerini, OLAP üzerindeki işlemleri, OLAP ile istatistiksel veritabanları ve OLTP arasındaki farkı kapsar.

OLAP Sunucu Türleri

Dört tür OLAP sunucumuz var -

İlişkisel OLAP (ROLAP)
Çok Boyutlu OLAP (MOLAP)
Hibrit OLAP (HOLAP)
Özel SQL Sunucuları

İlişkisel OLAP

ROLAP sunucuları, ilişkisel arka uç sunucu ile istemci ön uç araçları arasına yerleştirilir. Depo verilerini depolamak ve yönetmek için ROLAP, ilişkisel veya genişletilmiş ilişkisel DBMS kullanır.

ROLAP aşağıdakileri içerir -

Toplama gezinme mantığının uygulanması.
Her bir DBMS arka ucu için optimizasyon.
Ek araçlar ve hizmetler.

Çok boyutlu OLAP

MOLAP, verilerin çok boyutlu görünümleri için dizi tabanlı çok boyutlu depolama motorları kullanır. Çok boyutlu veri depolarında, veri seti seyrekse depolama kullanımı düşük olabilir. Bu nedenle, birçok MOLAP sunucusu, yoğun ve seyrek veri kümelerini işlemek için iki düzeyde veri depolama temsili kullanır.

Hibrit OLAP

Hibrit OLAP, hem ROLAP hem de MOLAP'ın bir kombinasyonudur. Daha yüksek ROLAP ölçeklenebilirliği ve daha hızlı MOLAP hesaplaması sunar. HOLAP sunucuları, ayrıntılı bilgilerin büyük veri hacimlerini depolamaya izin verir. Toplamalar MOLAP deposunda ayrı olarak depolanır.

Özel SQL Sunucuları

Özel SQL sunucuları, salt okunur bir ortamda yıldız ve kar tanesi şemaları üzerinden SQL sorguları için gelişmiş sorgu dili ve sorgu işleme desteği sağlar.

OLAP İşlemleri

OLAP sunucuları çok boyutlu veri görünümüne dayandığından, OLAP işlemlerini çok boyutlu verilerde tartışacağız.

İşte OLAP işlemlerinin listesi -

Roll-up
Drill-down
Dilim ve zar
Pivot (döndür)

Toplama

Toplama, aşağıdaki yollardan herhangi biriyle bir veri küpü üzerinde toplama gerçekleştirir -

Bir boyut için konsept hiyerarşisinde yukarı tırmanarak
Boyut küçültme yoluyla

Aşağıdaki şema, toplamanın nasıl çalıştığını göstermektedir.

Toplama, boyut konumu için bir konsept hiyerarşisine tırmanılarak gerçekleştirilir.
Başlangıçta kavram hiyerarşisi "sokak <şehir <il <ülke" idi.
Toplanırken veriler, konum hiyerarşisi şehir düzeyinden ülke düzeyine yükseltilerek toplanır.
Veriler, ülkeler yerine şehirlere göre gruplandırılmıştır.
Toplama gerçekleştirildiğinde, veri küpünden bir veya daha fazla boyut kaldırılır.

Derinlemesine

Detaya inme, toplamanın tersi işlemidir. Aşağıdaki yollardan biriyle gerçekleştirilir -

Bir boyut için kavram hiyerarşisini düşürerek
Yeni bir boyut getirerek.

Aşağıdaki diyagram, detaya inmenin nasıl çalıştığını göstermektedir -

Detaya inme, boyut süresi için bir kavram hiyerarşisini aşağı indirerek gerçekleştirilir.
Başlangıçta kavram hiyerarşisi "gün <ay <çeyrek <yıl" idi.
Detaya inerken, zaman boyutu çeyrek düzeyinden ay düzeyine iner.
Detaya inme gerçekleştirildiğinde, veri küpünden bir veya daha fazla boyut eklenir.
Verileri daha az ayrıntılı verilerden son derece ayrıntılı verilere yönlendirir.

Dilim

Dilim işlemi, belirli bir küpten belirli bir boyut seçer ve yeni bir alt küp sağlar. Dilimin nasıl çalıştığını gösteren aşağıdaki diyagramı düşünün.

Burada, "zaman" boyutu için, zaman = "Q1" ölçütü kullanılarak Dilim gerçekleştirilir.
Bir veya daha fazla boyut seçerek yeni bir alt küp oluşturacaktır.

Zar

Dice, belirli bir küpten iki veya daha fazla boyut seçer ve yeni bir alt küp sağlar. Zarın işleyişini gösteren aşağıdaki diyagramı düşünün.

Aşağıdaki seçim kriterlerine göre küp üzerinde zar işlemi üç boyut içerir.

(konum = "Toronto" veya "Vancouver")
(zaman = "Q1" veya "Q2")
(öğe = "Mobil" veya "Modem")

Eksen

Pivot işlemi aynı zamanda rotasyon olarak da bilinir. Alternatif bir veri sunumu sağlamak için veri eksenlerini görünümde döndürür. Pivot işlemini gösteren aşağıdaki diyagramı düşünün.

OLAP ve OLTP

Sr.No.	Veri Ambarı (OLAP)	Operasyonel Veritabanı (OLTP)
1	Bilginin tarihsel olarak işlenmesini içerir.	Günlük işlemeyi içerir.
2	OLAP sistemleri, yöneticiler, yöneticiler ve analistler gibi bilgi çalışanları tarafından kullanılır.	OLTP sistemleri, katipler, DBA'lar veya veritabanı uzmanları tarafından kullanılır.
3	İşletmeyi analiz etmede kullanışlıdır.	İşin yürütülmesinde faydalıdır.
4	Bilgiye odaklanır.	Veri girişine odaklanır.
5	Yıldız Şeması, Kar Tanesi, Şema ve Gerçek Takımyıldızı Şemasına dayalıdır.	Varlık İlişkisi Modeline göre.
6	Geçmiş verileri içerir.	Mevcut verileri içerir.
7	Özetlenmiş ve birleştirilmiş veriler sağlar.	İlkel ve oldukça ayrıntılı veriler sağlar.
8	Verilerin özetlenmiş ve çok boyutlu görünümünü sağlar.	Verilerin ayrıntılı ve düz ilişkisel görünümünü sağlar.
9	Sayı veya kullanıcı sayısı yüzlerce.	Kullanıcı sayısı binlerdedir.
10	Erişilen kayıt sayısı milyon cinsindendir.	Erişilen kayıt sayısı onlarcadır.
11	Veritabanı boyutu 100 GB ile 1 TB arasındadır	Veritabanı boyutu 100 MB ile 1 GB arasındadır.
12	Oldukça esnek.	Yüksek performans sağlar.

İlişkisel OLAP sunucuları, ilişkisel arka uç sunucusu ile istemci ön uç araçları arasına yerleştirilir. Ambar verilerini depolamak ve yönetmek için ilişkisel OLAP ilişkisel veya genişletilmiş ilişkisel DBMS kullanır.

ROLAP aşağıdakileri içerir -

Toplama gezinme mantığının uygulanması
Her bir DBMS arka ucu için optimizasyon
Ek araçlar ve hizmetler

Hatırlanacak noktalar

ROLAP sunucuları oldukça ölçeklenebilir.
ROLAP araçları, çok sayıda boyutta büyük hacimli verileri analiz eder.
ROLAP araçları, son derece değişken ve değiştirilebilir verileri depolar ve analiz eder.

İlişkisel OLAP Mimarisi

ROLAP aşağıdaki bileşenleri içerir -

Veritabanı sunucusu
ROLAP sunucusu
Ön uç aracı.

Avantajlar

ROLAP sunucuları, mevcut RDBMS ile kolayca kullanılabilir.
Sıfır gerçek saklanamadığı için veriler verimli bir şekilde depolanabilir.
ROLAP araçları önceden hesaplanmış veri küplerini kullanmaz.
DSS mikro strateji sunucusu, ROLAP yaklaşımını benimser.

Dezavantajları

Zayıf sorgu performansı.
Kullanılan teknoloji mimarisine bağlı olarak bazı ölçeklenebilirlik sınırlamaları.

Çok boyutlu OLAP (MOLAP), verilerin çok boyutlu görünümleri için dizi tabanlı çok boyutlu depolama motorlarını kullanır. Çok boyutlu veri depolarında, veri kümesi seyrekse depolama kullanımı düşük olabilir. Bu nedenle, birçok MOLAP sunucusu, yoğun ve seyrek veri kümelerini işlemek için iki düzeyde veri depolama temsili kullanır.

Hatırlanması Gereken Noktalar -

MOLAP araçları, seçilen özetleme veya hesaplama düzeyine bakılmaksızın bilgileri tutarlı yanıt süresiyle işler.
MOLAP araçlarının, analiz için verileri depolamak üzere ilişkisel bir veritabanı oluşturmanın birçok karmaşıklığından kaçınması gerekir.
MOLAP araçları mümkün olan en hızlı performansa ihtiyaç duyar.
MOLAP sunucusu, yoğun ve seyrek veri kümelerini işlemek için iki düzeyli depolama temsilini benimser.
Daha yoğun alt küpler tanımlanır ve dizi yapısı olarak saklanır.
Seyrek alt küpler sıkıştırma teknolojisini kullanır.

MOLAP Mimarisi

MOLAP şu bileşenleri içerir -

Veritabanı sunucusu.
MOLAP sunucusu.
Ön uç aracı.

Avantajlar

MOLAP, önceden hesaplanmış özetlenmiş verilere en hızlı indekslemeye izin verir.
Daha büyük, daha az tanımlı verileri analiz etmesi gereken bir ağa bağlı kullanıcılara yardımcı olur.
Kullanımı daha kolay olduğundan MOLAP deneyimsiz kullanıcılar için uygundur.

Dezavantajları

MOLAP ayrıntılı veri içeremez.
Veri seti seyrekse, depolama kullanımı düşük olabilir.

MOLAP ve ROLAP

Sr.No.	MOLAP	ROLAP
1	Bilgi erişimi hızlıdır.	Bilgi erişimi nispeten yavaştır.
2	Veri kümelerini depolamak için seyrek dizi kullanır.	İlişkisel tablo kullanır.
3	MOLAP, kullanımı çok kolay olduğu için deneyimsiz kullanıcılar için çok uygundur.	ROLAP, deneyimli kullanıcılar için en uygunudur.
4	Veri küpleri için ayrı bir veritabanı tutar.	Veri ambarında bulunandan başka alan gerektirmeyebilir.
5	DBMS tesisi zayıf.	DBMS tesisi güçlüdür.

Şema, tüm veritabanının mantıksal bir açıklamasıdır. Tüm ilişkili veri öğeleri ve toplamalar dahil olmak üzere tüm kayıt türlerinin kayıtlarının adını ve açıklamasını içerir. Bir veritabanı gibi, bir veri ambarı da bir şemayı sürdürmeyi gerektirir. Bir veritabanı ilişkisel modeli kullanırken, bir veri ambarı Star, Snowflake ve Fact Constellation şemasını kullanır. Bu bölümde, bir veri ambarında kullanılan şemaları tartışacağız.

Yıldız Şeması

Bir yıldız şemasındaki her boyut, yalnızca tek boyutlu tablo ile temsil edilir.
Bu boyut tablosu, özellik kümesini içerir.
Aşağıdaki diyagram, bir şirketin satış verilerini dört boyuta, yani zamana, maddeye, şubeye ve konuma göre gösterir.

Merkezde bir olgu tablosu var. Dört boyutun her birinin anahtarlarını içerir.
Olgu tablosu, satılan dolar ve satılan birimler gibi nitelikleri de içerir.

Note- Her boyutun yalnızca bir boyut tablosu vardır ve her tablo bir dizi özelliği barındırır. Örneğin, konum boyut tablosu, {konum_anahtar, cadde, şehir, il_veya_durum, ülke} özellik kümesini içerir. Bu kısıtlama, veri yedekliliğine neden olabilir. Örneğin, "Vancouver" ve "Victoria" şehirlerinin ikisi de Kanada'nın British Columbia eyaletindedir. Bu tür şehirler için girişler, il_or_state ve country özellikleri boyunca veri fazlalığına neden olabilir.

Kar Tanesi Şeması

Snowflake şemasındaki bazı boyut tabloları normalleştirilmiştir.
Normalleştirme, verileri ek tablolara böler.
Yıldız şemasından farklı olarak, bir kar tanesi şemasındaki boyutlar tablosu normalleştirilir. Örneğin, yıldız şemasındaki öğe boyut tablosu normalleştirilir ve öğe ve tedarikçi tablosu olmak üzere iki boyut tablosuna bölünür.

Artık öğe boyut tablosu item_key, item_name, type, brand ve Supplier-key özelliklerini içerir.
Tedarikçi anahtarı, tedarikçi boyut tablosuna bağlıdır. Tedarikçi boyut tablosu, tedarikçi_anahtar ve tedarikçi_türü niteliklerini içerir.

Note - Snowflake şemasındaki normalizasyon nedeniyle artıklık azalır ve bu nedenle bakımı kolay hale gelir ve depolama alanı tasarrufu sağlar.

Gerçek Takımyıldızı Şeması

Bir olgu kümesinin birden çok olgu tablosu vardır. Aynı zamanda galaksi şeması olarak da bilinir.
Aşağıdaki şema, satış ve nakliye olmak üzere iki olgu tablosunu göstermektedir.

Satış bilgi tablosu yıldız şemasındakiyle aynıdır.
Gönderi bilgi tablosunun beş boyutu vardır: item_key, time_key, shipper_key, from_location, to_location.
Gönderim olgu tablosu ayrıca satılan dolar ve satılan birimler olmak üzere iki ölçü içerir.
Olgu tabloları arasında boyut tablolarını paylaşmak da mümkündür. Örneğin, zaman, öğe ve konum boyutu tabloları, satış ve sevkiyat bilgi tablosu arasında paylaşılır.

Şema Tanımı

Çok boyutlu şema, Veri Madenciliği Sorgu Dili (DMQL) kullanılarak tanımlanır. İki temel öğe olan küp tanımı ve boyut tanımı, veri ambarlarını ve veri reyonlarını tanımlamak için kullanılabilir.

Küp Tanımı için Sözdizimi

define cube < cube_name > [ < dimension-list > }: < measure_list >

Boyut Tanımı için Sözdizimi

define dimension < dimension_name > as ( < attribute_or_dimension_list > )

Yıldız Şeması Tanımı

Tartıştığımız yıldız şeması, Veri Madenciliği Sorgu Dili (DMQL) kullanılarak aşağıdaki gibi tanımlanabilir -

define cube sales star [time, item, branch, location]:   
    	   
dollars sold = sum(sales in dollars), units sold = count(*)    	  

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)        	
define dimension branch as (branch key, branch name, branch type)              	
define dimension location as (location key, street, city, province or state, country)

Kar Tanesi Şeması Tanımı

Snowflake şeması, DMQL kullanılarak aşağıdaki gibi tanımlanabilir -

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier (supplier key, supplier type))
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city (city key, city, province or state, country))

Gerçek Takımyıldızı Şeması Tanımı

Gerçek takımyıldız şeması, DMQL kullanılarak aşağıdaki gibi tanımlanabilir -

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year)
define dimension item as (item key, item name, brand, type, supplier type)
define dimension branch as (branch key, branch name, branch type)
define dimension location as (location key, street, city, province or state,country)
define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales
define dimension item as item in cube sales
define dimension shipper as (shipper key, shipper name, location as location in cube sales, shipper type)
define dimension from location as location in cube sales
define dimension to location as location in cube sales

Bölümleme, performansı artırmak ve verilerin kolay yönetimini kolaylaştırmak için yapılır. Bölümleme ayrıca sistemin çeşitli gereksinimlerini dengelemeye yardımcı olur. Her olgu tablosunu birden çok ayrı bölüme ayırarak, donanım performansını optimize eder ve veri ambarının yönetimini basitleştirir. Bu bölümde, farklı bölümleme stratejilerini tartışacağız.

Bölümleme Neden Gereklidir?

Bölümleme aşağıdaki nedenlerden dolayı önemlidir -

Kolay yönetim için,
Yedeklemeye / kurtarmaya yardımcı olmak için,
Performansı artırmak için.

Kolay Yönetim İçin

Bir veri ambarındaki olgu tablosu, boyut olarak yüzlerce gigabayta kadar büyüyebilir. Bu büyük boyuttaki olgu tablosunun tek bir varlık olarak yönetilmesi çok zordur. Bu nedenle bölümlemeye ihtiyacı var.

Yedekleme / Kurtarmaya Yardımcı Olmak İçin

Olgu tablosunu bölümlere ayırmazsak, olgu tablosunun tamamını tüm verilerle birlikte yüklememiz gerekir. Bölümleme, yalnızca düzenli olarak gerektiği kadar veri yüklememize izin verir. Yükleme süresini azaltır ve ayrıca sistemin performansını artırır.

Note- Yedekleme boyutunu azaltmak için, mevcut bölüm dışındaki tüm bölümler salt okunur olarak işaretlenebilir. Daha sonra bu bölümleri değiştirilemeyecekleri bir duruma getirebiliriz. Daha sonra yedeklenebilirler. Bu, yalnızca mevcut bölümün yedekleneceği anlamına gelir.

Performansı Artırmak İçin

Olgu tablosunu veri kümelerine bölerek sorgu prosedürleri geliştirilebilir. Sorgu performansı geliştirildi çünkü artık sorgu yalnızca ilgili bölümleri tarıyor. Tüm verileri taraması gerekmez.

Yatay Bölümleme

Bir olgu tablosunun bölümlenmesinin çeşitli yolları vardır. Yatay bölümlemede, veri ambarının yönetilebilirliği için gereksinimleri aklımızda tutmalıyız.

Zamana Göre Eşit Segmentlere Bölme

Bu bölümleme stratejisinde, olgu tablosu zaman aralığı temelinde bölümlenir. Burada her dönem, işletme içinde önemli bir saklama süresini temsil eder. Örneğin, kullanıcı şunları sorarsamonth to date datadaha sonra verileri aylık bölümlere ayırmak uygundur. Bölümlenmiş tabloları içlerindeki verileri kaldırarak yeniden kullanabiliriz.

Zamana Göre Farklı Boyutlu Segmentlere Bölme

Bu tür bir bölüm, yaşlı verilere seyrek erişilen yerlerde yapılır. Nispeten güncel veriler için bir dizi küçük bölüm, etkin olmayan veriler için daha büyük bölüm olarak uygulanır.

Dikkat Edilmesi Gereken Noktalar

Ayrıntılı bilgi çevrimiçi olarak erişilebilir durumda kalır.
Fiziksel tabloların sayısı nispeten küçük tutulur ve bu da işletim maliyetini düşürür.
Bu teknik, yakın tarih ve tüm tarih boyunca veri madenciliği yapan bir veri karışımının gerekli olduğu durumlarda uygundur.
Bu teknik, bölümleme profilinin düzenli olarak değiştiği durumlarda kullanışlı değildir, çünkü yeniden bölümleme, veri ambarının işletim maliyetini artıracaktır.

Farklı Bir Boyutta Bölme

Olgu tablosu, ürün grubu, bölge, tedarikçi veya başka herhangi bir boyut gibi zaman dışındaki boyutlara göre de bölümlenebilir. Bir örnek verelim.

Bir piyasa işlevinin, örneğin bir pazarlamada olduğu gibi farklı bölgesel departmanlara yapılandırıldığını varsayalım. state by statetemeli. Her bölge, kendi bölgesinde yakalanan bilgileri sorgulamak isterse, bilgi tablosunu bölgesel bölümlere ayırmanın daha etkili olduğu kanıtlanacaktır. Bu, ilgili olmayan bilgilerin taranmasını gerektirmediğinden sorguların hızlanmasına neden olur.

Dikkat Edilmesi Gereken Noktalar

Sorgunun ilgisiz verileri taraması gerekmez, bu da sorgu sürecini hızlandırır.
Bu teknik, boyutların gelecekte değişme ihtimalinin düşük olduğu durumlarda uygun değildir. Bu nedenle, boyutun gelecekte değişmeyeceğini belirlemeye değer.
Boyut değişirse, tüm olgu tablosunun yeniden bölümlenmesi gerekir.

Note - Önerilen boyut gruplamasının veri ambarının ömrü içinde değişmeyeceğinden emin olmadığınız sürece, bölümü yalnızca zaman boyutuna göre gerçekleştirmenizi öneririz.

Tablo Boyutuna Göre Bölme

Olgu tablosunu herhangi bir boyutta bölmek için net bir temel olmadığında, partition the fact table on the basis of their size.Önceden belirlenmiş boyutu kritik nokta olarak belirleyebiliriz. Tablo önceden belirlenen boyutu aştığında, yeni bir tablo bölümü oluşturulur.

Dikkat Edilmesi Gereken Noktalar

Bu bölümlemenin yönetilmesi karmaşıktır.
Her bölümde hangi verilerin depolandığını belirlemek için meta veriler gerekir.

Bölümleme Boyutları

Bir boyut çok sayıda girdi içeriyorsa, boyutların bölümlenmesi gerekir. Burada bir boyutun boyutunu kontrol etmeliyiz.

Zamanla değişen büyük bir tasarım düşünün. Karşılaştırmaları uygulamak için tüm varyasyonları saklamamız gerekirse, bu boyut çok büyük olabilir. Bu kesinlikle yanıt süresini etkiler.

Round Robin Bölmeleri

Round robin tekniğinde, yeni bir bölüme ihtiyaç duyulduğunda, eskisi arşivlenir. Kullanıcı erişim aracının doğru tablo bölümüne başvurmasına izin vermek için meta verileri kullanır.

Bu teknik, veri ambarındaki tablo yönetimi olanaklarının otomatikleştirilmesini kolaylaştırır.

Dikey Bölme

Dikey bölümleme, verileri dikey olarak böler. Aşağıdaki resimler dikey bölümlemenin nasıl yapıldığını göstermektedir.

Dikey bölümleme aşağıdaki iki şekilde gerçekleştirilebilir -

Normalization
Satır Bölme

Normalleştirme

Normalleştirme, veritabanı organizasyonunun standart ilişkisel yöntemidir. Bu yöntemde, satırlar tek bir satıra daraltılır, dolayısıyla alanı azaltır. Normalleştirmenin nasıl yapıldığını gösteren aşağıdaki tablolara bir göz atın.

Normalleştirme Öncesi Tablo

Ürün kimliği	Adet	Değer	sales_date	Store_id	Dükkan adı	yer	Bölge
30	5	3.67	3-Ağustos-13	16	güneşli	Bangalore	S
35	4	5.33	3-Eyl-13	16	güneşli	Bangalore	S
40	5	2.50	3-Eyl-13	64	san	Bombay	W
45	7	5.66	3-Eyl-13	16	güneşli	Bangalore	S

Normalleştirme Sonrası Tablo

Store_id	Dükkan adı	yer	Bölge
16	güneşli	Bangalore	W
64	san	Bombay	S

Ürün kimliği	Miktar	Değer	sales_date	Store_id
30	5	3.67	3-Ağustos-13	16
35	4	5.33	3-Eyl-13	16
40	5	2.50	3-Eyl-13	64
45	7	5.66	3-Eyl-13	16

Satır Bölme

Satır bölme, bölümler arasında bire bir harita bırakma eğilimindedir. Sıra bölmenin amacı, boyutunu küçülterek büyük masaya erişimi hızlandırmaktır.

Note - Dikey bölümlemeyi kullanırken, iki bölüm arasında büyük bir birleştirme işlemi gerçekleştirmeye gerek olmadığından emin olun.

Bölüm Anahtarını Tanımlayın

Doğru bölüm anahtarını seçmek çok önemlidir. Yanlış bir bölüm anahtarı seçmek, bilgi tablosunun yeniden düzenlenmesine yol açacaktır. Bir örnek verelim. Aşağıdaki tabloyu bölümlemek istediğimizi varsayalım.

Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_name

Herhangi bir anahtar üzerinde bölümlemeyi seçebiliriz. Olası iki anahtar olabilir

region
transaction_date

İşletmenin 30 coğrafi bölgede organize edildiğini ve her bölgenin farklı sayıda şubesi olduğunu varsayalım. Bu bize makul olan 30 bölüm verecek. Bu bölümleme yeterince iyidir, çünkü gereksinimlerimizin yakalanması, sorguların büyük çoğunluğunun kullanıcının kendi iş bölgesi ile sınırlı olduğunu göstermiştir.

Bölge yerine işlem_tarihine göre bölümlendirirsek, her bölgeden en son işlem bir bölümde olacaktır. Şimdi, kendi bölgesindeki verilere bakmak isteyen kullanıcının, birden çok bölümü sorgulaması gerekiyor.

Bu nedenle, doğru bölümleme anahtarını belirlemeye değer.

Meta Veri nedir?

Meta veriler, bir veri ambarına giden yol haritasıdır.
Bir veri ambarındaki meta veriler, ambar nesnelerini tanımlar.
Meta veriler bir dizin görevi görür. Bu dizin, karar destek sisteminin bir veri ambarının içeriğini bulmasına yardımcı olur.

Note- Bir veri ambarında, belirli bir veri ambarının veri adları ve tanımları için meta veriler oluştururuz. Bu meta verilerle birlikte, çıkarılan verilerin kaynağı olan çıkarılan herhangi bir veriye zaman damgası eklemek için ek meta veriler de oluşturulur.

Meta Veri Kategorileri

Meta veriler genel olarak üç kategoriye ayrılabilir -

Business Metadata - Veri sahipliği bilgilerine, iş tanımına ve değişen politikalara sahiptir.
Technical Metadata- Veritabanı sistem adlarını, tablo ve sütun adlarını ve boyutlarını, veri türlerini ve izin verilen değerleri içerir. Teknik meta veriler ayrıca birincil ve yabancı anahtar özellikleri ve dizinler gibi yapısal bilgileri içerir.
Operational Metadata- Veri para birimini ve veri kökenini içerir. Veri para birimi, verilerin etkin, arşivlenmiş veya temizlenmiş olup olmadığı anlamına gelir. Veri kökenleri, taşınan verilerin geçmişi ve ona uygulanan dönüşüm anlamına gelir.

Meta Verilerin Rolü

Meta veriler, bir veri ambarında çok önemli bir role sahiptir. Bir depodaki meta verilerin rolü, depo verilerinden farklıdır, ancak yine de önemli bir rol oynar. Meta verilerin çeşitli rolleri aşağıda açıklanmıştır.

Meta veriler bir dizin görevi görür.
Bu dizin, karar destek sisteminin veri ambarının içeriğini bulmasına yardımcı olur.
Meta veriler, veriler operasyonel ortamdan veri ambarı ortamına dönüştürüldüğünde verilerin haritalanması için karar destek sistemine yardımcı olur.
Meta veriler, güncel ayrıntılı veriler ile yüksek düzeyde özetlenmiş veriler arasında özetlemeye yardımcı olur.
Meta veriler ayrıca hafif ayrıntılı veriler ile yüksek düzeyde özetlenmiş veriler arasında özetlemeye yardımcı olur.
Meta veriler, sorgu araçları için kullanılır.
Meta veriler, çıkarma ve temizleme araçlarında kullanılır.
Meta veriler, raporlama araçlarında kullanılır.
Meta veriler, dönüştürme araçlarında kullanılır.
Meta veriler, yükleme işlevlerinde önemli bir rol oynar.

Aşağıdaki diyagram, meta verilerin rollerini gösterir.

Meta Veri Havuzu

Meta veri havuzu, bir veri ambarı sisteminin ayrılmaz bir parçasıdır. Aşağıdaki meta verilere sahiptir -

Definition of data warehouse- Veri ambarı yapısının açıklamasını içerir. Açıklama şema, görünüm, hiyerarşiler, türetilmiş veri tanımları ve veri pazarı konumları ve içerikleri ile tanımlanır.
Business metadata - Veri sahipliği bilgileri, iş tanımı ve değişen politikaları içerir.
Operational Metadata- Veri para birimini ve veri kökenini içerir. Veri para birimi, verilerin etkin, arşivlenmiş veya temizlenmiş olup olmadığı anlamına gelir. Veri kökenleri, taşınan verilerin geçmişi ve ona uygulanan dönüşüm anlamına gelir.
Data for mapping from operational environment to data warehouse - Kaynak veritabanları ve içerikleri, veri çıkarma, veri bölümü temizliği, dönüştürme kuralları, veri yenileme ve temizleme kurallarını içerir.
Algorithms for summarization - Boyut algoritmalarını, ayrıntı düzeyi, toplama, özetleme vb. Verileri içerir.

Meta Veri Yönetiminin Zorlukları

Meta verilerin önemi abartılamaz. Meta veriler, raporların doğruluğunu artırmaya yardımcı olur, veri dönüşümünü doğrular ve hesaplamaların doğruluğunu sağlar. Meta veriler aynı zamanda iş terimlerinin tanımını iş son kullanıcılarına zorlar. Meta verinin tüm bu kullanımları ile birlikte zorlukları da var. Bazı zorluklar aşağıda tartışılmaktadır.

Büyük bir organizasyondaki meta veriler, organizasyonun tamamına dağılmıştır. Bu meta veriler elektronik tablolarda, veritabanlarında ve uygulamalarda yayılır.
Meta veriler, metin dosyalarında veya multimedya dosyalarında mevcut olabilir. Bu verileri bilgi yönetimi çözümlerinde kullanmak için doğru bir şekilde tanımlanmalıdır.
Sektör genelinde kabul edilmiş standartlar yoktur. Veri yönetimi çözümü satıcılarının odak noktası dar.
Metadata geçirmenin kolay ve kabul edilmiş yöntemleri yoktur.

Neden Bir Veri Martına İhtiyacımız Var?

Aşağıda, bir veri pazarı oluşturmanın nedenleri listelenmiştir -

Verileri empoze etmek için bölümlemek için access control strategies.
Taranacak veri hacmini azaltarak sorguları hızlandırmak için.
Verileri farklı donanım platformlarına ayırmak için.
Verileri bir kullanıcı erişim aracına uygun bir biçimde yapılandırmak.

Note- Data marting işleminin maliyeti çok yüksek olabileceğinden başka bir nedenle data mart yapmayın. Veri alışverişi yapmadan önce, veri marting stratejisinin özel çözümünüz için uygun olduğundan emin olun.

Uygun Maliyetli Veri Martingi

Veri alışverişini uygun maliyetli hale getirmek için aşağıdaki adımları izleyin -

İşlevsel Bölmeleri Tanımlayın
Kullanıcı Erişim Aracı Gereksinimlerini Belirleyin
Erişim Kontrolü Sorunlarını Belirleyin

İşlevsel Bölmeleri Tanımlayın

Bu adımda, kuruluşun doğal işlevsel bölünmeleri olup olmadığını belirleriz. Departman bölünmeleri ararız ve departmanların bilgiyi kullanma şeklinin organizasyonun geri kalanından ayrı olup olmadığını belirleriz. Bir örnek verelim.

Her satıcının, bir ürün grubunun satışlarını maksimize etmekten sorumlu olduğu bir perakende organizasyonu düşünün. Bunun için aşağıdakiler değerli bilgilerdir -

günlük satış işlemi
haftalık satış tahmini
günlük olarak stok pozisyonu
günlük stok hareketleri

Satıcı, ilgilenmediği ürünlerle ilgilenmediğinden, veri alışverişi, ilgili ürün grubunun ilgilendiği verilerin bir alt kümesidir. Aşağıdaki şema, farklı kullanıcılar için veri alışverişini göstermektedir.

Fonksiyonel bölünmeyi belirlerken dikkate alınması gereken hususlar aşağıda verilmiştir -

Bölümün yapısı değişebilir.
Ürünler bir departmandan diğerine geçebilir.
Satıcı, satışlara ne olduğunu analiz etmek için diğer ürünlerin satış trendini sorgulayabilir.

Note - Bir veri marketi kullanmanın ticari faydalarını ve teknik fizibilitesini belirlememiz gerekiyor.

Kullanıcı Erişim Aracı Gereksinimlerini Belirleyin

Desteklemek için veri reyonlarına ihtiyacımız var user access toolsdahili veri yapıları gerektiren. Bu tür yapılardaki veriler, veri ambarının kontrolü dışındadır ancak düzenli olarak doldurulması ve güncellenmesi gerekir.

Doğrudan kaynak sistemden doldurulan bazı araçlar vardır, ancak bazıları olamaz. Bu nedenle, aracın kapsamı dışındaki ek gereksinimlerin gelecekte belirlenmesi gerekmektedir.

Note - Tüm erişim araçlarında verilerin tutarlılığını sağlamak için, verilerin doğrudan veri ambarından doldurulmaması, bunun yerine her aracın kendi veri mağazasına sahip olması gerekir.

Erişim Kontrolü Sorunlarını Belirleyin

Verilere yalnızca yetkili kullanıcılar tarafından erişilmesini sağlamak için gizlilik kuralları olmalıdır. Örneğin, bireysel bankacılık kurumu için bir veri ambarı, tüm hesapların aynı tüzel kişiliğe ait olmasını sağlar. Gizlilik yasaları sizi, belirli bir bankaya ait olmayan bilgilere erişimi tamamen engellemeye zorlayabilir.

Veri reyonları, veri ambarındaki veri segmentlerini fiziksel olarak ayırarak eksiksiz bir duvar oluşturmamızı sağlar. Olası gizlilik sorunlarını önlemek için ayrıntılı veriler veri ambarından kaldırılabilir. Her tüzel kişilik için data mart oluşturabilir ve detaylı hesap verileriyle veri ambarı üzerinden yükleyebiliriz.

Veri Martlarını Tasarlama

Veri reyonları, veri ambarı içinde yıldız tanesi şemasının daha küçük bir sürümü olarak tasarlanmalı ve veri ambarının veritabanı tasarımıyla eşleşmelidir. Veritabanı örnekleri üzerinde kontrolün korunmasına yardımcı olur.

Özetler, veri ambarında tasarlandıkları şekilde veri pazarlanır. Özet tablolar, yıldız tanesi şemasındaki tüm boyut verilerinin kullanılmasına yardımcı olur.

Veri Marting Maliyeti

Veri alışverişi için maliyet ölçüleri aşağıdaki gibidir -

Donanım ve Yazılım Maliyeti
Ağ Girişi
Zaman Aralığı Kısıtlamaları

Donanım ve Yazılım Maliyeti

Veri reyonları aynı donanım üzerinde oluşturulsa da, bazı ek donanım ve yazılım gerektirirler. Kullanıcı sorgularını işlemek için ek işlem gücü ve disk depolama gerektirir. Veri ambarında ayrıntılı veriler ve veri pazarı varsa, çoğaltılmış verileri depolamak ve yönetmek için ek maliyetle karşılaşacağız.

Note - Veri alışverişi, toplamalardan daha pahalıdır, bu nedenle alternatif bir strateji olarak değil ek bir strateji olarak kullanılmalıdır.

Ağ Girişi

Bir veri pazarı, veri ambarından farklı bir konumda olabilir, bu nedenle LAN veya WAN'ın içinde aktarılan veri hacimlerini işleme kapasitesine sahip olduğundan emin olmalıyız. data mart load process.

Zaman Aralığı Kısıtlamaları

Bir data mart yükleme işleminin kullanılabilir zaman penceresini ne ölçüde tüketeceği, dönüşümlerin karmaşıklığına ve sevk edilen veri hacimlerine bağlıdır. Kaç tane veri marketinin mümkün olduğunun belirlenmesi şunlara bağlıdır:

Ağ kapasitesi.
Zaman aralığı mevcut
Aktarılan veri hacmi
Veri pazarına veri eklemek için kullanılan mekanizmalar

Bir veri ambarının başarılı bir şekilde uygulanması için sistem yönetimi zorunludur. En önemli sistem yöneticileri -

Sistem konfigürasyon yöneticisi
Sistem planlama yöneticisi
Sistem olay yöneticisi
Sistem veritabanı yöneticisi
Sistem yedekleme kurtarma yöneticisi

Sistem Yapılandırma Yöneticisi

Sistem konfigürasyon yöneticisi, veri ambarının kurulumunun ve konfigürasyonunun yönetiminden sorumludur.
Yapılandırma yöneticisinin yapısı bir işletim sisteminden diğerine değişir.
Unix yapılandırma yapısında, yönetici satıcıdan satıcıya değişir.
Yapılandırma yöneticilerinin tek kullanıcı arayüzü vardır.
Konfigürasyon yöneticisinin arayüzü, sistemin tüm yönlerini kontrol etmemizi sağlar.

Note - En önemli yapılandırma aracı G / Ç yöneticisidir.

Sistem Çizelgeleme Yöneticisi

Veri ambarının başarılı bir şekilde uygulanmasından Sistem Çizelgeleme Yöneticisi sorumludur. Amacı, geçici sorgular planlamaktır. Her işletim sisteminin, bir tür toplu kontrol mekanizmasına sahip kendi programlayıcısı vardır. Bir sistem planlama yöneticisinin sahip olması gereken özelliklerin listesi aşağıdaki gibidir -

Küme veya MPP sınırları boyunca çalışın
Uluslararası saat farklarıyla başa çıkın
İş başarısızlığını ele alın
Birden çok sorguyu işleyin
İş önceliklerini destekleyin
Başarısız işleri yeniden başlatın veya yeniden sıraya koyun
İş tamamlandığında kullanıcıyı veya bir işlemi bilgilendirin
Sistem kesintilerinde iş programlarını koruyun
İşleri diğer kuyruklarda yeniden sıraya alın
Kuyrukların durdurulmasını ve başlatılmasını destekleyin
Kuyruğa alınan işleri günlüğe kaydet
Sıralar arası işlemeyle ilgilenin

Note - Yukarıdaki liste, iyi bir programlayıcının değerlendirilmesi için değerlendirme parametreleri olarak kullanılabilir.

Bir planlayıcının üstesinden gelebilmesi gereken bazı önemli işler aşağıdaki gibidir -

Günlük ve geçici sorgu planlama
Düzenli rapor gereksinimlerinin yerine getirilmesi
Veri yükleme
Veri işleme
Dizin oluşturma
Backup
Toplama oluşturma
Veri dönüşümü

Note - Veri ambarı bir küme veya MPP mimarisi üzerinde çalışıyorsa, sistem planlama yöneticisinin mimaride çalışabilmesi gerekir.

Sistem Olay Yöneticisi

Etkinlik yöneticisi bir tür yazılımdır. Olay yöneticisi, veri ambarı sisteminde tanımlanan olayları yönetir. Veri ambarının yapısı çok karmaşık olduğu için veri ambarını manuel olarak yönetemiyoruz. Bu nedenle, kullanıcının herhangi bir müdahalesi olmadan tüm olayları otomatik olarak işleyen bir araca ihtiyacımız var.

Note- Etkinlik yöneticisi, olayları izler ve bunlarla ilgilenir. Etkinlik yöneticisi, bu karmaşık veri ambarı sisteminde ters gidebilecek sayısız şeyi de izler.

Etkinlikler

Olaylar, kullanıcı veya sistemin kendisi tarafından oluşturulan eylemlerdir. Olayın, tanımlanmış bir eylemin ölçülebilir, gözlemlenebilir, meydana gelmesi olduğu not edilebilir.

Aşağıda, izlenmesi gereken yaygın olayların bir listesi verilmiştir.

Donanım arızası
Belirli anahtar disklerde alan tükeniyor
Ölmekte olan bir süreç
Hata döndüren bir süreç
805 eşiğini aşan CPU kullanımı
Veritabanı serileştirme noktalarında iç çekişme
Arabellek önbellek isabet oranları eşiği aşıyor veya altında kalıyor
Maksimum boyutuna ulaşan bir masa
Aşırı bellek değişimi
Yer sıkıntısı nedeniyle genişletilemeyen bir masa
G / Ç darboğazları sergileyen disk
Belirli eşiklere ulaşan geçici veya sıralama alanı kullanımı
Diğer herhangi bir veritabanı paylaşılan bellek kullanımı

Olaylarla ilgili en önemli şey, kendi başlarına icra edebilmeleri gerektiğidir. Olay paketleri, önceden tanımlanmış olaylar için prosedürleri tanımlar. Her bir olayla ilişkili kod, olay işleyicisi olarak bilinir. Bu kod, bir olay meydana geldiğinde çalıştırılır.

Sistem ve Veritabanı Yöneticisi

Sistem ve veritabanı yöneticisi iki ayrı yazılım parçası olabilir, ancak aynı işi yaparlar. Bu araçların amacı, belirli süreçleri otomatikleştirmek ve diğerlerinin yürütülmesini basitleştirmektir. Bir sistem ve veritabanı yöneticisi seçme kriterleri aşağıdaki gibidir -

kullanıcı kotasını artırmak.
kullanıcılara rol atama ve atamalarını kaldırma
profilleri kullanıcılara atayın ve atamasını kaldırın
veritabanı alanı yönetimi yapmak
alan kullanımını izleyin ve raporlayın
parçalanmış ve kullanılmayan alanı toparlayın
alanı ekle ve genişlet
kullanıcı ekle ve kaldır
kullanıcı şifresini yönet
özet veya geçici tabloları yönet
kullanıcıya geçici alan atama veya atamasını kaldırma
alanı eski veya tarihi geçmiş geçici tablolardan geri kazanmak
hata ve izleme günlüklerini yönetin
günlük ve izleme dosyalarına göz atmak için
yönlendirme hatası veya izleme bilgisi
hata ve izleme günlüğünü açma ve kapatma
sistem alanı yönetimi yapmak
alan kullanımını izleyin ve raporlayın
eski ve kullanılmayan dosya dizinlerini temizleyin
boşluk ekleyin veya genişletin.

Sistem Yedekleme Kurtarma Yöneticisi

Yedekleme ve kurtarma aracı, operasyonların ve yönetim personelinin verileri yedeklemesini kolaylaştırır. Sistem yedekleme yöneticisinin kullanılan program yöneticisi yazılımıyla entegre edilmesi gerektiğini unutmayın. Yedeklerin yönetimi için gerekli olan önemli özellikler aşağıdaki gibidir -

Scheduling
Yedek veri takibi
Veritabanı bilinci

Yedeklemeler yalnızca veri kaybına karşı koruma sağlamak için alınır. Hatırlanması gereken önemli noktalar aşağıdadır -

Yedekleme yazılımı, veri parçasının nerede ve ne zaman yedeklendiğine dair bir çeşit veritabanı tutacaktır.
Yedek kurtarma yöneticisi, bu veritabanına yönelik iyi bir ön uca sahip olmalıdır.
Yedekleme kurtarma yazılımı veri tabanına duyarlı olmalıdır.
Veritabanının farkında olan yazılım, veritabanı terimleri ile ele alınabilir ve uygun olmayacak yedeklemeleri gerçekleştirmez.

Süreç yöneticileri, veri ambarının hem içine hem de dışına veri akışını sağlamaktan sorumludur. Üç farklı tür süreç yöneticisi vardır -

Yük yöneticisi
Depo yöneticisi
Sorgu yöneticisi

Veri Ambarı Yük Yöneticisi

Yük yöneticisi, verileri ayıklamak ve veritabanına yüklemek için gerekli işlemleri gerçekleştirir. Bir yük yöneticisinin boyutu ve karmaşıklığı, bir veri ambarından diğerine belirli çözümler arasında farklılık gösterir.

Yük Yöneticisi Mimarisi

Yük yöneticisi aşağıdaki işlevleri yerine getirir -

Kaynak sistemden verileri çıkarın.
Çıkarılan verileri hızlı bir şekilde geçici veri deposuna yükleyin.
Veri ambarındakine benzer yapıya basit dönüşümler gerçekleştirin.

Kaynaktan Verileri Çıkarın

Veriler, operasyonel veri tabanlarından veya harici bilgi sağlayıcılardan alınır. Ağ geçitleri, verileri ayıklamak için kullanılan uygulama programlarıdır. Temel DBMS tarafından desteklenir ve istemci programının bir sunucuda çalıştırılmak üzere SQL oluşturmasına izin verir. Açık Veritabanı Bağlantısı (ODBC) ve Java Veritabanı Bağlantısı (JDBC), ağ geçidi örnekleridir.

Hızlı Yükleme

Toplam yük penceresini en aza indirmek için, verilerin mümkün olan en hızlı zamanda depoya yüklenmesi gerekir.
Dönüşümler, veri işlemenin hızını etkiler.
Verileri, dönüşümleri ve kontrolleri uygulamadan önce ilişkisel bir veritabanına yüklemek daha etkilidir.
Ağ geçidi teknolojisi, büyük veri hacimleri söz konusu olduğunda verimsiz oldukları için uygun değildir.

Basit Dönüşümler

Yükleme sırasında basit dönüşümler yapmak gerekebilir. Basit dönüşümleri tamamladıktan sonra karmaşık kontroller yapabiliriz. EPOS satış işlemini yüklediğimizi varsayalım, aşağıdaki kontrolleri yapmamız gerekiyor -

Depo içinde gerekli olmayan tüm sütunları çıkarın.
Tüm değerleri gerekli veri türlerine dönüştürün.

Depo yöneticisi

Depo yöneticisi, depo yönetimi sürecinden sorumludur. Üçüncü taraf bir sistem yazılımı, C programları ve kabuk komut dosyalarından oluşur. Bir depo yöneticisinin boyutu ve karmaşıklığı, belirli çözümlere göre değişir.

Depo Yöneticisi Mimarisi

Bir depo yöneticisi aşağıdakileri içerir -

Kontrol süreci
Saklanan prosedürler veya SQL ile C
Yedekleme / Kurtarma aracı
SQL betikleri

Depo Yöneticisinin İşlevleri

Bir depo yöneticisi aşağıdaki işlevleri yerine getirir -

Tutarlılık ve referans bütünlüğü kontrolleri gerçekleştirmek için verileri analiz eder.
Temel verilere göre dizinler, iş görünümleri, bölüm görünümleri oluşturur.
Yeni toplamalar oluşturur ve mevcut toplamaları günceller.
Normalleştirmeler üretir.
Geçici deponun kaynak verilerini, yayınlanan veri ambarına dönüştürür ve birleştirir.
Veri ambarındaki verileri yedekler.
Yakalanan ömrünün sonuna gelen verileri arşivler.

Note - Depo Yöneticisi, dizinin ve toplamaların uygun olup olmadığını belirlemek için sorgu profillerini analiz eder.

Sorgu Yöneticisi

Sorgu yöneticisi, sorguları uygun tablolara yönlendirmekten sorumludur. Sorguları uygun tablolara yönlendirerek sorgu talebi ve yanıt sürecini hızlandırır. Ek olarak, sorgu yöneticisi, kullanıcı tarafından gönderilen sorguların yürütülmesini planlamaktan sorumludur.

Sorgu Yöneticisi Mimarisi

Bir sorgu yöneticisi aşağıdaki bileşenleri içerir -

C aracı veya RDBMS aracılığıyla sorgu yeniden yönlendirme
Saklanan prosedürler
Sorgu yönetimi aracı
C aracı veya RDBMS aracılığıyla sorgu planlama
Üçüncü taraf yazılım aracılığıyla sorgu planlama

Sorgu Yöneticisinin İşlevleri

Verileri kullanıcıya anlayacağı bir biçimde sunar.
Son kullanıcı tarafından gönderilen sorguların yürütülmesini planlar.
Depo yöneticisinin hangi dizinlerin ve toplamaların uygun olduğunu belirlemesine izin vermek için sorgu profillerini depolar.

Bir veri ambarının amacı, büyük miktarlarda veriyi kullanıcılar için kolayca erişilebilir kılmak, böylece kullanıcıların bir bütün olarak işletme hakkında bilgi almalarına izin vermektir. Ancak verilere, bilgilere erişime engel olabilecek bazı güvenlik kısıtlamaları uygulanabileceğini biliyoruz. Analistin kısıtlı bir veri görüşüne sahip olması durumunda, işletme içindeki trendlerin tam bir resmini yakalamak imkansızdır.

Her bir analistten gelen veriler özetlenebilir ve farklı özetlerin bir araya getirilebileceği yönetime aktarılabilir. Özetlerin toplamaları bir bütün olarak toplamanınki ile aynı olamayacağından, birisi verileri bir bütün olarak analiz etmediği sürece verilerdeki bazı bilgi eğilimlerini gözden kaçırmak mümkündür.

Güvenlik gereksinimleri

Güvenlik özelliklerinin eklenmesi, veri ambarının performansını etkiler, bu nedenle güvenlik gereksinimlerini olabildiğince erken belirlemek önemlidir. Veri ambarı devreye girdikten sonra güvenlik özellikleri eklemek zordur.

Veri ambarının tasarım aşamasında, hangi veri kaynaklarının daha sonra eklenebileceğini ve bu veri kaynaklarını eklemenin etkisinin ne olacağını aklımızda tutmalıyız. Tasarım aşamasında aşağıdaki olasılıkları göz önünde bulundurmalıyız.

Yeni veri kaynaklarının yeni güvenlik ve / veya denetim kısıtlamalarının uygulanmasını gerektirip gerektirmeyeceği?
Genel olarak mevcut olan verilere erişimi kısıtlı olan yeni kullanıcıların ekleyip eklemediği?

Bu durum, gelecekteki kullanıcılar ve veri kaynakları iyi bilinmediğinde ortaya çıkar. Böyle bir durumda, olası gereksinimleri bilmek için iş bilgisini ve veri ambarının amacını kullanmamız gerekir.

Aşağıdaki etkinlikler güvenlik önlemlerinden etkilenir -

Kullanıcı erişimi
Veri yükleme
Veri hareketi
Sorgu oluşturma

Kullanıcı erişimi

Önce verileri sınıflandırmamız ve ardından kullanıcıları erişebilecekleri verilere göre sınıflandırmamız gerekiyor. Yani kullanıcılar erişebilecekleri verilere göre sınıflandırılır.

Data Classification

Verileri sınıflandırmak için aşağıdaki iki yaklaşım kullanılabilir -

Veriler hassasiyetine göre sınıflandırılabilir. Çok hassas veriler, yüksek düzeyde kısıtlı olarak sınıflandırılır ve daha az hassas veriler daha az kısıtlayıcı olarak sınıflandırılır.
Veriler ayrıca iş işlevine göre sınıflandırılabilir. Bu kısıtlama, yalnızca belirli kullanıcıların belirli verileri görüntülemesine izin verir. Burada kullanıcıları, verilerin yalnızca ilgilendikleri ve sorumlu oldukları kısmını görüntüleyecek şekilde kısıtlıyoruz.

İkinci yaklaşımda bazı sorunlar var. Anlamak için bir örnek verelim. Bir banka için veri ambarını oluşturduğunuzu varsayalım. Veri ambarında depolanan verilerin tüm hesaplar için işlem verileri olduğunu düşünün. Buradaki soru, işlem verilerini kimlerin görmesine izin verildiğidir. Çözüm, verileri işleve göre sınıflandırmaktır.

User classification

Kullanıcıları sınıflandırmak için aşağıdaki yaklaşımlar kullanılabilir -

Kullanıcılar, bir organizasyondaki kullanıcıların hiyerarşisine göre sınıflandırılabilir, yani kullanıcılar departmanlara, bölümlere, gruplara vb. Göre sınıflandırılabilir.
Kullanıcılar, rollerine göre departmanlar arasında gruplandırılan kişilerle rollerine göre de sınıflandırılabilir.

Classification on basis of Department

Kullanıcıların satış ve pazarlama departmanından olduğu bir veri ambarı örneği verelim. Farklı departmanlara odaklanan erişim ile yukarıdan aşağıya şirket görünümüne göre güvenliğe sahip olabiliriz. Ancak, farklı düzeylerdeki kullanıcılar için bazı kısıtlamalar olabilir. Bu yapı aşağıdaki diyagramda gösterilmektedir.

Ancak her departman farklı verilere erişirse, her departman için güvenlik erişimini ayrı ayrı tasarlamalıyız. Bu, departman veri reyonları ile sağlanabilir. Bu veri reyonları veri ambarından ayrıldığından, her veri pazarı için ayrı güvenlik kısıtlamaları uygulayabiliriz. Bu yaklaşım aşağıdaki şekilde gösterilmektedir.

Classification Based on Role

Veriler genel olarak tüm departmanlar için mevcutsa, rol erişim hiyerarşisini izlemek yararlıdır. Diğer bir deyişle, verilere genel olarak tüm departmanlar tarafından erişiliyorsa, kullanıcının rolüne göre güvenlik kısıtlamaları uygulayın. Rol erişim hiyerarşisi aşağıdaki şekilde gösterilmektedir.

Denetim Gereklilikleri

Denetim, güvenliğin bir alt kümesi, maliyetli bir faaliyettir. Denetim, sistemde ağır ek yüklere neden olabilir. Bir denetimi zamanında tamamlamak için daha fazla donanıma ihtiyacımız var ve bu nedenle, mümkün olan her yerde denetimin kapatılması önerilir. Denetim gereksinimleri aşağıdaki şekilde kategorize edilebilir:

Connections
Disconnections
Veri erişimi
Veri değişikliği

Note- Yukarıda belirtilen kategorilerin her biri için, başarıyı, başarısızlığı veya her ikisini birden denetlemek gerekir. Güvenlik nedenleri açısından arızaların denetimi çok önemlidir. Başarısızlığın denetlenmesi, yetkisiz veya hileli erişimi vurgulayabileceği için önemlidir.

Ağ Gereksinimleri

Ağ güvenliği, diğer menkul kıymetler kadar önemlidir. Ağ güvenliği gereksinimini göz ardı edemeyiz. Aşağıdaki konuları dikkate almamız gerekiyor -

Verileri veri ambarına aktarmadan önce şifrelemek gerekli mi?
Verilerin alabileceği ağ yollarıyla ilgili kısıtlamalar var mı?

Bu kısıtlamaların dikkatlice değerlendirilmesi gerekir. Hatırlanması gereken noktalar aşağıdadır -

Şifreleme ve şifre çözme süreci genel giderleri artıracaktır. Daha fazla işlem gücü ve işlem süresi gerektirir.
Sistem halihazırda yüklü bir sistem ise şifreleme maliyeti yüksek olabilir çünkü şifreleme kaynak sistem tarafından karşılanır.

Veri Hareketi

Verileri taşırken olası güvenlik etkileri vardır. Bazı kısıtlanmış verileri yüklenecek düz bir dosya olarak aktarmamız gerektiğini varsayalım. Veriler veri ambarına yüklendiğinde aşağıdaki sorular ortaya çıkar -

Düz dosya nerede saklanır?
Bu disk alanına kimler erişebilir?

Bu düz dosyaların yedeklenmesinden bahsedersek, aşağıdaki sorular ortaya çıkar -

Şifrelenmiş veya şifresi çözülmüş sürümleri yedekliyor musunuz?
Bu yedeklemelerin ayrı olarak saklanan özel teyplere yapılması gerekiyor mu?
Bu kasetlere kimin erişimi var?

Sorgu sonuç kümeleri gibi diğer bazı veri taşıma biçimlerinin de dikkate alınması gerekir. Geçici tablo oluşturulurken sorulan sorular şu şekildedir:

Bu geçici masa nerede tutulacak?
Böyle bir tabloyu nasıl görünür kılarsınız?

Güvenlik kısıtlamalarının kazara ihlal edilmesinden kaçınmalıyız. Kısıtlanmış verilere erişimi olan bir kullanıcı, erişilebilir geçici tablolar oluşturabilirse, veriler yetkili olmayan kullanıcılar tarafından görülebilir. Kısıtlı verilere erişimi olan kullanıcılar için ayrı bir geçici alana sahip olarak bu sorunun üstesinden gelebiliriz.

Dokümantasyon

Denetim ve güvenlik gereksinimlerinin uygun şekilde belgelendirilmesi gerekir. Bu, gerekçelendirmenin bir parçası olarak ele alınacaktır. Bu belge şuradan toplanan tüm bilgileri içerebilir -

Veri sınıflandırması
Kullanıcı sınıflandırması
Ağ gereksinimleri
Veri taşıma ve depolama gereksinimleri
Tüm denetlenebilir eylemler

Güvenliğin Tasarım Üzerindeki Etkisi

Güvenlik, uygulama kodunu ve geliştirme zaman çizelgelerini etkiler. Güvenlik aşağıdaki alanı etkiler -

Uygulama geliştirme
Veri tabanı tasarımı
Testing

Uygulama geliştirme

Güvenlik, genel uygulama geliştirmeyi etkiler ve ayrıca veri ambarının yük yöneticisi, ambar yöneticisi ve sorgu yöneticisi gibi önemli bileşenlerinin tasarımını da etkiler. Yük yöneticisi, kaydı filtrelemek ve farklı konumlara yerleştirmek için kod kontrol edilmesini gerektirebilir. Belirli verileri gizlemek için daha fazla dönüştürme kuralı da gerekebilir. Ayrıca, herhangi bir ekstra nesneyi işlemek için fazladan meta veri gereksinimleri olabilir.

Ekstra görünümler oluşturmak ve sürdürmek için, depo yöneticisi güvenliği sağlamak için ekstra kodlar isteyebilir. Verilerin mevcut olmaması gereken bir konuma taşınması için kandırılmasını önlemek için veri ambarına fazladan kontrollerin kodlanması gerekebilir. Sorgu yöneticisi, değişikliklerin herhangi bir erişim kısıtlamasını işlemesini gerektirir. Sorgu yöneticisinin tüm ekstra görünümlerden ve toplamalardan haberdar olması gerekir.

Veri tabanı tasarımı

Veritabanı düzeni de etkilenir çünkü güvenlik önlemleri uygulandığında görünüm ve tabloların sayısında artış olur. Güvenlik eklemek, veritabanının boyutunu artırır ve dolayısıyla veritabanı tasarımı ve yönetiminin karmaşıklığını artırır. Ayrıca, yedekleme yönetimi ve kurtarma planına karmaşıklık katacaktır.

Test yapmak

Veri ambarını test etmek karmaşık ve uzun bir süreçtir. Veri ambarına güvenlik eklemek, test süresinin karmaşıklığını da etkiler. Testi aşağıdaki iki şekilde etkiler -

Entegrasyon ve sistem testi için gereken süreyi artıracaktır.
Test paketinin boyutunu artıracak test edilecek ek işlevler vardır.

Veri ambarı karmaşık bir sistemdir ve büyük miktarda veri içerir. Bu nedenle, ihtiyaca göre gelecekte kurtarılmaya hazır olması için tüm verilerin yedeklenmesi önemlidir. Bu bölümde, yedekleme stratejisinin tasarlanmasındaki sorunları tartışacağız.

Yedekleme Terminolojileri

Daha fazla ilerlemeden önce, aşağıda tartışılan bazı yedekleme terminolojilerini bilmeniz gerekir.

Complete backup- Aynı anda tüm veritabanını yedekler. Bu yedekleme, tüm veritabanı dosyalarını, kontrol dosyalarını ve günlük dosyalarını içerir.
Partial backup- Adından da anlaşılacağı gibi, veritabanının tam bir yedeğini oluşturmaz. Kısmi yedekleme, büyük veritabanlarında çok kullanışlıdır çünkü veritabanının çeşitli bölümlerinin her gün bir döngü içinde yedeklendiği ve böylece tüm veritabanının haftada bir etkin bir şekilde yedeklendiği bir stratejiye izin verir.
Cold backup- Veritabanı tamamen kapalıyken soğuk yedekleme alınır. Çok örnekli ortamda, tüm örnekler kapatılmalıdır.
Hot backup- Veritabanı motoru çalışır durumdayken sıcak yedekleme alınır. Sıcak yedeklemenin gereksinimleri RDBMS'den RDBMS'ye değişir.
Online backup - Sıcak yedeklemeye oldukça benzer.

Donanım Yedeklemesi

Yedekleme için hangi donanımın kullanılacağına karar vermek önemlidir. Yedekleme ve geri yükleme işleminin hızı, kullanılan donanıma, donanımın nasıl bağlandığına, ağın bant genişliğine, yedekleme yazılımına ve sunucunun G / Ç sisteminin hızına bağlıdır. Burada mevcut olan bazı donanım seçeneklerini ve bunların artılarını ve eksilerini tartışacağız. Bu seçenekler aşağıdaki gibidir -

Bant Teknolojisi
Disk Yedeklemeleri

Bant Teknolojisi

Bant seçimi aşağıdaki şekilde kategorize edilebilir -

Teyp ortamı
Bağımsız teyp sürücüleri
Bant istifleyiciler
Bant siloları

Tape Media

Birkaç çeşit teyp ortamı vardır. Bazı teyp ortamı standartları aşağıdaki tabloda listelenmiştir -

Teyp Ortamı	Kapasite	G / Ç oranları
DLT	40 GB	3 MB / sn
3490e	1,6 GB	3 MB / sn
8 mm	14 GB	1 MB / sn

Dikkate alınması gereken diğer faktörler aşağıdaki gibidir:

Bant ortamının güvenilirliği
Birim başına teyp ortamı maliyeti
Scalability
Teyp sistemine yükseltme maliyeti
Birim başına teyp ortamı maliyeti
Bant ortamının raf ömrü

Standalone Tape Drives

Teyp sürücüleri aşağıdaki şekillerde bağlanabilir -

Doğrudan sunucuya
Ağa uygun cihazlar olarak
Uzaktan diğer makineye

Teyp sürücülerini bir veri ambarına bağlamada sorunlar olabilir.

Sunucunun 48 düğümlü bir MPP makinesi olduğunu düşünün. Teyp sürücüsünü bağlayacak düğümü bilmiyoruz ve sunucuda en az kesinti ve en az dahili G / Ç gecikmesi ile en iyi performansı elde etmek için bunları sunucu düğümlerine nasıl yayacağımızı bilmiyoruz.
Teyp sürücüsünü ağa uygun bir aygıt olarak bağlamak, ağın yüksek veri aktarım hızlarını karşılayabilmesini gerektirir. İhtiyaç duyduğunuz süre boyunca yeterli bant genişliğinin mevcut olduğundan emin olun.
Teyp sürücülerinin uzaktan bağlanması da yüksek bant genişliği gerektirir.

Bant İstifleyiciler

Tek bir teyp sürücüsüne birden çok teyp yükleme yöntemi, teyp istifleyicileri olarak bilinir. İstifleyici, işini bitirdiğinde geçerli bandı çıkarır ve sonraki bandı yükler, bu nedenle bir seferde erişilebilecek yalnızca bir bant kullanılabilir. Fiyat ve yetenekler değişebilir, ancak ortak yetenek, gözetimsiz yedekleme yapabilmeleridir.

Bant Siloları

Bant siloları büyük depo kapasiteleri sağlar. Bant siloları binlerce bandı depolayabilir ve yönetebilir. Birden çok teyp sürücüsünü entegre edebilirler. Sakladıkları bantları etiketlemek ve saklamak için yazılım ve donanıma sahipler. Silonun bir ağ veya özel bir bağlantı üzerinden uzaktan bağlanması çok yaygındır. Bağlantının bant genişliğinin işe uygun olduğundan emin olmalıyız.

Disk Yedeklemeleri

Disk yedekleme yöntemleri şunlardır:

Diskten diske yedeklemeler
Ayna kırılması

Bu yöntemler OLTP sisteminde kullanılmaktadır. Bu yöntemler, veritabanı arıza süresini en aza indirir ve kullanılabilirliği en üst düzeye çıkarır.

Disk-to-Disk Backups

Burada yedekleme teypten ziyade diskte alınır. Diskten diske yedeklemeler aşağıdaki nedenlerle yapılır -

İlk yedeklemelerin hızı
Geri yükleme hızı

Verileri diskten diske yedeklemek, teybe göre çok daha hızlıdır. Ancak, yedeklemenin ara adımıdır. Daha sonra veriler teybe yedeklenir. Diskten diske yedeklemenin diğer bir avantajı, size en son yedeklemenin çevrimiçi bir kopyasını vermesidir.

Mirror Breaking

Buradaki fikir, çalışma günü boyunca dayanıklılık için disklerin yansıtılmasıdır. Yedekleme gerektiğinde, yansıtma setlerinden biri kırılabilir. Bu teknik, diskten diske yedeklemelerin bir çeşididir.

Note - Yedeklemenin tutarlılığını sağlamak için veritabanının kapatılması gerekebilir.

Optik Müzik Kutuları

Optik müzik kutuları, verilerin hat yakınında saklanmasına izin verir. Bu teknik, çok sayıda optik diskin, bir bant istifleyici veya bir bant silosu ile aynı şekilde yönetilmesine izin verir. Bu tekniğin dezavantajı, disklerden daha yavaş yazma hızına sahip olmasıdır. Ancak optik ortam, onları arşivleme için iyi bir ortam seçeneği haline getiren uzun ömür ve güvenilirlik sağlar.

Yazılım Yedeklemeleri

Yedekleme işlemine yardımcı olan yazılım araçları vardır. Bu yazılım araçları bir paket olarak gelir. Bu araçlar yalnızca yedekleme almakla kalmaz, aynı zamanda yedekleme stratejilerini etkin bir şekilde yönetebilir ve kontrol edebilir. Piyasada pek çok yazılım paketi bulunmaktadır. Bunlardan bazıları aşağıdaki tabloda listelenmiştir -

Paket ismi	SATICI
Networker	Legato
ADSM	IBM
Dönem	Epoch Sistemleri
Omniback II	HP
İskenderiye	Sıralı

Yazılım Paketlerini Seçme Kriterleri

En iyi yazılım paketini seçme kriterleri aşağıda listelenmiştir -

Teyp sürücüleri eklendikçe ürün ne kadar ölçeklenebilir?
Paketin istemci-sunucu seçeneği var mı, yoksa veritabanı sunucusunun kendisinde mi çalışması gerekiyor?
Küme ve MPP ortamlarında çalışacak mı?
Ne derece paralellik gereklidir?
Paket tarafından hangi platformlar destekleniyor?
Paket, teyp içerikleri hakkındaki bilgilere kolay erişimi destekliyor mu?
Paket veritabanı farkında mı?
Paket tarafından hangi teyp sürücüsü ve teyp ortamı destekleniyor?

Bir veri ambarı gelişmeye devam ediyor ve kullanıcının gelecekte hangi sorguyu göndereceği tahmin edilemez. Bu nedenle, bir veri ambarı sistemini ayarlamak daha zor hale gelir. Bu bölümde, bir veri ambarının performans, veri yükü, sorgular vb. Gibi farklı yönlerinin nasıl ayarlanacağını tartışacağız.

Veri Ambarı Ayarlamadaki Zorluklar

Bir veri ambarını ayarlamak, aşağıdaki nedenlerden dolayı zor bir prosedürdür -

Veri ambarı dinamiktir; asla sabit kalmaz.
Kullanıcının gelecekte hangi sorguyu göndereceğini tahmin etmek çok zordur.
İş gereksinimleri zamanla değişir.
Kullanıcılar ve profilleri değişmeye devam ediyor.
Kullanıcı bir gruptan diğerine geçebilir.
Depodaki veri yükü de zamanla değişir.

Note - Tam bir veri ambarı bilgisine sahip olmak çok önemlidir.

Performans değerlendirme

İşte performansın objektif ölçümlerinin bir listesi -

Ortalama sorgu yanıt süresi
Tarama oranları
Günlük sorgu başına kullanılan süre
İşlem başına bellek kullanımı
G / Ç işlem oranları

Hatırlanması gereken noktalar aşağıdadır.

Hizmet seviyesi sözleşmesinde (SLA) önlemlerin belirtilmesi gerekir.
Zaten gerekli olandan daha iyiyse, yanıt süresini ayarlamaya çalışmanın hiçbir faydası yoktur.
Performans değerlendirmesi yapılırken gerçekçi beklentilere sahip olmak esastır.
Kullanıcıların makul beklentilere sahip olması da önemlidir.
Sistemin karmaşıklığını kullanıcıdan gizlemek için toplamalar ve görünümler kullanılmalıdır.
Kullanıcının sizin ayarlamadığınız bir sorguyu yazması da mümkündür.

Veri Yük Ayarı

Veri yükü, gece boyunca işlemenin kritik bir parçasıdır. Veri yükleme tamamlanana kadar başka hiçbir şey çalışamaz. Bu, sisteme giriş noktasıdır.

Note- Verilerin aktarılmasında veya verilerin ulaşmasında bir gecikme olursa, tüm sistem kötü bir şekilde etkilenir. Bu nedenle, önce veri yükünü ayarlamak çok önemlidir.

Aşağıda tartışılan çeşitli veri yükünü ayarlama yaklaşımları vardır -

En yaygın yaklaşım, verileri kullanarak veri eklemektir. SQL Layer. Bu yaklaşımda, normal kontroller ve kısıtlamaların yapılması gerekir. Veriler tabloya eklendiğinde, kod, verileri eklemek için yeterli alan olup olmadığını kontrol etmek için çalışacaktır. Yeterli alan yoksa, bu tablolara daha fazla alan tahsis edilmesi gerekebilir. Bu kontrollerin gerçekleştirilmesi zaman alır ve CPU için maliyetlidir.
İkinci yaklaşım, tüm bu kontrolleri ve kısıtlamaları atlamak ve verileri doğrudan önceden biçimlendirilmiş bloklara yerleştirmektir. Bu bloklar daha sonra veritabanına yazılır. İlk yaklaşımdan daha hızlıdır, ancak yalnızca tüm veri bloklarıyla çalışabilir. Bu, bir miktar alan israfına yol açabilir.
Üçüncü yaklaşım, verileri zaten tabloyu içeren tabloya yüklerken, dizinleri koruyabilmemizdir.
Dördüncü yaklaşım, verileri zaten veri içeren tablolara yüklemek için, drop the indexes & recreate themveri yükleme tamamlandığında. Üçüncü ve dördüncü yaklaşım arasındaki seçim, halihazırda ne kadar veri yüklendiğine ve kaç dizinin yeniden oluşturulması gerektiğine bağlıdır.

Bütünlük Kontrolleri

Bütünlük kontrolü, yükün performansını büyük ölçüde etkiler. Hatırlanması gereken noktalar aşağıdadır -

Bütünlük kontrollerinin sınırlandırılması gerekir çünkü yoğun işlem gücü gerektirirler.
Veri yükünün performans düşüşünü önlemek için kaynak sistemde bütünlük kontrolleri uygulanmalıdır.

Sorguları Ayarlama

Veri ambarında iki tür sorgumuz var -

Sabit sorgular
Ad hoc sorgular

Sabit Sorgular

Sabit sorgular iyi tanımlanmıştır. Aşağıda, sabit sorgulara örnekler verilmiştir -

düzenli raporlar
Hazır sorgular
Ortak toplamalar

Bir veri ambarındaki sabit sorguları ayarlamak, ilişkisel veritabanı sistemindekiyle aynıdır. Tek fark, sorgulanacak veri miktarının farklı olabilmesidir. Sabit sorguları test ederken en başarılı yürütme planını saklamak iyidir. Bu yürütme planını saklamak, yürütme planının değişmesine neden olacağı için değişen veri boyutunu ve veri çarpıklığını tespit etmemize olanak tanır.

Note - Olgu tablosunda daha fazlasını yapamayız, ancak boyut tabloları veya toplamalar ile uğraşırken, bu sorguları ayarlamak için normal SQL ayarlaması, depolama mekanizması ve erişim yöntemleri koleksiyonu kullanılabilir.

Ad hoc Sorgular

Ad hoc sorguları anlamak için, veri ambarının ad hoc kullanıcılarını bilmek önemlidir. Her kullanıcı veya kullanıcı grubu için aşağıdakileri bilmeniz gerekir -

Gruptaki kullanıcı sayısı
Düzenli zaman aralıklarında geçici sorgular kullanıp kullanmadıkları
Sık sık geçici sorgu kullanıp kullanmadıkları
Zaman zaman bilinmeyen aralıklarla geçici sorgular kullanıp kullanmadıkları.
Çalıştırma eğiliminde oldukları maksimum sorgu boyutu
Çalıştırma eğiliminde oldukları sorgunun ortalama boyutu
Temel verilere ayrıntılı erişim gerekip gerekmediği
Günlük geçen oturum açma süresi
Günlük kullanımın en yoğun zamanı
Yoğun saat başına çalıştırdıkları sorgu sayısı

Points to Note

Kullanıcı profillerini takip etmek ve düzenli olarak çalıştırılan sorguları belirlemek önemlidir.
Yapılan ayarlamanın performansı etkilememesi de önemlidir.
Sık çalıştırılan benzer ve geçici sorguları belirleyin.
Bu sorgular belirlenirse, veritabanı değişir ve bu sorgular için yeni dizinler eklenebilir.
Bu sorgular tanımlanırsa, özellikle verimli yürütülmelerini sağlayacak sorgular için yeni toplamalar oluşturulabilir.

Veri ambarı sistemlerinin doğru ve verimli çalışmasını sağlamak için testler çok önemlidir. Bir veri ambarında gerçekleştirilen üç temel test seviyesi vardır:

Birim testi
Entegrasyon testi
Sistem testi

Birim Testi

Birim testinde her bileşen ayrı ayrı test edilir.
Her modül, yani prosedür, program, SQL Script, Unix kabuğu test edilir.
Bu test, geliştirici tarafından gerçekleştirilir.

Entegrasyon Testi

Entegrasyon testinde, uygulamanın çeşitli modülleri bir araya getirilir ve ardından giriş sayısına göre test edilir.
Entegrasyondan sonra çeşitli bileşenlerin iyi çalışıp çalışmadığını test etmek için gerçekleştirilir.

Sistem Testi

Sistem testinde tüm veri ambarı uygulaması birlikte test edilir.
Sistem testinin amacı, tüm sistemin birlikte doğru çalışıp çalışmadığını kontrol etmektir.
Sistem testi, test ekibi tarafından gerçekleştirilir.
Tüm veri ambarının boyutu çok büyük olduğu için, test planı yürürlüğe girmeden önce genellikle minimum sistem testi gerçekleştirmek mümkündür.

Test programı

Öncelikle test planı geliştirme sürecinde test programı oluşturulur. Bu programda, tüm veri ambarı sisteminin testi için gereken tahmini süreyi tahmin ediyoruz.

Bir test programı oluşturmak için farklı metodolojiler mevcuttur, ancak bunların hiçbiri mükemmel değildir çünkü veri ambarı çok karmaşık ve büyüktür. Ayrıca veri ambarı sistemi doğası gereği gelişiyor. Bir test programı oluştururken aşağıdaki sorunlarla karşılaşılabilir -

Basit bir problem, tamamlanması bir gün veya daha uzun sürebilen büyük bir sorgu boyutuna sahip olabilir, yani sorgu istenen bir zaman ölçeğinde tamamlanamaz.
Bir diski kaybetmek gibi donanım arızaları veya yanlışlıkla bir tabloyu silmek veya büyük bir tablonun üzerine yazmak gibi insan hataları olabilir.

Note - Yukarıda bahsedilen zorluklar nedeniyle, normalde test için izin vereceğiniz süreyi her zaman iki katına çıkarmanız önerilir.

Yedek Kurtarmayı Test Etme

Yedek kurtarma stratejisinin test edilmesi son derece önemlidir. İşte bu testin gerekli olduğu senaryoların listesi -

Medya hatası
Tablo alanı veya veri dosyası kaybı veya hasarı
Yineleme günlük dosyasının kaybı veya hasarı
Kontrol dosyasının kaybı veya hasarı
Örnek hatası
Arşiv dosyası kaybı veya hasarı
Masa kaybı veya hasarı
Veri hatası sırasında hata

Çalışma Ortamının Test Edilmesi

Test edilmesi gereken bir dizi husus vardır. Bu yönler aşağıda listelenmiştir.

Security- Güvenlik testi için ayrı bir güvenlik belgesi gereklidir. Bu belge, izin verilmeyen işlemlerin bir listesini ve her biri için testlerin planlanmasını içerir.
Scheduler- Bir veri ambarının günlük işlemlerini kontrol etmek için planlama yazılımı gereklidir. Sistem testi sırasında test edilmesi gerekir. Programlama yazılımı, veri ambarı ile bir ara yüz gerektirir ve bu, planlayıcının gece boyunca işlemeyi ve toplamaların yönetimini kontrol etmesine ihtiyaç duyar.
Disk Configuration.- G / Ç darboğazlarını belirlemek için disk yapılandırmasının da test edilmesi gerekir. Test, farklı ayarlarla birden çok kez yapılmalıdır.
Management Tools.- Sistem testi sırasında tüm yönetim araçlarının test edilmesi gerekir. İşte test edilmesi gereken araçların listesi.
- Organizasyon müdürü
- Sistem Müdürü
- Veritabanı yöneticisi
- Yapılandırma yöneticisi
- Yedek kurtarma yöneticisi

Veritabanını Test Etme

Veritabanı aşağıdaki üç şekilde test edilir -

Testing the database manager and monitoring tools - Veritabanı yöneticisini ve izleme araçlarını test etmek için, test veritabanının oluşturulması, çalıştırılması ve yönetiminde kullanılmalıdır.
Testing database features - Test etmemiz gereken özelliklerin listesi burada -
- Paralel olarak sorgulama
- Paralel olarak dizin oluştur
- Paralel veri yükleme
Testing database performance- Sorgu yürütme, veri ambarı performans ölçümlerinde çok önemli bir rol oynar. Düzenli olarak çalıştırılması gereken ve test edilmeleri gereken sabit sorgu setleri vardır. Geçici sorguları test etmek için, kullanıcı gereksinimleri belgesine bakmalı ve işi tamamen anlamalıdır. İşletmenin farklı endeks ve toplama stratejilerine karşı sorması muhtemel en garip sorguları test etmek için zaman ayırın.

Uygulamayı Test Etme

Uçtan uca yük, indeks, agregat ve sorguların beklentilere göre çalışmasını sağlamak için tüm yöneticiler doğru entegre olmalı ve çalışmalıdır.
Her yöneticinin her işlevi doğru şekilde çalışmalıdır
Ayrıca uygulamayı belirli bir süre boyunca test etmek de gereklidir.
Hafta sonu ve ay sonu görevleri de test edilmelidir.

Testin Lojistiği

Sistem testinin amacı aşağıdaki alanların tümünü test etmektir -

Programlama yazılımı
Günlük operasyonel prosedürler
Yedek kurtarma stratejisi
Yönetim ve zamanlama araçları
Gecelik işleme
Sorgu performansı

Note- En önemli nokta ölçeklenebilirliği test etmektir. Bunu yapmamak, bize sistem büyüdüğünde çalışmayan bir sistem tasarımı bırakacaktır.

Aşağıdakiler, veri ambarının gelecekteki yönleridir.

Açık veritabanı büyüklüğünün son birkaç yılda büyüklüğünün yaklaşık iki katı büyüdüğünü gördüğümüz gibi, içerdiği önemli değeri gösteriyor.
Veritabanlarının boyutu büyüdükçe, çok büyük bir veritabanını neyin oluşturduğuna dair tahminler büyümeye devam ediyor.
Bugün mevcut olan donanım ve yazılım, büyük miktarda veriyi çevrimiçi tutmaya izin vermiyor. Örneğin, bir Telco arama kaydı, yalnızca bir aylık kayıt boyutunda olan 10 TB verinin çevrimiçi tutulmasını gerektirir. Satış, pazarlama müşterisi, çalışanlar vb. Kayıtların tutulması gerekiyorsa, boyut 100 TB'den fazla olacaktır.
Kayıt, metin bilgisi ve bazı multimedya verilerini içerir. Multimedya verileri, metin verileri olarak kolayca değiştirilemez. Multimedya verilerinin aranması kolay bir iş değildir, oysa metinsel bilgiler bugün mevcut olan ilişkisel yazılımla alınabilir.
Boyut planlamasının yanı sıra, boyutu giderek artan veri ambarı sistemleri oluşturmak ve çalıştırmak karmaşıktır. Kullanıcı sayısı arttıkça veri ambarının boyutu da artmaktadır. Bu kullanıcıların da sisteme erişmesi gerekecektir.
İnternetin büyümesiyle birlikte, kullanıcıların çevrimiçi verilere erişme zorunluluğu vardır.

Dolayısıyla, veri ambarının gelecekteki şekli bugün yaratılandan çok farklı olacaktır.