İyi çalışmalarınızı bilgi tabanına gönderin basittir. Aşağıdaki formu kullanın

Öğrenciler, yüksek lisans öğrencileri, bilgi tabanını çalışmalarında ve çalışmalarında kullanan genç bilim adamları size çok minnettar olacaktır.

Yayınlanan http://www.allbest.ru/

• 1. İlişkisel veri modeli
• 1.1 İlişkisel veri modeli. Temel tanımlar
• 1.2 İlişkilerle ilgili işlemler
• 2. Kurumsal bilgi sistemleri
• bibliyografya

1. İlişkisel veri modeli

1.1 İlişkisel veri modeli. Temel tanımlar

Matematik disiplinlerinde "tablo" kavramı, "ilişki" (ilişki) kavramına karşılık gelir. Tablo, gerçek dünya nesnesini - varlığı yansıtır ve satırlarının her biri varlığın belirli bir örneğini yansıtır. Her sütunun tablo için benzersiz bir adı vardır. Dizelerin adları yoktur, sıraları tanımlanmamıştır ve sayıları mantıksal olarak sınırlandırılmamıştır. İlişkisel veri modelinin ana avantajlarından biri homojenliktir (bir tablonun her satırının bir formatı vardır). Kullanıcı, ilgili varlıkların homojenliğine sahip olup olmadığına kendisi karar verir. Bu, model uygunluğu sorununu çözer.

Temel konseptler:

* İlişki, bazı verileri içeren iki boyutlu bir tablodur.

* Varlık - verileri veritabanında depolanan herhangi bir nitelikteki bir nesne. Nitelikler - varlığı karakterize eden özellikler (sütunlar).

* İlişki derecesi - sütun sayısı.

* İlişki şeması - öznitelik adlarının bir listesi, örneğin, ÇALIŞAN (No., Tam Ad, Doğum Yılı, Pozisyon, Departman).

* Etki alanı - bir dizi ilişki özniteliği değeri (veri türü).

* Tuple - tablo satırı.

* Kardinalite (güç) - tablodaki satır sayısı.

* Birincil anahtar, bir ilişkideki satırları benzersiz şekilde tanımlayan bir niteliktir. Birden çok özniteliği olan birincil anahtara bileşik anahtar denir. Birincil anahtar tamamen veya kısmen boş olamaz (boş değere sahip). Birincil anahtar olarak kullanılabilen anahtarlara aday veya alternatif anahtarlar denir.

* Yabancı anahtar, bir tablonun, başka bir tablonun birincil anahtarı olarak hizmet edebilen öznitelik(ler)idir. Başka bir tablonun birincil anahtarına başvurudur.

Normalleştirme, bir veritabanındaki bilgi fazlalığını azaltmayı amaçlayan bir süreçtir. Verilerin kendisine ek olarak, veritabanında çeşitli adlar, nesne adları ve ifadeler de normalleştirilebilir.

Normalleştirilmemiş bir veritabanı, bir veya daha fazla farklı tabloda bilgi içerir; bu, belirli bir tabloya verilerin dahil edilmesinin herhangi bir belirgin nedenden kaynaklanmadığı izlenimini yaratır. Bu durumun veri güvenliği, disk alanı yönetimi, sorgu hızı, veritabanı güncelleme verimliliği ve belki de en önemlisi depolanan bilgilerin bütünlüğü üzerinde olumsuz bir etkisi olabilir. Normalleştirmeden önceki veritabanı, mantıksal olarak daha yönetilebilir daha küçük tablolara henüz bölünmemiş bir yapıdır.

Normal form, veritabanı normalleştirme düzeyinin veya derinliğinin bir tür göstergesidir. Bir veritabanının normalizasyon düzeyi, içinde bulunduğu normal forma karşılık gelir.

1.2 İlişkilerle ilgili işlemler

Bir tabloyu ilk normal forma (1NF) dönüştürmek için iki kurala uyulmalıdır:

1. Atomiklik veya bölünmezlik. Her sütun bir bölünemez değer içermelidir.

2. Tablo, tekrar eden sütunlar veya veri grupları içermemelidir.

Örneğin bir tablo bir alanda bir kişinin tam adresini (cadde, şehir, posta kodu) içeriyorsa, bir sütunda farklı değerler içereceğinden 1NF kurallarına uymayacaktır. atomite kuralının ihlali. Veya veritabanı filmlerle ilgili verileri içeriyorsa ve aktör1, aktör2, aktör3 sütunlarına sahipse, veri tekrarı olacağı için kurallara da uymayacaktır.

Normalleştirme, 1NF ile uyumluluk için veritabanı yapısının kontrol edilmesiyle başlamalıdır. Atomik olmayan tüm sütunlar, kurucu sütunlarına bölünmelidir. Tabloda yinelenen sütunlar varsa, ayrı bir tablo ayırmaları gerekir.

Bir tabloyu ilk normal forma dönüştürmek için:

* Birden fazla bilgi içeren tüm alanları bulun.

* Bileşen parçalarına ayrılabilen veriler ayrı alanlara yerleştirilmelidir.

* Yinelenen verileri ayrı bir tabloya taşıyın.

* Tüm tabloların ilk normal formun koşullarına uyup uymadığını kontrol edin.

Tabloları ikinci normal forma (2NF) dönüştürmek için, elde edilen tabloların zaten 1NF'de olması gerekir. Normalleştirme sırayla yapılmalıdır.

Şimdi, ikinci normal formda, koşulun karşılanması gerekir - anahtar olmayan herhangi bir sütun (yabancı olanlar dahil) birincil anahtara bağlı olmalıdır. Tipik olarak, anahtara bağlı olmayan değerlere sahip olan bu sütunların tanımlanması kolaydır. Bir sütunda yer alan veriler, satırı tanımlayan anahtarla ilgili değilse, kendi ayrı tablolarına ayrılmalıdır. Birincil anahtar eski tabloya döndürülmelidir.

Tabanı ikinci normal forma dönüştürmek için:

* Bu tablonun birincil anahtarına doğrudan bağımlı olmayan tüm sütunları tanımlayın.

* Kullanıcılar ve forum tablolarında gerekli alanları oluşturun, mevcut alanlardan seçim yapın veya yenilerinden birincil anahtarlar oluşturun.

* Her tablonun kendi birincil anahtarına ihtiyacı vardır

* Yabancı anahtarlar oluşturun ve tablolar arasındaki ilişkileri belirtin. 2NF'ye normalleştirmenin son adımı, ilişkili tablolarla ilişkilendirme için yabancı anahtarların tahsis edilmesi olacaktır. Bir tablonun birincil anahtarı, başka bir tablonun yabancı anahtarı olmalıdır.

İpuçları:

2NF şeması oluşturmanın başka bir yolu da tablolar arasındaki ilişkilere bakmaktır. İdeal seçenek, tüm bire çok ilişkileri oluşturmaktır. Çoktan çoğa ilişkilerin yeniden yapılandırılması gerekir.

Düzgün bir şekilde normalleştirilmiş bir tabloda asla yinelenen satırlar olmaz (değerleri anahtar olmayan ve aynı verileri içeren iki veya daha fazla satır).

Bir veritabanı, ikinci normal forma dönüştürülürse ve anahtar olmayan her sütun birbirinden bağımsızsa, üçüncü normal formda olacaktır. Bu noktaya kadar normalleşme süreci doğru takip edilirse 3NF'ye indirgemede herhangi bir sorun olmayabilir. Bir sütundaki değerde bir değişiklik, başka bir sütunda bir değişiklik gerektiriyorsa, 3NF'nin ihlal edildiğini bilmelisiniz.

Tabanı üçüncü normal forma dönüştürmek için:

* Hangi tabloların hangi alanlarında karşılıklı bağımlılık olduğunu belirleyin, yani. Bir bütün olarak seriden daha fazla birbirine bağlı alanlar.

* İlgili tablolar oluşturun. 1. adımda sorunlu bir sütun varsa, bunun için ayrı tablolar oluşturun.

* Birincil anahtarlar oluşturun veya tahsis edin. Her tablonun bir birincil anahtarı olmalıdır.

* İlişkilerden herhangi birini oluşturan gerekli yabancı anahtarları oluşturun.

Dördüncü normal formda, ek bir kural, çok değerli bağımlılıkları hariç tutmaktır. Diğer bir deyişle, tüm tablo satırları birbirinden bağımsız olmalıdır. Bazı X satırının varlığı, Y satırının da bu tabloda bir yerde olduğu anlamına gelmemelidir.

2. Kurumsal bilgi sistemleri

ilişkisel model veri sistemi

Bir sistem (Yunanca systema'dan - bir bütün, parçalardan oluşan bir bağlantı), birbirleriyle etkileşime giren, belirli bir bütünlük, birlik oluşturan bir dizi öğedir. Bir sistemi karakterize etmek için sıklıkla kullanılan bazı kavramlar aşağıda verilmiştir.

1. Sistem öğesi -- belirli bir işlevsel amacı olan sistemin bir parçası. Daha basit birbirine bağlı öğelerden oluşan karmaşık sistem öğelerine genellikle alt sistemler denir.

2. Sistemin organizasyonu - iç düzen, sistem öğelerinin etkileşiminde tutarlılık, özellikle sistem içindeki öğelerin durumlarının çeşitliliğini sınırlamada kendini gösterir.

3. Sistemin yapısı - sistemin temel özelliklerini belirleyen sistem öğelerinin etkileşiminin bileşimi, sırası ve ilkeleri. Sistemin tek tek öğeleri farklı düzeylerde birbirinden ayrılmışsa ve öğeler arasındaki iç bağlantılar yalnızca üst düzeylerden alt düzeylere doğru organize edilmişse ve bunun tersi de, sistemin hiyerarşik bir yapısından söz ederler. Tamamen hiyerarşik yapılar pratikte nadirdir, bu nedenle bu kavramı biraz genişleterek, hiyerarşik bir yapının genellikle diğer bağlantıların yanı sıra hiyerarşik bağlantıların çok önemli olduğu bu tür yapılar anlamına geldiği anlaşılır.

4. Sistem mimarisi -- kullanıcı için gerekli olan bir dizi sistem özelliği.

5. Sistemin bütünlüğü - sistemin özelliklerinin, bireysel öğelerinin özelliklerinin toplamına (özelliklerin ortaya çıkışı) temel olarak indirgenemezliği ve aynı zamanda, her bir öğenin özelliklerinin kendi özelliklerine bağımlılığı sistem içindeki yeri ve işlevi.

Bir bilgi sistemi, amaca ulaşmak için bilgiyi depolamak, işlemek ve yayınlamak için kullanılan birbirine bağlı bir dizi araç, yöntem ve personeldir"

"Bilgi, Bilgilendirme ve Bilgi Koruması Hakkında" Federal Yasa aşağıdaki tanımı sağlar:

"Bilgi sistemi, bilgisayar teknolojisini ve bilgi süreçlerini uygulayan iletişim araçlarını kullanmak da dahil olmak üzere, organizasyonel olarak sıralanmış bir belgeler (belge dizileri) ve bilgi teknolojileri setidir"

Ölçek sınıflandırması

Ölçeğe göre, bilgi sistemleri aşağıdaki gruplara ayrılır:

* bekar;

* grup;

* Kurumsal.

Kurumsal bilgi sistemi, birleşik yönetim gerektiren bir grup şirketten oluşan şirketler de dahil olmak üzere büyük ve orta ölçekli işletmelerin her türlü ekonomik faaliyetinin karmaşık otomasyonu için tasarlanmış ölçeklenebilir bir sistemdir.

Kurumsal bilgi sistemi, şirketin bölümlerinin %80'inden fazlasını otomatikleştiren bir sistem olarak düşünülebilir.

Son zamanlarda, ekonomik nesnelerin yönetiminde bilgi teknolojilerinin kullanımına ayrılmış birçok yayında, ekonomik nesnelerin gerçek otomatik bilgi sistemlerine atıfta bulunan "kurumsal bilgi sistemleri" terimi sıklıkla kullanılmaktadır.

Otomatik bilgi sistemi (AIS), muhasebe ve analitik bilgilerin işlenmesini otomatikleştirmek için tasarlanmış uzmanların yanı sıra çeşitli destek türlerinin bir kombinasyonudur. Kompozisyon açısından destek türleri, kural olarak, farklı sistemler için homojendir ve bu, sistemlerin çalışması sırasında uyumluluk ilkesinin uygulanmasını mümkün kılar. AIS'yi karmaşık bir sistem olarak inceleme sürecinde, bireysel parçaları ve elemanları ayırmak ve kullanımlarının özelliklerini oluşturma ve çalıştırma aşamalarında dikkate almak gerekir.

Kurumsal bilgi sistemleri, çalışma grupları için sistemlerin bir evrimidir, büyük şirketlere odaklanırlar ve coğrafi olarak dağınık düğümleri veya ağları destekleyebilirler. Temel olarak, birkaç seviyeden oluşan hiyerarşik bir yapıya sahiptirler. Bu tür sistemler, sunucuların uzmanlaşması veya çok seviyeli bir mimari ile bir istemci-sunucu mimarisi ile karakterize edilir. Bu tür sistemler geliştirilirken, grup bilgi sistemleri geliştirilirken kullanılan aynı veritabanı sunucuları kullanılabilir. Ancak büyük bilgi sistemlerinde en yaygın olarak kullanılan sunucular Oracle, DB2 ve Microsoft SQL Server'dır.

Grup ve kurumsal sistemler için, çalışma güvenilirliği ve veri güvenliği gereksinimleri önemli ölçüde artırılmıştır. Bu özellikler, veritabanı sunucularındaki verilerin, bağlantıların ve işlemlerin bütünlüğü korunarak sağlanır.

Kapsama göre sınıflandırma

Bilgi sistemleri kapsamına göre genellikle dört gruba ayrılır:

* işlem işleme sistemleri;

* karar verme sistemleri;

* bilgi ve referans sistemleri;

* ofis bilgi sistemleri.

bibliyografya

1. Agaltsov, V.P. Veri tabanı. 2 ciltte V. 2. Dağıtılmış ve uzak veritabanları: Ders Kitabı / V.P. Agaltsov. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Veritabanları: Ders Kitabı / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Forum, 2012.

3. Karpova, I.P. Veritabanları: Ders Kitabı / I.P. Karpov. - St. Petersburg: Peter, 2013.

4. Kirillov, V.V. İlişkisel veritabanlarına giriş İlişkisel veritabanlarına giriş / V.V. Kirillov, G.Yu. Gromov. - St. Petersburg: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Bilgi sistemleri ve veri tabanları: organizasyon ve tasarım: Ders Kitabı / V.Yu. Pirogov. - St. Petersburg: BHV-Petersburg, 2009.

6. G.N. Fedorov. Bilgi sistemi. - M.: Akademi, 2013.

7. A.E. Satunina, L.A. Sisoev. İşletmenin kurumsal bilgi sisteminin proje yönetimi. - M.: Finans ve istatistik, Infra-M, 2009.

Allbest.ru'da barındırılıyor

...

Benzer Belgeler

Veri modeli türlerinin özü ve özellikleri: hiyerarşik, ağ ve ilişkisel. İlişkisel veri modelinin temel kavramları. Nitelikler, veritabanı ilişki şeması. Veri bütünlüğü koşulları. Tablolar arasındaki ilişkiler. Veri modeli hakkında genel fikirler.

dönem ödevi, 29/01/2011 eklendi


Kurumsal bilgi sistemleri ve veritabanları, iş geliştirme ve hata ayıklama için kullanımları. Kurumsal bilgi sistemlerinin sınıflandırılması. OLTP sınıfının bilgi sistemleri. Operasyonel analitik işleme.

dönem ödevi, 19/01/2011 eklendi


İki boyutlu dosyalara ve ilişkisel veritabanı yönetim sistemlerine (DBMS) sahip veritabanları. Bir DBMS kullanarak bir veritabanı oluşturma ve bunlara yönelik sorguları işleme. Temel veritabanları türleri. İlişkisel veritabanlarının temel kavramları. İlişkilerin temel özellikleri.

özet, eklendi 20/12/2010


Bir veritabanı sistemi kavramı. İlişkisel model ve özellikleri. İlişkisel modelde bütünlük. İlişkisel cebir. Veritabanı tasarım sorunları. normal ilişki biçimleri. Varlık-ilişki yöntemini kullanarak bir veritabanı tasarlama. ER diyagramları. SQL dili.

dersler, eklendi 03.10.2008


Bir veritabanında depolanan verilerin belirli bir mantıksal yapısı. Temel veri modelleri. İlişkisel veri modelinin öğeleri. Yabancı anahtar kullanımına bir örnek. İlişkisel veri modelinin ilişkileri için temel gereksinimler.

sunum, eklendi 10/14/2013


Veritabanları ve bilgi işlemde kullanımları. Ağ veri modelinin özellikleri ve temel yapısal birimi. Hiyerarşik model, etki alanı nesneleri. İlişkisel model, görünürlüğü, verilerin tablo halinde sunulması.

özet, 19/12/2011 eklendi


Veritabanı yönetim sistemi Microsoft Access türleri ve işlevleri. Hiyerarşik, ağ, ilişkisel veritabanı tanımlama modeli. Bir veritabanı tablosunun temel kavramları. Veritabanı nesneleri oluşturmanın özellikleri, temel formlar. Access'te İnternet'e erişim.

kontrol çalışması, eklendi 01/08/2011


Modern veritabanı yönetim sistemleri (DBMS). Hiyerarşik veri modelinin analizi. İlişkisel veri modeli. Tablo kayıtlarında saklanan verilerin bölünmezliği kısıtlamasını ortadan kaldıran genişletilmiş bir ilişkisel model olarak ilişki sonrası veri modeli.

bilimsel çalışma, eklendi 06/08/2010


Veritabanı yönetiminde veri modelleri. Kavramsal veri modelleri. Bilgi sistemlerinde veri tabanlarının rolü. İlişkisel veri modeli. Konu alanının tanımı. "Evcil Hayvanlar" bilgi sistemi için bir veritabanı modeli oluşturma.

dönem ödevi, 19/04/2011 eklendi


Gerçek bir nesne veya sistem için basitleştirilmiş bir ikame olarak Access'te bir bilgi modeli. Verilerin organizasyonunu ve aralarındaki ilişkileri tanımlayan temel yapılar; ilişkisel veri organizasyonu türü. Vergilendirmede bir veritabanı örneği.

Görünüşe göre şimdi veri ambarlarının geliştirilmesi konusu yeni bir geliştirme döngüsüne girdi. Yeni teknolojiler, yaklaşımlar ve araçlar ortaya çıkıyor. Çalışmaları, testleri ve makul uygulamaları, gerçekten ilginç ve kullanışlı çözümler yaratmamızı sağlıyor. Ve bunları uygulamaya geçirin, geliştirmelerinizin gerçek işte kullanılmasının ve fayda sağlamanın tadını çıkarın.

sonsöz

Bu makaleyi hazırlarken öncelikle doğrudan veri ambarları ile çalışan mimarlar, analistler ve geliştiricilere odaklanmaya çalıştım. Ancak kaçınılmaz olarak “konuyu biraz daha genişlettiğim” ortaya çıktı - ve diğer okuyucu kategorileri görüş alanına girdi. Bazı noktalar tartışmalı görünecek, bazıları net değil, bazıları açık. İnsanlar farklıdır - farklı deneyimlere, geçmişlere ve pozisyonlara sahiptir.
Örneğin, yöneticilerin tipik soruları “ne zaman mimarları cezbederim?”, “Ne zaman mimarlık yapmalıyım?”, “Mimarlık – çok pahalı olmaz mı?” şeklindedir. bizim için oldukça garip geliyor (geliştiriciler, tasarımcılar), çünkü bizim için sistemin mimarisi onun doğuşuyla ortaya çıkıyor - fark edip etmememiz önemli değil. Ve projede bir mimarın resmi bir rolü olmasa bile, normal bir geliştirici her zaman “iç mimarına sırtını döner”.

İşin büyük şemasında, mimarın kim olduğu önemli değil, önemli olan birinin bu soruları sorması ve cevaplarını keşfetmesidir. Mimar açıkça seçiliyorsa, bu yalnızca sistemden ve gelişiminden öncelikli olarak onun sorumlu olduğu anlamına gelir.
Bu konuyla ilgili olarak “antifrajilite” konusu bana neden alakalı göründü?

"Kırılganlığa karşı korumanın benzersizliği, bilinmeyenle çalışmamıza, tam olarak ne yaptığımızı anlamadığımız koşullarda bir şeyler yapmamıza ve başarılı olmamıza izin vermesidir."/Nassim N.Taleb/

Bu nedenle, kriz ve yüksek derecede belirsizlik, mimari eksikliğin mazereti değil, ihtiyacı güçlendiren faktörlerdir.

Etiketler: Etiketler ekle

5.1. Kurumsal bilgi sistemlerinde verilerin organizasyonu.

BDT'yi en basit düzeyde ele alırsak, kurumsal bir bilgisayar (bilgisayar) ağı ve konu alanındaki sorunları çözmek için özel bir uygulama yazılım paketi (APP) içerdiğini söyleyebiliriz. Buna karşılık, hem PPP hem de bilgisayar ağı, onlar tarafından kontrol edilen ve yönetilen sistemlerin durumu ve gelişimi hakkında bilgi verilerinin kullanımını ima eder. Tarihsel olarak, BDT, birbirine bağlı ve genellikle hiyerarşik bir sistemi temsil eden bireysel işletmelerin ayrı dallı alt sistemlerinden oluşur. Bu tür alt sistemlerin hem kendi kaynaklarına hem de ilgili verileri depolamak için kendi yerlerine sahip olduğunu varsaymak doğaldır. Tek bir sistemde birleştirildiğinde, coğrafi olarak farklı depolama yerlerinde bulunan verilerin ortak doğru kullanımı hakkında sorular ortaya çıkıyor. Bu nedenle, CIS ile donatılmış bir üretim birliğini başarılı bir şekilde yönetmek için verilerin toplanması, depolanması ve işlenmesi için güvenilir bir sisteme ihtiyacı vardır. Başka bir deyişle, stratejik BI (İş Zekası) projelerini karşılayan birleşik bir bilgi altyapısına veya verileri depolamak ve kullanmak için entegre bir veritabanına ihtiyacınız var. Veri entegrasyonunun temel amacı, kurumsal iş verilerinin durumunun tek ve eksiksiz bir resmini elde etmektir. Entegrasyonun kendisi, aşağıdakileri ayırmanın tavsiye edildiğine dayanan karmaşık bir süreçtir:

teknoloji,

Ürün:% s,

Uygulamalar

yöntemler veri entegrasyonuna yönelik yaklaşımlardır.

teknoloji- bunlar, belirli veri entegrasyonu yöntemlerini uygulayan süreçlerdir.

Ürün:% sşu veya bu veri entegrasyon teknolojisini destekleyen ticari çözümlerdir.

Uygulamalar- bunlar, geliştiriciler tarafından müşterilerin - müşterilerin isteklerine göre sağlanan hazır teknik çözümlerdir.

Kurumsal bilgi sistemlerinin karmaşıklığına ve çözmek için tasarlandıkları görevlere bağlı olarak, içlerindeki verilerin organizasyonu biraz farklıdır. Özellikle, hem bireysel şubelerin hem de bir bütün olarak şirketin iş süreçlerinin etkin bir şekilde yönetilmesini sağlamak için tasarlanan BDT'de, kurumsal veritabanlarının varlığından bahsetmek gelenekseldir. Yönetimin en üst kademelerinde kullanılan ve çoğunlukla operasyonel analiz ve karar verme süreçleriyle ilişkilendirilen kurumsal bilgi sistemlerinde, çeşitli yönetim faaliyetlerinin planlanması, tasarlanması ve tahmin edilmesi sürecinde veri ambarı terminolojisi kullanılmaktadır. ifadesinin yer aldığını belirtmekte fayda var. entegre bilgi depolama ikisine de aittir.

5.2. Kurumsal veritabanları ve gereksinimleri

Sistem genelinde entegre bir veri deposu olan kurumsal veri tabanı, kurumun tüm iş süreçlerinin ve bölümlerinin etkin yönetimi için bilgi sağlamak üzere tasarlanmıştır. Veri entegrasyonu, bireysel ayrı bölümlerin veri tabanlarından gelen verileri organik olarak içeren yeni bir yapının oluşturulmasını içerir, bu nedenle böyle bir yapı belirli gereksinimleri sağlamalıdır:

Veritabanına basit ve kullanıcı dostu veri girişi,

Verilerin aşırı veri büyümesine yol açmayacak biçimde saklanması,

Erişim haklarının sınırlandırılması zorunlu şartına bağlı olarak, şirketin tüm bölümlerindeki çalışanların genel bilgilerine erişilebilirliği,

Gerekli bilgilerin hızlı bir şekilde bulunması ve seçilmesi,

Gerekli verilerin sıralanması ve filtrelenmesi,

Benzer verileri gruplama

Alanlar üzerinden ara ve son hesaplamalar,

Çıktı verilerinin dönüştürülmesi ve görünürlüğü,

ölçeklenebilirlik,

· Kazara oluşan arızalara, kalıcı veri kayıplarına ve yetkisiz erişime karşı güvenlik.

Ayrıca, ayrı (dağıtılmış) veritabanlarını tek bir kurumsal veri tabanına entegre ederken, veri tabanı ile kullanıcının dağıtılmamış gibi çalışacağı şekilde çalışabilmesini sağlamak önemlidir.

Entegre bir kurumsal veritabanının oluşturulması, başlıcaları olan çeşitli yöntemlerle mümkündür:

· Konsolidasyon,

federalizasyon,

· Yayma.

5.3. Kurumsal veri tabanları için entegrasyon çözümlerinin özellikleri

Konsolidasyon. Altında konsolidasyon genellikle aynı ada sahip verilerin eklenmesini ifade eder. Benzer bir terim, ana bankanın tüm varlık ve yükümlülüklerini şubeleri ile birlikte sunmanıza olanak tanıyan yıllık konsolide bilançonun oluşturulduğu bankacılık sektöründe yaygın olarak kullanılmaktadır.

Bir kurumla ilgili olarak, bu yöntemi kullanırken, veriler tek bir depolama konumuna (DB - Master) entegre edilerek birincil veritabanlarından (DB - Slave) kopyalanır ve toplanır. Kural olarak, merkez (merkez) ofisin sunucusu böyle bir depolama yeri olarak seçilir (Şekil 5.1).

Şekil 5.1. Veri Konsolidasyon Yöntemi

DB - Master'daki veriler, raporlama, analiz, geliştirme ve karar verme için kullanılır ve ayrıca şirketin diğer şubeleri için bir veri kaynağı olur.

Konsolidasyon sırasında bu tür çözümleri desteklemek için en yaygın teknolojiler aşağıdaki teknolojilerdir:

Çıkarma, dönüştürme ve yükleme - ETL (Dönüştürme Yükünü Çıkarma);

· Kurumsal içerik yönetimi - ECM (Kurumsal İçerik Yönetimi).

Konsolidasyon yönteminin avantajları şunlardır:

1. dönüştürme yeteneği ETL teknolojisi nedeniyle birincil sistemlerden nihai depolama yerlerine aktarım sürecinde önemli miktarda verinin (yeniden yapılandırılması, mutabakatı, temizlenmesi ve/veya birleştirilmesi)

2. Yapılandırılmamış verileri yönetme yeteneği ECM teknoloji çözümleri sayesinde belgeler, raporlar ve sayfalar gibi.

Konsolide BDT veritabanı ile çalışmak için özel iş uygulamaları, Bu, veritabanı verilerine, raporlara sorgular oluşturmanıza ve bunlara dayalı olarak veri analizi yapmanıza olanak tanır.

Konsolidasyon yoluyla entegrasyonun dezavantajı, senkronizasyon çakışmaları nedeniyle entegre depolama konumundaki konsolide verilerin birincil sistemlerdeki veri güncellemeleriyle senkronize olarak güncellenememeleridir.

Birincil sistemlerde ve nihai depolama konumunda veri güncelleme anları arasında bir zaman gecikmesinin varlığı.

Bu gecikme birkaç saniyeden birkaç saate hatta günlere kadar değişebilir.

Federalizasyon. Altında federalleşme genellikle birlik olarak anılır. Benzer bir terim, bir devletin sınırlarını düzenlerken (örneğin, Almanya, Rusya, ABD) siyasette sıklıkla kullanılır.

Kurumsal bir veri tabanında veri birleştirme süreci, birkaç birincil veri dosyasını tek bir sanal bütün halinde birleştiren sanal (görünür) bir resmin oluşturulmasıdır (bkz. Şekil 5.2). Veri federalizasyonunun kendisi, harici gereksinimlere dayalı olarak birincil sistemlerden verilerin çıkarılmasından oluşur. Federal yönteme göre entegre kurumsal veri tabanının yönetimi, federalizasyon işlemcisi

İncir. 2. Veri birleştirme yöntemi

Veriler için sanal veritabanına dönersek, herhangi bir iş uygulaması sanal resme bir istek oluşturur. Bu isteğe bağlı olarak, federasyon işlemcisi ilgili birincil sistemlerden verileri çıkarır, bunları sanal resme göre entegre eder ve sonucu, talebi oluşturan iş uygulamasına döndürür. Bu durumda gerekli tüm veri dönüşümleri birincil sistemlerden çıkarıldığında gerçekleştirilir.

Veri entegrasyonuna yönelik birleşik bir yaklaşım desteği, Kurumsal Bilgi Entegrasyonu anlamına gelen Kurumsal bilgi entegrasyonu (E I I) teknolojisi tarafından sağlanır.

Birleştirilmiş çözümün bir özelliği, birincil verilere erişmek için federasyon işlemcisinin meta veri(bilgi), birincil sistemlere erişimi optimize etmek için federatif çözüme yardımcı olan, sanal resmin bileşimi ve özellikleri, veri miktarı, bunlar arasındaki anlamsal ilişkiler ve bunlara erişim yolları hakkındaki verileri içerir.

Federasyon yaklaşımının başlıca avantajları şunlardır:

ek yeni bir veritabanı oluşturmadan mevcut verilere erişme yeteneği,

şirketlerin devralınması veya birleşmesi sonrasında başvurunun uygunluğu,

güvenlik nedenleriyle birincil sistemlerden veri kopyalamaya ilişkin lisans kısıtlamalarının olduğu durumlarda vazgeçilmez,

Gerekirse, şirketin yerel bölümlerinin yüksek özerkliğini ve faaliyetlerinin merkezi kontrolünün esnekliğini kullanmak,

· Büyük ulusötesi şirketler için yüksek derecede fayda.

Yaklaşımın dezavantajları şunları içerir:

Birden fazla veri kaynağına erişmenin ek maliyeti nedeniyle düşen performans,

federalleştirme, az miktarda veriyi çıkarmak için en uygun olanıdır,

Birincil veriler için yüksek kalite gereksinimleri.

Yayma. Altında yayılmış genellikle çoklu nesnelerin bölgesel transferini ifade eder. Veri yayılımı, birincil veritabanlarının çoğaltılmasını ve bir yerden diğerine taşınmasını ifade eder. Bu yöntemi uygularken iş uygulamalarıçevrimiçi çalışın ve meydana gelen belirli olaylara göre verileri hedeflere taşıyın. Bu teknik çözüm için, senkron veya asenkron modlarda mümkün olan verilerin güncellenmesi konusu önem kazanmaktadır.Senkron mod, hem birincil sistemdeki hem de son sistemdeki güncellemelerin aynı fiziksel işlem sırasında gerçekleştiğini varsayar.

Veri yayma yönteminin uygulanmasını destekleyen teknoloji örnekleri şunlardır:

Kurumsal uygulamaların entegrasyonu EAI - Kurumsal Uygulama Entegrasyonu,

· Kurumsal verilerin replikasyonu EDR – Enterprise Data Replication.

Veri yayma yönteminin uygulanmasının genelleştirilmiş yapısı, Şekil 5.3'ün formuna sahiptir.

Şekil 5.3. Veri yayma yöntemi

Veri dağıtım yönteminin ayırt edici bir özelliği, verilerin hedef sisteme gerçek zamana yakın minimum gecikmeyle garantili teslimidir.

Yöntemde teknoloji entegrasyonu (EAI) ve çoğaltma (EDR) kombinasyonu, aşağıdaki avantajlar şeklinde birçok avantaj sağlar:

· Yüksek performans,

Veri yeniden yapılandırma ve temizleme imkanı,

· Yedekler oluşturarak ve verileri geri yükleyerek yük dengeleme.

hibrit yaklaşım. Ekonomik faaliyetin gerçekliği öyledir ki, iki özdeş işletme, özellikle de iki özdeş şirket yoktur. Bu durum, BDT oluşturma ve doldurma sürecine damgasını vurmaktadır. Bu tamamen veritabanlarına veri entegre etme yöntemleri için geçerlidir. Bu nedenle birçok EIS, veri entegrasyonu uygulamalarında sözde veri entegrasyonunu kullanır. melez Aynı anda birkaç entegrasyon yöntemini içeren bir yaklaşım. Bu yaklaşımın örnekleri, müşteri bilgilerinin tutarlı bir resmini sağlayan teknolojilerdir:

Müşteri verilerinin CDI sistemlerine entegrasyonu - Müşteri Verileri Entegrasyonu,

· Müşteri verilerinin CRM – Müşteri İlişkileri Yönetimi modüllerine entegrasyonu.

Özellikle, CDI uygulama yaklaşımı çeşitli şekillerde ele alınabilir.

En kolay yol, birincil sistemlerden gelen verileri içeren birleştirilmiş bir müşteri veritabanı oluşturmaktır. Aynı zamanda, bilgi birikimi, farklı konsolidasyon modları kullanılarak düzenlenebilir: bu bilgilerin güncellenme sıklığına bağlı olarak operasyonel veya toplu.

İkinci yol, sanal olduğunda veri federasyonudur. iş sunumları birincil sistemlerde bulunan müşteri verileri. Ve meta veri dosyası, müşteri bilgilerini ilişkilendirmek için kullanılabilecek ortak anahtar öğeleri içerebilir.

Böylece genel (örneğin ayrıntılar) müşteri verileri en statik veriler olarak konsolide edilebilir. Ve daha dinamik veriler (sipariş ayrıntıları gibi) birleştirilebilir.

Ayrıca, hibrit yaklaşım, veri yayma yöntemi kullanılarak genişletilebilir. Örneğin, bir İnternet mağazasının hizmetlerini kullanan bir müşteri, hizmet sırasında ayrıntılarını değiştirir. Bu değişiklikler, veritabanının birleştirilmiş kısmına gönderilebilir ve oradan mağaza müşteri verilerini içeren tüm birincil sistemlere yayılabilir.

Yöntemlerin her birinin avantaj ve dezavantajlarını göz önünde bulundurarak, uygulama ve paylaşımlarında yaratıcı olunması tavsiye edilir.

Örneğin, veri birleştirme maliyeti, konsolidasyonun sağladığı iş avantajlarından daha ağır bastığında veri birleştirme yararlıdır. Özellikle taleplerin hızlı bir şekilde işlenmesi ve raporların hazırlanması tam da böyle bir durumdur.

Veri yayma yönteminin pratik uygulaması, hem performans hem de verileri yeniden yapılandırma ve temizleme yeteneği açısından çok çeşitlidir.

5.4. Veri ambarlarının konsepti ve yapısal çözümleri

Bilgi deposu - karar verme ve veri analizi süreçlerinin oluşturulduğu diğer sistemlerden gelen verilerin yanı sıra harici ve operasyonel verileri toplayan, konu odaklı entegre bir bilgi deposudur.

Veritabanları ve veri bankalarından farklı olarak, veri ambarları dahili değil, harici veri kaynaklarına dayanır: çeşitli bilgi sistemleri, elektronik arşivler, halka açık elektronik kataloglar, dizinler ve koleksiyonlar.

Veri ambarları kavramı iki ana fikir üzerine kuruludur:

1. Birbirinden farklı ayrıntılı verilerin (belirli gerçekleri, özellikleri, olayları vb. açıklayan) tek bir havuzda entegrasyonu.

2. İşleme ve analiz için kullanılan veri kümelerinin ve uygulamaların ayrılması.

Veri depolama, aşağıdakilerin elde edilmesinin gerekli olduğu durumlarda düzenlenir:

Güncel ve geçmiş veri değerlerinin entegrasyonu,

Farklı kaynaklardan gelen verilerin konsolidasyonu,

Analitik amaçlı güvenilir bir veri platformunun oluşturulması,

Kurum genelinde veri homojenliğinin sağlanması,

Mevcut işletim sistemlerini değiştirmeden kurumsal veri standartlarının uygulanmasını kolaylaştırmak,

· Geniş bir tarihsel resim ve gelişme eğilimlerini analiz etmek için fırsatlar sağlamak.

Tarihsel olarak, veri ambarları bir, iki ve üç katmanlı bir şema üzerine inşa edilmiştir.

Tek seviyeli şemalarİlk olarak, operasyonel sistemlerden gelen veriler kullanılarak analiz yapıldığında, az gelişmiş bir bilgi altyapısına sahip, işlevsel DSS'yi içeren en basit mimariler için tasarlanmıştır: veri - sunum formları.

Bu tür planların avantajları şunlardır:

Ara bağlantılar olmadan operasyonel sistemlerden özel bir sisteme hızlı veri aktarımı,

· Tek platform kullanımından kaynaklanan minimum maliyetler.

Dezavantajları:

Tek bir veri kaynağı nedeniyle çözülmesi gereken dar kapsamlı sorunlar,

· Bir temizleme adımının olmaması nedeniyle düşük veri kalitesi.

İki seviyeli şemalar bir zincir sağlayın: veri - veri pazarları - sunum formları. Kendi bilgi teknolojilerini kullanan çok sayıda bağımsız bölümü olan şirketlerde kullanılırlar.

Avantajlar:

Kullanılan vitrinler, belirli bir dizi soruyu cevaplamak için tasarlanmıştır,

· Performansı artıran vitrinlerdeki verileri optimize etmek mümkündür.

Dezavantajları:

Vitrinlerde tekrar tekrar olması nedeniyle veri tutarlılığının sağlanmasındaki zorluk,

Vitrinleri çok sayıda veri kaynağıyla doldurmanın potansiyel karmaşıklığı,

· Kurumsal düzeyde veri konsolidasyonu eksikliği göz önüne alındığında, işin tek bir resmi yoktur.

Gelişimin evrimi, modern kurumsal sistemler için tam teşekküllü bir veri ambarının inşasının aşağıdakilere göre gerçekleştirilmesine yol açmıştır. üç katmanlı mimari (bkz. şekil 5.4).

Üzerinde ilk düzeyde veri kaynağı olan çeşitli kayıt sistemleri vardır. Bu tür sistemler kurumsal kaynak planlama (ERP) sistemleri, referans (operasyonel) sistemler, dış kaynaklar veya haber ajanslarından veri sağlayan sistemler vb. olabilir.

Üzerinde saniye seviye, birinci seviyenin tüm kaynaklarından gelen verilerin toplandığı merkezi bir havuzun yanı sıra iki işlevi yerine getirmek üzere tasarlanmış bir operasyonel veri ambarı içerir:

Depo, operasyonel yönetim için kullanılan bir analitik bilgi kaynağıdır,

· Operasyonel depoda, merkezi depoya daha sonra yüklenmek üzere veriler hazırlanır. Verilerin hazırlanması altında, birinci seviyeden verilerin alınması için farklı düzenlemelerle bağlantılı olarak kontrollerin yapılması ve verilerin dönüştürülmesi anlamına gelir.

Üçüncü düzey, etki alanına özgü veri pazarlarının bir koleksiyonudur.

Veri marketleri – bunlar, içerikleri şirketin bireysel bölümlerinin analitik sorunlarının çözümüne katkıda bulunan, nispeten küçük işlevsel yönelimli sürücülerdir. Aslında, veri marketleri bir ambardaki verilerin alt kümeleridir. Aynı zamanda son kullanıcılar, data martta yeterli veri olmaması durumunda detaylı ambar verilerine erişme ve işin durumunun daha eksiksiz bir resmini elde etme olanağına sahiptir.

Şekil 5.4. Veri ambarı mimarisi

Bu tür organize veri ambarlarının ana teknolojik işlemleri şunlardır:

· çıkarma veri, heterojen kaynaklardan operasyonel bir ambara veri aktarma işlemidir,

· dönüşüm veri, verilerin özel kurallara göre değiştirilmesi ve daha sonra merkezi depolamaya aktarılmasıdır,

· temizlik veri, farklı kaynaklardan gelen verilerin tekrarının ortadan kaldırılmasıdır,

· Güncelleme veri, veri güncellemelerinin temel tabloların kaynak verilerine ve ambarda barındırılan türetilmiş verilere dağıtımıdır.

Avantajlar:

Tek bir saflaştırılmış veri kaynağının kullanılması nedeniyle vitrinlerin doldurulması basitleştirilmiştir,

· Data martları, kurumsal iş resmi ile senkronize edilir, bu da merkezi deponun genişletilmesini ve data martlarının eklenmesini kolaylaştırır,

· Garantili performans.

Dezavantajları:

Veri depolama teknolojisi gereksinimlerinde bir artışa yol açan veri yedekliliğinin varlığı,

5. 5. BDT'de veri tabanı yönetim sistemleri ve veri erişim teknolojileri

Veritabanı Yönetim sistemi(DBMS), bir veya daha fazla kullanıcı tarafından bir veritabanı oluşturmak, sürdürmek ve paylaşmak için tasarlanmış bir dizi dil ve yazılım aracıdır.

Şu anda, en yaygın olarak kullanılan VTYS, katı bir matematiksel aygıt tarafından tanımlanan ilişkisel bir veri modeli temelinde oluşturulmuştur. ilişki teorisi.

BDT'de çalışan DBMS'nin bir özelliği, uzayda dağıtılmış ortamlarda bulunan veritabanlarını yönetmek zorunda olmalarıdır.

BDT'de verilerin ek tekrarını veya kopyalanmasını önlemek için, ana vurgu, uzaktan veri işleme ilkesi üzerindedir. CIS'deki veritabanları, birçok kullanıcının ihtiyaç duyduğu verileri içerir. Kullanıcılarla ve tek bir veritabanı ile çalışan yerel bir bilgisayar ağı VTYS'si kurulurken, birkaç kullanıcının veritabanına aynı anda erişimini sağlamak mümkündür.

Veritabanları ile çok kullanıcılı çalışma için temel teknolojik çözümler dosya/sunucu ve istemci/sunucu teknolojileridir. Bu teknolojilerden en kabul edilebilir seçeneği alarak, BDT'deki istemci / sunucu, dağıtılmış veritabanlarını işlemek için özel sistemler düzenler. Aynı zamanda, dağıtılmış veritabanları, verilerin mantıksal düzeyde değil, fiziksel düzeyde dağıtılacağı şekilde yönetilir ve veritabanının kendisi tek bir "süper şema" olarak kabul edilir. Dağıtılmış bir veritabanında, yöneticinin işlevleri, birleşik veritabanı yöneticisi ve yerel veritabanı yöneticileri arasında paylaşılır. Entegre veritabanının yöneticisi, farklı kullanıcıların veritabanına erişiminin farklılaşmasını izler ve verilerin bütünlüğünü ve güvenliğini ve ayrıca birkaç kullanıcı tarafından aynı anda düzeltmeye karşı verilerin korunmasını sağlar. Erişim kontrolü, ağ işletim sisteminde bireysel kullanıcılara verilen haklar doğrultusunda gerçekleştirilir.

Uzak ve dağıtılmış kurumsal veritabanlarıyla çalışmak için DBMS yardımıyla oluşturulan programların karakteristik bir özelliği, açık bir veri erişim arayüzünün kullanılmasıdır - ODBC (Açık Veri Tabanı Bağlantısı). Tüm veri aktarım işlevleri, entegre veritabanının VTYS'si ile istemci uygulamalarının VTYS'si arasında bir bağlantı köprüsü olan ODBC arayüzüne atanır. Aynı zamanda, müşterinin VTYS'si sadece kendi yerel veritabanlarıyla değil, aynı zamanda entegre veri tabanında bulunan verilerle de etkileşime girebilir. İstemci, entegre veritabanının DBMS'sine istek gönderme, bunlarla ilgili verileri alma ve kendi güncellenmiş verilerini gönderme yeteneğine sahiptir.

Endüstri Veri Modelleri

Modellerin temel amacı, veri alanında yönlendirmeyi kolaylaştırmak ve iş geliştirme için önemli olan detayların vurgulanmasına yardımcı olmaktır. Günümüzün iş ortamında, çeşitli bileşenler arasındaki ilişkileri net bir şekilde anlamak ve organizasyonun büyük resmini iyi anlamak kesinlikle çok önemlidir. Modeller kullanılarak tüm detayların ve ilişkilerin tanımlanması, şirketin çalışmalarını organize etmek için zamanın ve araçların en verimli şekilde kullanılmasını sağlar.

Veri modelleri, verilerin nasıl temsil edildiğini ve erişildiğini açıklayan soyut modellerdir. Veri modelleri, belirli bir alanda veri öğelerini ve aralarındaki ilişkileri tanımlar. Veri modeli, belirli bir gerçek bilgi sınıfını doğru bir şekilde açıklamak için belirli bir dizi sembol ve kelime kullanan hem iş hem de BT uzmanları için bir gezinme aracıdır. Bu, organizasyon içindeki iletişimi geliştirir ve böylece daha esnek ve istikrarlı bir uygulama ortamı yaratır.

Veri modeli, bu durumda yapılandırılmış veri olan (değerin belirsiz olabileceği görüntü, ikili dosya veya metin gibi yapılandırılmamış verilerin aksine) verilerin anlamını benzersiz bir şekilde tanımlar.

Kural olarak, daha yüksek seviyeli (ve içerik olarak daha genel) ve daha düşük seviyeli (sırasıyla daha ayrıntılı) modeller ayırt edilir. Modellemenin üst seviyesi sözde kavramsal veri modelleri(kavramsal veri modelleri), bir işletmenin veya kuruluşun işleyişinin en genel resmini verir. Kavramsal model, kuruluşun işleyişi için kritik olan ana kavramları veya konu alanlarını içerir; genellikle sayıları 12-15'i geçmez. Böyle bir model, kuruluş için önemli olan varlık sınıflarını (iş nesneleri), özelliklerini (nitelikleri) ve bu sınıfların çiftleri arasındaki ilişkileri (yani ilişkiler) tanımlar. İş modelleme terminolojisi henüz tam olarak yerleşmediğinden, çeşitli İngilizce kaynaklarda, kavramsal veri modelleri konu alanı modeli (konu alanı modelleri olarak tercüme edilebilir) veya konu kurumsal veri modeli (konu kurumsal veri modelleri) olarak da adlandırılabilir. ).

Bir sonraki hiyerarşik seviye, mantıksal veri modelleri(mantıksal veri modelleri). Bunlara kurumsal veri modelleri veya iş modelleri de denilebilir. Bu modeller veri yapılarını, niteliklerini ve iş kurallarını içerir ve bir kuruluş tarafından iş perspektifinden kullanılan bilgileri temsil eder. Böyle bir modelde veriler, varlıklar ve aralarındaki ilişkiler şeklinde düzenlenir. Mantıksal model, verileri iş kullanıcıları tarafından kolayca anlaşılabilecek şekilde temsil eder. Mantıksal bir modelde, bir veri sözlüğü tahsis edilebilir - farklı kullanıcı kategorilerinin modelin tüm girdi ve bilgi çıktı akışları hakkında ortak bir anlayışa sahip olmasını sağlayan, tam tanımlarıyla birlikte tüm varlıkların bir listesi. Bir sonraki, daha düşük modelleme seviyesi, belirli yazılım araçları ve teknik platformlar kullanılarak mantıksal modelin fiziksel olarak uygulanmasıdır.

Mantıksal model, genellikle normalleştirilmiş bir model şeklini alan ayrıntılı kurumsal iş kararını içerir. Normalleştirme, modeldeki her veri öğesinin yalnızca bir değere sahip olmasını ve birincil anahtara tamamen ve benzersiz bir şekilde bağımlı olmasını sağlayan süreçtir. Veri öğeleri, benzersiz kimliklerine göre gruplar halinde düzenlenir. Veri öğelerini kontrol eden iş kuralları, geçerlilik ve doğruluklarının ön kontrolü ile normalleştirilmiş modele tam olarak dahil edilmelidir. Örneğin, Müşteri Adı gibi bir veri öğesi büyük olasılıkla Ad ve Soyadı olarak bölünecek ve diğer ilgili veri öğeleriyle birlikte Müşteri Kimliğinin birincil anahtarına sahip bir Müşteri varlığı içinde gruplandırılacaktır.

Mantıksal veri modeli, veritabanı, ağ oluşturma veya raporlama araçları gibi uygulama teknolojilerinden ve bunların fiziksel uygulamasından bağımsızdır. Bir kuruluşun yalnızca bir kurumsal veri modeli olabilir. Mantıksal modeller tipik olarak binlerce varlık, ilişki ve nitelik içerir. Örneğin, bir finans kurumu veya telekomünikasyon şirketi için bir veri modeli, yaklaşık 3.000 endüstri konsepti içerebilir.

Mantıksal ve anlamsal veri modeli arasında ayrım yapmak önemlidir. Mantıksal veri modeli, kurumsal iş çözümünü temsil ederken, anlamsal veri modeli, uygulanan iş çözümünü temsil eder. Aynı kurumsal mantıksal veri modeli, farklı anlamsal modeller kullanılarak uygulanabilir, yani. semantik modeller, fiziksel modellere yaklaşan bir sonraki modelleme seviyesi olarak düşünülebilir. Ayrıca, bu modellerin her biri, çeşitli uygulamaların gereksinimlerine göre kurumsal veri modelinin ayrı bir "dilim"ini temsil edecektir. Örneğin, kurumsal bir mantıksal veri modelinde, Müşteri varlığı tamamen normalleştirilir ve bir data mart için semantik bir modelde çok boyutlu bir yapı olarak temsil edilebilir.

Bir şirketin kurumsal mantıksal veri modeli oluşturmanın iki yolu olabilir: kendiniz oluşturun veya hazır bir model kullanın. endüstri modeli(endüstri mantıksal veri modeli). Bu durumda, terimlerdeki farklılıklar yalnızca aynı mantıksal modeli oluşturmaya yönelik farklı yaklaşımları yansıtır. Bir şirketin kendi mantıksal veri modelini bağımsız olarak geliştirmesi ve uygulaması durumunda, kural olarak böyle bir modele basitçe kurumsal mantıksal model denir. Kuruluş, profesyonel bir tedarikçinin bitmiş ürününü kullanmaya karar verirse, o zaman bir endüstri mantıksal veri modelinden bahsedebiliriz. İkincisi, belirli bir endüstrinin işleyişini yüksek derecede doğrulukla yansıtan hazır bir mantıksal veri modelidir. Bir endüstri mantıksal modeli, hem stratejik hem de taktiksel iş sorularını yanıtlamak için bir kurumsal veri ambarında olması gereken tüm bilgilerin etki alanına özgü ve entegre bir görünümüdür. Diğer herhangi bir mantıksal veri modeli gibi, endüstri modeli de uygulama çözümlerine bağlı değildir. Ayrıca, daha hızlı veri alımı için türetilmiş verileri veya diğer hesaplamaları içermez. Kural olarak, böyle bir modelin mantıksal yapılarının çoğu, etkin fiziksel uygulamasında iyi bir düzenleme bulur. Bu modeller birçok satıcı tarafından çok çeşitli alanlar için geliştirilmektedir: finans, üretim, turizm, sağlık, sigorta vb.

Bir endüstri mantıksal veri modeli, bir endüstri için ortak olan bilgileri içerir ve bu nedenle bir şirket için eksiksiz bir çözüm olamaz. Çoğu şirket, veri öğeleri ekleyerek ve tanımları genişleterek modeli ortalama %25 oranında artırmak zorundadır. Bitmiş modeller yalnızca temel veri öğelerini içerir ve geri kalan öğeler, modelin şirkete kurulumu sırasında uygun iş nesnelerine eklenmelidir.

Endüstri mantıksal veri modelleri, önemli sayıda soyutlama içerir. Soyutlama, benzer kavramların Etkinlik veya Katılımcı gibi ortak isimler altında birleştirilmesini ifade eder. Bu, endüstri modellerine esneklik katar ve onları daha birleşik hale getirir. Bu nedenle Event kavramı tüm sektörler için geçerlidir.

İş Zekası uzmanı Steve Hoberman, bir endüstri veri modeli satın alıp almamaya karar verirken dikkate alınması gereken beş faktörü özetliyor. Birincisi, modeli oluşturmak için gereken zaman ve kaynaklardır. Bir kuruluşun hızlı bir şekilde sonuçlara ulaşması gerekiyorsa, endüstri modeli bir avantaj sağlayacaktır. Bir endüstri modeli kullanmak, tüm organizasyonun bir resmini hemen sağlamayabilir, ancak önemli miktarda zaman kazandırabilir. Gerçek modelleme yerine, mevcut yapıları endüstri modeline bağlamak ve bunun organizasyonun ihtiyaçlarına göre en iyi nasıl özelleştirileceğini (örneğin, hangi tanımların değiştirilmesi ve hangi veri öğelerinin eklenmesi gerektiğini) tartışmak için zaman harcanacaktır.

İkinci faktör, modeli çalışır durumda tutmak için gereken zaman ve paradır. Bir kurumsal veri modeli, onu doğru ve güncel tutan bir metodolojinin parçası değilse, model çok hızlı bir şekilde eski hale gelecektir. Sektör veri modeli, dış kaynaklar tarafından güncel tutulduğu için bu riski önleyebilir. Elbette, organizasyon içinde meydana gelen değişiklikler, şirketin kendisi tarafından modele yansıtılmalıdır, ancak sektör değişiklikleri, tedarikçi tarafından modelde yeniden üretilecektir.

Üçüncü faktör, risk değerlendirme ve modelleme deneyimidir. Bir kurumsal veri modeli oluşturmak, hem iş hem de BT personelinden yetenekli kaynaklar gerektirir. Kural olarak, yöneticiler ya bir bütün olarak organizasyonun çalışmalarını ya da belirli bir bölümün faaliyetlerini iyi bilirler. Bunların çok azı işleriyle ilgili hem geniş (şirket çapında) hem de derin (birim çapında) bilgiye sahiptir. Çoğu yönetici genellikle yalnızca bir alanı iyi bilir. Bu nedenle, şirket çapında bir resim elde etmek için önemli iş kaynaklarına ihtiyaç vardır. Bu aynı zamanda BT personeli için gereksinimleri de artırır. Bir modeli oluşturmak ve test etmek için ne kadar fazla iş kaynağı gerekliyse, analistlerin o kadar deneyimli olması gerekir. Sadece işletme personelinden nasıl bilgi alınacağını bilmekle kalmamalı, aynı zamanda tartışmalı alanlarda ortak paydada bulunabilmeli ve tüm bu bilgileri bütünleşik bir şekilde sunabilmelidir. Modeli oluşturan kişi (çoğu durumda bu aynı analisttir) iyi modelleme becerilerine sahip olmalıdır. Kurumsal mantık modelleri oluşturmak, "gelecek için" modelleme ve karmaşık işleri kelimenin tam anlamıyla "kareler ve çizgiler"e dönüştürme becerisi gerektirir.

Öte yandan, endüstri modeli, üçüncü taraf uzmanların deneyimini kullanmanıza izin verir. Sektöre özel mantık modelleri, bir kuruluş içinde kurumsal veri modelleri geliştirirken ortaya çıkabilecek yaygın ve maliyetli sorunlardan kaçınmak için kanıtlanmış modelleme metodolojileri ve deneyimli profesyonellerden oluşan ekipler kullanır.

Dördüncü faktör, mevcut uygulama altyapısı ve satıcı ilişkileridir. Bir kuruluş zaten aynı satıcıdan birçok araç kullanıyorsa ve onlarla ilişkiler kurduysa, o zaman endüstri modelini onlardan da sipariş etmek mantıklıdır. Böyle bir model, aynı tedarikçinin diğer ürünleriyle serbestçe çalışabilecektir.

Beşinci faktör, endüstri içi bilgi alışverişidir. Bir şirketin aynı alanda faaliyet gösteren diğer kuruluşlarla veri paylaşması gerekiyorsa, bu durumda bir endüstri modeli çok yardımcı olabilir. Aynı sektördeki kuruluşlar, benzer yapısal bileşenleri ve terminolojiyi kullanır. Günümüzde çoğu sektörde şirketler işlerini başarılı bir şekilde yürütmek için verileri paylaşmak zorunda kalıyor.

Profesyonel satıcılar tarafından sunulan endüstri modelleri en etkili olanlardır. Kullanımlarının yüksek verimliliği, bu modellerin önemli düzeyde ayrıntı ve doğruluğu nedeniyle elde edilir. Genellikle birçok veri özniteliği içerirler. Ek olarak, bu modellerin yaratıcıları yalnızca kapsamlı modelleme deneyimine sahip olmakla kalmaz, aynı zamanda belirli bir sektör için model oluşturma konusunda da bilgilidir.

Endüstri veri modelleri, şirketlere iş bilgilerinin tek ve entegre bir görünümünü sağlar. Çoğu şirket, verilerini entegre etmeyi zor bulmaktadır, ancak bu, kurumsal çaptaki çoğu proje için bir ön koşuldur. The Data Warehousing Institute (TDWI) tarafından yapılan bir araştırmaya göre, ankete katılan kuruluşların %69'undan fazlası, entegrasyonun yeni uygulamanın benimsenmesinin önünde önemli bir engel olduğunu buldu. Aksine, veri entegrasyonunun uygulanması şirkete önemli bir gelir getiriyor.

Endüstri veri modeli, mevcut sistemlerle bağlantı kurmanın yanı sıra kurumsal kaynak planlaması (ERP), ana veri yönetimi, iş zekası, veri kalitesinin iyileştirilmesi ve çalışan gelişimi gibi kurumsal çaptaki projeler için büyük faydalar sağlar.

Bu nedenle, endüstri mantıksal veri modelleri, verileri entegre etmek ve işin bütünsel bir resmini elde etmek için etkili bir araçtır. Mantıksal modellerin kullanılması, kurumsal veri ambarlarının oluşturulması için gerekli bir adım gibi görünüyor.

Yayınlar

1. Steve Hoberman. Kurumsal Veri Modeliniz Olarak Endüstri Mantıksal Veri Modelinden Yararlanma
2. Claudia Imhoff. Akıllı Veri Modelleme ile Hızlı Takip Veri Ambarı ve İş Zekası Projeleri

Kurumsal veri tabanı, kurumsal bilgi sisteminin merkezi bağlantısıdır ve tek bir kurumsal bilgi alanı oluşturmanıza olanak tanır. Kurumsal veritabanları

Çalışmaları sosyal ağlarda paylaşın

Bu çalışma size uymuyorsa sayfanın alt kısmında benzer çalışmaların listesi bulunmaktadır. Arama butonunu da kullanabilirsiniz

TEMA V KURUMSAL VERİTABANLARI

V .1. Kurumsal sistemlerde verilerin organizasyonu. Kurumsal veri tabanları.

V .2. Kurumsal sistemlerde DBMS ve yapısal çözümler.

V.3. İnternet / İntranet teknolojileri ve kurumsal veritabanı erişim çözümleri.

V .1. KURUMSAL SİSTEMLERDE VERİ ORGANİZASYONU. KURUMSAL VERİTABANLARI

Kurumsal baz data, kurumsal bilgi sisteminin merkezi bağlantısıdır ve kurumun tek bir bilgi alanını oluşturmanıza olanak tanır. Kurumsal veri tabanları (Şekil 1.1).

Veritabanlarının çeşitli tanımları vardır.

Veritabanının altında (DB) Bir bilgisayarın depolama aygıtlarında depolanan tek bir veri kümesini oluşturacak şekilde mantıksal olarak ilişkili bir dizi bilgiyi anlayın. Bu set, otomatik kontrol sistemlerinin, veri işleme sistemlerinin, bilgi ve bilgi işlem sistemlerinin işleyişi sürecinde çözülen görevlerin ilk verileri olarak işlev görür.

Veritabanı terimini, paylaşmaya yönelik mantıksal olarak ilişkili verilerin bir koleksiyonu olarak kısaca formüle edebilirsiniz.

veritabanı altında bir veya daha fazla uygulama için en uygun şekilde kullanılabilecek şekilde minimum fazlalık ile birlikte depolanan bir veri koleksiyonunu ifade eder.

Veritabanları oluşturmanın amacı bir veri depolama biçimi olarak benimsenen algoritmalara (yazılım), kullanılan teknik araçlara, verilerin bilgisayardaki fiziksel konumuna bağlı olmayan bir veri sistemi oluşturmak. Veritabanı çok amaçlı kullanım (birkaç kullanıcı, birçok belge formu ve bir kullanıcının sorgusu) olduğunu varsayar.

Temel veritabanı gereksinimleri:

• Veri sunumunun eksiksizliği. Veritabanındaki veriler, nesne hakkındaki tüm bilgileri yeterince temsil etmeli ve ODS için yeterli olmalıdır.
• Veritabanı bütünlüğü. Veriler, ODS'lerinin işlenmesi sırasında ve çalışma sırasında ortaya çıkan herhangi bir durumda korunmalıdır.
• Veri yapısının esnekliği. Veritabanı, dış koşullar değiştiğinde bütünlüğünü ve bütünlüğünü bozmadan veri yapılarının değiştirilmesine izin vermelidir.
• Gerçekleştirilebilirlik. Bu, çeşitli nesnelerin, özelliklerinin ve ilişkilerinin nesnel bir temsilinin olması gerektiği anlamına gelir.
• kullanılabilirlik. Veriye erişimin farklılaşmasının sağlanması gerekmektedir.
• fazlalık. Veritabanı, herhangi bir nesne hakkındaki verileri temsil etmede minimum fazlalığa sahip olmalıdır.

Bilgi anlaşılır sorunu çözebileceğiniz bir dizi gerçek, model ve buluşsal kural.

Bilgi tabanı (KB)  Karar vericilerden alınan, kullanılan veri tabanları ve kuralların toplanması. Bilgi tabanı, uzman sistemlerin bir unsurudur.

ayırt edilmelidir verileri sunmanın farklı yolları.

Fiziksel bilgi - Bu, bilgisayarın belleğinde depolanan verilerdir.

Verilerin mantıksal temsili kullanıcının fiziksel veri temsiline karşılık gelir. Verilerin fiziksel ve karşılık gelen mantıksal temsili arasındaki fark, ikincisinin fiziksel veriler arasındaki bazı önemli ilişkileri yansıtmasıdır.

kurumsal veritabanı altında Otomatikleştirilmiş bir organizasyon hakkında gerekli tüm veri ve bilgileri bir biçimde veya başka bir şekilde birleştiren bir veritabanını anlayın. Kurumsal bilgi sistemlerinde böyle bir kavramentegre veritabanları, tek giriş ve çoklu bilgi kullanımı ilkesinin uygulandığı.

Pirinç. 1.1. Departmanların kurumun bilgi kaynakları ile etkileşiminin yapısı.

Kurumsal veri tabanları odaklanmış (merkezileştirilmiş) ve dağıtıldı.

Konsantre (merkezi) veritabanı verileri fiziksel olarak bir bilgisayarın depolama aygıtlarında depolanan bir veritabanıdır. Şek. 1.2, çeşitli platformlardaki veritabanlarına erişmek için bir sunucu uygulamasının bir diyagramını gösterir.

Şekil 1.2. Heterojen bir diyagram merkezi veritabanı

Bilgi işlemenin merkezileştirilmesi, geleneksel dosya sistemlerinin tutarsızlık, tutarsızlık ve veri fazlalığı gibi eksikliklerini ortadan kaldırmayı mümkün kıldı. Ancak veri tabanları büyüdükçe ve özellikle coğrafi olarak dağınık organizasyonlarda kullanıldığında sorunlar ortaya çıkmaktadır. Örneğin, bir kuruluşun çeşitli bölümlerinin verilere eriştiği bir telekomünikasyon ağ düğümünde bulunan konsantre veri tabanları için, bilgi hacminde ve işlem sayısında bir artış ile aşağıdaki zorluklar ortaya çıkar:

• Büyük veri alışverişi akışı;
• Yüksek ağ trafiği;
• Düşük güvenilirlik;
• Düşük genel performans.

Yoğunlaştırılmış bir veritabanında güncellemeler sırasında bilgilerin güvenliğini, bütünlüğünü ve tutarlılığını sağlamak daha kolay olsa da, bu sorunlar bazı zorluklar yaratır. Veri ademi merkeziyetçiliği bu sorunlara olası bir çözüm olarak önerilmiştir. Ademi merkeziyetçilik şunları sağlar:

• Yük paylaşımı nedeniyle daha yüksek derecede işleme eşzamanlılığı;
• Uzak (uzaktan) sorgular yapılırken sahadaki verilerin kullanımının iyileştirilmesi;
• daha düşük maliyetler;
• Yerel veritabanlarını yönetmek kolaydır.

Düğümlerinde iş istasyonları (küçük bilgisayarlar) bulunan bir ağ oluşturmanın maliyeti, bir ana bilgisayar kullanarak benzer bir sistem oluşturmanın maliyetinden çok daha düşüktür. Şekil 1.3, dağıtılmış bir veritabanının mantıksal bir diyagramını göstermektedir.

Şekil 1.3. Dağıtılmış kurumsal veritabanı.

Dağıtılmış bir veritabanının aşağıdaki tanımını veriyoruz.

Dağıtılmış veritabanı - bu, bilgi ağının farklı düğümlerinde depolanan ve tek bir veri kümesi oluşturacak şekilde mantıksal olarak birbirine bağlanan bir bilgi, dosya (ilişki) koleksiyonudur (bağlantı işlevsel olabilir veya aynı dosyanın kopyaları aracılığıyla olabilir). Bu nedenle, mantıksal olarak birbirine bağlı, ancak fiziksel olarak aynı bilgisayar ağının parçası olan birkaç makinede bulunan bir dizi veri tabanıdır.

Dağıtılmış bir veritabanının özellikleri için en önemli gereksinimler şunlardır:

• Ölçeklenebilirlik;
• Uyumluluk;
• Çeşitli veri modelleri için destek;
• taşınabilirlik;
• Konum şeffaflığı;
• Dağıtılmış veritabanı düğümlerinin özerkliği (Site Özerkliği);
• Dağıtılmış isteklerin işlenmesi;
• Dağıtılmış işlemlerin yürütülmesi.
• Homojen bir güvenlik sistemi için destek.

Konum şeffaflığı, kullanıcıların konumları hakkında hiçbir şey bilmeden veritabanlarıyla çalışmasına olanak tanır. Dağıtılmış veritabanı düğümlerinin özerkliği, her bir veritabanının diğerlerinden bağımsız olarak korunabileceği anlamına gelir. Dağıtılmış sorgu, farklı veritabanlarının nesnelerine (tablolar veya görünümler) erişimin gerçekleştiği bir sorgudur (SQL ifadesi). Dağıtılmış işlemler yürütülürken, ilgili tüm veritabanları üzerinde eşzamanlılık kontrolü uygulanır. Oracle7, dağıtılmış işlemleri gerçekleştirmek için iki aşamalı bilgi aktarım teknolojisini kullanır.

Dağıtılmış bir veritabanını oluşturan veritabanlarının homojen olması (yani aynı VTYS tarafından çalıştırılması) veya aynı işletim sistemi ortamında ve/veya aynı tür bilgisayarlarda çalışması gerekmez. Örneğin, bir veritabanı SUN OS(UNIX) çalıştıran bir SUN bilgisayarındaki bir Oracle veritabanı olabilir, ikinci bir veritabanı bir MVS işletim sistemi çalıştıran bir IBM 3090 anabilgisayarında bir DB2 DBMS tarafından çalıştırılabilir ve üçüncü bir veritabanı aşağıdakiler tarafından çalıştırılabilir. IBM ana bilgisayarında da bir SQL/DS DBMS, ancak bir VM işletim sistemi. Yalnızca bir koşul zorunludur - veritabanlarına sahip tüm makinelere parçası oldukları ağ üzerinden erişilebilir olmalıdır.

Dağıtılmış bir veritabanının ana görevi – verilerin ağ üzerinden dağıtılması ve buna erişim sağlanması. Bu sorunu çözmenin aşağıdaki yolları vardır:

• Her düğüm, uzak sorgular için kullanılabilen kendi veri kümesini depolar ve kullanır. Bu dağıtım bölünür.
• Uzak sitelerde sıklıkla kullanılan bazı veriler çoğaltılabilir. Böyle bir dağıtıma kısmen çoğaltılmış denir.
• Tüm veriler her düğümde çoğaltılır. Böyle bir dağıtıma tamamen yedekli denir.
• Bazı dosyalar yatay olarak (bir kayıt alt kümesi seçilir) veya dikey olarak (öznitelik alanlarının bir alt kümesi seçilir) bölünebilirken, bölünmüş alt kümeler bölünmemiş verilerle birlikte farklı düğümlerde depolanır. Bu tür dağılıma bölünmüş (parçalanmış) denir.

Kavramsal düzeyde dağıtılmış bir veritabanı oluştururken aşağıdaki görevleri çözmeniz gerekir:

• Tüm ağ için tek bir kavramsal şemaya sahip olmak gerekir. Bu, kullanıcı için mantıksal veri şeffaflığı sağlayacaktır, bunun sonucunda tüm veritabanına ayrı bir terminalde (merkezi bir veritabanıyla olduğu gibi çalışır) bir istek oluşturabilecektir.
• Ağdaki verileri bulmak için bir şemaya ihtiyaç vardır. Bu, kullanıcının gerekli verileri almak için talebi nereye ileteceğini belirtmek zorunda kalmaması için veri yerleştirmede şeffaflık sağlayacaktır.
• Dağıtılmış veritabanlarının heterojenliği sorununu çözmek gerekir. Dağıtık veri tabanları, donanım ve yazılım açısından homojen veya heterojen olabilir. Dağıtılmış veritabanı donanım açısından heterojen, ancak yazılım açısından homojen ise (düğümlerdeki aynı VTYS) heterojenlik sorununu çözmek nispeten kolaydır. Dağıtılmış bir sistemin düğümlerinde farklı DBMS kullanılıyorsa, veri yapılarını ve dilleri dönüştürmek için araçlara ihtiyaç vardır. Bu, dağıtılmış veritabanı düğümlerinde dönüşümün şeffaflığını sağlamalıdır.
• Sözlükleri yönetme sorununu çözmek gerekir. Dağıtılmış bir veritabanında her türlü şeffaflığı sağlamak için çok sayıda sözlük ve referans kitabı yöneten programlara ihtiyaç vardır.
• Dağıtılmış bir veritabanında sorguları yürütmek için yöntemler tanımlamak gereklidir. Dağıtılmış bir veritabanında sorgu yürütme yöntemleri, merkezileştirilmiş veritabanlarındaki benzer yöntemlerden farklıdır, çünkü sorguların ayrı bölümleri ilgili verilerin konumunda yürütülmeli ve kısmi sonuçları diğer düğümlere aktarmalıdır; aynı zamanda tüm süreçlerin koordinasyonu sağlanmalıdır.
• Sorguların paralel yürütülmesi sorununu çözmek gerekir. Dağıtılmış bir veritabanında, eşzamanlı işlemeyi yönetmek için, özellikle bilgi güncellendiğinde senkronizasyonu sağlaması gereken, veri tutarlılığını garanti eden karmaşık bir mekanizma gereklidir.
• Bölme de dahil olmak üzere verilerin dağıtımı ve yerleştirilmesi için gelişmiş bir metodoloji ihtiyacı, dağıtılmış bir veritabanı için ana gereksinimlerden biridir.

Sayısal olmayan bilgi işleme için güçlü bir araç olan bilgisayar sistemleri mimarisinin aktif olarak gelişen yeni alanlarından biri, veritabanı makineleri. Veritabanı makineleri, belgeler ve gerçekleri depolamak, aramak ve dönüştürmek, nesnelerle çalışmak gibi sayısal olmayan görevleri çözmek için kullanılır. Verinin, çevreleyen dünyanın nesneleri hakkında dijital ve grafik bilgi olarak tanımlanmasının ardından, sayısal ve sayısal olmayan işlemede veri kavramına farklı içerikler gömülür. Sayısal işleme, değişkenler, vektörler, matrisler, çok boyutlu diziler, sabitler vb. gibi nesneleri kullanırken sayısal olmayan işleme, dosyalar, kayıtlar, alanlar, hiyerarşiler, ağlar, ilişkiler vb. nesneleri kullanır. sayısal işleme, çalışan dosyasının kendisiyle değil, doğrudan nesneler (örneğin, belirli bir çalışan veya çalışan grubu) hakkındaki bilgilerle ilgilidir. Belirli bir kişiyi seçmek için çalışan dosyasını indekslemez; Burada istenen kaydın içeriğiyle daha çok ilgilenir. Büyük hacimli bilgiler genellikle sayısal olmayan işleme tabi tutulur. Çeşitli uygulamalarda, bu veriler üzerinde bu tür işlemler gerçekleştirilebilir, örneğin:

• şirketin tüm çalışanlarının maaşını artırmak;
• tüm müşterilerin hesaplarındaki banka faizini hesaplamak;
• stoktaki tüm malların listesinde değişiklik yapmak;
• kütüphanede veya bibliyografik bilgi erişim sisteminde saklanan tüm metinlerden gerekli özeti bulmak;
• yasal belgeleri içeren bir dosyada istenen sözleşmenin tanımını bulun;
• patent açıklamalarını içeren tüm dosyaları görüntüleyin ve önerilene benzer bir patent (varsa) bulun.

Veritabanı motorunu uygulamak için, paralel ve ilişkisel tek işlemciye alternatif olarak mimarilervon Neumanngerçek zamanlı olarak büyük miktarda bilgi ile çalışmanıza izin veren yapı.

Veritabanı motorları, bilgi temsili, uzman sistemler, çıkarım, örüntü tanıma vb. gibi yapay zeka kavramlarının keşfedilmesi ve uygulanmasıyla bağlantılı olarak önem kazanmaktadır.

Bilgi depoları. Günümüzde pek çok kişi, çoğu şirketin halihazırda birkaç veritabanı işlettiğini ve bilgiyle başarılı bir şekilde çalışmak için yalnızca farklı türde veritabanlarına değil, farklı nesil VTYS'lere de ihtiyaç duyulduğunu kabul ediyor. İstatistiklere göre, her kuruluş ortalama 2,5 farklı DBMS kullanıyor. Şirketlerin işlerini, daha doğrusu bu işle uğraşan kişileri, veritabanlarının teknolojik özelliklerinden "yalıtmak", kullanıcılara, fiziksel olarak nerede depolandığına bakılmaksızın tek bir kurumsal bilgi görünümü sağlamak için ihtiyaç belirgin hale geldi. . Bu, bilgi depolama teknolojisinin ortaya çıkmasını teşvik etti ( Veri Ambarı, DW).

DW'nin temel amacı, farklı veritabanlarında bulunan verilerin tek bir mantıksal temsilinin veya başka bir deyişle tek bir kurumsal veri modelinin oluşturulması.

Genel olarak bilgi teknolojisinin gelişmesi, özellikle de paralel bilgisayar alanındaki gelişmelere dayanan paralel sorgu işlemeye dayalı yeni veritabanlarının ortaya çıkması sayesinde yeni bir DW geliştirme turu mümkün oldu. Biz oluşturduk sorgu oluşturucularkarmaşık veritabanı sorguları oluşturmayı kolaylaştıran sezgisel bir grafik arayüz ile. çeşitli yazılımara katman yazılımısağlanan iletişimfarklı veritabanları türleri arasındave sonunda fiyatta keskin bir düşüş yaşadıbilgi depolama cihazları.

Bir şirketin yapısında bir veri bankası bulunabilir.

Veri tabanı - otomatik kontrol sistemlerinde ve bilgi ve bilgisayar sistemlerinde, bir grup kullanıcı veya sistemde çözülen bir dizi görev için merkezi bilgi desteği sağlayan işlevsel ve organizasyonel bileşen.

Veri tabanı temel amacı olan bir bilgi ve referans sistemi olarak kabul edilir:

• tüm otomatik sistemin bilgi tabanını oluşturan bir dizi bilginin veya içinde çözülen belirli bir dizi görevin çalışma durumunda toplanması ve bakımı;
• görevin veya kullanıcının gerektirdiği verilerin verilmesinde;
• saklanan bilgilere toplu erişim sağlamada;
• bilgi tabanında yer alan bilgilerin kullanımının gerekli yönetiminin sağlanmasında.

Bu nedenle, modern bir veri bankası, teknik, sistem ve ağ araçlarını, veritabanlarını ve DBMS'yi, çeşitli amaçlar için bilgi alma sistemlerini içeren karmaşık bir yazılım ve donanım kompleksidir.

V .2. KURUMSAL SİSTEMLERDE VTYS VE YAPISAL ÇÖZÜMLER

Veritabanı ve bilgi yönetim sistemleri

Modern bilgi sistemlerinin önemli bir bileşeni, veritabanı yönetim sistemleridir (DBMS).

VTYS - veritabanları oluşturmak, sürdürmek ve kullanmak için tasarlanmış bir dizi yazılım ve dil aracı.

Veritabanı yönetim sistemi, veri işleme sistemlerine veritabanlarına erişim sağlar. Daha önce belirtildiği gibi, kurumsal bilgi sistemlerinin oluşturulmasında DBMS'nin önemli bir rolü ve modern ağ bilgisayar teknolojilerine dayalı dağıtılmış bilgi kaynakları kullanılarak bilgi sistemlerinin oluşturulmasında özellikle önemli bir rol elde edilmektedir.

Modern DBMS'nin ana özelliği, modern DBMS'nin aşağıdaki gibi teknolojileri desteklemesidir:

• istemci/sunucu teknolojisi.
• Veritabanı dilleri için destek. Buşema tanımlama dili DB (SDL - Şema Tanımlama Dili),veri işleme dili (DML - Data Manipulation Language), entegre diller SQL (Yapılandırılmış Kuyruk Dili), QDB (Sorgu - Örnek Olarak) ve QMF (Sorgu Yönetim Tesisi) ) için sorgu belirtimi ve rapor üretimi için gelişmiş bir çevre birimi aracıdır. DB 2 vb.;
• Harici bellekteki verilerin doğrudan yönetimi.
• Bellek arabelleği yönetimi.
• İşlem yönetimi. OLTP teknolojisi (Çevrimiçi İşlem İşleme), OLAP - teknoloji (Çevrimiçi Analiz İşleme) DW için.
• Veri koruma ve bütünlüğünü sağlayın. Sistemin kullanımına yalnızca verilere erişim hakkı olan kullanıcılar izin verilir. Kullanıcılar veriler üzerinde işlem yaptığında, saklanan verilerin tutarlılığı (bütünlüğü) korunur. Bu, kurumsal çok kullanıcılı bilgi sistemlerinde önemlidir.
• Günlük tutma.

Modern DBMS, yukarıda listelenen veritabanı gereksinimlerini karşılamalıdır. Ayrıca, aşağıdaki ilkelere uymaları gerekir:

• Veri bağımsızlığı.
• çok yönlülük VTYS, kavramsal veri modelinin özel mantıksal görünümleri görüntülemesi için güçlü bir desteğe sahip olmalıdır.
• uyumluluk DBMS, yazılım ve donanımın geliştirilmesiyle birlikte çalışır durumda kalmalıdır.
• Veri yedekleme. Dosya sistemlerinden farklı olarak, bir veritabanı tek bir entegre veri kümesi olmalıdır.
• Veri koruması. DBMS, yetkisiz erişime karşı koruma sağlamalıdır.
• Veri bütünlüğü. DBMS, kullanıcıların veritabanını değiştirmesini engellemelidir.
• Eş zamanlı çalışmayı yönetmek. DBMS, veritabanını paylaşılan erişim modundaki tutarsızlıklardan korumalıdır. Veritabanının tutarlı bir durumunu sağlamak için tüm kullanıcı isteklerinin (işlemlerinin) belirli bir sırayla gerçekleştirilmesi gerekir.
• DBMS evrensel olmalıdır. Tek bir mantıksal ve fiziksel temelde farklı veri modellerini desteklemelidir.
• VTYS hem merkezileştirilmiş hem de dağıtılmış veritabanlarını desteklemeli ve böylece bilgisayar ağlarında önemli bir bağlantı haline gelmelidir.

Bir VTYS'yi otomatikleştirilmiş sistemlerde veritabanlarının bakımına odaklanan bir yazılım ürünleri sınıfı olarak düşünürsek, VTYS türlerini belirleyen en önemli iki özelliği ayırt edebiliriz. Onlara göre DBMS iki açıdan ele alınabilir:

• dağıtılmış (kurumsal) veritabanlarına ilişkin yetenekleri;
• DBMS'de uygulanan veri modeli türüyle ilişkileri.

Kurumsal (dağıtılmış) veritabanlarıyla ilgili olarak, aşağıdaki VTYS türleri geleneksel olarak ayırt edilebilir:

• DBMS "masaüstü". Bu ürünler öncelikle kişisel verilerle (masaüstü verileri) çalışmaya odaklanır. Ortak veritabanlarını paylaşmak için komut setleri vardır, ancak boyutları küçüktür (küçük ofis tipi). Her şeyden önce, Access, dBASE, Paradox, ExPro gibi bir DBMS'dir. Access, dBASE, Paradox, ExPro neden kurumsal verilere zayıf erişime sahip? Gerçek şu ki, kişisel ve kurumsal veriler arasındaki engeli aşmanın kolay bir yolu yoktur. Ve mesele, bir kişisel veri DBMS'sinin (veya küçük bir ofisin) mekanizmasının, birçok ağ geçidi, ağ geçidi ürünü vb. aracılığıyla verilere erişmeye odaklanması bile değildir. Sorun şu ki, bu mekanizmalar tipik olarak tam dosya aktarımlarını ve kapsamlı dizin desteğinin eksikliğini içerir, bu da büyük sistemlerde pratikte durma olan sunucu kuyruklarına neden olur.
• Özel yüksek performanslı çok kullanıcılı DBMS. Bu tür VTYS'ler, çok kullanıcılı bir sistem çekirdeği, bir veri işleme dili ve geliştirilmiş çok kullanıcılı VTYS'ler için tipik olan aşağıdaki işlevlerin varlığı ile karakterize edilir:
• bir tampon havuzunun düzenlenmesi;
• işlem sıralarını işlemek için bir sistemin varlığı;
• çok kullanıcılı veri engelleme mekanizmalarının varlığı;
• işlem günlüğü;
• erişim kontrol mekanizmalarının mevcudiyeti.

Bunlar Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium gibi DBMS'dir ve diğerleri kurumsal veritabanlarının işlenmesi için geniş bir hizmet sunar.

Veritabanlarıyla çalışırken, işlem mekanizması kullanılır.

işlem mantıksal bir iş birimidir.

işlem yürütülen bir dizi veri işleme ifadesidirtek olarak(hepsi ya da hiçbiri) ve çeviri veritabanıbir bütünsel durumdan başka bir bütünsel duruma.

Bir işlemin ASID özellikleri olarak bilinen dört önemli özelliği vardır:

• (A) Atomiklik . İşlem, atomik bir işlem olarak yürütülür - tüm işlem yürütülür veya işlemin tamamı yürütülmez.
• (C) Tutarlılık. Bir işlem, bir veritabanını tutarlı (tutarlı) bir durumdan başka bir tutarlı (tutarlı) duruma taşır. Bir işlem içinde, veritabanı tutarlılığı bozulabilir.
• (I) İzolasyon . Farklı kullanıcıların işlemleri birbirine müdahale etmemelidir (örneğin, kesinlikle sırayla yapılıyormuş gibi).
• (D) Dayanıklılık. İşlem tamamlanmışsa, bir sonraki anda sistem çökse bile, çalışmasının sonuçları veritabanına kaydedilmelidir.

İşlem genellikle kullanıcının VTYS'ye katıldığı andan itibaren otomatik olarak başlar ve aşağıdaki olaylardan biri gerçekleşene kadar devam eder:

• Bir COMMIT WORK komutu verildi (bir işlemi gerçekleştirmek için).
• ROLLBACK WORK komutu yayınlandı.
• Kullanıcının DBMS ile bağlantısı kesildi.
• Sistemde bir arıza vardı.

Kullanıcı için genellikle giyer atomik karakter. Aslında bu, kullanıcı (uygulama) ve veritabanı arasındaki karmaşık bir etkileşim mekanizmasıdır. Kurumsal sistem yazılımı, gerçek zamanlı bir işlem işleme motoru kullanır (Çevrimiçi İşlem İşleme Sistemleri, OLTP), özellikle muhasebe programları, müşteri uygulamalarını almak ve işlemek için yazılımlar, finansal uygulamalar, birçok bilgi üretir. Bu sistemler, büyük miktarda veriyi, karmaşık işlemleri ve yoğun okuma/yazma işlemlerini işlemek için tasarlanmıştır (ve uygun şekilde optimize edilmiştir).

Ne yazık ki, OLTP sistemlerinin veri tabanlarına yerleştirilen bilgiler, sıradan kullanıcılar tarafından kullanım için çok uygun değildir (yüksek derecede tablo normalizasyonu, belirli veri sunum formatları ve diğer faktörler nedeniyle). Bu nedenle, farklı bilgi işlem hatlarından gelen veriler (kopyalanmak anlamında) kullanıcıya gönderilir. depolama deposu, sıralama ve tüketiciye müteakip teslimat. Bilgi teknolojisinde, depoların rolü şu kişiler tarafından oynanır:bilgi depoları.

Bilginin son kullanıcıya teslimi - gerçek zamanlı olarak analitik veri işleme sistemleri devreye girer (Çevrimiçi Analitik İşleme, OLAP), sorgular oluşturmak ve sonuçları analiz etmek için uygun araçlar aracılığıyla verilere son derece kolay erişim sağlar. OLAP sistemlerinde, çeşitli analiz ve istatistiksel işleme yöntemleri kullanılarak bir bilgi ürününün değeri artırılır. Ek olarak, bu sistemler veri çıkarma hızı, genelleştirilmiş bilgilerin toplanması açısından optimize edilmiştir ve sıradan kullanıcılara odaklanmıştır (sezgisel bir arayüze sahiptirler). Eğer OLTP sistemi "Ocak 199x'te M bölgesinde N ürününün satış düzeyi neydi?" gibi basit sorulara yanıt verir, ardından OLAP sistemleri daha karmaşık kullanıcı istekleri için hazırsınız, örneğin: "Önceki iki yıla kıyasla ikinci çeyrek planına göre tüm bölgeler için N ürününün satışlarının bir analizini verin."

İstemci/sunucu mimarisi

Modern sistemlerde dağıtılmış bilgi işlemeteknoloji ön plana çıkıyor müşteri sunucusu. sistemde istemci-sunucu mimarileriveri işleme, aralarındaki iletişim bir ağ üzerinden gerçekleşen bir istemci bilgisayar ve bir sunucu bilgisayar arasında bölünür. Veri işleme süreçlerinin bu ayrımı, işlevlerin gruplandırılmasına dayanmaktadır. Tipik olarak, bir istemci bilgisayar uygulama programlarını çalıştırırken, bir veritabanı sunucusu bilgisayarı veritabanı işlemlerini gerçekleştirmek için ayrılmıştır. Şekil 2.1, sunucu görevi gören bir bilgisayar ve istemcisi olarak görev yapan başka bir bilgisayarı içeren basit bir istemci-sunucu mimarisi sistemini göstermektedir. Her makine farklı işlevleri yerine getirir ve kendi kaynaklarına sahiptir.

		Veri tabanı
sunucu bilgisayar
Ağ
IBM uyumlu bilgisayar	IBM uyumlu bilgisayar	IBM uyumlu bilgisayar
		Uygulamalar

Pirinç. 2.1. İstemci-sunucu mimarisi sistemi

İstemci bilgisayarın ana işlevi, uygulamayı (kullanıcı arayüzü ve sunum mantığı) çalıştırmak ve uygulama tarafından gerektiğinde sunucu ile iletişim kurmaktır.

sunucu - Bu, istekleri üzerine diğer nesnelere hizmet sağlayan bir nesnedir (bilgisayar).

Terimden de anlaşılacağı gibi, sunucu bilgisayarın ana işlevi, istemcinin ihtiyaçlarına hizmet etmektir. "Sunucu" terimi, iki farklı işlev grubunu belirtmek için kullanılır: bir dosya sunucusu ve bir veritabanı sunucusu (bundan böyle bu terimler, bağlama bağlı olarak, bu işlev gruplarını uygulayan yazılım veya bu yazılıma sahip bilgisayarlar anlamına gelir). ). Dosya sunucuları veritabanı işlemlerini gerçekleştirmek için tasarlanmamıştır, ana işlevleri dosyaları birkaç kullanıcı arasında paylaşmaktır, yani. birçok kullanıcının bilgisayardaki dosyalara aynı anda erişmesini sağlamak - bir dosya sunucusu. Dosya sunucusuna bir örnek, Novell'in NetWare işletim sistemidir. Veritabanı sunucusu, bir dosya sunucusu bilgisayarına kurulabilir ve çalıştırılabilir. NLM (Ağ Yüklenebilir Modülü) biçimindeki Oracle DBMS, bir dosya sunucusunda NetWare ortamında çalışır.

Yerel ağ sunucusu, işlevsel amacına ve ağın gereksinimlerine uygun kaynaklara sahip olmalıdır. Açık sistem yaklaşımına yönelim nedeniyle, farklı bilgisayarlarda bulunması gerekmeyen mantıksal sunuculardan (yani bu kaynaklar üzerinden hizmet sağlayan bir dizi kaynak ve yazılım aracı anlamına gelir) bahsetmenin daha doğru olduğunu unutmayın. Açık bir sistemdeki mantıksal sunucunun bir özelliği, verimlilik nedeniyle sunucunun ayrı bir bilgisayara taşınması uygunsa, bunun hem kendisinde hem de uygulamada herhangi bir değişiklik yapılmasına gerek kalmadan yapılabilmesidir. kullanan programlar.

Önemli sunucu gereksinimlerinden biri, veritabanı sunucusunun barındırıldığı işletim sisteminin çok görevli (ve tercihen, ancak zorunlu olarak değil, çok kullanıcılı) olması gerektiğidir. Örneğin, çoklu görev gereksinimini karşılamayan MS-DOS (veya PC-DOS) işletim sistemine sahip bir kişisel bilgisayara kurulan Oracle DBMS, veritabanı sunucusu olarak kullanılamaz. Ve çok görevli (çok kullanıcılı olmasa da) OS / 2 işletim sistemine sahip bir bilgisayara kurulu aynı Oracle DBMS, bir veritabanı sunucusu olabilir. UNIX, MVS, VM ve diğer bazı işletim sistemlerinin birçok çeşidi hem çok görevli hem de çok kullanıcılıdır.

Dağıtılmış Bilgi İşlem

"Dağıtılmış bilgi işlem" terimi genellikle birbirini tamamlayıcı olmakla birlikte iki farklı kavramı belirtmek için kullanılır:

• Dağıtılmış veritabanı;
• Dağıtılmış veri işleme.

Bu kavramların uygulanması, çeşitli araçlar kullanarak son kullanıcılar için çeşitli makinelerde depolanan bilgilere erişimi düzenlemeyi mümkün kılar.

Birçok sunucu türü vardır:

• Veritabanı sunucusu;
• Yazdırma sunucusu;
• Uzaktan erişim sunucusu;
• Faks sunucusu;
• Web sunucusu vb.

İstemci/Sunucu teknolojisinin özünde Aşağıdaki gibi temel teknolojiler vardır:

• İşletim sistemleri teknolojileri, açık sistemlerin etkileşimi kavramı, programların işleyişi için nesneye yönelik ortamların oluşturulması;
• Telekomünikasyon teknolojileri;
• Ağ teknolojileri;
• Grafiksel kullanıcı arayüzü teknolojileri ( GUI);
• Vb.

İstemci-sunucu teknolojisinin avantajları:

• İstemci/sunucu teknolojisi, heterojen bilgi işlem ortamlarında bilgi işlem yapılmasına izin verir. Platform Bağımsızlığı: Farklı işletim sistemlerine sahip farklı bilgisayar türlerini içeren heterojen ağ ortamlarına erişim.
• Veri kaynaklarından bağımsızlık: heterojen veritabanlarından bilgilere erişim. Bu tür sistemlere örnek olarak DB2, SQL/DS, Oracle, Sybase verilebilir.
• İstemci ve sunucu arasındaki yük dengesi.
• En verimli şekilde gerçekleştiği yerde hesaplamalar yapmak;
• Verimli ölçekleme yeteneği sağlar;
• Çapraz platform bilgi işlem. Platformlar arası bilgi işlem, basitçe teknolojilerin heterojen bilgi işlem ortamlarında uygulanması olarak tanımlanır. Burada aşağıdaki seçenekler sağlanmalıdır:
• Uygulama birden çok platformda çalışmalıdır;
• Tüm platformlarda aynı arayüze ve çalışma mantığına sahip olmalıdır;
• Uygulama, yerel işletim ortamıyla entegre olmalıdır;
• Tüm platformlarda aynı şekilde davranmalıdır;
• Basit ve tutarlı bir desteğe sahip olmalıdır.

 Dağıtılmış Hesaplama. Dağıtılmış bilgi işlem, işin birkaç bilgisayar arasında dağıtılmasını içerir (dağıtılmış bilgi işlem daha geniş bir kavram olmasına rağmen).

 küçültme. Ölçek küçültme, ana bilgisayar uygulamalarının küçük bilgisayar platformlarına aktarılmasıdır.

• Altyapı ve donanım maliyetlerini azaltın. Uygun Maliyetli: Düşük maliyetli bilgi işlem donanımının mevcudiyeti ve yerel alan ağlarının artan yaygınlığı, istemci-sunucu teknolojisini diğer veri işleme teknolojilerinden daha uygun maliyetli hale getirir. Ekipman gerektiğinde yükseltilebilir.

 Genel uygulama yürütme süresinin azaltılması;

 Azaltılmış istemci bellek kullanımı;

 Ağ trafiğini azaltmak.

• Multimedya ile çalışma yeteneği: Bugüne kadar, PC'ler için multimedya ile çalışmak için birçok program oluşturulmuştur. Terminal-host konfigürasyonu için böyle bir program yoktur veya çok pahalıdırlar.
• Veritabanı işlemleri için daha fazla bilgi işlem kaynağı kullanma yeteneği: uygulamalar istemci bilgisayarlarda çalıştığından, ek (terminal-ana bilgisayar yapılandırmasına kıyasla) kaynaklar, CPU ve operasyonel kaynaklar gibi veritabanı işlemleri için sunucu bilgisayarda serbest bırakılır.
• Artan programcı üretkenliği: C, PL1 veya COBOL gibi programlama dillerinden daha hızlı uygulamalar geliştirmek için SQL*Forms ve CASE gibi araçlar kullanılarak programcı üretkenliği artırılır.
• Artan son kullanıcı üretkenliği: Günümüzde birçok son kullanıcı Lotus, Paradox, Word Perfect, Harvard Graphics vb. gibi sistemleri benimsemiştir.

Arka uç arayüzü tanımlanır ve sabitlenir. Bu nedenle, mevcut bir sistemin yeni istemci parçalarını oluşturmak mümkündür (sistem düzeyinde birlikte çalışabilirlik örneği).

Pirinç. 2.2. Bir sunucu paylaşımına istemci erişiminin bir örneği.

İstemci-sunucu teknolojisi nasıl uygulanır

İstemci-sunucu teknolojisine dayalı ve dağıtık veri işleme yeteneğine sahip bir sistemin kurulumu aşağıda tartışılmaktadır. Aşağıdaki bilgisayar donanımı ve yazılımı gereklidir:

• veritabanı sunucusu bilgisayarı;
• istemci bilgisayarlar;
• iletişim ağı;
• ağ yazılımı;
• Uygulama yazılımı.

SQL dili . Üst düzey sorgu dili - SQL (Yapılandırılmış Sorgu Dili ) NMD, NDL ve PJD gibi veritabanlarına sorguları uygulamak için kullanılır ve bir standart olarak kabul edilmiştir. Dilim SQL başlangıçta firmanın yazılım ürünlerinin veri dili olarak kabul edildi IBM ve ilişkisel bir DBMS'nin YMD'si IBM'den SİSTEM R . Dilin önemli bir özelliği SQL aynı dilin iki farklı arabirim aracılığıyla temsil edilmesidir, yani: etkileşimli bir arabirim aracılığıyla ve bir uygulama programlama arabirimi (dinamik SQL). Dinamik SQL birçok yerleşik dil özelliğinden oluşur SQL , özellikle etkileşimli uygulamalar oluşturmak için sağlanmıştır; burada bir etkileşimli uygulama, etkileşimli terminalde çalışan son kullanıcı tarafından veritabanına erişimi desteklemek için yazılmış bir programdır. Dilim SQL veritabanı verilerini tanımlama, işleme ve yönetme işlevlerini sağlar ve uygulanan VTYS'nin bakış açısından kullanıcı için şeffaftır.

Pirinç. 2.3. Dağıtılmış veritabanlarına kullanıcı isteklerini yürütmek için şema.

Veritabanlarının iç yapısı, kullanılan veri modelleri tarafından belirlenir. Kavramsal model, harici modellerden daha fazla soyutlama yeteneğine ve daha zengin anlambilime sahiptir. Dış modeller, veritabanı ile kullanıcı etkileşiminin bir aracı olarak yönetimin ve uygulamanın sözdizimsel doğasına atıfta bulunarak, genellikle sözdizimsel veya operasyonel modeller olarak adlandırılır. Bilgi modellemede, kavramsal model seviyesinden fiziksel veri modeli seviyesine kadar VTYS mimarisini etkileyen çeşitli soyutlama seviyeleri vardır.

Veri modeli üç bileşenden oluşur:

• Veritabanı üzerinde kullanıcının bakış açısından temsil edilecek bir veri yapısı.
• Veri yapısı üzerinde gerçekleştirilecek geçerli işlemler. Çeşitli DDL ve NML işlemlerini kullanarak bu yapı ile çalışabilmek gerekmektedir. İçeriğini değiştiremezseniz zengin bir yapı değersizdir.
• Bütünlük denetimi için kısıtlamalar. Veri modeli, bütünlüğünü korumak ve korumak için araçlarla sağlanmalıdır. Örnek olarak, aşağıdaki iki kısıtlamayı göz önünde bulundurun:
• Her alt ağacın bir kaynak düğümü olmalıdır. Hiyerarşik veritabanları, bir üst düğüm olmadan alt düğümleri depolayamaz.
• İlişkisel bir veritabanıyla ilgili olarak, özdeş demetler olamaz. Bir dosya için bu gereksinim, tüm kayıtların benzersiz olmasını gerektirir.

VTYS'nin en önemli özelliklerinden biri nesneleri bağlama yeteneğidir.

Nesneler arasında aşağıdaki bağlantı türleri vardır:

• Bire Bir (1:1). Bir kümenin bir nesnesi, başka bir kümenin bir nesnesi ile ilişkilendirilebilir.
• Bire Çok (1:M). Bir kümenin bir nesnesi, başka bir kümenin birçok nesnesi ile ilişkilendirilebilir.
• Çoktan Çoka (M:N). Bir kümenin bir nesnesi, başka bir kümenin birçok nesnesiyle ilişkilendirilebilir, ancak aynı zamanda, başka bir kümenin bir nesnesi, birinci kümenin birçok nesnesiyle ilişkilendirilebilir.
• dallanmış . Bir kümenin bir nesnesi, birçok kümenin nesneleriyle ilişkilendirilebilir.
• özyinelemeli . Belirli bir kümenin bir nesnesi, aynı kümenin bir nesnesi ile ilişkilendirilebilir.

Aşağıdaki ana veri modelleri vardır:

• İlişkisel veri modeli.
• Hiyerarşik veri modeli.
• Eksik ağ veri modeli.
• CODASYL veri modeli.
• Genişletilmiş ağ veri modeli.

V.3. İNTERNET / INTRANET TEKNOLOJİLERİ VE KURUMSAL VERİTABANI ERİŞİM ÇÖZÜMLERİ

"İstemci-sunucu" mimarisine dayalı sistemlerin temel sorunu, açık sistem kavramına uygun olarak, mümkün olan en geniş açık sistem donanım ve yazılım çözümleri sınıfında mobil olmaları gerekliliğidir. Kendimizi UNIX tabanlı yerel alan ağlarıyla sınırlasak bile, farklı ağlar farklı ekipman ve iletişim protokolleri kullanır. Tüm olası protokolleri destekleyen sistemler oluşturmaya çalışmak, işlevsellik pahasına ağ ayrıntılarıyla aşırı yüklenmelerine yol açar.

Bu sorunun daha da karmaşık bir yönü, heterojen bir yerel ağın farklı düğümlerinde verilerin farklı temsillerinin kullanılması olasılığı ile ilgilidir. Farklı bilgisayarlarda farklı adresleme, sayıların temsili, karakter kodlaması vb. olabilir. Bu özellikle üst düzey sunucular için önemlidir: telekomünikasyon, bilgi işlem, veritabanları.

"İstemci-sunucu" mimarisine dayalı sistemlerin hareketliliği sorununa ortak bir çözüm, uzaktan prosedür çağrı protokollerini (RPC - Uzaktan Prosedür Çağrısı) uygulayan yazılım paketlerine güvenmektir. Bu araçları kullanarak, uzak ana bilgisayardaki bir hizmeti aramak normal bir prosedür çağrısı gibi görünür. Elbette, yerel ağ ekipmanı ve ağ protokollerinin özellikleriyle ilgili tüm bilgileri içeren RPC araçları, çağrıyı bir dizi ağ etkileşimine dönüştürür. Böylece ağ ortamının ve protokollerin özellikleri uygulama programlayıcısından gizlenir.

Bir uzak prosedür çağrıldığında, RPC programları istemci veri formatlarını ara makineden bağımsız formatlara ve ardından sunucu veri formatlarına dönüştürür. Yanıt parametreleri geçerken benzer dönüşümler gerçekleştirilir.

İlginizi çekebilecek diğer ilgili çalışmalar.vshm>
6914.		Veritabanı konsepti	11.56KB
	Veritabanı, mahkeme kararlarının normatif eylemlerinin hesaplanmasına ilişkin makalelerin nesnel bir biçiminde sunulan bir dizi bağımsız materyal ve bu materyallerin elektronik bir bilgisayar kullanılarak bulunabileceği ve işlenebileceği şekilde sistematize edilmiş diğer benzer materyaller Rusya Federasyonu Medeni Kanunu Sanat. Belirli kurallara göre düzenlenen ve bilgisayarın belleğinde tutulan bir veri tabanı, bazılarının mevcut durumunu karakterize eden bir dizi veri ...
8064.		Dağıtılmış veritabanları	43.66KB
	Dağıtılmış veritabanları Dağıtılmış bir RDB veritabanı, bir bilgisayar ağının farklı düğümleri üzerinde fiziksel olarak dağıtılan, mantıksal olarak birbirine bağlı paylaşılan bir veri kümesidir. Veri erişimi, veri replikalarının varlığına veya yokluğuna bağlı olmamalıdır. Sistem, bir veri birleştirme birleştirmesini, aktarılan bilgi miktarını idare edebilen bir ağ bağlantısını ve tablolara katılmak için yeterli işlem gücüne sahip bir düğümü gerçekleştirmek için yöntemleri otomatik olarak belirlemelidir. RDBMS aşağıdaki özelliklere sahip olmalıdır ...
20319.		VERİTABANLARI VE KORUNMASI	102.86KB
	Çevrimiçi çevrimiçi veritabanları 1960'ların ortalarında ortaya çıktı. Operasyonel veri tabanları üzerindeki işlemler, terminaller kullanılarak interaktif olarak işlendi. Basit dizin-sıralı kayıt organizasyonu, hızla daha güçlü bir set odaklı kayıt modeline dönüştü. Charles Bachmann, verileri tanımlamak ve verileri işlemek için standart bir dil geliştiren Veri Tabanı Görev Grubu'nun (DBTG) çalışmasına liderlik ettiği için Turing Ödülü'nü aldı.
5031.		Veritabanı Geliştirme Kitaplığı	11.72MB
	Veritabanı tasarım teknolojisi. Varlıklar arasındaki ilişkileri tanımlama ve bir veri modeli oluşturma. Modern bilgi teknolojisinin ana fikirleri, değişen gerçek dünyayı yeterince yansıtmak ve kullanıcıların bilgi ihtiyaçlarını karşılamak için verilerin veritabanlarında düzenlenmesi gerektiği kavramına dayanmaktadır. Bu veri tabanları, DBMS veri tabanı yönetim sistemleri adı verilen özel yazılım sistemlerinin kontrolü altında oluşturulur ve çalıştırılır.
13815.		Hiyerarşik Veri Tabanı Modeli	81.62KB
	Modern bilgi teknolojisinin ana fikirleri, bilgi teknolojisinin temelinin, belirli bir konu alanının durumunu yeterince yansıtan ve kullanıcıya bu konu alanında ilgili bilgileri sağlayan veritabanlarında düzenlenen veriler olduğu veritabanları kavramına dayanmaktadır. Kabul edilmelidir ki veriler...
14095.		Kütüphane veritabanı geliştirme	11.72MB
	Depolanan verilerin hacmindeki ve yapısal karmaşıklığındaki artış, bilgi sistemleri kullanıcı çemberinin genişlemesi, en uygun ve nispeten anlaşılması kolay ilişkisel (tablo) VTYS'nin yaygın olarak kullanılmasına yol açmıştır.
5061.		Poliklinik veri tabanının oluşturulması	2.4MB
	Bilgisayar teknolojisi ve bilgi teknolojisinin gelişmesi, çeşitli amaçlar için otomatik bilgi sistemlerinin (AIS) oluşturulması ve yaygın olarak kullanılması için fırsatlar sağlamıştır. Ekonomik ve teknik tesislerin yönetimi için bilgi sistemleri geliştirilmekte ve uygulanmaktadır.
13542.		Jeolojik bilgi veritabanları	20.73KB
	Son zamanlarda, bilgisayar teknolojilerinin ve özellikle veri tabanlarının bilimsel alana girişi hızlı bir şekilde gerçekleşmektedir. Bu süreç jeolojiyi de atlamaz, çünkü doğa bilimlerinde büyük miktarda bilgiyi depolamaya ve işlemeye ihtiyaç vardır.
9100.		Veri tabanı. Temel konseptler	26.28KB
	Bir veri tabanı, herhangi bir konu alanında, ekonomide, yönetimde, kimyada vb. gerçek dünyanın belirli nesneleri hakkında bir bilgi topluluğudur. Bir bilgi sisteminin amacı, yalnızca nesneler hakkında veri depolamak değil, aynı zamanda bu verileri manipüle etmektir. nesneler arasındaki ilişkileri dikkate alır. Her nesne, veritabanında öznitelikler olarak adlandırılan bir dizi veri özelliği ile karakterize edilir.
5240.		"Üniversite Dekanlığı" veritabanının oluşturulması	1.57MB
	Bir veritabanı (DB), bir veya daha fazla uygulama için optimal bir şekilde kullanımlarına izin veren, böyle bir organizasyona ve minimum fazlalığa sahip bir bilgisayarın harici depolama ortamında birlikte depolanan birbiriyle ilişkili veriler topluluğudur.

dersin amacı

Bu dersin materyalini inceledikten sonra şunları bileceksiniz:

• Ne oldu kurumsal veri modeli ;
• nasıl dönüştürülür kurumsal veri modeli veri ambarı modeline;
• temel unsurlar kurumsal veri modeli ;
• kurumsal veri modelinin sunum katmanları ;
• kurumsal bir veri modelini çok boyutlu bir veri ambarı modeline dönüştürmek için algoritma ;

ve öğren:

• dayalı veri ambarı modelleri geliştirmek kurumsal veri modeli kuruluşlar;
• CASE araçlarını kullanarak bir yıldız şeması geliştirin;
• bölme tabloları çok boyutlu model CASE araçlarını kullanarak.

Kurumsal veri modeli

Tanıtım

Herhangi bir veri ambarının özü, veri modelidir. Bir veri modeli olmadan, bir veri ambarındaki verileri düzenlemek çok zor olacaktır. Bu nedenle, DW geliştiricileri böyle bir model geliştirmek için zaman ve çaba harcamalıdır. HD modelinin gelişimi CD tasarımcısının omuzlarına düşüyor.

OLTP sistemlerinin tasarımı ile karşılaştırıldığında, bir veri ambarı tasarlama metodolojisi, depolama veri yapılarının analiz problemlerini çözmeye ve karar verme süreci için bilgi desteğine yönelik yönelimi ile ilgili bir dizi ayırt edici özelliğe sahiptir. Veri ambarının veri modeli, bu sorunlara etkin bir çözüm sağlamalıdır.

Bir veri ambarının tasarımındaki başlangıç ​​noktası, sözde olabilir. kurumsal veri modeli(kurumsal veri modeli veya kurumsal veri modeli, EDM), bir kuruluşun OLTP sistemlerini tasarlama sürecinde oluşturulur. Tasarım yaparken kurumsal veri modeli genellikle, iş operasyonları temelinde, organizasyonun tüm bilgi ihtiyaçlarını toplayacak ve sentezleyecek böyle bir veri yapısı yaratmaya çalışılır.

Böylece, kurumsal veri modeli bir DW modeli oluşturmak için gerekli bilgileri içerir. Dolayısıyla ilk aşamada eğer organizasyonda böyle bir model varsa, bir veri ambarı tasarımcısı, bir dönüştürme problemini çözerek bir veri ambarı tasarlamaya başlayabilir kurumsal veri modeli HD modelinde.

Kurumsal veri modeli

Dönüştürme sorunu nasıl çözülür kurumsal veri modeli HD modelinde mi? Bu sorunu çözmek için bu modele sahip olmanız gerekir, yani. kurumsal veri modeli inşa edilmeli ve belgelenmiş. Ve anlaman gerek ne Bu modelden ve nasıl HD modele dönüştürülmelidir.

Konsepti netleştirelim kurumsal veri modeli. Altında kurumsal veri modeli Kuruluşun konu alanlarının çok seviyeli, yapılandırılmış bir tanımını, konu alanlarının veri yapılarını, iş süreçlerini ve iş prosedürlerini, kuruluşta benimsenen veri akışlarını, durum diyagramlarını, veri-süreç matrislerini ve kullanılan diğer model temsillerini anlayın. örgütün faaliyetleri. Böylece geniş anlamda, kurumsal veri modeli organizasyonun faaliyetlerini karakterize eden (bazı soyut düzeyde model) çeşitli düzeylerde bir dizi modeldir, yani. içerik kurumsal model doğrudan belirli bir organizasyonda hangi model yapıların dahil edildiğine bağlıdır.

Ana unsurlar kurumsal veri modelişunlardır:

• organizasyonun konu alanlarının tanımı (faaliyet alanlarının tanımı);
• yukarıda tanımlanan konu alanları arasındaki ilişkiler;
• bilgi veri modeli (ERD-modeli veya "varlık-ilişki" modeli);
• her konu alanı açıklaması için:
  • varlık anahtarları;
  • varlık özellikleri;
  • alt tipler ve süper tipler;
  • varlıklar arasındaki ilişkiler;
  • nitelik gruplamaları;
  • konu alanları arasındaki ilişkiler;
• işlevsel model veya iş süreci modeli;
• veri akış diyagramları;
• durum diyagramları;
• diğer modeller.

Böylece, kurumsal veri modeli kuruluşun bilgi ihtiyaçlarını temsil eden varlıkları, nitelikleri ve ilişkileri içerir. Şek. 16.1 ana unsurları gösterir kurumsal veri modeli.

Kurumsal veri modelinin sunum katmanları

Kurumsal veri modeli, belirli iş ihtiyaçlarını desteklemekle ilgili varlık gruplarını temsil eden konu alanlarına göre alt bölümlere ayrılmıştır. Bazı konu alanları, sözleşme yönetimi gibi belirli iş fonksiyonlarını kapsayabilirken, diğerleri ürünleri veya hizmetleri tanımlayan işletmeleri gruplandırabilir.

Her mantıksal model, mevcut bir konu alanına karşılık gelmelidir. kurumsal veri modeli. Mantıksal model bu gereksinimi karşılamıyorsa, konu alanını tanımlayan bir model buna eklenmelidir.

Bir kurumsal veri modeli genellikle birkaç sunum katmanına sahiptir. Aslında yüksek seviye(yüksek seviye) kurumsal veri modeli kuruluşun ana konu alanlarının ve bunların kuruluş düzeyindeki ilişkilerinin bir açıklaması yer almaktadır. Şek. 16.2 bir parçadır kurumsal veri modeliÜst düzey.

Pirinç. 16.2.

Şekilde gösterilen şema dört konu alanını göstermektedir: "Müşteri" ( müşteri), "Kontrol" ( hesap), "Sipariş" ( sipariş) ve "Ürün" ( Ürün). Tipik olarak, model görünümünün en üst düzeyinde, yalnızca doğrudan bağlantılarörneğin, aşağıdaki gerçeği düzelten konu alanları arasında: alıcı, mal siparişi için faturayı öder. Bu düzeyde ayrıntılı bilgi ve dolaylı ilişkiler kurumsal model verilmez.

Bir sonrakinde orta seviye(orta seviye) kurumsal veri modeli konu alanlarının nesneleri hakkında ayrıntılı bilgileri gösterir, yani anahtarlar ve varlık özellikleri, ilişkileri, alt türleri ve üst türleri vb. Üst düzey modelin her alanı için bir orta düzey model vardır. Şek. 16.3, orta seviye sunumu gösterir kurumsal model"Sipariş" konu alanının bir parçası için.

Şek. 16.3 "Sipariş" konu alanının ( sipariş) nitelikleri ve aralarındaki ilişkiler aracılığıyla tanımlanan çeşitli varlıkları içerir. Sunulan model, siparişin tarihi, siparişi kimin verdiği, siparişi kimin gönderdiği, siparişi kimin aldığı ve daha birçok soruyu yanıtlamanıza olanak tanır. Yukarıdaki şemadan, bu organizasyonda iki tür sipariş olduğu görülebilir - bir reklam kampanyası için siparişler ( Reklam) ve perakende siparişler ( Perakende).

dikkat, ki kurumsal veri modeli organizasyonun faaliyetlerinin çeşitli yönlerini ve değişen derecelerde ayrıntı ve eksiksizliği temsil edebilir. Eğer kurumsal model organizasyonun tüm yönlerini temsil eder, aynı zamanda denir organizasyon veri modeli(kurumsal veri modeli).

Veri ambarı tasarlama açısından bakıldığında, veri ambarı modeli oluşturmaya karar vermede önemli bir faktör kurumsal veri modeli devlet mi tamlık kurumsal veri modeli.

Bir organizasyonun kurumsal veri modeli, evrimsel bir özelliğe sahiptir, yani. sürekli gelişiyor ve gelişiyor. Bazı konu alanları kurumsal veri modeli iyi gelişmiş olabilir, bazıları için henüz çalışma başlamamış olabilir. Konu alanının bir parçası üzerinde çalışılmamışsa kurumsal veri modeli, o zaman bu modeli bir veri ambarı tasarlamak için bir başlangıç ​​noktası olarak kullanmanın bir yolu yoktur.

tamamlama derecesi kurumsal model HD tasarımında aşağıdaki gibi tesviye edilebilir. Bir veri ambarının geliştirilmesi genellikle zaman içinde bir dizi aşamaya bölündüğünden, tasarım süreci ile senkronize edilebilir. tamamlama süreci bireysel parçaların gelişimi kurumsal veri modeli kuruluşlar.

en düşük kurumsal veri modelinin sunum katmanı karşılık gelen veritabanı nesnelerinin fiziksel özellikleri hakkında bilgi görüntüler. mantıksal veri modeli orta kurumsal veri modelinin sunum katmanı.

BT uzmanları, giderek artan bir şekilde dikkatlerini endüstri standardı veri modelleri ve iş karar şablonlarına dayalı veri yönetimi çözümlerine çevirmektedir. Belirli faaliyet alanları için yüklenmeye hazır karmaşık fiziksel veri modelleri ve iş zekası raporları, kuruluşun bilgi bileşenini birleştirmenize ve iş süreçlerini önemli ölçüde hızlandırmanıza olanak tanır. Çözüm şablonları, hizmet sağlayıcıların mevcut sistemlerde gizlenen standart dışı bilgilerin gücünden yararlanmasına ve böylece proje zaman çizelgelerini, maliyetlerini ve risklerini azaltmasına olanak tanır. Örneğin, gerçek projeler, veri modeli ve iş karar şablonlarının geliştirme çabasını %50 oranında azaltabileceğini gösteriyor.

Bir endüstri mantıksal modeli, hem stratejik hem de taktiksel iş sorularını yanıtlamak için bir kurumsal veri ambarında olması gereken tüm bilgilerin alana özgü, entegre ve mantıksal olarak yapılandırılmış bir görünümüdür. Modellerin temel amacı, veri alanında yönlendirmeyi kolaylaştırmak ve iş geliştirme için önemli olan detayların vurgulanmasına yardımcı olmaktır. Günümüzün iş ortamında, çeşitli bileşenler arasındaki ilişkileri net bir şekilde anlamak ve organizasyonun büyük resmini iyi anlamak kesinlikle çok önemlidir. Modeller kullanılarak tüm detayların ve ilişkilerin tanımlanması, şirketin çalışmalarını organize etmek için zamanın ve araçların en verimli şekilde kullanılmasını sağlar.

Veri modelleri, verilerin nasıl temsil edildiğini ve erişildiğini açıklayan soyut modellerdir. Veri modelleri, belirli bir alanda veri öğelerini ve aralarındaki ilişkileri tanımlar. Veri modeli, belirli bir gerçek bilgi sınıfını doğru bir şekilde açıklamak için belirli bir dizi sembol ve kelime kullanan hem iş hem de BT uzmanları için bir gezinme aracıdır. Bu, organizasyon içindeki iletişimi geliştirir ve böylece daha esnek ve istikrarlı bir uygulama ortamı yaratır.

Yetkililer ve yerel özyönetim modeli için bir CBS örneği.

Bugün, yazılım ve hizmet sağlayıcıların teknolojik yenilikler, hükümet kısıtlamalarının kaldırılması ve tedarik zincirlerinin karmaşıklığı ile bağlantılı sektördeki değişikliklere hızlı bir şekilde yanıt verebilmesi stratejik olarak önemlidir. İş modelindeki değişikliklerle birlikte, şirketin faaliyetlerini desteklemek için gerekli olan bilgi teknolojisinin karmaşıklığı ve maliyeti artıyor. Veri yönetimi, kurumsal bilgi sistemlerinin ve bunların işlevsel ve iş gereksinimlerinin sürekli değiştiği bir ortamda özellikle zordur.

Bu süreci kolaylaştırmaya ve optimize etmeye yardımcı olmak için, BT yaklaşımını modern düzeye dönüştürmek için endüstri veri modellerinden yararlanılır.

Şirketten sektör veri modelleriEsri

Esri ArcGIS platformu için veri modelleri, CBS projelerinde kullanılmak ve çeşitli uygulama alanları için veri yapıları oluşturmak için çalışma şablonlarıdır. Bir veri modeli oluşturmak, daha sonra kişisel veya kurumsal bir coğrafi veritabanı oluşturmak için kullanılabilecek kavramsal bir tasarım, mantıksal yapı ve fiziksel yapı oluşturmayı içerir. ArcGIS, bir veritabanı şeması oluşturmak ve yönetmek için araçlar sağlar ve çeşitli uygulamalar ve endüstrilerde bir CBS projesini hızlı bir şekilde başlatmak için veri modeli şablonları kullanılır. Esri, kullanıcı topluluğuyla birlikte, kurumsal bir coğrafi veritabanı tasarlamaya hızla başlamanıza yardımcı olabilecek bir dizi şablon geliştirmek için önemli miktarda zaman harcamıştır. Bu projeler support.esri.com/datamodels adresinde açıklanmış ve belgelenmiştir. Aşağıda, bu sitede göründükleri sırayla Esri'nin endüstri modeli adlarının anlamsal çevirileri bulunmaktadır:

• Adres kaydı
• Tarım
• Meteoroloji
• Temel Mekansal Veriler
• biyoçeşitlilik
• Binaların iç alanı
• Sera gazı muhasebesi
• İdari sınırların korunması
• Silahlı Kuvvetler. İstihbarat teşkilatı
• Enerji (yeni ArcGIS MultiSpeak protokolü dahil)
• Ekolojik binalar
• Acil Durumlar Bakanlığı. yangın koruması
• Orman kadastrosu
• Ormancılık
• jeoloji
• Ulusal düzeyde CBS (e-gov)
• Yeraltı suyu ve atık su
• sağlık hizmeti
• Anıt alanlarının arkeolojisi ve korunması
• Ulusal Güvenlik
• hidroloji
• Uluslararası Hidrografik Organizasyon (IHO). ENC için S-57 formatı
• Sulama
• Tapu
• Belediye
• Deniz seyrüseferi
• devlet kadastrosu
• Petrol ve gaz yapıları
• boru hatları
• raster mağazalar
• Batimetri, deniz dibi topografyası
• Telekomünikasyon
• Ulaşım
• Sıhhi tesisat, kanalizasyon, kamu hizmetleri

Bu modeller, endüstri standardının gerekli tüm özelliklerini içerir, yani:

• serbestçe kullanılabilir;
• "seçilen" üreticinin teknolojisine bağlı değildir;
• gerçek projelerin uygulanması sonucunda oluşturulan;
• sektör uzmanlarının katılımıyla oluşturulan;
• çeşitli ürünler ve teknolojiler arasında bilgi etkileşimi sağlamak için tasarlanmış;
• diğer standartlar ve düzenleyici belgelerle çelişmeyin;
• dünya çapında uygulanan projelerde kullanılan;
• projenin kendisi değil, oluşturulmakta olan sistemin yaşam döngüsü boyunca bilgi ile çalışmak üzere tasarlanmıştır;
• diğer proje ve/veya modellerle uyumunu kaybetmeden müşterinin ihtiyaçlarına göre genişletilebilir;
• ek materyaller ve örnekler eşliğinde;
• çeşitli sanayi şirketlerinin kılavuzlarında ve teknik malzemelerinde kullanılan;
• geniş bir katılımcı topluluğu, topluluğa erişim herkese açıkken;
• son yıllarda yayınlarda veri modellerine çok sayıda referans.

Esri, PODS (Pipeline Open Data Standards - petrol ve gaz endüstrisi için açık bir standart; şu anda bir Esri PODS Esri Spatial olarak bir PODS uygulaması var) gibi kullanım için çeşitli endüstri modellerini öneren bağımsız kuruluşlardan oluşan uzman bir grubun parçasıdır. 5.1.1 coğrafi veritabanı) veya ArcGIS for Aviation'dan ICAO ve FAA önerilerinin yanı sıra AIXM 5.0 navigasyon veri değişim standardını dikkate alan bir coğrafi veritabanı (GDB). Ayrıca, S-57 ve ArcGIS for Maritime (deniz ve kıyı özellikleri) gibi mevcut endüstri standartlarına sıkı sıkıya bağlı olan önerilen modeller ve ayrıca Esri Professional Services'ın çalışmasından oluşturulan ve "fiili" standartlar olan modeller vardır. ilgili alanlarda. Örneğin, Ulus ve Yerel Yönetim için GIS, NSDI ve INSPIRE standartlarını etkilerken, Hidro ve Yeraltı Suyu, ücretsiz olarak temin edilebilen ArcHydro profesyonel paketinde ve ticari ürünlerinde yoğun olarak kullanılırken, üçüncü firmalar. Esri'nin NHDI gibi "fiili" standartları da desteklediğine dikkat edilmelidir. Önerilen tüm veri modelleri belgelenmiştir ve kurumsal BT süreçlerinde kullanıma hazırdır. Modellere eşlik eden malzemeler şunları içerir:

• varlık ilişkilerinin UML diyagramları;
• veri yapıları, etki alanları, dizinler;
• ArcGIS GDB formatında hazır coğrafi veritabanı şablonları;
• örnek veriler ve örnek uygulamalar;
• veri yükleme komut dosyaları örnekleri, analiz yardımcı programlarının örnekleri;
• önerilen veri yapısı hakkında referans kitaplar.

Esri, inşaat sektörü modelleri konusundaki deneyimini kitaplar şeklinde özetliyor ve yayınlanmış materyalleri yerelleştiriyor. Esri CIS aşağıdaki kitapları yerelleştirdi ve yayınladı:

• Jeo-uzaysal Hizmet Odaklı Mimari (SOA);
• Ulaşım için coğrafi veritabanlarının tasarlanması;
• Kurumsal coğrafi bilgi sistemleri;
• GIS: elektrik ve gaz işletmelerinin yeni enerjisi;
• Dijital bir harita üzerinde petrol ve gaz;
• Dünyamızı modellemek. Esri Geodatabase Tasarım Kılavuzu;
• GIS'i düşünmek. CBS planlaması: yöneticiler için bir rehber;
• Coğrafi Bilgi Sistemleri. Temel bilgiler;
• İdari ve ekonomik yönetim için CBS;
• Web CBS. İlkeler ve uygulama;
• Sistem Tasarım Stratejileri, 26. baskı;
• Şirketler ve GIS sistemleri kullanıcıları tarafından yayınlanan yayınlarla ArcReview dergisinin 68 sayısı;
• ... ve diğer birçok tematik not ve yayın.

Örneğin, kitap Dünyamızı modellemek..."(çeviri), genel olarak CBS veri modellemesine ve özel olarak coğrafi veritabanı veri modeline yönelik kapsamlı bir kılavuz ve referans kılavuzudur. Kitap, bir CBS projesinin her yönüyle ilgili kararları, doğru veri modelleme kararlarının nasıl alınacağını gösterir: veri tabanı tasarım verilerinden ve veri toplamadan mekansal analiz ve görselleştirmeye kadar Projeye uygun bir coğrafi veri tabanının nasıl tasarlanacağını, programlama olmadan veri tabanı işlevselliğinin nasıl kurulacağını, karmaşık projelerde iş akışının nasıl yönetileceğini, nehir, ulaşım gibi çeşitli ağ yapılarının nasıl modelleneceğini ayrıntılı olarak açıklar. veya elektrik ağları, uydu görüntü verilerini coğrafi analiz ve haritalamaya entegre edin ve 3B CBS veri modelleri oluşturun. Ulaşım için coğrafi veritabanları tasarlama" Çok sayıda projede test edilmiş ve Avrupa ve Amerika Birleşik Devletleri'nin yasal gerekliliklerinin yanı sıra uluslararası standartlara tam olarak uyan metodolojik yaklaşımları içerir. Ve kitapta " GIS: elektrik ve gaz işletmelerinin yeni enerjisi Gerçek dünya örneklerini kullanarak, müşteri hizmetleri, ağ işletimi ve diğer iş süreçleri gibi unsurlar dahil olmak üzere kurumsal bir CBS'nin bir enerji tedarikçisine getirebileceği faydaları gösterir.

Esri CIS ve DATA+ tarafından Rusça olarak yayınlanan tercüme edilmiş ve orijinal kitaplardan bazıları. Hem CBS teknolojisi ile ilgili kavramsal konuları hem de çeşitli ölçek ve amaçlarda CBS modelleme ve dağıtmanın birçok uygulamalı yönünü kapsar.

Örnek olarak BISDM (Bina İç Mekan Veri Modeli) sürüm 3.0 veri modelini kullanan endüstri modellerinin kullanımını ele alacağız. BISDM, daha genel bir BIM modelinin (Bina Bilgi Modeli, bina bilgi modeli) geliştirilmiş halidir ve bina ve yapıların tasarımında, inşasında, işletilmesinde ve hizmetten çıkarılmasında kullanılması amaçlanmıştır. CBS yazılımında kullanılır, coğrafi verileri diğer platformlarla etkili bir şekilde değiş tokuş etmenize ve onlarla etkileşime girmenize olanak tanır. Genel görev grubu FM'yi (kuruluş altyapı yönetimi) ifade eder. Kullanımına izin veren BISDM modelinin ana avantajlarını listeliyoruz:

• heterojen bir ortamda bilgi alışverişini tek tip kurallara göre organize etmek;
• BIM konseptinin "fiziksel" bir uygulamasını ve bir inşaat projesini yönetmek için önerilen kuralları elde edin;
• binanın tüm yaşam döngüsü boyunca (tasarımdan hizmetten çıkarmaya kadar) CBS araçlarını kullanarak tek bir depoyu sürdürmek;
• projedeki çeşitli uzmanların çalışmalarını koordine etmek;
• tüm katılımcılar için planlanan programı ve inşaat aşamalarını görselleştirin;
• maliyet ve inşaat süresi hakkında bir ön tahminde bulunun (4D ve 5D verileri);
• projenin ilerlemesini kontrol etmek;
• bakım ve onarım dahil olmak üzere binanın kaliteli çalışmasını sağlamak;
• alan kullanımının verimliliğini analiz etme işlevleri (kiralama, depolama tesisleri, çalışan yönetimi) dahil olmak üzere varlık yönetim sisteminin bir parçası olmak;
• binanın enerji verimliliğini hesaplamak ve yönetmek;
• insan akışlarının hareketini simüle eder.

BISDM, kullanım amacı ve türleri, kurulan iletişimler, kurulu ekipman, onarım ve bakımın muhasebeleştirilmesi, olayların kaydedilmesi, diğer şirket varlıklarıyla ilişkiler dahil olmak üzere bir binadaki iç tesisler düzeyinde mekansal verilerle çalışma kurallarını tanımlar. Model, coğrafi ve coğrafi olmayan verilerin birleşik bir deposunun oluşturulmasına yardımcı olur. Dünyanın önde gelen şirketlerinin deneyimi, varlıkları izole etmek ve hem binanın kendisini hem de içini oluşturan tüm fiziksel unsurların uzamsal ve mantıksal ilişkilerini GDB düzeyinde (jeodatabase) modellemek için kullanıldı. BISDM ilkelerini takip etmek, diğer sistemlerle entegrasyon görevlerini önemli ölçüde basitleştirmenize olanak tanır. İlk aşamada bu genellikle CAD ile entegrasyondur. Daha sonra binanın işletilmesi sırasında ERP ve EAM sistemleri (SAP, TRIRIGA, Maximo vb.) ile veri alışverişi yapılır.

ArcGIS kullanarak BISDM yapısal elemanlarının görselleştirilmesi.

BISDM kullanılması durumunda, müşteri/tesis sahibi, tesis oluşturma fikrinden komple bir proje geliştirmeye, inşaat kontrolüne kadar uçtan uca bilgi alışverişi alır. - Tesisin işletmeye alındığı zamana kadar tarih bilgisi, işletme sırasında ve hatta tesisin yeniden inşası veya hizmetten çıkarılması sırasında parametrelerin kontrolü. BISDM paradigmasının ardından, yardımıyla oluşturulan CBS ve GDB, ilgili sistemler için ortak bir veri deposu haline geldi. GDB'de genellikle üçüncü taraf sistemler tarafından oluşturulan ve işletilen veriler bulunur. Oluşturulan sistemin mimarisi tasarlanırken bu dikkate alınmalıdır.

Belirli bir aşamada, birikmiş "kritik bilgi kütlesi", yeni bir niteliksel düzeye geçmenizi sağlar. Örneğin, yeni bir binanın tasarım aşamasının tamamlanmasının ardından, CBS'de otomatik olarak 3D etüt modellerini görselleştirmek, kurulacak ekipman listesini derlemek, döşenecek mühendislik ağlarının kilometrelerini hesaplamak, bir dizi doğrulama yapmak mümkündür. ve hatta proje maliyetinin bir ön mali tahminini verin.

Bir kez daha, BISDM ve ArcGIS birlikte kullanıldığında, GDB bir kata ait z-koordinatları, eleman bağlantı türleri, ekipman dahil olmak üzere nesnenin eksiksiz bir tanımını içerdiğinden, biriken verilerden otomatik olarak 3B modeller oluşturmak mümkün hale gelir. kurulum yöntemleri, malzeme, mevcut yollar, personel hareketleri, her bir elemanın işlevsel amacı, vb. vb. Tüm tasarım malzemelerinin BISDM GDB'ye ilk aktarımından sonra, aşağıdakiler için ek içeriğe ihtiyaç duyulduğuna dikkat edilmelidir:

• 3B nesne ve ekipman modellerinin belirlenen yerlere yerleştirilmesi;
• malzemelerin maliyeti ve bunların döşenmesi ve montajı için prosedür hakkında bilgi toplamak;
• kurulu standart dışı ekipmanın boyutlarına göre açıklık kontrolü.

ArcGIS kullanımı sayesinde, harici kaynaklardan ek 3B nesnelerin ve referans kitaplarının içe aktarılması basitleştirilmiştir. ArcGIS Data Interoperability modülü, bu tür verileri içe aktarmak ve modele doğru şekilde yerleştirmek için prosedürler oluşturmanıza olanak tanır. IFC, AutoCAD Revit, Bentlye Microstation dahil olmak üzere sektörde kullanılan tüm formatlar desteklenmektedir.

IBM'den sektör veri modelleri

IBM, çeşitli sektörler için bir dizi depolama yönetimi aracı ve modeli sağlar:

• IBM Bankacılık ve Finansal Piyasalar Veri Ambarı (finans)
• IBM Bankacılık Veri Ambarı
• IBM Bankacılık Süreç ve Hizmet Modelleri
• IBM Health Plan Veri Modeli (sağlık)
• IBM Insurance Information Warehouse (sigorta)
• IBM Sigorta Süreç ve Hizmet Modelleri
• IBM Perakende Veri Ambarı (perakende)
• IBM Telekomünikasyon Veri Ambarı (telekomünikasyon)
• InfoSphere Depo Paketi:
  - Customer Insight için (müşterileri anlamak için)
  - Pazar ve Kampanya İçgörüsü için (şirketi ve pazarı anlamak için)
  - Tedarik Zinciri İçgörüsü için (tedarikçileri anlamak için).

örneğin, model IBMbankacılıkveParasalpazarlarVeriDepo veri açısından bankacılık sektörünün belirli zorluklarını ele almak için tasarlanmış ve IBMbankacılıkişlemveHizmetModeller- süreçler ve SOA (hizmet odaklı mimari) açısından. Telekomünikasyon endüstrisi için sunulan modeller IBMbilgiÇerçeve(IFW) Ve IBMTelekomünikasyonVeriDepo (TDW). Analitik sistemler oluşturma sürecini önemli ölçüde hızlandırmanın yanı sıra, telekomünikasyon endüstrisinin özelliklerini dikkate alarak iş zekası uygulamalarının geliştirilmesi, kurumsal veri yönetimi ve veri ambarlarının organizasyonu ile ilgili riskleri azaltmaya yardımcı olurlar. IBM TDW yetenekleri, kablolu ve kablosuz telefon hizmetleri, veri iletimi ve multimedya içeriği sunan İnternet sağlayıcıları ve kablolu ağ operatörlerinden telefon, uydu, uzun mesafe ve uluslararası iletişim hizmetleri sağlayan çok uluslu şirketlere kadar telekomünikasyon pazarının tüm yelpazesini kapsar. kuruluşlar küresel ağlar olarak. Bugün, TDW dünya çapında irili ufaklı kablolu ve kablosuz servis sağlayıcılar tarafından kullanılmaktadır.

denilen araç Müşteri İçgörüsü için InfoSphere Depo Paketi bankacılık, sigorta, finans, sağlık sigortası programları, telekomünikasyon, perakende ve dağıtım dahil olmak üzere artan sayıda iş projesi ve sektör için yapılandırılmış ve kolayca uygulanan bir iş içeriğidir. İş kullanıcıları için Pazar ve Kampanya İçgörüsü için InfoSphere Depo Paketi adım adım geliştirme ve işletmeye özel süreç yoluyla pazar istihbaratınızın ve pazarlama kampanyalarınızın etkinliğini en üst düzeye çıkarmanıza yardımcı olur. Üzerinden Tedarik Zinciri İçgörüsü için InfoSphere Depo Paketi organizasyonlar tedarik zinciri operasyonları hakkında güncel bilgi edinme yeteneğine sahiptir.

Esri'nin IBM çözüm mimarisi içindeki konumu.

Özellikle dikkat edilmesi gereken nokta, IBM'in kamu hizmetlerine ve kamu hizmeti şirketlerine yaklaşımıdır. Artan tüketici taleplerini karşılamak için kamu hizmeti şirketleri, bugün kullandıklarından daha esnek bir mimariye ve ayrıca serbest bilgi alışverişini kolaylaştıracak endüstri standardı bir nesne modeline ihtiyaç duyuyor. Bu, daha uygun maliyetli iletişimi mümkün kılarak enerji şirketlerinin iletişim yeteneklerini geliştirecek ve yeni sistemlere, kuruluş içinde nerede bulunurlarsa bulunsunlar, gerekli tüm kaynaklar için daha iyi görünürlük sağlayacaktır. Bu yaklaşımın temeli, departmanların işlevleri ile yeniden kullanılabilen çeşitli uygulamaların hizmetleri arasında bir yazışma oluşturan bir bileşen modeli olan SOA'dır (Hizmet Odaklı Mimari). Bu tür bileşenlerin "hizmetleri", kullanıcıdan arkalarındaki sistemlerin tüm karmaşıklığını gizleyerek, bağlayıcı olmadan arabirimler aracılığıyla iletişim kurar. Bu modda kuruluşlar, yazılım satıcısı, işletim sistemi, programlama dili veya yazılımın diğer dahili özelliklerinden bağımsız olarak yeni uygulamaları kolayca ekleyebilir. Konsept SOA temelinde uygulanır GÜVENLİ ( Enerji için Çözüm Mimarisi, kamu hizmeti endüstrisinin altyapılarına ilişkin standartlara dayalı, bütünsel bir görünüm kazanmasını sağlar.

Esri ArcGIS®, elektrik enerjisi, gaz iletimi, dağıtım ve telekomünikasyon ağlarının dijital varlıklarının oluşturulmasını ve yönetimini sağlayan coğrafi bilgi sistemleri (GIS) için dünya çapında tanınan bir yazılım platformudur. ArcGIS, mekansal konumlarını dikkate alarak elektrik dağıtım şebekesinin bileşenlerinin en eksiksiz envanterini yapmanızı sağlar. ArcGIS, akıllı şebekeyi yönetmek için gereken araçları, uygulamaları, iş akışlarını, analitiği ve bilgi ve bütünleştirme yeteneklerini sağlayarak IBM SAFE mimarisini büyük ölçüde genişletir. IBM SAFE içindeki ArcGIS, konumları hakkında doğru verilerle altyapı nesneleri, varlıklar, müşteriler ve çalışanlar hakkında çeşitli kaynaklardan bilgi edinmenin yanı sıra kurumsal varlıklar (sütunlar, boru hatları, teller, transformatörler, kablo kanalları vb.). GÜVENLİ bir altyapı içindeki ArcGIS, GIS, SCADA ve müşteri hizmetleri sistemlerinden gelen verileri trafik, hava koşulları veya uydu görüntüleri gibi harici bilgilerle birleştirerek önemli iş uygulamalarını dinamik olarak bağlamanıza olanak tanır. Kamu hizmetleri bu birleştirilmiş bilgileri C.O.R.'dan çeşitli amaçlar için kullanır. (operasyon ortamının büyük resmi) saha denetimleri, bakım, ağ analizi ve planlamasına kadar.

Bir güç kaynağı kuruluşunun bilgi bileşenleri, en düşük - fiziksel - en üst, en karmaşık iş süreci mantığı düzeyine kadar değişen çeşitli düzeyler kullanılarak modellenebilir. Bu katmanlar, otomatik ölçüm günlüğü ve denetleyici kontrol ve veri toplama (SCADA) kontrolü gibi tipik endüstri gereksinimlerini karşılamak için entegre edilebilir. SAFE mimarisini inşa ederek, kamu hizmeti şirketleri, Enerji ve Kamu Hizmetleri için Ortak Bilgi Modeli (CIM) adı verilen endüstri çapında bir açık nesne modelini geliştirmede önemli adımlar atıyorlar. Bu model, veri ve nesneleri yapılandırmak için açık standartların kullanımını teşvik ettiğinden, birçok işletmeyi hizmet odaklı bir mimariye taşımak için gerekli temeli sağlar. Tüm sistemlerin aynı nesneleri kullanmasını sağlayarak, aynı nesnelerin farklı uygulamalarıyla ilişkili karışıklık ve esneklik minimuma indirilecektir. Böylece, "müşteri" nesnesinin tanımı ve diğer önemli iş nesneleri, güç kaynağı şirketinin tüm sistemlerinde birleştirilmiş olacaktır. CIM ile, hizmet sağlayıcılar ve hizmet tüketicileri artık ortak bir veri yapısını paylaşabilir, bu da CIM bilgi paylaşımının oluşturulacağı ortak bir temel oluşturduğu için maliyetli iş bileşenlerini dışarıdan temin etmeyi kolaylaştırır.

Çözüm

Kapsamlı endüstri veri modelleri, şirketlere iş bilgilerinin tek ve entegre bir görünümünü sağlar. Çoğu şirket, verilerini entegre etmeyi zor bulmaktadır, ancak bu, kurumsal çaptaki çoğu proje için bir ön koşuldur. The Data Warehousing Institute (TDWI) tarafından yapılan bir araştırmaya göre, ankete katılan kuruluşların %69'undan fazlası, entegrasyonun yeni uygulamanın benimsenmesinin önünde önemli bir engel olduğunu buldu. Aksine, veri entegrasyonunun uygulanması şirkete maddi gelir ve artan verimlilik getiriyor.

İyi oluşturulmuş bir model, bu durumda yapılandırılmış veri olan verilerin anlamını benzersiz bir şekilde tanımlar (değerin belirsiz olabileceği görüntü, ikili dosya veya metin gibi yapılandırılmamış verilerin aksine). En etkili endüstri modelleri, Esri ve IBM dahil olmak üzere profesyonel satıcılar tarafından sunulmaktadır. Modellerinin kullanımındaki yüksek getiri, önemli düzeyde ayrıntı ve doğruluk nedeniyle elde edilir. Genellikle birçok veri özniteliği içerirler. Ek olarak, Esri ve IBM uzmanları, yalnızca kapsamlı modelleme deneyimine sahip olmakla kalmaz, aynı zamanda belirli bir sektör için model oluşturma konusunda da bilgilidir.

Bu makale, veri ambarlarının mimarisine odaklanacaktır. İnşa ederken neye rehberlik edilmelidir, hangi yaklaşımlar işe yarar - ve neden.

"Masal bir yalan - ama içinde bir ipucu var ..."

Büyükbaba dikti ... depolama. Ve depo büyüdükçe büyüdü. Sadece nasıl çalıştığını gerçekten bilmiyordum. Ve büyükbaba bir inceleme başlattı. Büyükbaba, büyükanneyi, torunu, kediyi ve fareyi bir aile konseyi için çağırdı. Ve şu konuyu söylüyor: “Depolamamız büyüdü. Tüm sistemlerden gelen veriler akın eder, tablolar görünür ve görünmezdir. Kullanıcılar raporlarını hazırlar. Görünüşe göre her şey yolunda - yaşamak ve yaşamak. Evet, sadece bir üzüntü - kimse nasıl çalıştığını bilmiyor. Görünüşe göre - görünmez bir şekilde diskler gerektiriyor - yeterince alamayacaksınız! Ve sonra bana farklı şikayetlerle gelen kullanıcılar var: ya rapor donuyor ya da veriler eski. Ve bazen bu tam bir felaket oluyor - çarın babasına raporlarla geliyoruz, ancak rakamlar birbiriyle aynı fikirde değil. Saat bile değil - kral kızacak - o zaman kafanı yıkma - ne benim için ne de senin için. Bu yüzden sizi toplamaya ve danışmaya karar verdim: ne yapacağız?

Gözlerini meclise dikti ve sordu:
- İşte buradasın büyükanne, depomuzun nasıl düzenlendiğini biliyor musun?
- Hayır dede, bilmiyorum. Ve nasıl bilmeliyim? Orada, onu ne kadar cesur adamlar koruyor! Biraz bıyık! Adım atmayın. Bir şekilde onları ziyarete gittim, turta pişirdim. Ve biraz turta yediler, bıyıklarını sildiler ve “Niçin geldin büyükanne? Depolama alanınız nedir? Bize ne tür bir rapora ihtiyacınız olduğunu söyleyin - bunu sizin için yapacağız! En önemlisi daha sık turta getiriyorsunuz! Acı verici bir şekilde lezzetli tatlar. ”
- Ve sen, sevgili torunum, depomuzun nasıl düzenlendiğini biliyor musun?
- Hayır dede, bilmiyorum. Bana biraz erişim sağladı. Bağlandım, baktım - ve tablolar var - görünüşe göre görünmez. Ve farklı şemalar gizlidir. Gözler büyür.... İlk başta kafam karıştı. Sonra yakından baktım - bazıları boş, diğerleri dolu, ama sadece yarısı. Ayrıca, veriler tekrarlanmış gibi görünüyor. Bu kadar fazlalığa sahip disklerde stok yapamamanıza şaşmamalı!
- Pekala, sen kedi, depomuz hakkında ne söyleyebilirsin? İçinde iyi bir şey var mı?
- Evet, nasıl demez dede - söyleyeceğim. Torunumun isteği üzerine ayrı bir şemada pilot pilot yapmaya çalıştım - küçük bir vitrin. Hangi ticaretin devletimiz için faydalı olduğunu anlamak için - tüccarlar için hangi ürünler iyidir, haraç öderler - hazine doldurulur. Ve hangileri kötü. Ve bu depodan veri toplamaya başladım. Toplanan gerçekler. Ve onları ürünlerle karşılaştırmaya başladı. Ve ne, büyükbaba, gördüm - ürünler aynı görünüyor, ama işaretlere bakıyorsun - farklılar! Sonra torunumun tarağıyla onları taramaya başladım. Kaşıdı, kaşıdı - ve gözü okşayarak belli bir tekdüzeliğe yol açtı. Ama erken sevindim - ertesi gün penceredeki harika verileri güncellemek için komut dosyalarımı başlattım - ve her şey benim için gitti! "Nasıl yani?" - Sanırım, - torun üzülecek - bugün pilotumuzu bakana göstermek gerekecek. Bunu nasıl yapacağız - bu tür verilerle?
- Evet, üzücü hikayeler, kedi, sen anlat. Pekala, sen küçük fare, kasayı gerçekten öğrenmeye çalışmadın mı? Sen canlı, çevik, girişken bir kızsın! Bize ne söyleyeceksin?
- Evet, nasıl, büyükbaba, deneme - elbette, ben sessiz bir fareyim ama çevikim. Her nasılsa kedinin torunu, devlet depomuzun veri modelinden onu almasını istedi. Ve elbette kedi bana geldi - sana, diyor fare, tüm umutlar! Peki, iyi insanların (ve kedilerin) yapamadığı iyilik nedir? Depo başkanının veri modelini bir kasada sakladığı kaleye gittim. Ve saklandım. O modeli kasadan çıkarmasını bekledim. Kahve içmek için dışarı çıkar çıkmaz masaya atladım. Modele bakıyorum - hiçbir şey anlamıyorum! Nasıl yani? Kasamızı tanımıyorum! Sayısız binlerce tablomuz, verimiz - yorulmak bilmeyen akışımız var! Ve burada - her şey uyumlu ve güzel ... Bu modele baktı - ve kasaya geri koydu.
- Evet, çok garip şeyler söyledin, fare.
Büyükbaba çok düşündü.
Ne yapalım arkadaşlar? Ne de olsa, böyle bir depoyla uzun süre yaşamayacaksınız ... Kullanıcılar yakında sabrını tamamen kaybedecek.

Masaldaki büyükbabamız ne karar verirse versin - yeni bir depolama tesisi inşa etmek veya mevcut olanı yeniden canlandırmaya çalışmak - tekrar “kollarımızı sıvamadan” sonuçlar çıkarmalıyız.
Bazı dar kapalı gruplarda uzmanlığa odaklanma tehlikesi, kontrol süreçlerinin eksikliği ve kuruluşta kullanılan sistemlerin mimarisinin şeffaflığının sağlanması gibi organizasyonel yönleri bir kenara bırakalım.
Bugün, belirli bir sistemin (veya sistem grubunun) - veri ambarlarının mimarisini oluşturmaya odaklanmak istiyorum. Bir kuruluş depolama gibi karmaşık ve pahalı bir sistem oluşturmaya başladığında ilk etapta nelere odaklanılmalıdır.

bilgi alma

Herhangi bir sistemin yaratılması ve geliştirilmesi üzerinde çalışan hiçbirimiz, bunun “geçici bir ev” veya bir veya iki yıl içinde “solup gidecek” bir çözüm olmasını istemiyoruz, çünkü. Müşterilerin ve İşletmenin ihtiyaç ve beklentilerini karşılayamayacaktır. Günümüzde “esnek metodolojilere” geçiş ne kadar güçlü olursa olsun, bir insanın kendini keman yapan bir “usta” gibi hissetmesi, kullanılıp atılan davullar için çubuklar oyan bir zanaatkardan çok daha hoştur.
Niyetimiz kulağa doğal geliyor: Sağlam ve kaliteli, düzenli olarak “dosya ile gece nöbeti” yapmamızı gerektirmeyecek, son kullanıcıların önünde utanmayacağımız ve göründüğü gibi görünmeyecek sistemler yapmak. tüm "başlangıçsız" takipçilere bir "kara kutu".

İlk olarak, depolarla çalışırken düzenli olarak karşılaştığımız tipik sorunları listeleyelim. Şimdi elimizdekileri yazalım - şu ana kadar düzene koymaya ve resmileştirmeye çalışmadan.

1. Prensip olarak, iyi bir depolama alanımız var: ona dokunmazsanız, her şey çalışır. Doğru, bir değişiklik gerekli olur olmaz “yerel çöküşler” başlar.
2. Veriler, yönetmeliklere göre günlük olarak, büyük bir süreç içerisinde, 8 saat içinde yüklenir. Ve bize yakışıyor. Ancak aniden bir arıza meydana gelirse, bu manuel müdahale gerektirir. Ve sonra her şey uzun süre tahmin edilemez bir şekilde çalışabilir, çünkü. sürece insan katılımı gereklidir.
3. Haddelenmiş sürüm - sorun bekleyin.
4. Bazı kaynaklar verileri zamanında veremedi - tüm işlemler bekliyor.
5. Veri bütünlüğü, veritabanı tarafından kontrol edilir - bu nedenle, bozulduğunda süreçlerimiz çöker.
6. Çok büyük bir depolama alanımız var - ortak bir şemada 2000 tablo. Ve diğer birçok şemada 3000 daha. Nasıl düzenlendikleri ve hangi nedenle ortaya çıktıkları hakkında zaten çok az fikrimiz var. Bu nedenle, bir şeyi yeniden kullanmak bizim için zor olabilir. Ve birçok sorunun yeniden çözülmesi gerekiyor. Çünkü, daha kolay ve daha hızlıdır ("başka birinin kodunda" anlamaktan). Sonuç olarak, tutarsızlıklarımız ve yinelenen işlevselliklerimiz var.
7. Kaynağın kaliteli veri sağlamasını bekliyoruz. Ancak durumun böyle olmadığı ortaya çıkıyor. Sonuç olarak, nihai raporlarımızı uzlaştırmak için çok zaman harcıyoruz. Ve bunda çok başarılıydılar. Hatta kolaylaştırılmış bir sürecimiz var. Doğru, zaman alır. Ama kullanıcılar alıştı...
8. Kullanıcı her zaman raporlarımıza güvenmez ve belirli bir rakam için gerekçe ister. Bazı durumlarda haklı, bazılarında ise haksızdır. Ama bunları kanıtlamak bizim için çok zor, çünkü "uçtan uca analiz" (veya veri kökeni) araçları sağlamıyoruz.
9. Ek geliştiriciler getirebiliriz. Ama bir sorunumuz var - onları nasıl işe dönüştürebiliriz? İşi paralelleştirmenin en verimli yolu nedir?
10. Bir yıl boyunca “sistemin çekirdeğini” geliştirmeye girmeden sistem kademeli olarak nasıl geliştirilir?
11. Veri ambarı, kurumsal modelle ilişkilendirilir. Ama kesin olarak biliyoruz ki (XYZ bankasında gördük) sonsuza kadar bir model inşa etmenin mümkün olduğunu (XYZ bankasında hiçbir hareket olmadan altı ay boyunca ticari varlıkları dolaştık ve tartıştık). Neden o hiç? Ya da belki onsuz daha iyi, eğer onunla bu kadar çok sorun varsa? Belki bir şekilde üretir?
12. Modeli yönetmeye karar verdik. Ancak ambar veri modeli sistematik olarak nasıl geliştirilir? "Oyunun kurallarına" ihtiyacımız var mı ve bunlar ne olabilir? Bize ne verecek? Modelde bir hata yaparsak ne olur?
13. "İşin bunlara ihtiyacı yoksa" verileri mi yoksa değişikliklerinin geçmişini mi kaydetmeliyiz? "Çöp depolamak" ve bu verilerin gerçek görevler için kullanımını karmaşık hale getirmek istemem. Kasa geçmişi tutmalı mı? Neye benziyor? Depolama zamanla nasıl çalışır?
14. Bir NSI yönetim sistemimiz varsa, depodaki verileri birleştirmeye çalışmak gerekli midir? MDM varsa, bu şimdi tüm ana veri sorununun çözüldüğü anlamına mı geliyor?
15. Yakında kilit muhasebe sistemlerini değiştirmemiz bekleniyor. Veri deposu bir kaynak değişikliğine hazır olmalı mı? Buna nasıl ulaşılır?
16. Meta verilere ihtiyacımız var mı? Bundan ne anlayacağız? Tam olarak nerede kullanılabilirler? Nasıl uygulanabilir? "Tek bir yerde" tutulmaları gerekiyor mu?
17. Müşterilerimiz gereksinimlerinde ve arzularında son derece istikrarsızdır - sürekli değişen bir şeyler vardır. Genel olarak işimiz çok dinamik. Biz bir şeyler yaparken zaten gereksiz hale geliyor. Sıcak kek gibi sonuçları olabildiğince çabuk ürettiğimizden nasıl emin olabiliriz?
18. Kullanıcılar hız ister. Ancak ana önyükleme süreçlerimizi sık sık çalıştıramıyoruz, çünkü bu, kaynak sistemleri yükler (performans üzerinde kötü bir etkisi vardır) - bu nedenle, ek veri akışlarını kapatıyoruz - bu da noktasal olarak - ihtiyacımız olanı alacak. Doğru, çok fazla akış ortaya çıkıyor. Ve sonra bazı verileri atacağız. Ek olarak, bir yakınsama sorunu olacaktır. Ama başka yolu yok...

Zaten çok şey oldu. Ancak bu tam bir liste değildir - onu tamamlamak ve geliştirmek kolaydır. Masada saklamayacağız, ancak göze çarpan bir yere asacağız - bu konuları çalışma sürecinde dikkatimizin odağında tutacağız.
Görevimiz, sonuç olarak kapsamlı bir çözüm geliştirmektir.

anti-kırılganlık

Listemize bakıldığında, bir sonuç çıkarılabilir. Bir tür “raporlama için veri tabanı” oluşturmak, verileri oraya atmak ve hatta bir tür rutin veri güncelleme süreçleri oluşturmak zor değil. Sistem bir şekilde yaşamaya başlar, kullanıcılar ortaya çıkar ve onlarla birlikte yükümlülükler ve SLA'lar, yeni gereksinimler ortaya çıkar, ek kaynaklar bağlanır, metodolojiler değişir - tüm bunlar geliştirme sürecinde dikkate alınmalıdır.

Bir süre sonra, resim aşağıdaki gibidir:
"İşte kasa. Ve dokunmazsanız çalışır. Bir şeyi değiştirmemiz gerektiğinde sorunlar ortaya çıkar.”

Bize etkisini değerlendiremediğimiz ve kavrayamadığımız bir değişiklik geliyor (çünkü bu tür araçları sisteme ilk başta koymadık) - ve risk almamak için olana dokunmuyoruz, bir tane daha yapıyoruz. yandaki uzantı ve bir tane daha ve daha fazlası - kararımızı gecekondu mahallelerine çevirmek ya da Latin Amerika'da dedikleri gibi, polisin bile gitmeye korktuğu "favelalar".
Kişinin kendi sistemi üzerinde kontrol kaybı hissi var, kaos. Mevcut süreçleri sürdürmek ve sorunları çözmek için giderek daha fazla el gerekiyor. Ve değişiklik yapmak giderek zorlaşıyor. Başka bir deyişle, sistem streslere karşı kararsız hale gelir, değişikliklere uyum sağlayamaz. Ayrıca, kimsenin bir "kartı" olmadığı için "faydalı yolu bilen" karakterlere güçlü bir bağımlılık vardır.

Bir nesnenin bu özelliği, kaos, rastgele olaylar ve karışıklıkların etkisi altında çökmektir - Nassim Nicholas Taleb diyor kırılganlık . Aynı zamanda karşıt kavramı da sunar: anti-kırılganlık – nesne stres ve kazalar tarafından yok edilmediğinde, ancak ondan doğrudan bir fayda aldığında. ("Antifrajilite. Kaostan nasıl yararlanılır")
Aksi takdirde çağrılabilir uyarlanabilirlik veya değişime direnç .

Bu, bu bağlamda ne anlama geliyor? BT sistemleri için "kaos kaynakları" nelerdir? Ve BT mimarisi açısından "kaostan yararlanmak" ne anlama geliyor?
Akla gelen ilk düşünce dışarıdan gelen değişimlerdir. Sistem için dış dünya nedir? Özellikle depolama için. Tabii ki, her şeyden önce - depo için veri kaynaklarından yapılan değişiklikler:

• gelen verilerin formatlarını değiştirmek;
• bazı veri kaynağı sistemlerinin diğerleriyle değiştirilmesi;
• sistem entegrasyonu için değişen kurallar/platformlar;
• verilerin yorumlanmasının değiştirilmesi (formatlar kaydedilir, verilerle çalışma mantığı değişir);
• entegrasyon veri düzeyinde yapılıyorsa veri modelinin değiştirilmesi (veritabanı işlem günlük dosyalarının ayrıştırılması);
• veri hacimlerinde büyüme - kaynak sistemde çok az veri varken ve yük küçükken - bunları istediğiniz zaman, isteğe bağlı olarak yoğun bir istekle alabilirdiniz, veriler ve yük arttı - şimdi katı kısıtlamalar var;
• vb.

Kaynak sistemlerin kendileri, bilginin bileşimi ve yapısı, entegrasyon etkileşiminin türü ve ayrıca verilerle çalışmanın mantığı değişebilir. Her sistem, kendi veri modelini ve sistemin amaç ve hedeflerini karşılayan onlarla çalışma yaklaşımlarını uygular. Ve endüstri modellerini ve referans uygulamalarını ne kadar birleştirmeye çalışırlarsa çalışsınlar, her halükarda nüanslar kaçınılmaz olarak ortaya çıkacaktır. (Ayrıca, endüstrinin birleşmesi sürecinin kendisi, çeşitli nedenlerle, fazla ilerlemiyor.)
Kurumsal verilerle çalışma kültürü - bilgi mimarisinin varlığı ve kontrolü, tek bir anlamsal model, ana veri yönetim sistemleri (MDM), depodaki verileri birleştirme görevini bir şekilde kolaylaştırır, ancak gerekliliğini dışlamaz.

Depolama tüketicileri tarafından daha az kritik değişiklik başlatılmaz (gereksinim değişiklikleri):

• önceden bir rapor oluşturmak için yeterli veri vardı - şimdi ek alanlar veya yeni bir veri kaynağı bağlamak gerekiyordu;
• önceden uygulanan veri işleme yöntemleri eskidir - algoritmalar ve etkilediği her şeyin yeniden işlenmesi gerekir;
• Önceden, herkes bilgi panelindeki sözlük özniteliğinin mevcut değerinden memnundu - şimdi analiz edilen olgunun / olayın meydana geldiği anda ilgili olan değer gereklidir;
• daha önce olmayan veri depolama tarihinin derinliği için bir gereklilik vardı - verileri 2 yıl değil 10 yıl boyunca saklamak;
• Önceden, “gün sonu/dönem” itibariyle veriye sahip olmak yeterliydi - şimdi “gün içi” veya belirli bir olay sırasında (örneğin, bir kredi başvurusuna karar verme - için) veri durumuna ihtiyacınız var. Basel II);
• daha önce dün (T-1) veya daha sonrasına ilişkin verileri raporlamaktan memnunduk, şimdi T0'a ihtiyacımız var;
• vb.

Hem kaynak sistemlerle entegrasyon etkileşimleri hem de ambar veri tüketicilerinden gelen gereksinimler veri ambarı için dış faktörlerdir: bir kaynak sistem diğerinin yerini alır, veri hacimleri büyür, gelen veri biçimleri değişir, kullanıcı gereksinimleri değişir, vb. Ve tüm bunlar, sistemimizin - depomuzun - hazır olması gereken tipik harici değişikliklerdir. Doğru mimari ile sistemi öldürmemeleri gerekir.

Ama hepsi bu kadar değil.
Değişkenlikten bahsetmişken, her şeyden önce dış faktörleri hatırlıyoruz. Sonuçta, içimizde her şeyi kontrol edebiliyoruz, bize öyle geliyor değil mi? Evet ve hayır. Evet, etki alanı dışındaki faktörlerin çoğu dışsaldır. Ama bir de “iç entropi” var. Ve tam da onun varlığından dolayı bazen “0 noktasına” geri dönmemiz gerekiyor. Oyunu baştan başlatın.
Hayatta, genellikle sıfırdan başlama eğilimindeyiz. Neden bunu yapmaya meyilliyiz? Ve o kadar kötü mü?
BT'ye uygulandı. Sistemin kendisi için - bu çok iyi olabilir - bireysel kararları yeniden gözden geçirme yeteneği. Özellikle yerel olarak yapabileceğimiz zaman. Yeniden düzenleme, sistem geliştirme sürecinde periyodik olarak ortaya çıkan "ağ"ın çözülmesi sürecidir. "Başlangıca" dönmek faydalı olabilir. Ama bir bedeli var.
Uygun mimari yönetimi ile bu fiyat düşürülür ve sistem geliştirme sürecinin kendisi daha kontrol edilebilir ve şeffaf hale gelir. Basit bir örnek: modülerlik ilkesine uyulursa, harici arayüzleri etkilemeden ayrı bir modülü yeniden yazmak mümkündür. Ve bu monolitik bir yapı ile yapılamaz.

Bir sistemin kırılganlığı, mimarisi tarafından belirlenir. Ve onu uyarlanabilir yapan da bu özelliğidir.
hakkında konuştuğumuzda uyarlanabilir mimari- sistemin değişikliklere uyum sağlayabildiğini kastediyoruz ve mimarinin kendisini sürekli değiştirdiğimizden değil. Aksine, mimari ne kadar kararlı ve kararlı olursa, revizyonu gerektiren gereksinimler ne kadar az olursa, sistem o kadar uyarlanabilir.

Tüm mimarinin revizyonunu gerektiren çözümlerin fiyatı çok daha yüksek olacaktır. Ve evlat edinmeleri için çok iyi nedenleriniz olması gerekiyor. Örneğin böyle bir neden, mevcut mimari içerisinde uygulanamayan bir gereklilik olabilir. Sonra derler ki - mimariyi etkileyen bir gereklilik vardı.
Bu nedenle “antifrajilite sınırlarımızı” da bilmemiz gerekiyor. Mimari "bir boşlukta" geliştirilmemiştir - mevcut gereksinimlere ve beklentilere dayanmaktadır. Ve durum kökten değişirse - mevcut mimarinin ötesine geçtiğimizi anlamalıyız - ve onu revize etmemiz, farklı bir çözüm geliştirmemiz ve geçiş yolları üzerinde düşünmemiz gerekiyor.
Örneğin, günün sonunda her zaman depoda veriye ihtiyacımız olacağını varsaydık, standart sistem arayüzlerini kullanarak (bir dizi görünüm aracılığıyla) günlük olarak veri toplayacağız. Ardından risk yönetimi bölümünden verinin gün sonunda değil, kredi verme kararı alınırken alınması gerektiği yönünde talepler geldi. "Gerilmemiş olanı uzatmaya" gerek yok - sadece bu gerçeği kabul etmeniz gerekiyor - ne kadar erken olursa o kadar iyi. Ve sorunu çözmemizi sağlayacak bir yaklaşım üzerinde çalışmaya başlayın.
Burada çok ince bir çizgi var - sadece "andaki gereksinimleri" göz önünde bulundurursak ve birkaç adım ileriye (ve birkaç yıl sonrasına) bakmazsak, o zaman mimariyi etkileyen bir gereksinimle çok geç karşılaşma riskini artırırız - ve değişikliğimizin maliyeti çok yüksek olacak. Biraz ileriye bakmak - ufkumuz sınırları içinde - hiç kimseye zarar vermedi.

“Depolama peri masalından” bir sistem örneği, kırılgan tasarım yaklaşımları üzerine kurulmuş çok titrek bir sistem örneğidir. Ve eğer bu olursa, bu özel sistem sınıfı için yıkım oldukça hızlı gerçekleşir.
Neden böyle söyleyebilirim? Depolama konusu yeni değil. Bu süre zarfında geliştirilen yaklaşımlar ve mühendislik uygulamaları tam olarak bunu hedeflemiştir - sistemin yaşayabilirliğini korumak.
Basit bir örnek vermek gerekirse, kalkış depolama projelerinin başarısız olmasının en yaygın nedenlerinden biri, entegrasyon arayüzlerini eşleştirmeden geliştirilmekte olan kaynak sistemlerin üzerine depolama oluşturmaya çalışmaktır - doğrudan tablolardan veri çekmeye çalışmak. Sonuç olarak, geliştirme sürecine girdiler - bu süre zarfında kaynak veritabanı değişti - ve depolamadaki indirme akışları çalışamaz hale geldi. Bir şeyi yeniden yapmak için çok geç. Ve eğer deponun içinde birkaç kat masa yaparak kendinizi güvenceye almadıysanız, o zaman her şeyi atabilir ve baştan başlayabilirsiniz. Bu sadece bir örnek ve en basitlerinden biri.

Taleb'in kırılgan ve kırılmazlık kriteri basittir. Baş yargıç zamanı. Sistem zamanın testine dayanır ve "hayatta kalma" ve "yok edilemezliğini" gösterirse - kırılganlık özelliğine sahiptir.
Bir sistemi tasarlarken, bir gereklilik olarak anti-kırılganlığı hesaba katarsak, bu, bizi sistemin hem “dışarıdan kaosa” hem de “içten gelen kaosa” daha uyumlu hale getirecek mimarisini inşa etmek için bu tür yaklaşımları kullanmaya teşvik edecektir. ”. Ve nihayetinde sistem daha uzun bir ömre sahip olacaktır.
Hiçbirimiz "geçici" yapmak istemiyoruz. Ve şimdi başka bir yol olmadığı konusunda kendinizi kandırmayın. Bir insan için her an, özellikle kriz zamanlarında birkaç adım ileriye bakmak normaldir.

Veri ambarı nedir ve neden inşa ediyoruz?

Depolama mimarisi makalesi, okuyucunun yalnızca ne olduğunu bildiğini değil, aynı zamanda bu tür sistemlerle ilgili biraz deneyimi olduğunu varsayar. Yine de, bunu yapmanın gerekli olduğunu düşündüm - kökenlere, yolun başlangıcına, çünkü. gelişmenin “dayanak noktası” oradadır.

İnsanlar veri ambarlarının gerekli olduğu sonucuna nasıl vardı? Ve sadece "çok büyük bir veritabanından" nasıl farklılar?
Uzun zaman önce, dünyada sadece “iş veri işleme sistemleri” varken, BT sistemlerinin ön uç oltp sistemleri, arka ofis dss, metin veri işleme sistemleri, veri ambarları vb. sınıflara ayrılması yoktu. .
Bu, ilk ilişkisel DBMS Ingres'in Michael Stonebreaker tarafından yaratıldığı zamandı.
Ve bu, kişisel bilgisayarların çağının bilgisayar endüstrisine bir kasırga gibi girdiği ve o zamanın BT topluluğunun tüm fikirlerini sonsuza dek değiştirdiği zamandı.

O zaman Clipper, dBase ve FoxPro gibi masaüstü sınıfı DBMS temelinde yazılmış kurumsal uygulamaları bulmak kolaydı. Ve istemci-sunucu uygulamaları ve DBMS pazarı yalnızca ivme kazanıyordu. Birbiri ardına, BT alanındaki nişlerini uzun süre işgal edecek veritabanı sunucuları ortaya çıktı - Oracle, DB2, vb.
Ve "veritabanı uygulaması" terimi dolaşıma girdi. Böyle bir uygulama neleri içeriyordu? Basitleştirilmiş - kullanıcıların aynı anda bilgi girebileceği bazı girdi formları, "bir düğme üzerinde" veya "programa göre" başlatılan bazı hesaplamalar ve ayrıca ekranda görülebilen veya dosya olarak kaydedilip mühürlenmek üzere gönderilen bazı raporlar .
İlk akıl hocalarımdan biri "Özel bir şey yok - sadece basit bir uygulama, sadece bir veritabanı" dedi. "Özel bir şey yok mu?" - O zaman düşündüm.

Yakından bakarsanız, hala özellikler var. Kullanıcılar büyüdükçe, gelen bilgilerin hacmi artar, sistem üzerindeki yük arttıkça, geliştiricileri-tasarımcıları, performansı kabul edilebilir bir seviyede tutmak için bazı "hilelere" giderler. Birincisi, monolitik bir “iş veri işleme sisteminin”, kullanıcıların çevrimiçi modda çalışmasını destekleyen bir muhasebe uygulamasına ve toplu veri işleme ve raporlama için ayrı bir uygulamaya bölünmesidir. Bu uygulamaların her birinin kendi veritabanı vardır ve hatta farklı yük türleri - OLTP ve DSS için farklı ayarlarla, veritabanı sunucusunun ayrı bir örneğinde barındırılır. Ve veri akışları bunlar arasında oluşturulur.

Hepsi bu? Sorun çözülmüş gibi görünüyor. Sonra ne olur?
Ve sonra şirketler büyür, bilgi ihtiyaçları çoğalır. Dış dünyayla etkileşimlerin sayısı da artıyor. Sonuç olarak, tüm süreçleri tamamen otomatikleştiren büyük bir uygulama değil, farklı üreticilerden birkaç farklı uygulama var. Şirkette bilgi üreten sistemlerin sayısı - veri kaynağı sistemleri artıyor. Ve er ya da geç, farklı sistemlerden alınan bilgileri görme ve karşılaştırma ihtiyacı olacaktır. Şirkette yeni bir sistem sınıfı olan Veri Ambarı böyle ortaya çıkıyor.
Bu sistem sınıfının genel kabul görmüş tanımı aşağıdaki gibidir.

Veri Ambarı (veya Veri Ambarı)- bir kuruluşta karar vermeyi desteklemek için raporların ve iş analizinin hazırlanması için özel olarak tasarlanmış ve amaçlanan alana özgü bir bilgi veritabanı

Böylece, konsolidasyon Farklı sistemlerden gelen veriler, onlara belirli bir "tek" (birleşik) şekilde bakabilme yeteneği, veri depolama sınıfı sistemlerinin temel özelliklerinden biridir. BT sistemlerinin evrimi sırasında depolamanın ortaya çıkmasının nedeni budur.

Veri Ambarlarının Temel Özellikleri

Daha ayrıntılı olarak bir göz atalım. Bu sistemlerin temel özellikleri nelerdir? Veri ambarlarını diğer kurumsal BT sistemlerinden farklı kılan nedir?

İlk olarak, bunlar büyük hacimlerdir. Çok büyük. VLDB - önde gelen satıcılar, ürünlerinin kullanımıyla ilgili tavsiyelerini verirken bu tür sistemleri böyle adlandırırlar. Şirketin tüm sistemlerinden veriler bu büyük veritabanına akar ve orada ders kitaplarında dedikleri gibi "sonsuza kadar ve değişmeden" saklanır (pratikte hayat daha karmaşık hale gelir).

İkincisi, tarihsel verilerdir - "Kurumsal hafıza" - sözde veri ambarları. Depoda zamanla çalışmak açısından her şey oldukça ilginç. Muhasebe sistemlerinde veriler şu anda önemlidir. Ardından kullanıcı bazı işlemler gerçekleştirir ve veriler güncellenir. Aynı zamanda, değişikliklerin geçmişi korunmayabilir - muhasebe uygulamasına bağlıdır. Örneğin, bir banka hesabı bakiyesi alın. Günün sonunda veya bir olay anındaki (örneğin, puanın hesaplandığı zaman) "şimdi" deki cari bakiyeyle ilgilenebiliriz. İlk ikisi oldukça basit bir şekilde çözülürse, ikincisi büyük olasılıkla özel çaba gerektirecektir. Depoyla çalışırken, kullanıcı geçmiş dönemlere erişebilir, bunları mevcut olanla karşılaştırabilir vb. Veri ambarlarını muhasebe sistemlerinden - zaman ekseninde çeşitli noktalarda verilerin durumunu elde etme - geçmişte belirli bir derinliğe kadar önemli ölçüde ayıran bu zamanla ilgili yeteneklerdir.

Üçüncüsü, bu konsolidasyon Ve veri birleştirme . Ortak analizlerini mümkün kılmak için onları ortak bir forma getirmek gerekir - birleşik veri modeli , gerçekleri birleşik referans kitaplarıyla karşılaştırın. Burada çeşitli yönler ve zorluklar olabilir. Her şeyden önce - kavramsal – aynı terim altında, farklı departmanlardan farklı kişiler farklı şeyleri anlayabilir. Ve tam tersi - temelde aynı şey olan bir şeyi farklı olarak adlandırmak. "Tek bir görünüm" nasıl sağlanır ve aynı zamanda belirli bir kullanıcı grubunun vizyonunun özellikleri nasıl korunur?

Dördüncüsü, onunla çalışmak veri kalitesi . Depoya veri yükleme sürecinde bunlar temizlenir, genel dönüşümler ve dönüşümler yapılır. Genel dönüşümler tek bir yerde yapılmalı ve ardından çeşitli raporlar oluşturmak için kullanılmalıdır. Bu, iş kullanıcıları için - özellikle de farklı departmanlardan birbiriyle uyuşmayan sayılarla masaya getirilen yönetim için - çok fazla tahrişe neden olan tutarsızlıkları önleyecektir. Kötü veri kalitesi, raporlarda hata ve tutarsızlıklara yol açar ve bunun sonucu olarak seviye düşer kullanıcı güveni tüm sisteme, bir bütün olarak tüm analitik hizmete.

mimari konsept

Depoya rastlayan herkes, büyük olasılıkla bir tür "katmanlı yapı" gözlemledi - çünkü. bu sınıfın sistemleri için kök salmış olan bu mimari paradigmadır. Ve tesadüfen değil. Depolama katmanları, sistemin ayrı bileşenleri olarak algılanabilir - kendi görevleri, sorumluluk alanları, "oyunun kuralları" ile.
Katmanlı mimari, sistemin karmaşıklığıyla başa çıkmanın bir yoludur - sonraki her katman, bir öncekinin dahili uygulamasının karmaşıklıklarından soyutlanır. Bu yaklaşım, her seferinde “bisikleti” yeniden icat etmeden aynı türden görevleri belirlemenize ve bunları tek tip bir şekilde çözmenize olanak tanır.
Şekilde şematik bir kavramsal mimari diyagram gösterilmektedir. Bu, yalnızca ana fikri yansıtan basitleştirilmiş bir diyagramdır - kavram, ancak ayrıntıların daha derinlemesine incelenmesiyle ortaya çıkacak "anatomik ayrıntılar" olmadan.

Diyagramda gösterildiği gibi, kavramsal olarak aşağıdaki katmanları seçin. Veri depolama alanını (doldurulmuş bir dikdörtgenle gösterilir) ve veri yükleme yazılımını (koşullu olarak aynı renkteki oklarla gösterilir) içeren üç ana katman. Bununla birlikte, çok önemli bir bağlantı rolü oynayan bir yardımcı hizmet katmanının yanı sıra - veri yükleme ve kalite kontrolünü yönetmek.

Birincil Veri Katmanı - birincil veri katmanı (veya evreleme , veya işletim katmanı ) - kaynak sistemlerden yüklenecek ve birincil bilgileri, dönüşümler olmadan - orijinal kalitesinde ve eksiksiz bir değişiklik geçmişi desteği ile kaydedilecek şekilde tasarlanmıştır.
Bu katmanın görevi– veri kaynaklarının fiziksel cihazından sonraki depolama katmanlarını, veri toplama yöntemlerini ve değişikliklerin deltasını vurgulama yöntemlerini soyutlamak.

Çekirdek Veri Katmanı - depolama çekirdeği - depolamayı yalnızca bir "toplu entegrasyon platformundan" veya bir "büyük veri dökümünden" ayıran sistemin merkezi bileşeni, çünkü ana rolü veri konsolidasyonu farklı kaynaklardan, tek tip yapılara indirgeme, anahtarlar. Çekirdeğe yüklenirken, veri kalitesi ve genel dönüşümlerle ilgili ana çalışma, oldukça karmaşık olabilen gerçekleştirilir.
Bu katmanın görevi- tüketicilerini veri kaynaklarının mantıksal yapısının özelliklerinden ve farklı sistemlerden gelen verileri karşılaştırma ihtiyacından soyutlamak, verilerin bütünlüğünü ve kalitesini sağlamak.

Data Mart Katmanı - analitik vitrinler - ana işlevi, verileri analiz için uygun yapılara dönüştürmek olan bir bileşen (BI, vitrinlerle çalışıyorsa, bu genellikle boyutlu bir modeldir) veya tüketici sisteminin gereksinimlerine göre.
Kural olarak, veri marketleri - güvenilir ve doğrulanmış bir kaynak olarak - yani çekirdekten veri alır. verileri tek bir forma getirmek için bu bileşenin hizmetini kullanın. Bu tür pencereleri arayacağız düzenli . Bazı durumlarda, vitrinler verileri doğrudan hazırlamadan alabilir - birincil verilerle çalışır (kaynak anahtarlarında). Bu yaklaşım, kural olarak, farklı sistemlerden veri konsolidasyonunun gerekli olmadığı ve veri kalitesinden daha fazla verimliliğin gerekli olduğu yerel görevler için kullanılır. Bu tür görüntüler denir işletme . Bazı analitik göstergeler çok karmaşık hesaplama yöntemlerine sahip olabilir. Bu nedenle, bu tür önemsiz olmayan hesaplamalar ve dönüşümler için sözde ikincil vitrinler .
Vitrin katmanı görevi– belirli bir tüketicinin – bir BI platformu, bir grup kullanıcı veya harici bir sistemin – gereksinimlerine göre verilerin hazırlanması.

Yukarıda açıklanan katmanlar, kalıcı bir veri depolama alanının yanı sıra verileri yüklemek ve dönüştürmek için bir yazılım modülünden oluşur. Bu katmanlara ve bölgelere ayırma mantıklıdır. Bu bileşenlerin fiziksel uygulaması farklı olabilir - daha verimli ise, verileri farklı katmanlarda depolamak veya dönüştürmek için farklı platformlar bile kullanabilirsiniz.
Depolama alanları, veri dönüştürme sürecinde kullanılan teknik (arabellek tabloları) ve hedef tablolar, tüketici bileşeni tarafından erişilen. Hedef tabloları görünümlerle "örtmek" iyi bir uygulamadır. Bu, sistemin daha sonraki bakımını ve geliştirilmesini kolaylaştırır. Her üç katmanın da hedef tablolarındaki veriler, veri yükleme işlemlerini sağlamaya ve ayrıca depolamadaki veri akışlarının bilgi denetimini sağlamaya yarayan özel teknik alanlar (meta-öznitelikler) ile işaretlenmiştir.

Tüm katmanlar için hizmet işlevleri sağlayan özel bir bileşen (veya bileşen grubu) da ayırt edilir. Anahtar görevlerinden biri - kontrol işlevi - tüm sistem için bir bütün olarak "oyunun tek kurallarını" sağlamak ve yukarıda açıklanan katmanların her birini uygulamak için farklı seçenekler kullanma hakkını bırakmaktır - dahil. verileri yüklemek ve işlemek için farklı teknolojiler, farklı depolama platformları vb. kullanın. onu arayalım hizmet katmanı (Hizmet Katmanı) . İş verilerini içermez, ancak kendi depolama yapılarına sahiptir - bir meta veri alanının yanı sıra veri kalitesiyle çalışmak için bir alan (ve kendisine atanan işlevlere bağlı olarak muhtemelen diğer yapılar) içerir.

Sistemin ayrı bileşenlere bu kadar net bir şekilde bölünmesi, sistem geliştirmenin kontrol edilebilirliğini önemli ölçüde artırır:

• belirli bir bileşenin işlevselliğinin geliştiricisine atanan görevin karmaşıklığı azalır (aynı anda harici sistemlerle entegrasyon sorunlarını çözmesi ve veri temizleme prosedürlerini düşünmesi ve verilerin en uygun sunumunu düşünmesi gerekmez). tüketiciler) - görevin ayrıştırılması, değerlendirilmesi ve küçük bir teslimatın gerçekleştirilmesi daha kolaydır;
• çeşitli sanatçıları (ve hatta ekipleri veya müteahhitleri) çalışmaya dahil edebilirsiniz - çünkü bu yaklaşım, görevleri etkili bir şekilde paralelleştirmenize ve birbirleri üzerindeki karşılıklı etkilerini azaltmanıza olanak tanır;
• kalıcı evrelemenin varlığı, tüm konu alanı için tüm çekirdeği veya vitrinleri tasarlamadan veri kaynaklarını hızlı bir şekilde bağlamanıza ve ardından önceliklere göre katmanların geri kalanını kademeli olarak oluşturmanıza olanak tanır (ayrıca, veriler zaten depoda olacaktır - mevcut deponun sonraki geliştirme görevlerini büyük ölçüde kolaylaştıracak sistem analistlerine);
• çekirdeğin varlığı, veri kalitesiyle yapılan tüm çalışmaların (olası ıskalar ve hataların yanı sıra) vitrinlerden ve son kullanıcıdan gizlenmesine olanak tanır ve en önemlisi, bu bileşeni vitrinler için tek bir veri kaynağı olarak kullanarak sorunlardan kaçınabilirsiniz. ortak algoritmaların tek bir yerde uygulanması nedeniyle veri yakınsaması ile;
• Vitrinleri vurgulamak, farklı departman kullanıcılarının sahip olabileceği verileri anlamanın farklılıklarını ve özelliklerini dikkate almanıza olanak tanır ve bunları BI gereksinimlerine göre tasarlamak, yalnızca toplu rakamlar yayınlamanıza değil, aynı zamanda detaya inme fırsatları sağlayarak veri güvenilirliğini sağlamanıza da olanak tanır. birincil göstergelere;
• hizmet katmanının varlığı, uçtan uca veri analizi (veri kökeni), birleşik veri denetim araçlarını kullanmanıza, değişikliklerin deltasını vurgulamaya yönelik ortak yaklaşımlara, veri kalitesiyle çalışmanıza, yük yönetimine, hata izleme ve tanılama araçlarına izin verir. , ve sorun çözümünü hızlandırır.

Bu ayrıştırma yaklaşımı aynı zamanda sistemi değişime karşı daha dirençli hale getirir ("monolitik bir yapıya" kıyasla) - kırılganlığını önler:

• kaynak sistemlerden yapılan değişiklikler evreleme üzerinde çalışılır - çekirdekte, yalnızca bu evreleme tablolarından etkilenen iş parçacıkları değiştirilir, vitrinler üzerindeki etki minimumdur veya yoktur;
• müşteri gereksinimlerindeki değişiklikler çoğunlukla vitrinlerde işlenir (zaten depoda olmayan ek bilgiler gerektirmediği sürece).

Ardından, yukarıdaki bileşenlerin her birini inceleyeceğiz ve onlara biraz daha ayrıntılı bakacağız.

sistem çekirdeği

"Ortadan" başlayalım - sistemin çekirdeği veya orta katman. Çekirdek Katman olarak etiketlenmez. Çekirdek, veri konsolidasyonu rolünü gerçekleştirir - tek yapılara, dizinlere, anahtarlara indirgeme. Burada veri kalitesi ile ana çalışma gerçekleştirilir - temizleme, dönüştürme, birleştirme.

Bu bileşenin varlığı, aynı işlevin uygulanmasını her uygulama mağazası için ayrı ayrı tekrarlamak yerine, kaynak sistemlerden alınan birincil verileri ortak kurallar ve algoritmalar izleyerek tek bir biçime dönüştüren veri akışlarını yeniden kullanmanıza olanak tanır. kaynakların verimsiz kullanımı, verilerde de tutarsızlıklara yol açabilir.
Depolama çekirdeği, genel durumda, hem kaynak sistem modellerinden hem de tüketicilerin biçimlerinden ve yapılarından farklı bir veri modelinde uygulanır.

Depolama motoru modeli ve kurumsal veri modeli

Orta depolama katmanının ana görevi kararlılıktır. Bu nedenle buradaki ana odak noktası veri modelidir. Genellikle "kurumsal veri modeli" olarak adlandırılır. Ne yazık ki, etrafında bazen yapısının tamamen terk edilmesine yol açan belirli bir mit ve saçmalık halesi gelişti, ancak boşuna.

Efsane 1. Kurumsal veri modeli, binlerce varlıktan (tablo) oluşan devasa bir modeldir.
Aslında. Herhangi bir konu alanında, herhangi bir iş alanında, herhangi bir şirketin verilerinde, en karmaşık bile olsa, birkaç temel varlık vardır - 20-30.

Efsane 2. Herhangi bir "kendi modeli" geliştirmeye gerek yok - bir endüstri referans modeli satın alıyoruz - ve her şeyi buna göre yapıyoruz. Para harcıyoruz - ama garantili bir sonuç alıyoruz.
Aslında. Referans modeller gerçekten çok faydalı olabilir, çünkü. Bu alanı modellemede endüstri deneyimi içerir. Onlardan fikirler, yaklaşımlar, adlandırma uygulamaları çizebilirsiniz. Önemli bir şeyi kaçırmamak için alanın "kapsam derinliğini" kontrol edin. Ancak böyle bir modeli "kutudan çıktığı gibi" kullanmamız pek mümkün değil - olduğu gibi. Bu, örneğin, bir ERP sistemi (veya CRM) satın almak ve onu “kendi başınıza çevirmeden” uygulamakla aynı efsanedir. Bu tür modellerin değeri, bu belirli işin, bu belirli şirketin gerçeklerine uyarlanmalarında doğar.

Efsane 3. Depolama çekirdek modelinin geliştirilmesi aylar alabilir ve bu süre zarfında proje gerçekten dondurulacaktır. Buna ek olarak, çılgın miktarda toplantı ve birçok insanın katılımını gerektirir.
Aslında. Depo modeli, depo ile birlikte parça parça yinelemeli olarak geliştirilebilir. Kaplanmamış alanlar için "uzatma noktaları" veya "saplamalar" yerleştirilir - yani. bazı "evrensel yapılar" uygulanmaktadır. Aynı zamanda, hem "veri koymanın" hem de (daha da zor) elde etmenin zor olduğu 4 tablodan oluşan süper evrensel bir şey almamak için önlemi bilmeniz gerekir. Ve performans açısından son derece uygun olmayan bir durum.

Modeli geliştirmek zaman alacaktır. Ancak bu, “varlıkların çizilmesi” için harcanan zaman değildir - bu, konu alanını analiz etmek, verilerin nasıl yapılandırıldığını anlamak için gereken zamandır. Bu nedenle analistler bu sürece çok yakından dahil oluyor ve çeşitli iş uzmanları da dahil oluyor. Ve bu seçici olarak yapılır. Ve çok sayıda insanla toplantılar düzenleyerek, büyük anketler göndererek vb.
Kaliteli iş ve sistem analizi, bir depolama çekirdek modeli oluşturmanın anahtarıdır. Pek çok şeyi anlamanız gerekir: verilerin nerede (hangi sistemlerde) üretildiği, nasıl düzenlendiği, hangi iş süreçlerinde dolaştığı vb. Nitel analiz hiçbir sisteme zarar vermemiştir. Aksine, problemler anlayışımızdaki “boş noktalardan” kaynaklanmaktadır.

Bir veri modeli geliştirmek, yeni bir şey icat etme ve ortaya çıkarma süreci değildir. Aslında, şirketteki veri modeli zaten var. Ve tasarım süreci daha çok "kazılar" gibidir. Model, kurumsal verilerin "zemininden" nazikçe ve dikkatli bir şekilde gün ışığına çıkarılır ve yapılandırılmış bir forma bürünür.

Efsane 4. Şirketimizde iş o kadar dinamik ki ve her şey o kadar hızlı değişiyor ki, bir model yapmak bizim için işe yaramaz - sistemin bu bölümünü devreye almadan önce modası geçmiş olacak.
Aslında. Çekirdekteki kilit faktörün istikrar olduğunu hatırlayın. Ve hepsinden önemlisi, modelin topolojisi. Niye ya? Çünkü merkezi olan ve diğer her şeyi etkileyen bu bileşendir. Kararlılık, çekirdek modeli için de bir gerekliliktir. Model çok hızlı bir şekilde eski hale gelirse, yanlış tasarlanmıştır. Gelişimi için yanlış yaklaşımlar ve “oyunun kuralları” seçilmiştir. Bu aynı zamanda bir niteliksel analiz sorunudur. Kurumsal modelin kilit unsurları çok nadiren değişir.
Ama aklımıza “Ürünler” dizini yerine, örneğin şekerleme satan bir firma için “Tatlılar”, “Pastalar” ve “Börekler” yapmak geliyorsa. Ardından, mal listesinde pizza göründüğünde - evet, birçok yeni tablo girmeniz gerekecek. Ve bu sadece bir yaklaşım meselesi.

Efsane 5. Kurumsal bir model oluşturmak çok ciddi, karmaşık ve sorumlu bir iştir. Ve hata yapmak korkutucu.
Aslında. Çekirdek model, kararlı olmasına rağmen, hala “metalden dökülmüş” değildir. Diğer tasarım kararları gibi, yapısı da gözden geçirilebilir ve değiştirilebilir. Sadece onun bu kalitesini unutma. Ancak bu, üzerinde “nefes alamayacağınız” anlamına gelmez. Ve bu, işleme için planlanması gereken geçici çözümlerin ve "saplamaların" kabul edilemez olduğu anlamına gelmez.

Efsane 6. Bir veri kaynağımız varsa - örneğin, bir NSI sistemi (veya bir ana veri yönetim sistemi - MDM), o zaman kurumsal modele iyi bir şekilde karşılık gelmelidir (özellikle yakın zamanda tasarlanmışsa ve satın almak için zamanı yoksa). “yan etkiler”, “gelenekler” ve geçici binalar). Görünüşe göre bu durumda - bir çekirdek modeline ihtiyacımız yok mu?
Aslında. Evet, bu durumda, depolama çekirdek modelinin yapımı büyük ölçüde kolaylaştırılmıştır - çünkü üst düzey hazır bir kavramsal model izliyoruz. Ama hiç de dışlanmıyor. Niye ya? Çünkü belirli bir sistemin modelini oluştururken, belirli kurallar geçerlidir - ne tür tablolar kullanılacak (her varlık için), verilerin nasıl sürümlendirileceği, geçmişi hangi ayrıntı düzeyinde tutulacağı, hangi meta nitelikler (kullanılacak teknik alanlar), vb. .

Ek olarak, sahip olduğumuz NSI ve MDM sistemi ne kadar harika ve kapsamlı olursa olsun, kural olarak, diğer muhasebe sistemlerinde “yaklaşık aynı” yerel dizinlerin varlığıyla ilgili nüanslar olacaktır. Ve bu sorun, hoşumuza gitsin ya da gitmesin, depoda çözülmek zorunda kalacak çünkü raporlama ve analizler burada toplanıyor.

Birincil veri katmanı (veya tarihselleştirilebilir evreleme veya operasyonel katman)

Üzerinde Birincil Veri Katmanı olarak belirlenmiştir. Bu bileşenin rolü: kaynak sistemlerle entegrasyon, birincil verilerin yüklenmesi ve depolanması ve ayrıca ön veri temizliği - kaynakla "etkileşim arayüzü anlaşmasında" sabitlenen biçim-mantıksal kontrol kurallarına uygunluğun kontrolü.
Ek olarak, bu bileşen, kaynağın verilerdeki değişiklikleri izlemenize izin verip vermediğine ve nasıl (hangi kritere göre "yakalanabileceklerine" bakılmaksızın) - "gerçek değişiklik deltasını" vurgulayarak - depolama için çok önemli bir görevi çözer. ). Veriler evrelemeye girer girmez, meta niteliklerle işaretleme sayesinde delta seçimi sorunu diğer tüm katmanlar için zaten açıktır.

Bu katmandaki veriler, birincil verileri mümkün olduğunca orijinal biçimlerine yakın tutmak için kaynak sisteme mümkün olduğunca yakın yapılarda saklanır. Bu bileşenin bir diğer adı da "operasyonel katman"dır.
Neden yerleşik “evreleme” terimini kullanmıyorsunuz? Gerçek şu ki, daha önce, "büyük veri ve VLDB çağından" önce, disk alanı çok pahalıydı - ve genellikle birincil veriler, eğer saklanırsa, yalnızca sınırlı bir süre içindi. Ve genellikle "evreleme" adı denir temizlenebilir tampon.
Şimdi, teknoloji bir adım öne çıktı - ve yalnızca tüm birincil verileri saklamayı değil, aynı zamanda onları yalnızca mümkün olan ayrıntı düzeyiyle tarihselleştirmeyi de karşılayabiliyoruz. Bu, verilerin büyümesini kontrol etmememiz gerektiği anlamına gelmez ve kullanım "sıcaklığına" bağlı olarak veri depolama maliyetini optimize ederek bilgi yaşam döngüsünü yönetme ihtiyacını ortadan kaldırmaz - yani. daha az talep gören "soğuk veri"nin daha ucuz medya ve depolama platformlarına taşınması.

Bize "tarihi sahneleme"nin varlığını veren şey:

• hata yapma olasılığı (yapılarda, dönüşüm algoritmalarında, geçmiş tutmanın ayrıntı düzeyinde) - depolama kullanılabilirlik bölgesinde tamamen tarihlenebilir birincil verilere sahip olduğumuzdan, tablolarımızı her zaman yeniden yükleyebiliriz;
• düşünmek için bir fırsat - havuzun gelişiminin bu yinelemesinde çekirdeğin büyük bir parçasının geliştirilmesiyle zaman alabiliriz, çünkü sahnelememizde, her durumda, olacaklar ve eşit bir zaman ufkuyla (bir “tarihin başlangıç ​​noktası” olacak);
• analiz olasılığı - artık kaynakta olmayan verileri bile kaydedeceğiz - orada üzerine yazılabilir, arşive gidebilir vb. – bizde, analiz için uygun kalırlar;
• bilgi denetimi olasılığı - en ayrıntılı birincil bilgiler sayesinde, indirmenin bizim için nasıl çalıştığını, sonunda bu sayıları aldığımızı anlayabileceğiz (bunun için ayrıca meta niteliklerle işaretlemeniz gerekir) ve indirmenin çalıştığı ilgili meta veriler - buna hizmet katmanında karar verilir).

"Tarihi sahneleme" inşasında ne gibi zorluklar ortaya çıkabilir:

• bu katmanın işlemsel bütünlüğü için gereksinimleri belirlemek uygun olacaktır, ancak uygulama bunun başarılmasının zor olduğunu göstermektedir (bu, bu alanda üst ve alt tabloların referans bütünlüğünü garanti etmediğimiz anlamına gelir) - bütünlük hizalaması sonraki işlemlerde gerçekleşir katmanlar;
• bu katman çok büyük hacimler içerir (depolamadaki en büyük - analitik yapıların tüm fazlalığına rağmen) - ve bu tür hacimleri hem yükleme hem de sorgular açısından idare edebilmeniz gerekir (aksi takdirde, ciddi şekilde düşürebilirsiniz) tüm depolamanın performansı).

Bu katman hakkında başka ne söylenebilir.
Öncelikle “uçtan uca yükleme süreçleri” paradigmasından uzaklaşırsak “kervan son deve hızında gidiyor” artık işimize gelmiyor ya da daha doğrusu “kervan” ilkesini bırakıp geçiş yapıyoruz. "konveyör" ilkesine göre: kaynaktan veri aldık - katmanınıza koyduk - bir sonraki kısmı almaya hazırız. Bu demektir
1) diğer katmanlarda işlemin gerçekleşmesini beklemiyoruz;
2) diğer sistemler tarafından veri sağlama programına bağlı değiliz.
Basitçe söylemek gerekirse, belirli bir bağlantı yöntemi aracılığıyla bir kaynaktan veri alan, deltayı kontrol eden, ayıklayan ve verileri evreleme hedef tablolarına koyan bir yükleme işlemi planlıyoruz. Ve bu kadar.

İkincisi, görünüşe göre, bu süreçler çok basit bir şekilde düzenlenmiştir - mantık açısından önemsiz olarak söylenebilir. Bu da, sistemimizdeki yükü azaltarak ve kaynakları bağlama sürecini hızlandırarak (geliştirme süresi) çok iyi optimize edilip parametrelendirilebilecekleri anlamına gelir.
Bunun olması için, bu bileşenin çalıştığı platformun teknolojik özelliklerini çok iyi bilmeniz gerekir - ve sonra çok etkili bir araç yapabilirsiniz.

Analitik vitrin katmanı

Vitrin katmanı ( Data mart katmanı), son kullanıcılara - insanlara veya sistemlere - verilerin hazırlanmasından ve sağlanmasından sorumludur. Bu seviyede, tüketicinin gereksinimleri mümkün olduğunca dikkate alınır - hem mantıksal (kavramsal) hem de fiziksel. Hizmet tam olarak ihtiyaç duyulanı sağlamalıdır - ne daha fazla, ne daha az.

Tüketici harici bir sistemse, kural olarak, ihtiyaç duyduğu veri yapılarını ve bilgi toplama kurallarını belirler. İyi bir yaklaşım, tüketicinin doğru veri toplamadan sorumlu olduğu yaklaşımdır. Hazırlanan veri ambarı, vitrini oluşturdu, artımlı veri toplama olanağı sağladı (sonraki delta değişikliklerinin seçimi için meta niteliklerle işaretleme) ve daha sonra tüketici sistemi bu vitrini nasıl kullandığını yönetir ve bundan sorumludur. Ancak bazı özellikler vardır: Sistemde veri toplama için aktif bir bileşen olmadığında, ya bir bütünleştirme işlevi görecek harici bir bileşene ihtiyaç duyulur ya da depolama, bir "entegrasyon platformu" olarak hareket edecek ve doğru artımlı veri yüklemesini sağlayacaktır. ayrıca – depolamanın dışında. Burada birçok nüans ortaya çıkıyor ve arayüz etkileşiminin kuralları her iki taraf tarafından da düşünülmeli ve anlaşılmalıdır (ancak, her zaman olduğu gibi, entegrasyon söz konusu olduğunda). Kural olarak, bu tür vitrinlere verilerin rutin olarak temizlenmesi/arşivlenmesi uygulanır (bu “geçiş verilerinin” uzun süre saklanması nadiren gereklidir).

Analitik görevler açısından en büyük önemi, "insanlar için" - daha doğrusu birlikte çalıştıkları BI araçları için - vitrinlerdir.
Bununla birlikte, harici özel sistemleri doldurmak için ne BI araçlarına ne de rutin işlemlere ihtiyaç duymayan "özellikle ileri düzey kullanıcılar" - analistler, veri bilimciler - kategorisi vardır. Kendi takdirine bağlı olarak tablolar ve dönüşümler oluşturabilecekleri bir tür "ortak vitrin" ve "kendi sanal alanına" ihtiyaçları var. Bu durumda arşivin sorumluluğu, bu ortak data martların mevzuata uygun olarak doldurulmasını sağlamaktır.
Ayrı olarak, Veri Madenciliği araçları - derin veri analizi gibi tüketicileri ayırabiliriz. Bu araçların kendi veri hazırlama gereksinimleri vardır ve veri bilimcileri tarafından da kullanılır. Depo için, görev azaltılmıştır - yine, üzerinde anlaşmaya varılmış bir formattaki belirli vitrinleri indirmek için hizmeti desteklemek.

Ancak, analitik vitrinlere geri dönelim. Bu veri katmanında depolama tasarımcıları açısından ilgi çekici olan onlardır.
Bana göre, neredeyse tüm BI platformlarının artık “keskinleştirilmiş” olduğu veri marketlerini tasarlamak için zamana göre test edilmiş en iyi yaklaşım, Ralph Kimball'un yaklaşımıdır. O isimle tanınır boyutlu modelleme – çok boyutlu modelleme. Bu konuda çok sayıda yayın var. Örneğin, temel kurallar Marga Ross'un yayınında bulunabilir. Ve tabii ki çok değişkenli modellemenin gurularından tavsiyelerde bulunabilirsiniz. Bir başka yararlı kaynak da Kimball's Tips.
Mağaza vitrinleri yaratmaya yönelik çok boyutlu yaklaşım, hem yöntem savunucuları hem de önde gelen yazılım satıcıları tarafından o kadar iyi tanımlanmış ve işlenmiştir ki, burada herhangi bir ayrıntı üzerinde durmanın bir anlamı yoktur - orijinal kaynak her zaman tercih edilir.

Tek bir vurgu yapmak istiyorum. "Raporlama ve analitik" farklıdır. "Ağır raporlama" var - dosya şeklinde oluşturulan ve sağlanan dağıtım kanalları aracılığıyla kullanıcılara teslim edilen önceden sipariş edilmiş raporlar. Ve bilgi panelleri var - BI panoları. Temel olarak, bunlar web uygulamalarıdır. Ve bu uygulamaların yanıt süresi gereksinimleri, diğer herhangi bir web uygulamasıyla aynıdır. Bu, BI paneli için normal yenileme süresinin dakika değil, saniye olduğu anlamına gelir. Bir çözüm tasarlarken bunu akılda tutmak önemlidir. Buna nasıl ulaşılır? Standart optimizasyon yöntemi: Tepki süresinin nelerden oluştuğuna ve neleri etkileyebileceğimize bakarız. En çok neye zaman harcıyorsun? Veritabanının fiziksel (disk) okuması, ağ üzerinden veri aktarımı için. İstek başına okunan ve iletilen veri miktarı nasıl azaltılır? Cevap açık ve basittir: ya verileri toplamanız ya da sorguya katılan büyük olgu tablolarına bir filtre uygulamanız ve büyük tabloların birleşimini hariç tutmanız gerekir (olgu tablolarına yapılan referanslar yalnızca boyutlardan geçmelidir).

BI ne için? Nasıl uygun? Çok değişkenli model neden etkilidir?
BI, kullanıcının sözde "ad hoc sorguları" gerçekleştirmesine izin verir. Bunun anlamı ne? Bu, talebi önceden tam olarak bilmediğimiz, ancak kullanıcının hangi bölümlerde hangi göstergeleri talep edebileceğini bildiğimiz anlamına gelir. Kullanıcı, uygun BI filtrelerini seçerek böyle bir sorgu oluşturur. İş zekası geliştiricisinin ve vitrin tasarımcısının görevi, çok fazla verinin istendiği ve uygulamanın "askıda kaldığı" bir durumdan kaçınarak, verilerin filtrelenmesi veya toplanması için böyle bir uygulama işlem mantığı sağlamaktır. Genellikle toplu rakamlarla başlarlar, ardından daha ayrıntılı verilere girerler, ancak bu arada gerekli filtreleri ayarlarlar.

Sadece "doğru yıldızı" oluşturmak ve BI için uygun bir yapı elde etmek her zaman yeterli değildir. Bazen denormalizasyonu bir yere (yükü nasıl etkileyeceğine bakarken) ve ikincil vitrinler ve kümeler yapmak için bir yere uygulamanız gerekir. İndeksler veya projeksiyonlar eklenecek bir yer (DBMS'ye bağlı olarak).

Böylece, “deneme yanılma” yoluyla, hem DBMS hem de BI platformunun özelliklerini ve ayrıca kullanıcının veri sunumu gereksinimlerini dikkate alacak olan BI için en uygun yapıyı elde edebilirsiniz.
"Çekirdekten" veri alırsak, doğrudan kaynak sistemlerden alınan birincil verilerin karmaşık işlenmesini etkilemeden vitrinlerin bu tür işlenmesi yerel nitelikte olacaktır - verileri yalnızca BI için uygun bir biçime "kaydırırız". Ve bunu birçok kez, farklı şekillerde, farklı gereksinimlere göre yapmayı göze alabiliriz. Bunu çekirdek verileri temelinde yapmak, "birincil" (yapısı ve kuralları, bildiğimiz gibi, "yüzebilir") derlemekten çok daha kolay ve hızlıdır.

hizmet katmanı

Hizmet katmanı ( - Hizmet Katmanı), çeşitli depolama katmanlarındaki verileri işlemek için kullanılabilen ortak (hizmet) işlevlerin uygulanmasından sorumludur - yük yönetimi, veri kalitesi yönetimi, sorun tanılama ve izleme araçları vb.
Bu seviyenin varlığı, depolamada şeffaflık ve yapılandırılmış veri akışları sağlar.

Bu katman iki veri depolama alanı içerir:

• meta veri alanı - veri yükleme kontrol mekanizması için kullanılır;
• veri kalitesi alanı - çevrimdışı veri kalitesi kontrollerini uygulamak için (yani, doğrudan ETL süreçlerinde yerleşik olmayanlar).

Yük yönetimi sürecini farklı şekillerde oluşturabilirsiniz. Olası yaklaşımlardan biri şudur: tüm depolama tabloları setini modüllere böldük. Bir modüle yalnızca bir katmanın tabloları dahil edilebilir. Her modülde bulunan tablolar ayrı bir sürecin parçası olarak yüklenir. diyelim kontrol süreci . Kontrol sürecinin başlatılması kendi programına göre yapılır. Kontrol süreci, her biri bir hedef tablo yükleyen ve ayrıca bazı ortak adımlar içeren atomik süreçlere çağrıları düzenler.
Açıkçası, evreleme tablolarını kaynak sistemlere veya daha doğrusu bağlantı noktalarına göre modüllere bölmek yeterlidir. Ancak çekirdek için bunu yapmak zaten daha zor - çünkü. orada veri bütünlüğünü sağlamamız gerekiyor, bu da bağımlılıkları hesaba katmamız gerektiği anlamına geliyor. Onlar. çözülmesi gereken çatışmalar olacaktır. Ve bunları çözmenin farklı yolları var.

Yük yönetiminde önemli bir nokta, hata işlemeye yönelik birleşik bir yaklaşımın geliştirilmesidir. Hatalar kritiklik düzeyine göre sınıflandırılır. Kritik bir hata oluştuğunda, işlem durdurulmalı ve mümkün olan en kısa sürede, çünkü. oluşumu, depolamada veri bozulmasına yol açabilecek önemli bir sorunu gösterir. Bu nedenle, yük yönetimi sadece süreçleri başlatmakla kalmaz, aynı zamanda onları durdurmak ve zamansız (yanlışlıkla) başlatmayı önlemekle ilgilidir.

Servis katmanının çalışması için özel bir metadata yapısı oluşturulur. Bu alan, yükleme işlemleri, yüklenen veri kümeleri, artışı sürdürmek için kullanılan kontrol noktaları (hangi işlemin hangi noktaya kadar okuduğu) ve sistemin çalışması için gerekli diğer hizmet bilgileri hakkında bilgileri depolayacaktır.
Tüm katmanlardaki tüm hedef tabloların, biri bu dizeyi güncelleyen işlemin kimliği olan özel bir meta-alan seti ile işaretlendiğini unutmamak önemlidir. Bir havuz içindeki tablolar için, bu süreç işaretlemesi, sonradan delta değişikliklerini çıkarmak için birleşik bir yol sağlar. Birincil veri katmanına veri yüklerken durum daha karmaşıktır - yüklenen farklı nesneler için delta çıkarma algoritması farklı olabilir. Öte yandan, kabul edilen değişiklikleri işlemenin mantığı ve çekirdek ve vitrinler için hedef tablolara yuvarlanma mantığı, her şeyin oldukça önemsiz olduğu aşamaya göre çok daha karmaşıktır - yeniden kullanılabilir tipik adımları parametreleştirmek ve düşünmek kolaydır ( prosedürler).

Buradaki görevi tam olarak bu konuyu kapsayacak şekilde belirlemedim - yükleme organizasyonu - sadece dikkat edilmesi gereken aksanları koyuyorum.
Yukarıdaki yaklaşım seçeneklerden sadece biridir. O oldukça uyarlanabilir. Ve onun "kavramsal prototipi" Toyota konveyörü ve "tam zamanında" sistemiydi. Onlar. Sadece "gecelik veri yükleme" yaygın paradigmasından uzaklaşıyoruz ve gün boyunca küçük porsiyonlar halinde yükleme yapıyoruz - çünkü veriler çeşitli kaynaklarda hazır: gelen, yüklenendir. Aynı zamanda, çalışan birçok paralel işlemimiz var. Ve yeni verilerin "sıcak kuyruğu" sürekli olarak "yanıp söner" - ve hatta bir süre sonra söner. Bu özelliği dikkate almalıyız. Ve gerekirse, her şeyin zaten ayrılmaz olduğu özel vitrinler "dilimler" oluşturmak için. Onlar. aynı anda hem verimlilik hem de tutarlılık (bütünlük) elde etmek imkansızdır. Bir dengeye ihtiyacımız var - bir yerde bir şey önemli, başka bir yerde.

Günlüğe kaydetme ve izleme araçları sağlamak son derece önemlidir. İyi bir uygulama, farklı parametreler ayarlayabileceğiniz ve bir bildirim sistemi - belirli olaylara abonelik - kurabileceğiniz yazılı olayları kullanmaktır. Çünkü sistem yöneticisinin müdahalesi gerektiğinde, bunu mümkün olan en kısa sürede bilmesi ve gerekli tüm teşhis bilgilerini alması çok önemlidir. Günlükler, olay sonrası sorun analizi için ve ayrıca sistem arızaları olaylarını araştırmak için de kullanılabilir. veri kalitesi.

Ambar veri modellerini tasarlama ve bakımını yapma

Veritabanının dahil olduğu (ve özellikle bir depoda) herhangi bir sistemi geliştirirken veri modellerinin tasarımına dikkat etmek neden önemlidir? Neden bir metin düzenleyicide bile herhangi bir yere bir dizi tablo atmıyorsunuz? Neden bu resimlere ihtiyacımız var?
İşin garibi, deneyimli geliştiriciler bile bu tür soruları gündeme getiriyor.
Aslında evet, hiçbir şey tabloları çizmenizi ve onları kullanmaya başlamanızı engellemez. Eğer ... eğer aynı zamanda kafadaysa (!) Geliştirici, şekillendirdiği yapının uyumlu bir genel resmine sahiptir. Ya birden fazla geliştirici varsa? Peki ya bu tabloları başka biri kullanacaksa? Ama ya zaman geçerse - bir kişi bu alanı terk eder ve sonra tekrar ona dönerse?

Modelsiz anlamak mümkün mü? Temel olarak, yapabilirsiniz. Ve bunu anlamak ve "bir kağıt parçası üzerindeki resimleri tahmin etmek" ve verileri "süpürmek - yerleştirmek" için. Ancak hazır bir yapıyı - bir veri modelini - kullanmak çok daha kolay, daha net ve daha hızlıdır. Ve ayrıca “yapısının mantığını” anlamak için - yani. Oyunun ortak kurallarının olması güzel olurdu.

Ve en önemli şey o bile değil. En önemlisi, bir model tasarlarken, (sadece seçenekler olmadan!) Konu alanını, veri yapısının özelliklerini ve çeşitli iş durumlarında kullanımlarını daha yakından ve derinlemesine incelemek zorunda kalıyoruz. Karmaşık diye kolayca “bir kenara iteceğimiz”, işaretlerimizi atarak “bulanıklaştırdığımız” sorular, tasarım modeli - analiz ve tasarım sırasında ve daha sonra değil - raporlar oluşturduğumuzda ve “uyumsuzları nasıl azaltacağımızı” ve her seferinde “tekerleği yeniden icat ettiğimizi” düşündüğümüzde şimdi belirlemek ve karar vermek zorunda kalacağız.

Bu yaklaşım, kırılmaz sistemler oluşturmayı mümkün kılan mühendislik uygulamalarından biridir. Açıkça düzenlenmiş, şeffaf, geliştirmesi kolay ve "kırılganlık sınırları" hemen görülebildiği için, yeni gereksinimler ortaya çıktığında ve yeniden tasarım için gereken süre (gerekirse) için "felaketin ölçeği" daha doğru bir şekilde değerlendirilebilir. .
Bu nedenle, veri modeli, sistemin geliştirilmesi sırasında korunması gereken ana eserlerden biridir. İyi bir şekilde, her analist, geliştirici vb. için “masada” olmalıdır. – sistem geliştirme projelerinde yer alan herkes.

Veri modelleri tasarlamak ayrı, çok kapsamlı bir konudur. Depolama tasarımına iki ana yaklaşım vardır.
Yaklaşım çekirdek için iyidir "varlık-ilişki" - konu alanı, daha doğrusu seçilen alanı temel alınarak normalleştirilmiş bir (3NF) model oluşturulduğunda. Burada yukarıda tartışılan aynı “kurumsal model” oynuyor.

Analitik vitrinler tasarlanırken uygun çok boyutlu model . Bu yaklaşım, iş kullanıcılarının anlayışına çok uygundur. bu, insan algısı için basit ve kullanışlı bir modeldir - insanlar, metriklerin (göstergelerin) anlaşılır ve tanıdık kavramları ve analiz edildikleri bölümlerle çalışır. Ve bu, gereksinimleri toplama sürecini basit ve net bir şekilde oluşturmamızı sağlar - çeşitli departman temsilcileriyle iletişim kurarak bir dizi "kesme ve gösterge matrisi" çizeriz. Ve sonra onu tek bir yapıya getiriyoruz - “analiz modeli”: “ölçüm veriyolu”nu oluşturuyoruz ve üzerlerinde tanımlanan gerçekleri belirliyoruz. Bu arada, hiyerarşiler ve toplama kuralları üzerinde çalışıyoruz.

Ayrıca, VTYS'nin özelliklerini dikkate alarak optimizasyon öğeleri ekleyerek fiziksel modele geçmek çok kolaydır. Örneğin, Oracle için bölümleme, bir dizi dizin vb. Vertica için diğer teknikler kullanılacaktır - sıralama, segmentasyon, bölümleme.
Özel denormalizasyon da gerekli olabilir - sorguların performansını iyileştirdiğimiz, ancak aynı zamanda veri güncellemesini karmaşıklaştırdığımız için verilere kasıtlı olarak fazlalık eklediğimizde (çünkü yedeklilik sırasında dikkate alınması ve desteklenmesi gerekir). veri yükleme işlemi). Belki de performansı artırmak için ek toplu tablolar oluşturmamız veya Vertica'daki projeksiyonlar gibi ek DBMS özelliklerini kullanmamız gerekecek.

Bu nedenle, ambar verilerini modellerken aslında birkaç sorunu çözüyoruz:

• görev, temel sistem ve iş analizinin kavramsal (mantıksal) bir modelini oluşturmaktır - konu alanının incelenmesi, ayrıntılara derinleştirilmesi ve "canlı verilerin" nüanslarını ve iş dünyasında kullanımlarını dikkate almak;
• bir analiz modeli oluşturma görevi - ve ardından vitrinlerin kavramsal (mantıksal) bir modeli;
• fiziksel modeller oluşturma görevi, veri artıklığı yönetimi, sorgular ve veri yükleme için VTYS'nin özelliklerini dikkate alan optimizasyondur.

Kavramsal modeller geliştirirken, bir veritabanı yapısı tasarladığımız belirli bir VTYS'nin özelliklerini dikkate almayabiliriz. Ayrıca, farklı DBMS için birkaç fiziksel model oluşturmak için bir kavramsal model kullanabiliriz.

Özetleyelim.

• Bir veri modeli bir dizi “güzel resimler” değildir ve onu tasarlama süreci onları çizme süreci değildir. Model, konu alanındaki anlayışımızı yansıtır. Ve derleme süreci, çalışma ve araştırma sürecidir. Zamanın boşa harcandığı yer burasıdır. Ve hiç de “çizmek ve renklendirmek” için değil.
• Bir veri modeli, bir tasarım eseridir, ekip üyeleri arasında yapılandırılmış bir şekilde bilgi paylaşmanın bir yoludur. Bunu yapmak için herkes tarafından anlaşılabilir (bu, gösterim ve açıklama ile sağlanır) ve erişilebilir (yayınlanır) olmalıdır.
• Veri modeli bir kez oluşturulup dondurulmaz, sistem geliştirme sürecinde oluşturulur ve geliştirilir. Gelişimi için kuralları kendimiz belirledik. Ve onları nasıl daha iyi, daha basit, daha verimli hale getireceğimizi görürsek değiştirebiliriz.
• Veri modeli (fiziksel), optimizasyona yönelik bir dizi en iyi uygulamayı birleştirmenize ve kullanmanıza olanak tanır - ör. bu VTYS için halihazırda çalışmış olan teknikleri kullanın.

Veri ambarı projelerinin özellikleri

Şirketin veri ambarları kurduğu ve geliştirdiği projelerin özellikleri üzerinde duralım. Bir de onlara mimari yönün etkisi açısından bakalım. Bu tür projeler için ve en başından beri mimari inşa etmek neden önemlidir? Ve veri ambarı projesine esneklik kazandıran, işi sanatçılar arasında etkin bir şekilde dağıtmanızı sağlayan ve ayrıca sonucu tahmin etmeyi kolaylaştıran ve süreci daha öngörülebilir hale getiren iyi düşünülmüş bir mimarinin varlığıdır.

Veri Ambarı özel bir yazılımdır

Bir veri ambarı, kutulu bir çözüm değil, her zaman "özel bir geliştirme"dir. Evet, bir referans veri modeli, ortak kaynaklardan (örneğin, ERP sistemleri) önceden yapılandırılmış ETL süreçleri, bir dizi tipik BI gösterge tablosu ve raporu içeren sektöre özel BI uygulamaları vardır. Ancak pratikte, depolama nadiren uygulanır - bir "kutu" olarak. Yaklaşık 10 yıldır depolama ile çalışıyorum ve hiç böyle bir hikaye görmemiştim. Şirketin benzersiz özellikleriyle ilgili her zaman nüanslar vardır - hem iş hem de BT ortamı. Dolayısıyla çözümü sağlayan “satıcı”nın mimariyi sağlayacağını ummak biraz pervasızlık olur. Bu tür sistemlerin mimarisi genellikle organizasyonun kendi içinde olgunlaşır. Veya projenin ana yüklenicisi olan müteahhit firmanın uzmanları tarafından oluşturulur.

Veri ambarı bir entegrasyon projesidir

Veri ambarı, birçok kaynak sistemden gelen bilgileri yükler ve işler. Ve onlarla “dostça ilişkiler” sürdürmek için onlara karşı son derece dikkatli olmanız gerekir. Diğer şeylerin yanı sıra, kaynak sistemler üzerindeki yükü en aza indirmek, “kullanılabilirlik ve erişilemezlik” pencerelerini dikkate almak, mimarilerini dikkate alarak etkileşim arayüzlerini seçmek vb. Ardından, depolama mümkün olan en kısa sürede ve gerekli sıklıkta veri toplayabilecektir. Aksi takdirde, en operasyonel frekansla güncellenmeyen bir yedekleme devresine "aktarılırsınız".
Ayrıca "insan faktörü" de dikkate alınmalıdır. Entegrasyon sadece makinelerin etkileşimi değildir. Aynı zamanda insanlar arasındaki iletişimdir.

Veri Ambarı bir ekip projesidir

Büyük bir şirkette, böyle bir sistem nadiren yalnızca bir ekip tarafından yapılabilir. Kural olarak, burada her biri belirli bir sorunu çözen birkaç ekip çalışır.

Mimari, bütünlüğünü korurken ve aynı işlevselliğin farklı yerlerde, farklı kişiler tarafından tekrarlanmasından kaçınırken, paralel çalışmalarını düzenleme imkanı sağlamalıdır. Gereksiz işçilik maliyetlerine ek olarak, bu tür tekrarlar daha sonra verilerde tutarsızlıklara yol açabilir.

Ek olarak, genellikle dağınık olan bu kadar çok insan ve ekip sistem geliştirme sürecine dahil olduğunda, kaçınılmaz olarak şu soru ortaya çıkar: aralarında iletişim ve bilgi etkileşimi nasıl kurulur. Ne kadar standart ve anlaşılır yaklaşımlar ve uygulamalar kullanılırsa, bu tür işleri kurmak o kadar kolay, kullanışlı ve verimli olur. Ve dahil olmak üzere, aralarında 1 numaralı veri ambarları için veri modelleri olan "çalışan eserler" in bileşimi hakkında düşünmeye değer (önceki bölüme bakın).

Veri ambarı diğer sistemlere göre daha uzun ömürlüdür

Açıklığa kavuşturmama izin verin - ifade, ana kaynaklarla entegre, tarihsel verilere sahip ve şirketin birçok bölümüne bilgi ve analitik hizmetler sağlayan "canlı", çalışan bir depolama için doğrudur.

Buna inanmak için ne gibi gerekçelerim var?
İlk olarak, bir depo inşa etmek çok kaynak yoğun bir süreçtir: ekipmanın fiili maliyetlerine, gerekli teknolojik yazılım ve geliştirme lisanslarına ek olarak, şirketin neredeyse tüm sistemleri ve bölümleri de buna dahil olur. Tüm bu süreci sıfırdan tekrarlamak çok cesur bir girişimdir.

İkincisi, eğer depolama doğru mimariye sahipse, o zaman hem kaynak sistemlerin değişmesine, hem de son kullanıcılardan yeni gereksinimlerin ortaya çıkmasına ve veri hacimlerinin büyümesine kolayca dayanabilir.
Mimari doğruysa, bilgi akışları şeffafsa, böyle bir sistem, etkiyi değerlendirmedeki zorluklar nedeniyle değişiklik yaparken bir stupor durumunda kalma riski olmadan uzun süre geliştirilebilir.

Kademeli yinelemeli geliştirme

Müşterinin, depolama ile ilgili hikayeye dahil olmak isteyeceği son şey, tam kurumsal veri modeli tasarlanana, tüm kaynaklar tam olarak bağlı olana kadar, bir veya iki yıl boyunca gereksinimlerini dondurmaktır.

Müşterilerin gözünde veri ambarı genellikle mutlak bir canavar gibi görünür - sistem geliştirmenin görevleri, hedefleri ve ufku çok hacimlidir. Ve çoğu zaman Müşteri, “bütçesi pahasına” BT departmanının bazı “kendi görevlerini” çözeceğinden korkar. Ve yine, insanlar arasındaki etkileşim sorunu ve birinin konumunu sakince ifade etme ve müzakere etme yeteneği sorunuyla karşı karşıyayız.

Yetkili mimari yaklaşımlar, sonuç vermeye başlamadan önce birkaç yıl boyunca “geliştirmeye” girmeden, işlevselliği kademeli olarak artırarak sistemi yinelemeli olarak geliştirmenize izin verir.

Unutulmamalıdır ki "mucizeler olmaz" - ve "başlangıç" da zaman alır. Depolar için oldukça büyük olabilir - çünkü bunlar büyük miktarda veridir, bu geçmiş verilerdir - bilgi işleme kurallarının mevcut olanlardan farklı olabileceği eski dönemler için. Bu nedenle, analitik geliştirme, kaynak sistemlerle etkileşim ve gerçek veriler üzerinde yük testleri de dahil olmak üzere bir dizi "deneme yanılma" için yeterli zaman gereklidir.

Veri Ambarı - "çoklu proje hikayesi"

Bir veri ambarı için tek bir iş müşterisini seçmek zordur. Ve (sebepsiz değil) bir depo inşaatı projesinin başarısındaki kilit faktörün şirket yönetiminin desteği olduğuna inanılıyor - doğrudan ilk kişi.
Bir depo nadiren tek bir proje içinde oluşturulur ve geliştirilir. Kural olarak, veri konsolidasyonu ve analitiği için çeşitli ihtiyaçlar vardır, bunların arkasında farklı Müşteriler ve kullanıcı grupları vardır. Bu nedenle, depo genellikle birkaç paralel proje çerçevesinde geliştirilir.

Yenilik ve kanıtlanmış çözümler dengesi

Depolama konusunun çok “eski” olmasına rağmen (böyle bir kelime BT gibi genç bir endüstri için geçerliyse) ve oldukça muhafazakar. Bununla birlikte, ilerleme durmuyor - ve pahalı ve yavaş diskler, pahalı bellek vb. nedeniyle daha önce var olan sınırlamalar. - şimdi kaldırıldı. Aynı zamanda, bazı mimari yaklaşımları yeniden gözden geçirmenin zamanı geldi. Ayrıca, bu hem teknolojik platformlar hem de bunlara dayalı uygulamalı sistemlerin mimarisi için geçerlidir.

Burada bir denge kurmak ve hem kaynaklara hem de depolanan bilgilere oldukça "çevre dostu" bir yaklaşımı sürdürmek önemlidir. Aksi takdirde, depoyu çok hızlı bir şekilde yarı yapılandırılmış bir "çöp dökümü" haline getirebilirsiniz; bu, eğer çözülebilirse, oldukça fazla çaba harcayacaktır.
Evet, daha fazla fırsatımız var, ancak bu, zamanla geliştirilen ve test edilen, nasıl ve neden kullanılacağı açık olan tüm uygulamaları reddetmemiz ve yalnızca sisli tarafından yönlendirilen “tüm ciddiyetlere dalmamız” gerektiği anlamına gelmez. “inovasyon” hayaleti.
Dengeyi korumak, yeni fırsatlara kapı açan yeni yöntemler ve yaklaşımlar kullanmak, ancak aynı zamanda kimsenin iptal etmediği acil sorunları çözmek için kanıtlanmış eski yöntemleri kullanmak anlamına gelir.
Uygulamalı çözümlerin geliştiricileri ve tasarımcıları olarak ne yapabiliriz? Öncelikle üzerinde çalıştığımız platformların teknolojik değişimlerini, kabiliyetlerini, özelliklerini ve uygulama sınırlarını bilmek ve anlamak.

Depolama için en kritik ve önemli teknoloji platformu olarak DBMS'ye bakalım.
Son zamanlarda, başlangıçta "evrensel" olarak oluşturulan ilişkisel veritabanlarında uzmanlaşmaya doğru açık bir kayma olmuştur. Uzun bir süredir, önde gelen satıcılar, farklı sınıfların (OLTP, DSS & DWH) uygulamaları için çeşitli seçenekler sunuyor. Ek olarak, metin, coğrafi veriler vb. ile çalışmak için ek fırsatlar vardır.

Ancak mesele bununla sınırlı değildi - başlangıçta belirli bir görev sınıfına odaklanan ürünler ortaya çıkmaya başladı - yani. özel DBMS. İlişkisel modeli kullanabilirler veya kullanmayabilirler. Önemli olan, başlangıçta yalnızca genel olarak "iş bilgilerinin" saklanması ve işlenmesi için değil, aynı zamanda belirli görevler için "keskinleştirilmiş" olmalarıdır.

Görünüşe göre, merkezileşme ve uzmanlaşma, periyodik olarak birbirinin yerini alan, gelişmeyi ve dengeyi sağlayan birbirini tamamlayan iki eğilimdir. Evrimsel (kademeli) kademeli gelişim ve kardinal değişikliklerin yanı sıra. Böylece, 90'larda Michael Stonebreaker, dünyanın veritabanları dünyasında başka bir devrime ihtiyaç duymadığı fikrini açıkça ortaya koyan 3. Nesil Veritabanı Manifestosu'nun yazarlarından biriydi. Bununla birlikte, 10 yıl sonra, DBMS dünyasında yeni bir çağın başlangıcı için ön koşulları açıkladığı - tam olarak uzmanlıklarına dayanarak - yayınladığı eserler yayınlamaktadır.
Yaygın evrensel DBMS'lerin, donanım platformlarındaki değişiklikleri veya uygulamaların daha iyi bir çözüm bulabileceğiniz sınıflara bölünmesini dikkate almayan “herkese uyan tek bir” mimari üzerine inşa edildiği gerçeğine odaklanıyor. evrensel gereksinimlerin uygulanması.
Ve bu fikir doğrultusunda bir takım projeler geliştirmeye başlar. Bunlardan biri, orijinal olarak veri depolama sınıfı sistemleri için özel olarak oluşturulmuş, paylaşılan hiçbir şey (SN) mimarisinde tasarlanmış sütunlu bir DBMS olan C-Store'dur. Bu ürün ayrıca HP Vertica olarak ticarileştirildi.

Görünüşe göre şimdi veri ambarlarının geliştirilmesi konusu yeni bir geliştirme döngüsüne girdi. Yeni teknolojiler, yaklaşımlar ve araçlar ortaya çıkıyor. Çalışmaları, testleri ve makul uygulamaları, gerçekten ilginç ve kullanışlı çözümler yaratmamızı sağlıyor. Ve bunları uygulamaya geçirin, geliştirmelerinizin gerçek işte kullanılmasının ve fayda sağlamanın tadını çıkarın.

sonsöz

Bu makaleyi hazırlarken öncelikle doğrudan veri ambarları ile çalışan mimarlar, analistler ve geliştiricilere odaklanmaya çalıştım. Ancak kaçınılmaz olarak “konuyu biraz daha genişlettiğim” ortaya çıktı - ve diğer okuyucu kategorileri görüş alanına girdi. Bazı noktalar tartışmalı görünecek, bazıları net değil, bazıları açık. İnsanlar farklıdır - farklı deneyimlere, geçmişlere ve pozisyonlara sahiptir.
Örneğin, yöneticilerin tipik soruları “ne zaman mimarları cezbederim?”, “Ne zaman mimarlık yapmalıyım?”, “Mimarlık – çok pahalı olmaz mı?” şeklindedir. bizim için oldukça garip geliyor (geliştiriciler, tasarımcılar), çünkü bizim için sistemin mimarisi onun doğuşuyla ortaya çıkıyor - fark edip etmememiz önemli değil. Ve projede bir mimarın resmi bir rolü olmasa bile, normal bir geliştirici her zaman “iç mimarına sırtını döner”.

İşin büyük şemasında, mimarın kim olduğu önemli değil, önemli olan birinin bu soruları sorması ve cevaplarını keşfetmesidir. Mimar açıkça seçiliyorsa, bu yalnızca sistemden ve gelişiminden öncelikli olarak onun sorumlu olduğu anlamına gelir.
Bu konuyla ilgili olarak “antifrajilite” konusu bana neden alakalı göründü?

"Kırılganlığa karşı korumanın benzersizliği, bilinmeyenle çalışmamıza, tam olarak ne yaptığımızı anlamadığımız koşullarda bir şeyler yapmamıza ve başarılı olmamıza izin vermesidir."/Nassim N.Taleb/

Bu nedenle, kriz ve yüksek derecede belirsizlik, mimari eksikliğin mazereti değil, ihtiyacı güçlendiren faktörlerdir.