Şirket ve lideri, yönetim hedeflerini bağımsız olarak seçer ve yapılan seçimden sorumludur.

Pirinç. 1.2. Kuruluşun personelinin bakış açısından sosyal ihtiyaçları gerçekleştirmenize izin veren bir hedefler sistemi

Pirinç. 1.4. Hiyerarşik organizasyon yönetim sistemindeki personel yönetimi işlevlerinin nesneleri ve taşıyıcıları

hedefler. Herhangi bir yapay sistem yaratmanın amacı, bir kişinin (kuruluş içindeki ve dışındaki insanlar), küçük bir grup, kolektif, devlet veya bir bütün olarak toplumun belirli bir bilinçli ihtiyacını karşılamaktır, bu nedenle "sistem" kavramı ikincildir. "ihtiyaç" kavramı.

Bir organizasyon sistemi olarak yönetim sistemi, düzenlilik ile ayırt edilir. CS ve OU'nun bireysel unsurlarının ve bölümlerinin eylemleri birbirine bağlıdır ve birbirine bağlıdır.Ancak, bir kuruluştaki bir kişi aynı anda bir düzen taşıyıcısıdır, kuruluşun hedefleri tarafından tanımlanan eylemleri gerçekleştirir ve kaosun ana unsuru, sistemin düzensizliğidir. Bir kişi olarak, birçok bireysel özelliğe sahiptir, kendi ihtiyaç ve hedefleri sistemine sahiptir, bu nedenle yönetimde "insan faktörünü" dikkate almanın önemi tartışılmazdır ve bu konunun karmaşıklığı çalışma ihtiyacını yaratır. bireyin sosyo-psikolojik özellikleri.

Yönetim teorisi ve pratiğinin belirli dönemlerde geliştirilmesi, yönetim sisteminin düzenini en üst düzeye çıkarmayı ve yönetim sorunlarını çözmeyi (örneğin, "Taylor'un bilimsel yönetimi") amaçladı, ancak bu yaklaşım beklendiği kadar etkili olmadı. Yeni olan her şeyin ortaya çıkmasından, sistemin tüm unsurlarının nicel ve nitel büyümesinden "sorumlu" olan bir kişinin inisiyatifi ve yaratıcılığı, organizasyon tarafından zincirlendi. Bu nedenle, daha fazla gelişme, sistemin düzeninin ve öğelerinin özgürlüğünün rasyonel bir kombinasyonunun yolunu izleyerek, çalışanların yaratıcı faaliyetlerini ve kuruluş tarafından faydalı kullanımını arttırır. Düzen ve kaosun oranı (çeşitli tezahürlerinde özgürlük), üretim türüne ve örgütsel ve yasal yönetim biçimine bağlıdır (Şekil 1.5).

Sistemleri incelemek, oluşturmak ve yönetmek için sistematik yaklaşım veya sistem Analizi.Özleri, yönetim sisteminin ve bireysel bölümlerinin bir bütün olarak, faaliyet ve geliştirme hedefleri, kaynaklar, yapı, süreçler ve diğer sistemlerle ilişkiler ile karakterize bağımsız bir fenomen olarak kabul edilmesinde kendini gösterir. Bu nedenle, herhangi bir sistemin sahip olması gerekir. hedef, Sahip olmak Kaynaklar ve olmak organize belirlenen hedefe ulaşmak için.

Rusya'daki işletmelerde ve firmalarda personel yönetimi, modern personel politikası kavramlarına, personel sorunlarına kapsamlı çözümlere, mevcut iyileştirmelere ve yeni personelle çalışma biçimleri ve yöntemlerine dayalı olarak tutarlılık ve eksiksizlik kazanmalıdır.

Karmaşık bir yaklaşım personel yönetimine, örgütsel ve ekonomik, sosyo-psikolojik, yasal, teknik, pedagojik ve diğer yönleri bütünlükleri ve sosyo-ekonomik faktörlerin belirleyici rolü ile ilişkileri içinde dikkate almayı içerir.

Sistem yaklaşımı personel yönetiminin bireysel yönleri arasındaki ilişkinin dikkate alınmasını yansıtır ve nihai hedeflerin geliştirilmesinde, bunlara ulaşmanın yollarını belirlemede, uygun bir yönetim oluşturmada ifade edilir.

üretimde personelle çalışmanın kapsamlı bir şekilde planlanmasını, düzenlenmesini ve teşvik edilmesini sağlayan bir yönetim mekanizması.

Pirinç. 1.5. PS'de düzen ve kaos oranı

Personel yönetim sisteminin bir takım özellikleri ve özellikleri vardır: karmaşıklık, bağlantıların olasılıklı doğası, bölünebilirlik, hiyerarşi, ortaya çıkma, dinamizm, kararlılık, çok kriter. Bu özellikle karmaşık bir sistemdir. Sistemin elemanlarının ve bağlantılarının sayısı çok fazladır (bazen hepsini tanımlamak zor veya imkansızdır). Tek tek öğeleri ve öğeler arasındaki ilişkileri değiştirmek, rastgele karakter. Kontrol sistemi bölünebilir ve çoğul, kendi aralarında belirli ilişkiler içinde olan alt sistemlere ve unsurlara bölünmüştür. O olur hiyerarşik, çok düzeyli, bireysel seviyeleri bir tabiiyet ilişkisi içindedir ve her eleman veya alt sistem, sistemin bileşen parçaları olarak dahil edilir. Sistemde, yeni niteliklerin ortaya çıkması sıçramalar ve sınırlar içinde gerçekleşir ve bu özellikte kendini gösterir. ortaya çıkma, ancak sistemin eski durumundan yeni durumuna görece kısa süreli bir geçiş süreci vardır ve sistemin bu özelliğine (yeteneğine) yeni nitelikler kazandırma ve yeni bir duruma geçme denilmektedir. dinamizm. Sistemin en önemli özelliği, istikrar, bu, bireysel geçiş durumları (süreçler) arasında sistemin aldığı gerçeğinde kendini gösterir. kararlı denge konumu ve bazı iç ve dış rahatsızlıklar bu denge durumunu bozamaz, bu nedenle sistem bu bozulmalara karşı duyarsızdır. Karmaşık sistem çok amaçlıdır. Bireysel hedeflere ulaşma derecesi farklıdır, bu nedenle personel yönetim sistemi olarak kabul edilir. polikriter, bu, yukarıda belirtildiği gibi, hedeflere ulaşmak ve işletme verimliliği için kriterleri sıralamayı gerektirir.

Yönetim, bir ekibin çalışmasını, çalışanların ihtiyaçlarını azami ölçüde karşılayacak, çalışmalarını etkinleştirmelerine ve işgücü verimliliğini artıracak şekilde organize etmek anlamına gelir. Burada özellikle önemli olan, firmaların ve işletmelerin işlerinin yönetimine personel katılımı sorunlarının çözümüdür.

Personel yönetiminin karmaşıklığı ve çok yönlülüğü, bu önemli sorunda birçok yön önermektedir. Aşağıdakileri ayırt edin

personel yönetiminin yönleri. Teknik ve teknolojik yön, belirli bir üretimin gelişme düzeyini, içinde kullanılan ekipman ve teknolojilerin özelliklerini, üretim koşullarını vb. Sorunun yasal yönü, personelle çalışırken iş mevzuatına uygunluk konularını içerir. Sosyo-psikolojik yaklaşım, personel yönetiminin sosyo-psikolojik desteği, çeşitli sosyolojik ve psikolojik prosedürlerin iş pratiğine getirilmesi konularını yansıtmayı mümkün kılar. Ve son olarak, pedagojik yön, personelin eğitimi ile ilgili sorunların çözümüdür.

Personel Yönetimi belirli hedeflenen eylemleri gerçekleştirme sürecinde gerçekleştirilir ve aşağıdaki ana aşamaları içerir: personel ile hedeflerin ve ana çalışma alanlarının belirlenmesi, üretimde personel ile çalışma sisteminin sürekli iyileştirilmesi; belirlenen hedeflere ulaşmak için araçların, biçimlerin ve yöntemlerin belirlenmesi, alınan kararların uygulanmasına ilişkin çalışmaların organizasyonu, planlanan faaliyetlerin uygulanması üzerinde koordinasyon ve kontrol.

ana alt sistemler personel yönetimi şunlardır:

1. Personel analizi, planlama ve tahmin alt sistemi. Ana görevi, nesnelerin ve yönetim yapılarının oluşturulması, gerekli mesleklere, uzmanlıklara ve niteliklere sahip personel ihtiyacının hesaplanmasıdır.

2. Personelin seçimi, yerleştirilmesi, değerlendirilmesi ve sürekli eğitimi için alt sistem. Buradaki ana görevler, gerekli personel ile tesislerin ve yönetim yapılarının yüksek kalitede sağlanması ve faaliyetlerinin etkin bir şekilde teşvik edilmesinin organizasyonudur.

3. Yüksek performanslı üretim ekipleri oluşturmak için bir dizi önlemin uygulanması amacıyla üretimde personelin rasyonel kullanımına yönelik alt sistem.

Sistemin önemli kısmı, prensipler ve yöntemler Personel Yönetimi. SU, onların yardımıyla OU'yu üretim sisteminin hedeflerine ulaşması için yönlendirir. İlkeler, yönetim teorisinin temel, başlangıç ​​noktaları ve yapısını, işleyiş mekanizmalarını ve örgüt kültürünü belirleyen kuruluşun faaliyetlerinin temel kurallarıdır. Yöntemler - bir nesnenin bir dizi teknik, yöntem veya eylem veya araştırma modu. İlkeler ve yöntemler değişmeden kalmaz, yönetim teorisi ve pratiği ile birlikte gelişir. İlkelerin ve yönetim yöntemlerinin seçimi, işletmenin dış ortamından etkilenir. Örneğin, Rus ekonomisinin piyasaya geçişi, uygulanan yönetim ilke ve yöntemleri sistemini ve özellikle personel yönetimini değiştirdi (Leninist bilimsel yönetim ilkelerinin reddedilmesine yol açtı).

Yönetimin temel ilkelerine, Personel yönetimi teorisi ve uygulaması için temel olan 1, şunları içerir: aşağıdakilerden oluşan planlama liderliği ilkesi: v tüm işlerin başlangıcının uzun bir dönem üretim gelişiminin yönlerinin, oranlarının ve oranlarının belirlenmesi olduğu gerçeği ve bu temelde personel politikasının planlanması ve bir personel yönetim stratejisinin geliştirilmesinin yanı sıra manevi ve maddi birleştirme ilkesi teşvikler. Personel yönetiminin önemli bir ilkesi de personelin kişisel ve iş niteliklerine göre seçilmesi ve yerleştirilmesi ilkesi olarak kabul edilmekte olup; enerjik, yaratıcı çalışanların sistematik seçimine dayalı personel değişimi; sürekli mesleki gelişim için koşulların sağlanması; her çalışanın hak, görev ve sorumluluklarının net tanımı; deneyimli ve genç işçi sayısı arasındaki doğru oran; faaliyetlerini ve kişisel niteliklerini değerlendirmek için haklı kriterlerin kullanımına dayalı olarak personelin mesleki ve mesleki terfisi için koşulların sağlanması; performansın doğrulanması ile personele duyulan güvenin birleşimi.

Büyük firmalarda personelin genel yönetimi için özel sorumluluk, genellikle personel yönetimi hizmetinde profesyonel olarak eğitilmiş personele verilir. Bu tür profesyonellerin firma stratejisinin uygulanmasına aktif olarak katkıda bulunmaları için, sadece kendi alanlarında bilgi ve yetkinliğe değil, aynı zamanda alt düzey yöneticilerin ihtiyaçlarının farkında olmalarına da ihtiyaçları vardır. Aynı zamanda, alt düzey yöneticiler personel yönetiminin özelliklerini, mekanizmasını, yeteneklerini ve eksikliklerini anlamıyorsa, İK uzmanlarının hizmetlerini tam olarak kullanamazlar. Bu nedenle, tüm liderlerin insanları yönetmenin yollarını ve yöntemlerini bilmesi ve anlaması önemlidir.

Sistematik bir yaklaşım, personel yönetim sisteminin birliği, uyarlanabilirliği ve gelişimi, yönetimin verimliliği ve optimalliği gibi ilkelerin kullanılmasını ifade eder. Aynı zamanda, yukarıda belirtildiği gibi, zaman içinde iki örnekle gösterilebilecek bir prensip değişkenliği vardır.

Yönetimin optimalliği ilkesi, yönetim kararları veya etkileri için en iyi seçeneği seçme ve uygulama arzusunu ifade eder, ancak yönetim uygulaması, kaynakların maliyetinin daha fazla iyileştirilmesi için kabul edilebilir bir çözüm veya yönetim etkisi aramanın rasyonel olduğunu kanıtlamıştır. çözüm, geliştirilmiş çözümün faydalarıyla telafi edilmez. Bu nedenle, optimallik genellikle kabul edilebilir en iyi çözümün aranması olarak anlaşılır, ancak kesin olarak optimal değildir.

Birçok sistemde tek adam yönetimi ilkesi ana olanlardan biridir, ancak birçok gelişmiş büyük şirkette, aşağıdaki yeni yönetim yapılarını uygulayarak bu ilkenin resmi kullanımını terk ettiler:

1. Şirketin birkaç başkanının aynı anda atanması

üst yönetim seviyesinin "bant genişliğini" artırmak için resmi olarak eşit haklar.

2. Bir çalışanın aynı anda birden fazla lidere tabi olduğu personel ve program-hedef yönetim yapılarının oluşturulması ve farklı yöneticilerin görevlerini yerine getirmek için önceliklerin kullanılması.

Temel ilkelere ek olarak, özel yönetim ilkeleri de ayırt edilir, örneğin, uygunluk ilkesi, hangi yönetimin çalışana yeterli yetkiyi devretmesi gerektiğine göre v sorumlu olduğu görevleri yerine getirebilir.

Personel politikalarının geliştirilmesinde uygulanan bir grup özel ilke aşağıda verilmiştir.

Bir kuruluşta bir personel yönetim sistemi oluşturmak için iki grup ilke vardır: bir personel yönetim sisteminin oluşturulması için gereksinimleri karakterize eden ilkeler ve bir personel yönetim sisteminin gelişim yönlerini belirleyen ilkeler (Tablo 1.2).

Bir personel yönetim sistemi oluşturma ilkeleri etkileşim içinde uygulanır ve bunların kombinasyonu, kuruluşun personel yönetim sisteminin işleyişi için özel koşullara bağlıdır.

Bilim ve uygulama, bir kuruluşun mevcut personel yönetim sisteminin durumunu incelemek, yeni bir sistem oluşturmak, haklı çıkarmak ve uygulamak için araçlar (yöntemler) geliştirmiştir.

Bu nedenle, personel yönetim sisteminde bir bütün olarak kullanılan ilkelerin doğru seçiminden ekip ve hepsinden önemlisi işletme yönetimi sorumludur ve v ayrı parçalar. Başkanın görevi, genel ve özel personel yönetimi ilkeleri sistemi oluşturmak ve zamanında düzeltmektir.

Sistemin bir sonraki en önemli unsuru, yasalara, düzenliliklere ve yönetim ilkelerine dayanan ve üretim sisteminin durumunu (teknoloji ve teknoloji düzeyi, sosyal, yasal gelişimi) dikkate alan personel yönetimi yöntemleridir. , psikolojik ilişkiler vb.), a ayrıca dış durum. Personel yönetimi yöntemleri çeşitlidir ve karmaşık bir şekilde kullanılır, birbirini karşılıklı olarak tamamlar ve belirli bir organizasyonda bulunan tek, bütünsel bir yönetim yöntemleri sistemi oluşturur. Genel metodolojik yaklaşımlar, personel yönetimi yöntemlerini tanımlamanıza ve sınıflandırmanıza izin verir. Aşağıdaki sınıflandırmayı kullanmak gelenekseldir.

Doğrudan yöntemler karar verme yetkisinin kullanılması ve onları karara uymaya zorlamak için yetkinin gücüyle astlarına belirli bir eylem tarzının dayatılmasından oluşur. Bu durumda icracının eylemleri açıkça tanımlanmıştır. Doğrudan yöntemler şunları içerir: idari ve yasal ve eğitim kurumu üzerinde yönlendirici bir etki mekanizmasının kullanılmasını ve bir astın eylemleri için disiplin ve maddi sorumluluğunu sağlayan örgütsel ve idari yöntemler. Bu yöntemler, medeni normlara, idari haklara, iş disiplinine, görev anlayışına, ayrıca talimatlara, düzenlemelere, tasarım ve teknolojik belgelere, ekipman çalışma kurallarına, güvenlik kurallarına, emirlere, talimatlara, talimatlara vb. Bu grup, yönetim organlarının yapısını oluşturma, personeli yönetme, norm ve standartları onaylama, emir ve talimat verme, personel işe alma, seçme ve yerleştirme, düzenlemeler, iş tanımları, standartlar geliştirme vb. yöntemlerini içerir. dolaylı yöntemler uygulayıcı tarafından karar vermek için koşullar yaratmak ve gerçekleştirilen eylemler için karar, motivasyon, maddi ve manevi sorumluluğun etkin seçimi için mekanizmalar kullanmak. Aynı zamanda, maddi ve manevi sorumluluk, çoğunlukla, işin başarısında astın çıkarı olarak hareket eder. Dolaylı yöntemler şunları içerir: ekonomik, sosyo-psikolojik ve ideolojik personel yönetimi yöntemleri.

Tablo 1.2 Bir kuruluşta personel yönetim sistemi oluşturma ilkeleri

İlke adı				İlkenin içeriği
1				2
Bir personel yönetim sisteminin oluşturulması için gereksinimleri karakterize eden ilkeler
Üretim hedeflerine göre personel yönetimi işlevlerinin koşulluluğu				Personel yönetimi fonksiyonları oluşturuldu v. keyfi olarak değil, üretimin ihtiyaç ve hedeflerine göre değişir.
İK fonksiyonlarının önceliği				Personel yönetim sisteminin alt sistemlerinin bileşimi, organizasyon yapısı, çalışanlar için gereksinimler ve sayıları, personel yönetimi işlevlerinin içeriğine, sayısına ve emek yoğunluğuna bağlıdır.
Optimallik oranı içi ve personel yönetimi bilgileri				Personel yönetim sistemini (fonksiyon içi) düzenlemeyi amaçlayan fonksiyonlar ile personel yönetiminin fonksiyonları arasındaki oranları belirler. (alt-fonksiyonlar)
Yönetimsel yönelimlerin optimal oranı				Üretimin işleyişini sağlamayı amaçlayan işlevlerle karşılaştırıldığında, personel yönetimi işlevinin üretim gelişimine yönelimini öngörme ihtiyacını belirler.
potansiyel taklitler				Bireysel çalışanların geçici emekliliği, herhangi bir yönetim işlevini yerine getirme sürecini kesintiye uğratmamalıdır. Bunu yapmak için, personel yönetim sisteminin her çalışanı, bir üst, alt çalışanın ve bir veya iki çalışanın işlevlerini taklit edebilmelidir. onların seviyesindeki çalışanlar
Ekonomik				Personel yönetim sisteminin en verimli ve ekonomik organizasyonunu, yönetim sistemi maliyetlerinin birim çıktı başına toplam maliyetler içindeki payının azalmasını ve üretim verimliliğinin artmasını varsayar. Personel yönetim sisteminin iyileştirilmesine yönelik tedbirler alındıktan sonra, yönetim maliyetleri artmışsa, bunların uygulanması sonucu elde edilen üretim sistemindeki etki ile örtüşmelidir.
ilerlemecilik				Gelişmiş yabancı ve yerli muadilleri ile personel yönetim sisteminin uyumu
	Perspektif	Bir personel yönetim sistemi oluştururken, kuruluşun gelişme beklentileri dikkate alınmalıdır.
	karmaşıklık	Bir personel yönetim sistemi oluştururken, yönetim sistemini etkileyen tüm faktörleri (yüksek makamlarla ilişkiler, sözleşme ilişkileri, kontrol nesnesinin durumu vb.)
	çabukluk	Personel yönetim sisteminin analizi ve iyileştirilmesi konusunda zamanında karar verme, sapmaları önleme veya derhal ortadan kaldırma
	Optimallik	Bir personel yönetim sisteminin oluşturulması için tekliflerin çok değişkenli çalışması ve belirli üretim koşulları için en rasyonel seçeneğin seçimi
	Basitlik	Personel yönetim sistemi ne kadar basitse, o kadar iyi çalışır, elbette personel yönetim sisteminin üretim zararına basitleştirilmesini ortadan kaldırır.
	Bilimsellik	Bir personel yönetim sisteminin oluşturulması için önlemlerin geliştirilmesi, yönetim alanındaki bilimin başarılarına dayanmalı ve piyasa koşullarında sosyal üretimin geliştirilmesi yasalarındaki değişiklikleri dikkate almalıdır.
	hiyerarşi	Personel yönetim sisteminin herhangi bir dikey bölümünde, temel özelliği "aşağı" (ayrıştırma, detaylandırma) ve "yukarı °" asimetrik bilgi aktarımı olan yönetim seviyeleri (yapısal bölümler veya bireysel yöneticiler) arasında hiyerarşik bir etkileşim olmalıdır. (toplama) yönetim sistemi aracılığıyla
	Özerklik	8 personel yönetim sisteminin herhangi bir yatay ve dikey bölümü, yapısal birimlerin veya bireysel yöneticilerin rasyonel özerkliği sağlanmalıdır.
	Tutarlılık	Dikey boyunca hiyerarşik bağlantılar arasındaki etkileşimin yanı sıra yatay olarak personel yönetim sisteminin nispeten özerk bağlantıları arasındaki etkileşim, genel olarak organizasyonun ana hedefleriyle tutarlı olmalı ve zaman içinde senkronize edilmelidir.
	konsantrasyon		İki yönde değerlendirilir: 1) ayrı bir alt bölümdeki çalışanların veya tüm personel yönetim sisteminin temel görevleri çözme konusundaki çabalarının yoğunlaştırılması ve 2) tekrarlamayı ortadan kaldıran personel yönetim sisteminin bir alt bölümünde homojen işlevlerin yoğunlaşması.
	uzmanlık		Personel yönetim sisteminde iş bölümü (yöneticilerin, uzmanların ve diğer çalışanların emeği tahsis edilir). Homojen işlevlerin yerine getirilmesinde uzmanlaşmış ayrı bölümler oluşturulur.
	paralellik		Bireysel yönetim kararlarının eş zamanlı uygulanmasını içerir, personel yönetiminin verimliliğini arttırır.
	Uyarlanabilirlik (esneklik)		Personel yönetim sisteminin, kontrol nesnesinin değişen hedeflerine ve çalışma koşullarına uyarlanabilirliği anlamına gelir.
	süreklilik		Personel yönetim sistemini farklı seviyelerde ve farklı uzmanlar tarafından geliştirmek için genel bir metodolojik temel alır, standart tasarımları
	süreklilik		Personel yönetim sistemi veya departman çalışanlarının çalışmalarında kesinti olmaması, belgelere harcanan sürenin azaltılması, teknik kontrollerin kesinti süresi vb.
	Ritim		Düzenli aralıklarla aynı miktarda işin yapılması ve personel yönetimi işlevlerinin tekrarının düzenliliği
	düzlük		Belirli bir çözüm geliştirmek için gerekli bilgilerin düzenliliği ve amaçlılığı. Yatay ve dikey olabilir (fonksiyonel birimler arasındaki ilişki ve farklı yönetim seviyeleri arasındaki ilişki)

Ekonomik yöntemler, ekonomik teşvikler ve faaliyet koşulları yoluyla icracılar üzerindeki etkiyi kullanır. Yöntemler, etkili bir çözüm veya davranış seçiminde ekonomik (maddi) çıkara dayanmaktadır. Ekonomik yöntemler grubu, teknik ve ekonomik analiz ve gerekçelendirme, planlama ve tahmin, maddi teşvikler, fiyatlandırma, vergilendirme, ekonomik normlar ve standartlar, kredi, analiz yöntemleri ve bir personel yönetim sisteminin inşasını içerir (Tablo 1.3). ve diğerleri Sosyo-psikolojik yöntemler, işçinin davranışını doğru yönde değiştirmeyi mümkün kılan ahlaki sorumluluk ve sosyo-psikolojik tutumlar sistemi aracılığıyla sanatçıyı etkiler. Yöntemlerin içerik tarafı, astların yaratıcı faaliyetlerini uygulama, ekibin olumlu bir sosyo-psikolojik iklimini oluşturma, sosyal ve psikolojik analiz, sosyal planlama, yetki devri, yönetime çalışan katılımı, kariyer planlaması ve çalışan büyümesi, ahlaki teşvikler, gelenekler, liderlik tarzı ve vesaire. İdeolojik yöntemler de motive edicidir. ve ahlaki ve politik sorumluluk sistemi, görev duygusu, vatan sevgisi yoluyla icracıları etkiler. Bunlar arasında propaganda, ajitasyon, siyasi ve sosyal faaliyeti teşvik etme yöntemleri, çalışma ahlakı eğitimi, eleştiri ve özeleştiri, siyasi eğitim ve kendi kendine eğitim, siyasi sorumluluk vb. Komünist Parti tarafından ülke ekonomisinin liderliği, ideolojik yöntemler personel yönetimi yöntemlerinin cephaneliğinden kayboldu. Bir kişi olarak çalışan, emek faaliyetine ve başarısına az ya da çok yansıyan belirli bir ideolojinin ve siyasi görüşlerin taşıyıcısıdır. Bu yöntemler, işletmenin ideolojisine, misyonuna, organizasyon kültürüne ve stratejisine yansıyan iş görüşlerini desteklemek için kullanılır. Ajitasyon, işletmenin karşılaştığı sorunları çözmek için toplu ve bireysel işçileri etkilemenin etkili bir yöntemi olarak hareket eder ve emek ahlakı oluşturma yöntemleri, önemli görevlerden birinin - yüksek ahlaki niteliklere sahip işçilerin eğitimi - çözülmesine yardımcı olur.

Çalışanların sosyo-demografik gruplara göre dağılımı

Herhangi bir temelde birleşmiş bireysel çalışanların toplamı

Kuruluşta istihdam edilen ve belirli özelliklere sahip personel

2. Kuruluşun personelinin yapısı:

Uzman ve işçi meslek gruplarının oranı

Herhangi bir temelde birleşmiş bireysel çalışanların toplamı

Çalışan gruplarının kuruluşun işlevlerine (faaliyet türleri) göre tahsisi

Özel hizmetlerde birleşmiş organizasyonun çalışanları seti

Kuruluşta istihdam edilen ve belirli özelliklere sahip personel

3. Uzmanlaşmış hizmetlerde, bölümlerde birleşmiş ve esas olarak çeşitli zihinsel faaliyetlerle uğraşan kuruluş çalışanlarının toplamına denir:

işçiler

Yönetim kadrosu

uzmanlar

4 Profesyonel kategori aşağıdaki pozisyonları içerir:

kasiyerler

mühendisler

Sekreterler

muhasebeciler

teknik

5. Yöneticilerin ve uzmanların yönetim kararlarının geliştirilmesi ve uygulanmasındaki faaliyetlerini sağlayan ve bunlara hizmet eden çalışanlar, kategoriye aittir:

işçiler

uzmanlar

liderler

Sosyal altyapı çalışanları

Teknik sanatçılar

6. Personel yönetimi işlevlerinin sahibi:

Kuruluşun tüm personeli

İK yöneticileri

Fonksiyonel ve üretim departmanlarının başkanları

Üst yönetim, personel yönetimi hizmeti ile birlikte fonksiyonel ve üretim departmanlarının başkanları

7. Personel yönetimi işlevlerinin amacı:

Kuruluşun tüm personeli

İK yöneticileri

Personel yönetimi hizmeti ile bağlantılı olarak fonksiyonel ve üretim departmanlarının başkanları

Üst yönetim, personel yönetimi hizmeti ile birlikte fonksiyonel ve üretim departmanlarının başkanları

Organizasyonun üst yönetimi

8. Şeffaflık ilkesi şu şekilde karakterize edilir:

Personel yönetim sisteminin analizi ve iyileştirilmesi konusunda zamanında karar verme

Kavramsal birlik, erişilebilir terminoloji

Yapısal birimlerin veya bireysel yöneticilerin rasyonel özerkliği

Personel yönetim sisteminin en verimli ve ekonomik organizasyonu

Personel yönetim sisteminin basitliği

9. Paralellik ilkesi şu anlama gelir:

Personel yönetim sisteminin kontrol nesnesinin değişen hedeflerine ve çalışma koşullarına uyarlanabilirliği

Aynı miktarda işi düzenli aralıklarla yapmak

Belirli bir çözüm geliştirmek için gerekli bilgilerin düzenliliği ve amaçlılığı

Bireysel yönetim kararlarının eş zamanlı uygulanması, personel yönetiminin etkinliğinin artırılması

Personel yönetim sisteminin analizi ve iyileştirilmesi konusunda zamanında karar verme, sapmaları önleme veya derhal ortadan kaldırma

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 indirilmeye hazır karmaşık fiziksel veri modelleri ve iş zekası raporları, işletmenin bilgi bileşenini birleştirmenize ve iş süreçlerinin yürütülmesini ö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 yararlanmalarını sağlayarak proje teslim sürelerini, maliyetleri ve riskleri azaltır. Örneğin, gerçek dünya projeleri, veri modeli ve iş karar şablonlarının geliştirme çabasını %50 oranında azaltabileceğini göstermektedir.

Bir endüstri mantık modeli, hem stratejik hem de taktiksel iş sorularını yanıtlamak için bir kurumsal veri ambarında bulunması gereken tüm bilgilerin etki alanına ö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 ayrıntıların vurgulanmasına yardımcı olmaktır. Modern koşullarda, başarılı bir iş için, çeşitli bileşenler arasındaki bağlantıları net bir şekilde anlamak ve organizasyonun genel resmi hakkında iyi bir fikre sahip olmak kesinlikle gereklidir. 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 sunulduğunu 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 dünya 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çinde daha iyi iletişime izin verir ve böylece daha esnek ve istikrarlı bir uygulama ortamı yaratır.

“Hükümet ve yerel yönetim için CBS” modeline bir örnek.

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, bir şirketin operasyonlarını desteklemek için gereken bilgi teknolojisinin karmaşıklığı ve maliyeti artar. Veri yönetimi, kurumsal bilgi sistemlerinin yanı sıra işlevsel ve iş gereksinimlerinin sürekli değiştiği bir ortamda özellikle zordur.

Endüstri veri modelleri, BT yaklaşımını modern düzeye taşırken bu süreci kolaylaştırmaya ve optimize etmeye yardımcı olmayı amaçlamaktadır.

Şirketten sektör veri modelleriEsri

Esri ArcGIS veri modelleri, CBS projelerinde kullanılmak ve farklı uygulama alanları için veri yapıları oluşturmak için çalışan şablonlardır. Veri modeli oluşturma, daha sonra kişisel veya kurumsal bir coğrafi veritabanı oluşturmak için kullanılabilecek kavramsal bir tasarım, mantıksal ve fiziksel yapı oluşturmayı içerir. ArcGIS, veritabanı şemanızı oluşturmak ve yönetmek için araçlar sağlar ve Veri Modeli Şablonları, çeşitli uygulamalar ve endüstrilerde bir CBS projesini hızlı bir şekilde başlatmak için kullanılır. Esri, kurumsal bir coğrafi veritabanı tasarımına hızlı bir başlangıç ​​sağlayabilecek bir dizi şablon geliştirmek için kullanıcı topluluğuyla ö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 bir çevirisi 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ı
• Askeri kuruluş. İstihbarat teşkilatı
• Enerji (yeni ArcGIS MultiSpeak protokolü dahil)
• Ekolojik yapılar
• Acil Durumlar Bakanlığı. İtfaiye
• 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 navigasyonu
• devlet kadastrosu
• Petrol ve gaz yapıları
• boru hatları
• raster depolama
• Batimetri, deniz dibi kabartması
• Telekomünikasyon
• Ulaşım
• Su temini, kanalizasyon, konut ve toplumsal hizmetler

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

• serbestçe kullanılabilir;
• “seçilmiş” ü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 standart ve yönetmeliklerle çelişmez;
• dünya çapında tamamlanmış projelerde kullanılan;
• projenin kendisi değil, oluşturulmakta olan sistemin tüm 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ılır;
• 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; PODS şu anda bir Esri PODS Esri Spatial 5.1.1 coğrafi veritabanı olarak uygulanıyor) gibi çeşitli endüstri modellerini öneren bağımsız kuruluşlardan oluşan uzman bir grubun parçasıdır. ) 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 veri tabanı (geodatabase). Ek olarak, 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 tarafından gerçekleştirilen çalışmalardan oluşturulan ve fiili standartlar olan modeller vardır. karşılık gelen alan. Örneğin, Ulus ve Yerel Yönetim için GIS, NSDI ve INSPIRE standartlarını etkiledi ve Hidro ve Yeraltı Suyu (hidroloji ve yeraltı suyu), ücretsiz olarak temin edilebilen profesyonel ArcHydro paketinde ve ticari ürünlerde yoğun olarak kullanılmaktadır. 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. Modeller için eşlik eden malzemeler şunları içerir:

• Varlıkların 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 pekiştiriyor ve yayınlanmış materyalleri yerelleştiriyor. Aşağıdaki kitaplar Esri CIS tarafından yerelleştirildi ve yayınlandı:

• Geospatial Service Oriented Architecture (SOA);
• Ulaşım için coğrafi veritabanlarının tasarlanması;
• Kurumsal coğrafi bilgi sistemleri;
• GIS: elektrik ve gaz işletmeleri için yeni enerji;
• Dijital bir harita üzerinde petrol ve gaz;
• Dünyamızı modellemek. Esri Geodatabase Tasarım Kılavuzu;
• GIS'i düşünüyorum. CBS Planlama: Yöneticiler için El Kitabı;
• Coğrafi Bilgi Sistemleri. Temel Bilgiler;
• İdari ve ekonomik yönetim için CBS;
• Web CBS. İlkeler ve Uygulamalar;
• Sistem Tasarım Stratejileri, 26. Baskı;
• ArcReview dergisinin şirketlerin ve GIS sistemleri kullanıcılarının yayınlarının yer aldığı 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 modellemesi ve özel olarak coğrafi veritabanı veri modeli için kapsamlı bir rehber ve referanstır. Kitap, bir CBS projesinin her yönüne dahil olan kararların, doğru veri modelleme kararlarının nasıl alınacağını gösterir. veri tabanı tasarımından veri ve veri toplamaya, mekansal analiz ve görselleştirmeye kadar Bir projeye uygun bir coğrafi veri tabanının nasıl tasarlanacağını, veri tabanı işlevselliğini programlamadan yapılandırmayı, karmaşık projelerde iş akışını yönetmeyi, nehir, ulaşım gibi çeşitli ağ yapılarını modellemeyi ayrıntılı olarak açıklar. veya elektrik ağları, uydu görüntülerini coğrafi analiz ve görüntüleme sürecine entegre edin ve CBS verilerinin 3B modellerini 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 gereklilikleri ile uluslararası standartların tam olarak uyumlu olduğu metodolojik yaklaşımları içerir. Ve kitapta" GIS: Elektrik ve Gaz İşletmeleri için Yeni Enerji"Gerçek dünyadan örnekler kullanılarak, müşteri hizmetleri, ağ operasyonları ve diğer iş süreçleri gibi unsurlar dahil olmak üzere kurumsal GIS'in bir enerji tedarikçisine getirebileceği faydalar gösterilmektedir.

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 konulara hem de çeşitli boyut ve amaçlara sahip CBS modelleme ve dağıtmanın birçok uygulamalı yönünü ele alırlar.

BISDM (Bina İç Mekan Veri Modeli, bir binanın iç alanının bilgi modeli) sürüm 3.0 veri modeli örneğini kullanarak endüstri modellerinin uygulamasını ele alacağız. BISDM, daha genel bir BIM (Yapı Bilgi Modeli) modelinin geliştirilmiş halidir ve binaların ve yapıların tasarımında, yapımı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 verimli bir şekilde değiştirmenize ve onlarla etkileşime girmenize olanak tanır. Genel FM görevleri grubunu ifade eder (kuruluşun altyapısının yönetimi). Kullanımına izin veren BISDM modelinin ana avantajlarını listeleyelim:

• tek tip kurallara göre heterojen bir ortamda bilgi alışverişini organize etmek;
• BIM konseptinin "fiziksel" bir uygulamasını ve inşaat proje yönetimi için önerilen kuralları elde edin;
• bir binanın tüm yaşam döngüsü boyunca (tasarımdan hizmetten çıkarmaya kadar) CBS aracılığıyla 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;
• inşaatın maliyeti ve zamanlaması hakkında bir ön tahminde bulunun (4D ve 5D verileri);
• projenin ilerlemesini izlemek;
• bakım ve onarım dahil olmak üzere binanın yüksek kalitede çalışmasını sağlamak;
• alan kullanımının verimliliğini analiz etme işlevleri (kiralama, depo, çalışan yönetimi) dahil olmak üzere varlık yönetim sisteminin bir parçası olmak;
• binanın enerji verimliliği hedeflerini hesaplamak ve yönetmek;
• insan akışlarının hareketini simüle eder.

BISDM, amaç ve kullanımlar, kurulan iletişimler, kurulu ekipman, onarım ve bakımın muhasebeleştirilmesi, olayların günlüğe kaydedilmesi ve 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, hem binanın kendisini hem de iç binalarını oluşturan tüm fiziksel unsurların mekansal ve mantıksal ilişkilerinin coğrafi veritabanı (jeodatabanı) düzeyinde varlıkları ve modelleri izole etmek için kullanıldı. BISDM ilkelerini takip etmek, diğer sistemlerle entegrasyon görevlerini önemli ölçüde basitleştirebilir. İlk aşama genellikle CAD entegrasyonudur. 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, bir nesne oluşturma fikrinden komple bir projenin geliştirilmesine kadar uçtan uca bilgi alışverişi, ilgili bilgilerin elde edilmesi ile inşaatın kontrolü alır. tesisin devreye alınma zamanı, işletim sırasında ve hatta tesisin yeniden inşası veya hizmetten çıkarılması sırasında parametrelerin kontrolü. BISDM paradigmasının ardından, CBS ve onun yardımıyla oluşturulan GDB, ilgili sistemler için ortak bir veri ambarı haline geldi. Genellikle GDB, üçüncü taraf sistemler tarafından oluşturulan ve işletilen verileri içerir. Oluşturulan sistemin mimarisi tasarlanırken bu dikkate alınmalıdır.

Belirli bir aşamada, biriken "kritik bilgi kütlesi", yeni bir niteliksel seviyeye geçmenize izin verir. Örneğin, yeni bir binanın tasarım aşamasının tamamlanmasının ardından, 3D etüt modellerinin CBS'de otomatik olarak görselleştirilmesi, kurulacak ekipman listesinin derlenmesi, döşenecek tesislerin kilometresinin hesaplanması, bir dizi kontrol yapılması ve hatta proje maliyetinin bir ön mali tahminini verir.

Bir kez daha, BISDM ve ArcGIS birlikte kullanıldığında, coğrafi veritabanı z koordinatları, kat üyeliği, eleman bağlantı türleri dahil olmak üzere nesnenin tam bir tanımını içerdiğinden, biriken verilerden otomatik olarak 3B modeller oluşturmanın mümkün olduğunu not ediyoruz. , ekipman kurulum yöntemleri, malzeme, mevcut yollar personel hareketi, her bir elemanın işlevsel amacı vb. vesaire. Tüm tasarım malzemelerinin BISDM GDB'ye ilk aktarımından sonra, aşağıdakiler için ek bilgi içeriğine ihtiyaç duyulduğuna dikkat edilmelidir:

• 3B nesne ve ekipman modellerinin belirlenmiş 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 geçirgenlik kontrolü.

ArcGIS kullanımı nedeniyle, harici kaynaklardan ek 3B nesneleri ve referansları içe aktarmak daha kolaydır, çünkü 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 iş alanları 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 hizmetleri)
• 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ıkveParasalPiyasalarVeriDepo veri açısından bankacılık sektörünün belirli sorunlarını ele almak üzere tasarlanmıştır ve IBMBankacılıkİşlemveHizmetModeller- süreçler ve SOA (Hizmet Odaklı Mimari) açısından. Telekomünikasyon endüstrisi için modeller sunulmaktadır 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'nin 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. yanı sıra kuruluşlar küresel ağlar. Bugün TDW, dünya çapında büyük ve küçük kablolu ve kablosuz servis sağlayıcılar tarafından kullanılmaktadır.

denilen bir araç Müşteri İçgörüsü için InfoSphere Depo Paketi bankacılık, sigorta, finans, sağlık sigortası, 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 dağıtılan iş içeriği sağlar. İş kullanıcıları için Pazar ve Kampanya İçgörüsü için InfoSphere Depo Paketi adım adım geliştirme ve işin özelliklerini dikkate alma süreci aracılığıyla pazar analizi faaliyetlerinin ve pazarlama kampanyalarının etkinliğini en üst düzeye çıkarmaya yardımcı olur. Kullanarak Tedarik Zinciri İçgörüsü için InfoSphere Depo Paketi kuruluşlar, tedarik zinciri operasyonları hakkında güncel bilgi alma yeteneğine sahiptir.

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

Özellikle kayda değer olan, IBM'in yardımcı programlara ve yardımcı programlara yaklaşımıdır. Tüketicilerin artan taleplerini karşılamak için kamu hizmetleri, günümüzde kullanılanlardan daha esnek bir mimariye ve ayrıca serbest bilgi akışını kolaylaştırmak için endüstri standardı bir nesne modeline ihtiyaç duyar. Bu, kamu hizmetlerinin iletişim yeteneklerini geliştirecek, iletişimi daha uygun maliyetli bir şekilde sağlayacak ve kuruluş içinde nerede bulunurlarsa bulunsunlar, ihtiyaç duyulan tüm kaynakların daha iyi görünürlüğünü sağlayan yeni sistemler sağlayacaktır. Bu yaklaşımın temeli, yeniden kullanılabilen çeşitli uygulamaların departman ve hizmetlerinin işlevlerini haritalayan 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, katı bağlama olmadan arayüzler aracılığıyla veri alışverişi yapar. Bu modda işletmeler, yazılım satıcısı, işletim sistemi, programlama dili veya yazılımın diğer içsel özelliklerinden bağımsız olarak kolayca yeni uygulamalar ekleyebilir. SOA'ya dayanan konsept uygulanıyor GÜVENLİ ( Enerji için Çözüm Mimarisi), kamu hizmeti şirketinin altyapısının standartlara dayalı, bütünsel bir görünümünü elde etmesini 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 gerçekleştirmenize olanak tanır. ArcGIS, akıllı bir enerji kuruluşunu yönetmek için gereken araçları, uygulamaları, iş akışlarını, analitiği ve bilgi bütünleştirme yeteneklerini sağlayarak IBM SAFE mimarisini önemli ölçüde genişletir. IBM SAFE çerçevesindeki ArcGIS, konumları hakkında doğru verilerle altyapı tesisleri, varlıklar, müşteriler ve çalışanlar hakkında çeşitli kaynaklardan bilgi almanızın yanı sıra kurumsal varlıklar (destekler, boru hatları, teller) hakkında coğrafi referanslı bilgiler oluşturmanıza, depolamanıza ve işlemenize olanak tanır. , transformatörler, kablo kanalları vb.) SAFE altyapısı içindeki ArcGIS, GIS, SCADA ve müşteri hizmetleri sistemlerinden gelen verileri trafik yoğunluğu, hava koşulları veya uydu görüntüleri gibi harici bilgilerle birleştirerek temel iş uygulamalarını dinamik olarak birbirine bağlar. Kamu hizmetleri, bu birleştirilmiş bilgileri S.O.R.'den çeşitli amaçlar için kullanır. (operasyon ortamının genel resmi) saha denetimi, bakım, ağ analizi ve planlamasına kadar.

Bir kamu hizmeti şirketinin bilgi bileşenleri, en düşük fiziksel - en yüksek, en karmaşık iş mantığı düzeyine kadar değişen çeşitli düzeyler kullanılarak modellenebilir. Bu katmanlar, otomatik ölçüm kaydı ve SCADA yönetimi gibi tipik endüstri gereksinimlerini karşılamak için entegre edilebilir. GÜVENLİ mimariyi inşa ederek, kamu hizmetleri, Enerji ve Kamu Hizmetleri için Ortak Bilgi Modeli (CIM) adı verilen endüstri çapında bir açık nesne modelini teşvik etmede önemli adımlar atmaktadır. Bu model, veri ve nesneleri yapılandırmak için açık standartların kullanımını teşvik ettiği için birçok işletmeyi hizmet odaklı bir mimariye taşımak için gerekli çerçeveyi sağlar. Tüm sistemlerin aynı nesneleri kullanması nedeniyle, 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. Artık CIM ile hizmet sağlayıcılar ve hizmet tüketicileri ortak bir veri yapısını paylaşabilir, bu da CIM bilgi alışverişi oluşturmak için ortak bir temel oluşturduğundan yüksek değerli iş bileşenlerini dış kaynaklardan 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 uygulamaların benimsenmesinin önünde önemli bir engel olduğunu buldu. Aksine, veri entegrasyonunun uygulanması şirkete somut gelir ve artan verimlilik getiriyor.

İyi yapılandırılmış bir model, bu durumda yapılandırılmış veri olan verinin anlamını benzersiz bir şekilde tanımlar (anlamın belirsiz olabileceği bir görüntü, ikili dosya veya metin gibi yapılandırılmamış verilerin aksine). En etkili endüstri modelleri, Esri ve IBM gibi profesyonel satıcılar tarafından sunulanlardır. Modellerinin yüksek kullanım getirisi, önemli düzeyde ayrıntı ve doğruluk nedeniyle elde edilir. Genellikle birçok veri özniteliği içerirler. Ek olarak, hem Esri hem de IBM, kapsamlı modelleme deneyimine sahiptir ve sektöre özel modeller oluşturma konusunda bilgilidir.

Bu makale veri ambarı 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ü, harika, harika. Ama nasıl çalıştığını gerçekten bilmiyordum. Ve büyükbaba bir inceleme başlattı. Büyükbaba, büyükanne, torunu, kedi ve fareyi aile meclisine çağırdı. Ve şunları söylüyor: “Depolamamız büyüdü. Tüm sistemlerden gelen veriler aşağı akar, tablolar görünür ve görünmezdir. Kullanıcılar raporlarını hazırlar. Her şey iyi görünüyor - 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 gerektirir - yeterli olmayacaksınız! Ve sonra kullanıcılar bana farklı şikayetlerle gelme alışkanlığı edindiler: ya rapor donuyor, sonra veriler eski. Ve sonra bu tam bir felaket - çarın babasına raporlarla geliyoruz, ancak rakamlar birbiriyle uyuşmuyor. Saat bile değil - kral kızgın - o zaman kafayı çıkarmayın - ne benim için ne de sizin için. Bu yüzden sizi bir araya toplamaya ve danışmaya karar verdim: ne yapacağız?"

Bakışlarını toplantıya çevirdi ve sordu:
- Sen, büyükanne, depomuzun nasıl düzenlendiğini biliyor musun?
- Hayır dede, bilmiyorum. Ve nereden bileyim? Orada, onu ne kadar cesur adamlar koruyor! Bazıları! yaklaşmayacaksın. Bir şekilde onları görmeye gittim, turta pişirdim. Ve turtaları yediler, bıyıklarını sildiler ve “Neden geldin büyükanne? Sen nasıl bir deposun? Bana ne tür bir rapora ihtiyacınız olduğunu söyleyin - bunu sizin için yapacağız! Turtaları daha sık getirmelisin! Acı verici bir şekilde lezzetliler."
- Ve sen, sevgili torun, depomuzun nasıl düzenlendiğini biliyor musun?
- Hayır dede, bilmiyorum. Bana bir şekilde erişim izni verdiler. Bağlandım, bakıyorum - ve masalar var - görünüşe göre - görünmez bir şekilde. Ve farklı şemalar gizlidir. Gözler doluyor…. İlk başta kafam karıştı. Sonra daha yakından baktım - bazıları boş, diğerleri dolu, ama sadece yarısı. Ve veriler tekrarlanıyor gibi görünüyor. Bu kadar fazlalık ile yeterli diske sahip olamamanız şaşırtıcı değil!
- Peki sen kedi, depolama tesisimiz hakkında ne diyorsun? Bunda iyi bir şey var mı?
- Ama nasıl deme, büyükbaba - Yapacağım. Torunumun isteği üzerine ayrı bir devrede pilot yapmaya çalıştım - küçük bir vitrin. Devletimiz için ne tür bir ticaretin karlı olduğunu anlamak için - tüccarlar için hangi ürünler iyidir, haraç öderler - hazineyi doldururlar. Ve hangileri çok kötü. Ve bu depodan kendim için veri seçmeye 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 plakalara bakıyorsun - farklılar! Sonra torunumun tarağıyla onları taramaya başladım. Chesal çizik - ve gözleri okşayarak belli bir tekdüzeliğe yol açtı. Ama erkenden sevinmiştim - ertesi gün penceredeki harika verileri güncellemek için komut dosyalarımı başlattım - ve benim için her şey gitti! "Nasıl yani?" - Sanırım, - torun üzülecek - bugün pilotumuzu bakana göstermek gerekecek. Bu tür verilerle nasıl gideceğiz?
- Evet, üzücü hikayeler, kedi, sen anlat. Peki, sen, küçük fare, gerçekten depoyu öğrenmeye çalışmadın mı? Sen bizimle canlı, çevik, sosyal bir kızsın! Bize ne söyleyeceksin?
- Evet, nasıl, büyükbaba, deneme - elbette, sessiz bir fareyim ama çevikim. Bir keresinde kedinin torunu, devlet depomuzun veri modelini almamı istedi. Ve elbette kedi bana geldi - senin için, diyor, fare, tüm umutlar! Peki, iyi insanların (ve kedilerin) yapmaması gereken iyilik nedir? Depo şefinin veri modelini kasada sakladığı kaleye gittim. Ve saklandı. 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? Depomuzu tanımıyorum! Sayısız binlerce tablomuz var, veri akışları önlenemez! 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 yapacağız arkadaşlar? Sonuçta, böyle ve böyle bir depo ile uzun yaşamayacaksınız ... Kullanıcılar yakında sabrını kaybedecek.

Büyükbabamız bir peri masalından ne karar verdiyse - yeni bir depolama tesisi inşa etmek ya da mevcut olanı yeniden canlandırmaya çalışmak - tekrar "kollarımızı sıvamadan" sonuçlar çıkarmak gerekiyor.
Uzmanlığın belirli bir dar kapalı grupta yoğunlaşma tehlikesi, kontrol süreçlerinin eksikliği ve işletmede 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. Kuruluş, depolama gibi karmaşık ve pahalı bir sistem oluşturmaya başladığında, her şeyden önce odakta tutulması gereken şey.

Bilgilendirme

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" yönelik önyargı ne kadar güçlü olursa olsun, bir insanın kendini keman yapan bir "usta" gibi hissetmesi, tek kullanımlık davullar için sopalar yapan bir zanaatkardan çok daha hoştur.
Niyetimiz kulağa doğal geliyor: Sağlam ve kaliteli, düzenli "dosyalı gece nöbetleri" 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çiler için bir "kara kutu".

Başlangıç ​​olarak, depolarla çalışırken düzenli olarak karşılaştığımız tipik sorunların bir listesini verelim. Ş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, 8 saat içinde büyük bir süreç içinde yüklenir. Ve bu bize yakışıyor. Ancak aniden bir arıza meydana gelirse, manuel müdahale gerektirir. Ve sonra her şey uzun süre tahmin edilemez bir şekilde çalışabilir, tk. sürece insan katılımını gerektirecektir.
3. Sürümü topladınız - sorun bekleyin.
4. Bazı kaynaklar zamanında veri gönderemedi - tüm işlemler bekliyor.
5. Verilerin 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 görevin yeniden çözülmesi gerekiyor. Çünkü bu daha kolay ve daha hızlıdır ("başkasının kodunu" 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ı oldular. 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 şu veya bu rakamın gerekçesini ister. Bazı durumlarda haklı, bazılarında değil. Ama onları haklı çıkarmak bizim için çok zor, çünkü "uçtan uca analiz" (veya veri kökeni) için hiçbir aracımız yok.
9. Ek geliştiriciler getirebiliriz. Ama bir sorunumuz var - onları çalışmaya nasıl dahil edeceğiz? İşleri paralelleştirmenin en etkili yolu nedir?
10. Bir yıl boyunca "sistemin çekirdeğinin" gelişimine girmeden sistem kademeli olarak nasıl geliştirilir?
11. Veri ambarı, kurumsal modelle ilişkilendirilir. Ama kesin olarak biliyoruz (XYZ bankasında gördük), bir model oluşturmanın sonsuz uzun sürebileceğini (altı ay boyunca XYZ bankasına gittik ve herhangi bir hareket olmadan ticari varlıkları tartıştık). Neden o hiç? Ya da belki onsuz daha iyi, eğer onunla bu kadar çok sorun varsa? Belki bir şekilde üretebiliriz?
12. Modeli sürmeye karar verdik. Ancak ambar veri modelinizi sistematik olarak nasıl geliştirirsiniz? "Oyunun kurallarına" ihtiyacımız var mı ve bunlar ne olabilir? Bize ne verecek? Ya modelde yanılıyorsak?
13. "İşin buna ihtiyacı yoksa" verileri veya değişikliklerin geçmişini kaydetmeli miyiz? "Çö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. Ana veri yönetim sistemimiz varsa ambardaki verileri birleştirmeye çalışmalı mıyız? MDM varsa, bu, ana verilerle ilgili tüm sorunun artık çözüldüğü anlamına mı geliyor?
15. Yakında kilit muhasebe sistemlerini değiştirmemiz bekleniyor. Veri deposunun kaynağı değiştirmeye hazır olması gerekiyor mu? Bu nasıl başarılabilir?
16. Meta verilere ihtiyacımız var mı? Bununla ne demek istiyoruz? Tam olarak nerede kullanılabilirler? Nasıl uygulayabilirsiniz? Bunları "tek bir yerde" saklamam gerekir mi?
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. En kısa sürede sonuç verecek şekilde nasıl yapabiliriz - sıcak kek gibi?
18. Kullanıcılar yanıt talep ediyor. Ancak ana önyükleme süreçlerimizi sık sık çalıştıramayız, çünkü bu, kaynak sistemleri yükler (performans üzerinde kötü bir etkiye sahiptir) - bu nedenle, ek veri akışlarını kapatıyoruz - bu da noktasal olarak - ihtiyacımız olanı alacak. Doğru, birçok akış var. Ve sonra bazı verileri atacağız. Ayrıca, 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, 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.

antifrajilite

Listemize bakıldığında, bir sonuç çıkarılabilir. Bir tür "raporlama veritabanı" oluşturmak, oraya veri yüklemek, 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, 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 görüntü şöyle:
"İşte kasa. Ve dokunmazsanız çalışır. Bir şeyi değiştirmemiz gerektiğinde sorunlar ortaya çıkıyor."

Etkisini değerlendiremediğimiz ve idrak edemediğimiz (çünkü bu tür araçları sisteme en başından sokmadığımız için) bir değişiklik bize geliyor - ve risk almamak için olana dokunmuyoruz, ancak yanda bir uzantı daha yapıyoruz ve bir tane daha ve ayrıca - çözümümüzü gecekondu mahallelerine ya da Latin Amerika'da dedikleri gibi, polisin bile girmeye korktuğu "favelalara" dönüştürüyoruz.
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 strese karşı kararsız, değişikliklere uyumsuz hale gelir. Ayrıca, kimsenin bir "haritası" 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 şokların etkisi altında çökmek - Nassim Nicholas Taleb çağırıyor kırılganlık ... Ve aynı zamanda karşıt konsepti de tanıtıyor: kırılganlık – nesne stres ve kazalardan bozulmadığı, ancak ondan doğrudan yararlandığı zaman... ("Antifragility. Kaostan nasıl yararlanılır")
Aksi takdirde çağrılabilir uyarlanabilirlik veya değişime dayanıklılık .

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 - mağaza için veri kaynakları tarafı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 kuralların / platformların değiştirilmesi;
• 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 fazla veri olmamasına ve yük yüksek olmamasına rağmen - herhangi bir zamanda, isteğe bağlı olarak yoğun bir istekle almak mümkündü, veri ve yük arttı - şimdi katı kısıtlamalar var ;
• vesaire.

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, sistemin amaç ve hedeflerini karşılayan kendi veri modelini ve bunlarla çalışma yaklaşımlarını uygular. Ve endüstri modellerini ve referans uygulamalarını ne kadar birleştirmeye çalışırlarsa çalışsınlar, kaçınılmaz olarak nüanslar ortaya çıkacaktır. (Ayrıca, çeşitli nedenlerle endüstrinin birleşmesi sürecinin kendisi fazla ilerleme kaydetmiyor.)
Kurumsal verilerle çalışma kültürü - bilgi mimarisinin varlığı ve kontrolü, birleşik bir anlamsal model, ana veri yönetim sistemleri (MDM), depodaki verileri birleştirme görevini bir şekilde kolaylaştırır, ancak ihtiyacını dışlamaz.

Depo tüketicileri tarafından daha az kritik değişiklik başlatılmaz (gereksinimler değişir):

• ö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 bundan etkilenen her şeyin yeniden işlenmesi gerekir;
• Daha önce, bilgi panelindeki sözlük özelliğinin mevcut değerinden herkes memnundu - şimdi analiz edilen olgu / olay zamanında ilgili olan değer gereklidir;
• daha önce olmayan veri depolama geçmişinin derinliği için bir gereklilik vardı - verileri 2 yıl değil 10 yıl boyunca saklamak;
• daha önce, “günün / dönemin sonu” itibariyle yeterli veri vardı - şimdi “gün içinde” veya belirli bir olay sırasında (örneğin, bir krediye karar verme) verilerin durumuna ihtiyacınız var başvuru - Basel II için);
• daha önce dün (T-1) veya daha sonrasına ilişkin verileri raporlamaktan memnunduk, şimdi T0'a ihtiyacımız var;
• vesaire.

Hem kaynak sistemlerle entegrasyon etkileşimleri hem de ambar verilerinin tüketicilerinden gelen gereksinimler, veri ambarı için dış faktörlerdir: bazı kaynak sistemler diğerlerinin 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 - depolamamızın - hazır olması gereken tipik harici değişikliklerdir. Doğru mimari ile sistemi öldürmemeleri gerekir.

Ama hepsi bu değil.
Değişkenlik hakkında konuşurken, her şeyden önce dış faktörleri hatırlıyoruz. Sonuçta, içeride her şeyi kontrol edebiliyoruz, öyle sanıyoruz, 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 olarak varlığı nedeniyle, bazen “0 noktasına” geri dönmemiz gerekir. Oyunu baştan başlatın.
Hayatta, genellikle sıfırdan başlama eğilimindeyiz. Bu neden bize özel? Ve gerçekten o kadar kötü mü?
BT'ye uygulanır. Sistemin kendisi için - bu çok iyi olabilir - bireysel kararları yeniden düşünme 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şa dönmek yardımcı olabilir. Ama bir bedeli var.
Yetkili mimari yönetimi ile bu fiyat düşer - 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 yazabilirsiniz. Ve bu monolitik bir yapı ile yapılamaz.

Bir sistemin kırılganlığı, içinde gömülü olan mimari 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, revizyonunu gerektiren gereksinimler ne kadar az olursa, sistem o kadar uyarlanabilir olur.

Tüm mimarinin revizyonunu içeren çözümler çok daha yüksek bir fiyata sahip olacaktır. Ve evlat edinmeleri için çok iyi nedenleriniz olması gerekiyor. Örneğin, böyle bir gerekçe, mevcut mimaride uygulanamayan bir gereklilik olabilir. Sonra derler ki - mimariyi etkileyen bir gereklilik var.
Bu nedenle, “antikırılganlık sınırlarımızı” da bilmemiz gerekir. Mimari “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 bulmamız ve geçiş yolları üzerinde düşünmemiz gerekiyor.
Örneğin, depolamada günün sonunda her zaman verilere ihtiyacımız olacağını varsaydık, standart sistem arayüzlerini kullanarak (bir dizi görünüm aracılığıyla) her gün veri alacağımızı varsaydık. Ardından, risk yönetimi bölümünden, günün sonunda değil, kredi verme kararı sırasında veri alma ihtiyacına yönelik talep geldi. “Gergin olmayanı çekmeye” çalışmanıza 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" hesaba katarsak ve birkaç adım ileriye (ve birkaç yıl sonrasına) bakmazsak, o zaman mimariyi etkileyen bir gereksinimle çok geç karşı karşıya kalma riskini artırırız - ve değişikliğimizin bedeli çok yüksek olacaktır. Biraz ileriye bakmak - ufkumuz sınırları içinde - henüz kimseyi incitmedi.

"Depolama hikayesinden" bir sistem örneği, kırılgan tasarım yaklaşımları üzerine kurulu çok titrek bir sistemin sadece bir ö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? Depolar konusu yeni değil. Bu süre zarfında geliştirilen yaklaşımlar ve mühendislik uygulamaları tam olarak buna yönelikti - sistemin canlılığını korumak.
Basit bir örnek: Kalkış depolama projelerinin başarısız olmasının en yaygın nedenlerinden biri, geliştirme aşamasında olan kaynak sistemler üzerinde entegrasyon arayüzleri üzerinde anlaşmaya varmadan depolama oluşturmaya çalışmaktır - doğrudan tablolardan veri almaya çalışmak. Sonuç olarak, geliştirme sürecine girdik - bu süre zarfında kaynak veritabanı değişti - ve depodaki yükleme akışları çalışmaz hale geldi. Bir şeyi yeniden yapmak için çok geç. Ve eğer deponun içinde birkaç kat masa yaparak kendinizi henüz güvenceye almadıysanız, o zaman her şeyi atabilir ve baştan başlayabilirsiniz. Bu sadece bir örnek ve basit olanlardan biri.

Kırılgan ve kırılgan olmayan için Taleb kriteri basittir. Ana yargıç zamandır. Sistem zamanın testine dayanırsa ve "canlılığını" 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 gelen 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 "derme çatma evler" yapmak istemiyoruz. Ve bugün başka yolu olmayan kendinizi kandırmayın. Bir kişinin herhangi bir zamanda, özellikle bir kriz anında birkaç adım ileriye bakması normaldir.

Veri ambarı nedir ve neden inşa ediyoruz?

Depolama mimarisiyle ilgili makale, 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 geri dönmek, çünkü gelişmenin "dayanak noktası" oradadır.

İnsanlar veri ambarlarının gerekli olduğu fikrine nasıl geldi? 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 oltp sistemleri, arka ofis dss, metin işleme sistemleri, veri ambarları vb. sınıflara ayrılması yoktu.
Bu süre zarfında ilk ilişkisel veritabanı motoru olan Ingres, Michael Stonebreaker tarafından yaratıldı.
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 zamanlar Clipper, dBase ve FoxPro gibi masaüstü sınıfı DBMS'ler temelinde yazılmış kurumsal uygulamaları bulmak kolaydı. Ve istemci-sunucu uygulamaları ve DBMS pazarı yalnızca ivme kazanıyordu. Veritabanı sunucuları birbiri ardına ortaya çıktı ve BT alanındaki nişlerini uzun süre işgal edecek - Oracle, DB2, vb.
Ve "veritabanı uygulaması" terimi yaygınlaştı. Böyle bir uygulama neleri içeriyordu? Basitleştirilmiş - kullanıcıların aynı anda bilgi girebilecekleri bazı girdi formları, "düğme ile" 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.
Mentorlarımdan biri kariyerimin başlarında "Özel bir şey yok - sadece normal bir uygulama, sadece bir veri tabanı" dedi. "Yani özel bir şey yok mu?" - O zaman düşündüm.

Yakından bakarsanız, hala bazı ö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" gider. Birincisi, monolitik bir "iş veri işleme sisteminin", kullanıcıların çevrimiçi çalışmalarını destekleyen bir muhasebe uygulamasına bölünmesidir ve verilerin toplu işlenmesi ve raporlama için bir uygulama ayrı olarak tahsis edilmiştir. 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ı aralarında sıralanır.

Hepsi bu mu? 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ı üreticilerin birkaç farklı uygulaması 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 veri ambarları bu şekilde ortaya çıkıyor - yeni bir sistem sınıfı.
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 tasarlanmış konu odaklı bir bilgi veritabanı

Böylece, konsolidasyon farklı sistemlerden gelen veriler, onlara belirli bir "tek tip" (birleşik) şekilde bakma yeteneği - bu, veri ambarları sınıfındaki sistemlerin temel özelliklerinden biridir. BT sistemlerinin evrimi sırasında depoların ortaya çıkmasının nedeni budur.

Veri ambarlarının temel özellikleri

Hadi daha yakından bakalı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, bu tarihsel verilerdir - "Kurumsal hafıza" - sözde veri ambarları. Depolarda zamanla çalışmak açısından her şey oldukça ilginç. Muhasebe sistemlerinde veriler şu anda günceldir. Ardından kullanıcı bir işlem gerçekleştirir ve veriler güncellenir. Aynı zamanda, değişikliklerin geçmişi kaydedilmeyebilir - bu, muhasebe uygulamasına bağlıdır. Örneğin bir banka hesabı bakiyesi alın. "Şimdi", günün sonunda veya bir olay sırasında (örneğin, puanlama puanını hesaplarken) mevcut bakiyeyle ilgilenebiliriz. İlk ikisinin çözülmesi oldukça kolay olsa da, ikincisi büyük olasılıkla özel çaba gerektirecektir. Depolama ile çalışan kullanıcı, geçmiş dönemlere başvurabilir, mevcut olanla karşılaştırabilir vb. Veri ambarlarını muhasebe sistemlerinden - zaman eksenindeki farklı 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 analizlerinin mümkün olması için, onları ortak bir forma getirmek gerekir - birleşik veri modeli , gerçekleri birleşik referans kitaplarıyla karşılaştırmak. Burada çeşitli yönler ve zorluklar olabilir. Her şeyden önce - kavramsal - Aynı terim altında, farklı bölümlerden farklı kişiler farklı şeyleri anlayabilir. Ve tam tersi - temelde aynı şey olan bir şeyi farklı olarak adlandırmak. Belirli bir kullanıcı grubunun belirli vizyonunu korurken "tek bir görünüm" nasıl sağlanır?

Dördüncüsü, bu iş veri kalitesi ... Verilerin depoya yüklenmesi sürecinde temizlenirler, 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ını, özellikle de farklı departmanlardan birbiriyle uyuşmayan numaralarla masaya getirilen yöneticileri rahatsız eden tutarsızlıkları önleyecektir. Düşük veri kalitesi, raporlarda hata ve tutarsızlıklar yaratır 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

Bir depoyla karşılaşan herkes, büyük olasılıkla bir tür "katmanlı yapı" gözlemlemiştir. bu sınıfın sistemleri için kök salmış olan bu mimari paradigmadır. Ve tesadüf değil. Depolama katmanları, sistemin ayrı bileşenleri olarak algılanabilir - kendi görevleri, sorumluluk alanı, “oyunun kuralları” ile.
Katmanlı mimari, sistemin karmaşıklığıyla başa çıkmanın bir yoludur - sonraki her seviye, bir öncekinin dahili uygulamasının karmaşıklıklarından soyutlanır. Bu yaklaşım, her seferinde "tekerleği" sıfırdan yeniden icat etmeden, aynı türdeki sorunları ayırmanıza ve bunları tek tip bir şekilde çözmenize olanak tanır.
Kavramsal mimari diyagram şekilde şematik olarak gösterilmiştir. Bu, yalnızca ana fikri yansıtan basitleştirilmiş bir diyagramdır - kavram, ancak ayrıntıların daha derin işlenmesiyle 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ş dikdörtgenle gösterilir) ve veri yükleme yazılımını (geleneksel olarak aynı renkteki oklarla gösterilir) içeren üç ana katman. Ve ayrıca çok önemli bir bağlantı rolü oynayan bir yardımcı hizmet katmanı - veri yükü yönetimi ve kalite kontrolü.

Birincil Veri Katmanı - birincil veri katmanı (veya sahneleme , veya işletim katmanı ) - kaynak sistemlerden yüklemek ve birincil bilgileri dönüştürmeden kaydetmek için tasarlanmıştır - orijinal kalitede ve eksiksiz bir değişiklik geçmişini destekler.
Bu katmanın görevi- sonraki depolama katmanlarını veri kaynaklarının fiziksel yapısından, veri toplama yöntemlerinden ve değişiklik deltasını ayırma yöntemlerinden soyutlamak.

Çekirdek Veri Katmanı - çekirdek depolama - depolamayı basit 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, ana iş oldukça karmaşık olabilen veri kalitesi ve genel dönüşümlerle yapılır.
Bu katmanın görevi- Verilerin bütünlüğünü ve kalitesini sağlamak için tüketicilerini veri kaynaklarının mantıksal aygıtının özelliklerinden ve farklı sistemlerden gelen verileri karşılaştırma ihtiyacından soyutlamak.

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 kural olarak 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 vitrinleri arayacağız düzenli ... Bazı durumlarda, vitrinler verileri doğrudan hazırlamadan alabilir - birincil verilerle (kaynak anahtarlarda) çalışır. 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 vitrinler denir işletme ... Bazı analitik göstergeler çok karmaşık hesaplama yöntemlerine sahip olabilir. Bu nedenle, bu tür önemsiz hesaplamalar ve dönüşümler için sözde ikincil vitrinler .
Vitrin Katmanı Görevi- belirli bir tüketicinin gereksinimlerine göre verilerin hazırlanması - bir BI platformu, bir grup kullanıcı veya harici bir sistem.

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. Fiziksel olarak, bu bileşenlerin uygulanması 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üketen bileşenin atıfta bulunduğu. 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 desteklemek ve aynı zamanda ambardaki veri akışlarının bilgi denetimini sağlamak için kullanılan özel teknik alanlarla (meta nitelikler) işaretlenmiştir.

Ayrıca, tüm katmanlar için hizmet işlevleri sağlayan özel bir bileşen (veya bir dizi bileşen) ayırt edilir. Anahtar görevlerinden biri kontrol işlevidir - tüm sistem için bir bütün olarak "oyunun tekdüze kuralları" sağlamak ve yukarıda açıklanan katmanların her birini uygulamak için çeşitli seçenekleri kullanma hakkını bırakmak - dahil. verileri yüklemek ve işlemek için farklı teknolojiler, farklı depolama platformları vb. kullanın. diyelim 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, sistemin gelişiminin kontrol edilebilirliğini önemli ölçüde artırır:

• bu veya bu bileşenin işlevselliğinin geliştiricisine verilen görevin karmaşıklığı azalır (aynı anda harici sistemlerle entegrasyon sorunlarını çözmemeli ve veri temizleme prosedürlerini düşünmeli ve en uygun sunum hakkında düşünmemelidir). tüketiciler için veriler) - görevin ayrıştırılması, değerlendirilmesi ve küçük bir teslimatın gerçekleştirilmesi daha kolaydır;
• çeşitli sanatçıların (ve hatta ekiplerin veya yüklenicilerin) çalışmalarına bağlanabilirsiniz - çü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 kalan katmanları oluşturmayı aşamalı olarak tamamlamanıza olanak tanır (ayrıca, veriler zaten depoda olacaktır - deponun sonraki gelişiminin görevlerini büyük ölçüde kolaylaştıracak sistem analistleri);
• bir çekirdeğin varlığı, veri kalitesiyle yapılan tüm çalışmaların (olası hatalar ve hataların yanı sıra) vitrinlerden ve son kullanıcıdan gizlenmesine izin verir ve en önemlisi - bu bileşeni vitrinler için tek bir veri kaynağı olarak kullanarak verilerden kaçınabilirsiniz ortak algoritmaların tek bir yerde uygulanmasından kaynaklanan yakınsama sorunları;
• martların seçimi, farklı departmanların 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ın BI gereksinimlerine yönelik tasarımları, yalnızca toplu rakamlar yayınlamaya değil, aynı zamanda fırsatlar sağlayarak veri doğrulamasını sağlamaya da olanak tanır. birincil göstergelere inmek;
• bir 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 genel yaklaşımlara, veri kalitesiyle çalışmanıza, yük yönetimi, izleme ve hata tanılama araçlarına izin verir. , ve problem çö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 yapı" ile karşılaştırıldığında) - kırılganlığını önler:

• kaynak sistemlerden gelen değişiklikler aşamalandırmada işlenir - çekirdekte, yalnızca bu aşamalandırma tablolarından etkilenen akışlar değiştirilir, vitrinler üzerindeki etki minimumdur veya yoktur;
• Tüketicilerin gereksinimlerindeki değişiklikler çoğunlukla vitrinlerde işlenir (bu, henüz mağazada olmayan ek bilgileri gerektirmiyorsa).

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

Sistem çekirdeği

Ortadan başlayalım - sistemin çekirdeği veya orta katman. Çekirdek Katman olarak etiketlenir. Çekirdek, veri konsolidasyonu rolünü oynar - tek tip yapılara, referans kitaplarına, anahtarlara getirme. Veri kalitesiyle ilgili ana çalışmanın yapıldığı yer burasıdır - temizleme, dönüştürme, birleştirme.

Bu bileşenin varlığı, kaynak sistemlerden alınan birincil verileri genel kuralları ve algoritmaları izleyerek belirli bir birleşik biçime dönüştüren veri akışlarını yeniden kullanmanıza ve aynı işlevselliğin uygulanmasını her bir uygulama mağazası için ayrı ayrı tekrarlamanıza olanak tanır. kaynakların verimsiz kullanımına ek olarak, verilerde tutarsızlıklara da neden olabilir.
Deponun özü, genel durumda, hem kaynak sistem modellerinden hem de tüketicilerin format ve yapılarından farklı bir veri modelinde uygulanır.

Depo Çekirdek Modeli ve Kurumsal Veri Modeli

Orta depolama katmanının ana endişesi kararlılıktır. Bu nedenle buradaki ana odak veri modelidir. Genellikle "kurumsal veri modeli" olarak adlandırılır. Ne yazık ki, etrafında bir tür mit ve saçmalık halesi oluştu, bu da bazen onu tamamen inşa etmeyi reddetmeye yol açtı, ancak boşuna.

Efsane 1. Kurumsal veri modeli, binlerce varlık (tablo) içeren 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ı edinebilirsiniz. Önemli bir şeyin gözden kaçırılmaması 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 sisteminin (veya CRM'nin) satın alınması ve bunun "kendinizi zorlamadan" uygulanmasıyla aynı efsanedir. Bu tür modellerin değeri, bu belirli işin, bu belirli şirketin gerçeklerine uyarlanmalarında doğar.

Efsane 3. Bir çekirdek veri havuzu modelinin geliştirilmesi aylar alabilir ve bu süre zarfında proje gerçekten dondurulacaktır. Ayrıca, çılgınca miktarda toplantı ve çok sayıda insan gerektirir.
Aslında. Depo modeli, depo ile parça parça yinelemeli olarak geliştirilebilir. Kaplanmamış alanlar için "genişleme noktaları" veya "saplamalar" belirlenir. bazı "evrensel tasarımlar" kullanılmaktadır. Aynı zamanda, 4 tablodan hem "veri koymanın" hem de (daha da zor) elde etmenin zor olduğu süper evrensel bir şey almamak için ne zaman duracağınızı bilmeniz gerekir. Ve performans açısından son derece yetersiz olan.

Modeli geliştirmek gerçekten zaman alıyor. Ancak bu, "varlıkların çizilmesi" için harcanan zaman değildir - bu, konu alanını analiz etmek, verilerin nasıl düzenlendiğini anlamak için gereken zamandır. Bu nedenle analistler bu sürece çok yakından dahil olur ve çeşitli iş uzmanları da dahil olur. Ve bu noktasal, seçici olarak yapılır. Ve çılgın sayıda insanın katılımıyla toplantılar düzenleyerek, büyük anketler göndererek vb.
İyi bir iş ve sistem analizi, bir çekirdek depo modeli oluşturmanın anahtarıdır. Anlaşılması gereken çok şey var: verilerin nerede (hangi sistemlerde) üretildiği, nasıl çalıştığı, hangi iş süreçlerinde dolaştığı vb. Nitel analiz hiçbir zaman tek bir sisteme zarar vermedi. Aksine, bizim anlayışımızdaki “beyaz noktalardan” sorunlar ortaya çıkar.

Bir veri modeli geliştirmek, yeni bir şey icat etme ve icat etme süreci değildir. Aslında, veri modeli şirkette zaten var. Ve tasarım süreci daha çok “kazı” gibidir. Model, kurumsal verilerin "toprağından" dikkatli ve dikkatli bir şekilde çıkarılır ve yapılandırılmış bir forma bürünür.

Efsane 4. Şirketimizde işimiz 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. Ana 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. Bir model çok hızlı bir şekilde modası geçmişse, yanlış tasarlanmıştır. Gelişimi için yanlış yaklaşımlar ve “oyunun kuralları” seçilmiştir. Ve aynı zamanda niteliksel bir analiz meselesidir. Kurumsal modelin kilit unsurları nadiren değişir.
Ancak, “Ürünler” dizini yerine şekerleme satan bir şirket yapmak aklımıza gelirse, “Tatlılar”, “Pastalar” ve “Börekler” yapın. 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 herhangi bir tasarım çözümü gibi, yapısı da revize edilebilir ve değiştirilebilir. Sadece bu kalitesini unutmanıza gerek yok. Ancak bu, “üzerinde nefes alamazsınız” anlamına gelmez. Ve bu, geri dönüşüm için planlanması gereken geçici çözümlerin ve "saplamaların" kabul edilemez olduğu anlamına gelmez.

Efsane 6. Veri kaynağımız, örneğin bir referans veri sistemi (veya bir ana veri yönetim sistemi - MDM) ise, o zaman zaten dostane bir şekilde kurumsal modele karşılık gelmelidir (özellikle yakın zamanda tasarlanmışsa ve bunu yapmak için zamanı yoksa). bir "taraf", "gelenekler" ve geçici kulübeler edinin). Görünüşe göre bu durumda - bir çekirdek modeline ihtiyacımız yok mu?
Aslında. Evet, bu durumda, havuzun çekirdek modelinin oluşturulması büyük ölçüde kolaylaştırılmıştır. hazır bir üst düzey kavramsal model izliyoruz. Ama hiç de dışlanmıyor. Niye ya? Çünkü belirli bir sistemin bir modelini oluştururken, kendi kurallarından bazıları 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 tutacak, hangi meta nitelikler (teknik alanlar) kullanmak), vb.

Ek olarak, ne kadar harika ve her şeyi kapsayan bir referans verisi ve MDM sistemine sahip olursak olalım, kural olarak, diğer muhasebe sistemlerinde "hemen hemen aynı" yerel dizinlerin varlığıyla ilgili nüanslar olacaktır. Ve bu problem, istesek de istemesek de, depoda çözülmek zorunda kalacak - sonuçta, raporlama ve analizler burada toplanıyor.

Birincil veri katmanı (veya tarihselleştirilmiş 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 ve 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) depo için çok önemli bir görevi çözer - "gerçek değişiklik deltasının" tahsisi - "). Veriler evrelemeye girer girmez - diğer tüm katmanlar için, delta tahsisi sorunu - meta niteliklerle etiketleme sayesinde 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 depolanır. Bu bileşenin bir diğer adı da "işletim katmanı"dır.
Neden sadece iyi bilinen “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 kaydedilirse, o zaman yalnızca sınırlı bir süre. Ve genellikle "evreleme" adı denir temizlenebilir tampon.
Artık teknolojiler bir adım öne çıktı - ve yalnızca tüm birincil verileri depolamayı değil, aynı zamanda bunları 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 veriyi” daha ucuz medya ve depolama platformlarına taşımak.

"Tarihselleştirilmiş evreleme"nin varlığı bize ne verir:

• hata yapma olasılığı (yapılarda, dönüşüm algoritmalarında, tarihin ayrıntı düzeyinde) - depolama için kullanılabilirlik bölgesinde tamamen tarihselleştirilmiş birincil verilere sahip olarak, tablolarımızı her zaman yeniden yükleyebiliriz;
• düşünmek için bir fırsat - depolama geliştirmesinin bu yinelemesinde tam olarak çekirdeğin büyük bir parçasını çalışmak için zaman ayırabiliriz, çünkü sahnelememizde, her halükarda, olacak ve eşit bir zaman ufku ile (bir "tarih referansı" noktası olacaktır);
• 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, daha sonra indirmenin bizim için nasıl çalıştığını, sonunda bu tür rakamları aldığımızı anlayabileceğiz (bunun için ayrıca meta niteliklerle işaretlememiz gerekiyor ve indirmenin çalıştığı ilgili meta veriler - buna hizmet katmanı tarafından karar verilir).

"Tarihselleştirilmiş bir evreleme" oluştururken hangi 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) - sonraki işlemlerde bütünlük hizalaması gerçekleşir katmanlar;
• bu katman çok büyük hacimler içerir (depolamadaki en hacimli - analitik yapıların tüm fazlalığına rağmen) - ve bu tür hacimleri hem yük hem de istekler açısından idare edebilmeniz gerekir (aksi takdirde, ciddi şekilde yapabilirsiniz) tüm depolamanın performansını düşürür).

Bu katman hakkında söylenecek başka ne ilginç.
İlk olarak, “uçtan uca yükleme süreçleri” paradigmasından uzaklaşırsak, “kervan son deve hızında hareket eder” kuralı artık işimize yaramaz, daha doğrusu “kervanı” terk ederiz. prensibi ve “konveyör” prensibine geçiş: kaynaktan veri aldık - katmanınıza koyduk - bir sonraki kısmı almaya hazırız. Demek oluyor
1) diğer katmanlarda işlemin gerçekleşmesini beklemiyoruz;
2) diğer sistemler tarafından veri sağlama programına bağımlı değiliz.
Basitçe söylemek gerekirse, belirli bir bağlantı yoluyla bir kaynaktan veri alan, deltayı kontrol eden, ayıklayan ve verileri hedef hazırlama tablolarına koyan bir yükleme süreci planlıyoruz. Ve hepsi bu.

İkincisi, gördüğünüz gibi, bu süreçler çok basittir - mantık açısından önemsiz olarak söylenebilir. Bu, 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 gerçekleşmesi için, bu bileşenin üzerinde çalıştığı platformun teknolojik özelliklerinin özelliklerini çok iyi bilmeniz gerekir - ve sonra çok etkili bir araç yapabilirsiniz.

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 hem mantıksal (kavramsal) hem de fiziksel olarak mümkün olduğunca dikkate alınır. 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. Veri ambarı hazırlandı, bir vitrin oluşturdu, artımlı veri toplama imkanı sağladı (değişiklik deltasının daha sonra vurgulanması için meta niteliklerle işaretleme) ve daha sonra tüketici sistemi bu vitrini nasıl kullandığından kendisi kontrol eder ve sorumludur. Ancak bazı tuhaflıklar vardır: sistem veri toplama için aktif bir bileşene sahip olmadığında - ya entegrasyon işlevini gerçekleştirecek harici bir bileşene ihtiyaç duyulur ya da depolama bir "entegrasyon platformu" olarak işlev görür - ve doğru artımlılığı sağlar. daha fazla veri yükleme - 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 veri marketlerine rutin veri temizleme / arşivleme uygulanır (bu "transit verilerinin" uzun süre saklanması nadiren gereklidir).

Analitik görevler açısından en önemlisi, "insanlar için" vitrinlerdir - daha doğrusu, birlikte çalıştıkları BI araçları için.
Bununla birlikte, harici özel sistemleri doldurmak için BI araçlarına veya düzenleyici süreçlere ihtiyaç duymayan "özellikle ileri düzey kullanıcılar" - analistler, veri araştırmacıları - kategorisi vardır. Kendi takdirlerine göre tablolar ve dönüşümler oluşturabilecekleri bir tür "ortak vitrinlere" ve "kendi sanal alanlarına" ihtiyaçları var. Bu durumda arşivin sorumluluğu, bu ortak vitrinlerin mevzuata uygun olarak verilerle 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. Depolama için, görev - yine, üzerinde anlaşılan formatta bazı vitrinleri yükleme hizmetini desteklemektir.

Ancak, analitik vitrinlere geri dönelim. Bunlar, bu veri katmanında depolama tasarımcıları açısından ilgi çekici olanlardır.
Bana göre, neredeyse tüm BI platformlarının artık "keskinleştiği" veri marketlerini tasarlamak için zamana göre test edilmiş en iyi yaklaşım, Ralph Kimball'un yaklaşımıdır. Olarak bilinir boyutlu modelleme - çok boyutlu modelleme. Bu konuyla ilgili birçok yayın var. Örneğin, temel kurallar Marga Ross'un yayınında bulunabilir. Ve tabi ki çok boyutlu modelleme gurusundan tavsiyelerde bulunabilirsiniz. Bir başka yararlı kaynak da Kimball's Tips
Vitrinlerin yaratılmasına yönelik çok boyutlu yaklaşım, hem "yöntem müjdecileri" hem de önde gelen yazılım satıcıları tarafından o kadar iyi tanımlanmış ve işlenmiştir ki, burada biraz ayrıntılı olarak ü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 sonra panolar var - BI panoları. Özünde, bunlar web uygulamalarıdır. Ve bu uygulamaların yanıt süresi, diğer tüm web uygulamalarıyla aynıdır. Bu, bir BI Panelinin yenilenmesi için normal sürenin dakika değil, saniye olduğu anlamına gelir. Çözümünüzü tasarlarken bunu akılda tutmak önemlidir. Bu nasıl başarılabilir? Standart optimizasyon yöntemi: Tepki süresinin nelerden oluştuğuna ve neleri etkileyebileceğimize bakarız. En çok boşa harcanan zaman nedir? Ağ üzerinden veri iletimi için fiziksel (disk) veritabanı okumaları için. Bir istekte okunan ve iletilen veri miktarı nasıl azaltılır? Cevap açık ve basittir: ya verileri toplamanız ya da sorguya katılan gerçek tabloların büyük tablolarına bir filtre uygulamanız ve büyük tabloların birleştirilmesini hariç tutmanız gerekir (olgu tablolarına yapılan referanslar yalnızca boyutlardan geçmelidir) .

BI ne için? Nasıl uygun? Çok boyutlu model neden etkilidir?
BI, kullanıcının geçici sorgular olarak adlandırılanları çalıştırmasına izin verir. Bunun anlamı ne? Bu, kesin talebi önceden bilmediğimiz, ancak kullanıcının hangi yönlerden 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, verilerin filtrelenmesi veya toplanması, böylece çok fazla veri istendiğinde ve uygulamanın "kilitlenmesi" durumunda bir durumu önleyecek şekilde uygulama işleminin böyle bir mantığını sağlamaktır. Genellikle toplu sayılarla başlarlar, daha sonra daha ayrıntılı verilere derinlemesine girerler, ancak bu arada gerekli filtreleri de yüklerler.

Sadece “doğru yıldızı” oluşturmak ve BI için uygun bir yapı elde etmek her zaman yeterli değildir. Bazen bir yere denormalizasyon uygulamanız gerekebilir (bunun yükü nasıl etkileyeceğine bakarken) ve ikincil vitrinler ve kümeler yapmak için bir yere. Bir yere indeksler veya projeksiyonlar ekleyin (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 olan bir yapı elde edebilirsiniz.
Verileri "çekirdekten" alırsak, vitrinlerin bu tür işlenmesi, doğrudan kaynak sistemlerden elde edilen birincil verilerin karmaşık işlenmesini hiçbir şekilde etkilemeden, doğası gereği yerel olacaktır - verileri yalnızca bir biçime "kaydırırız" BI için uygun. Ve bunu, farklı gereksinimlere uygun olarak, farklı şekillerde, birçok kez yapmaya gücümüz yetiyor. Bunu çekirdek verilerinde yapmak, "birincil"den (yapısı ve kuralları, bildiğimiz gibi, "yüzebilir") toplamaktan çok daha kolay ve hızlıdır.

Servis katmanı

Hizmet Katmanı, çeşitli depolama katmanlarındaki verileri işlemek için kullanılabilecek genel (hizmet) işlevlerin uygulanmasından sorumludur - yük yönetimi, veri kalitesi yönetimi, sorun teşhis 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 kontrollerinin uygulanması için (yani, doğrudan ETL süreçlerine dahil edilmemiş olanlar).

İndirme yönetimi sürecini farklı şekillerde düzenleyebilirsiniz. Olası yaklaşımlardan biri şudur: tüm depolama tablolarını modüllere ayırdık. Modül, yalnızca bir katmanın tablolarını içerebilir. Her modülde bulunan tablolar ayrı bir süreçte yüklenir. diyelim kontrol süreci ... Kontrol sürecinin başlangıcı kendi programına göre ayarlanır. Kontrol süreci, her biri bir hedef tablo yükleyen ve ayrıca bazı genel 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. orada verilerin 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 çakışmalar olacaktır. Ve bunları çözmek için farklı yöntemler var.

Yük yönetiminde önemli bir nokta, hata işleme konusunda tutarlı bir yaklaşım geliştirmektir. Hatalar önem derecelerine göre sınıflandırılır. Kritik bir hata oluştuğunda, süreç 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 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 satırı güncelleyen işlemin tanımlayıcısı olan özel bir meta-alan seti ile işaretlendiğine dikkat etmek önemlidir. Bir havuz içindeki tablolar için, bu süreç işaretlemesi, sonradan değişikliklerin deltasını vurgulamanın tutarlı bir yolunu sağlar. Birincil veri katmanına veri yüklerken durum daha karmaşıktır - yüklenen farklı nesneler için delta tahsis algoritması farklı olabilir. Ancak kabul edilen değişiklikleri işlemenin ve çekirdek ve vitrinler için hedef tablolara yuvarlanmasının mantığı, her şeyin oldukça önemsiz olduğu aşamaya göre çok daha karmaşıktır - yeniden kullanılabilir standart adımları (prosedürler) parametreleştirmek ve düşünmek kolaydır.

Buradaki görevi bu konuyu tam olarak kapsayacak şekilde belirlemedim - indirmelerin organizasyonu - sadece dikkat etmeye değer aksanları vurguluyorum.
Bu yaklaşım seçeneklerden sadece biridir. Oldukça duyarlı. Ve "kavramsal prototipi" Toyota konveyörü ve tam zamanında sistemiydi. Onlar. Burada, yalnızca "gecelik veri indirme" gibi yaygın paradigmadan uzaklaşıyoruz ve gün boyunca küçük porsiyonlarda indiriyoruz - çeşitli kaynaklarda veriler hazır olur olmaz: ne geldi - indirildi. 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 zamanla kaybolur. Bu özelliği dikkate almalıyız. Ve gerekirse, her şeyin zaten bütünsel olduğu "dilimler" ile özel vitrinler oluşturun. 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 olanakları sağlamak zorunludur. Farklı parametreler ayarlayabileceğiniz ve bildirim sistemini özelleştirebileceğiniz - belirli olaylara abone olarak - yazılan olayları kullanmak iyi bir uygulamadı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 aynı zamanda, olay sonrası sorunları analiz etmek ve sistem arızaları olaylarını araştırmak için de kullanılabilir. veri kalitesi.

Depo Veri Modellerinin Tasarlanması ve Bakımı

Veritabanının dahil olduğu (ve özellikle bir depoda) herhangi bir sistem geliştirirken veri modeli 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 soruyor.
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 tutarlı bir genel resmine sahiptir. Ya birden fazla geliştirici varsa? Ya bu tabloları başka biri kullanıyorsa? Peki ya zaman geçerse - kişi bu alanı terk eder ve sonra tekrar oraya dönerse?

Model olmadan çözebilir misin? Prensip olarak, yapabilirsiniz. Ve bunu anlamak ve "bir kağıt parçası üzerindeki resimleri anlamak" ve verileri "silmek - 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. Ayrıca "cihazının mantığını" da anlayın - yani. Oyunun genel 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 cihazının özelliklerini ve çeşitli iş durumlarında kullanımlarını daha yakından ve derinlemesine incelemek zorunda kalıyoruz. Ve karmaşık olarak kolayca "bir kenara iteceğimiz", işaretlerimizi atarak "bulanıklaştırdığımız" sorular, tam olarak yapmaya çalışmadan. tasarım modeli - analiz ederken ve tasarlarken şimdi teslim etmek ve karar vermek zorunda kalacağız ve daha sonra değil - ne zaman raporlar oluşturacağımızı ve “uyumsuzları nasıl azaltacağımızı” ve her seferinde “tekerleği yeniden icat edeceğimizi” düşüneceğiz.

Bu yaklaşım, kırılma önleyici sistemler oluşturmanıza izin veren mühendislik uygulamalarından biridir. Açıkça düzenlenmiş, şeffaf, geliştirme için uygun ve ayrıca "kırılganlık sınırları" hemen görünür olduklarından - yeni gereksinimler ortaya çıktığında ve yeniden tasarım için gereken süreyi (gerekirse) "felaketin ölçeğini" daha doğru bir şekilde tahmin edebilirsiniz.
Bu nedenle, veri modeli, sistemin geliştirilmesi sırasında korunması gereken ana eserlerden biridir. Dostane bir şekilde, her analistin, geliştiricinin vb. "masasında" olmalıdır. - sistem geliştirme projelerine katılan herkes.

Veri modelleri tasarlamak geniş ve ayrı bir konudur. Depolama tasarımına iki ana yaklaşım vardır.
Yaklaşım çekirdek için iyi çalışıyor varlık-ilişki - konu alanının veya daha doğrusu seçilen alanın incelenmesi temelinde normalleştirilmiş bir (3NF) model oluşturulduğunda. Yukarıda tartışılan aynı "kurumsal model" burada oynuyor.

Vitrin tasarlarken uygun çok boyutlu model ... Bu yaklaşım, iş kullanıcılarının anlayışına çok uygundur - çünkü basit ve insan algısı için uygun bir modeldir - insanlar, analiz edildikleri metrikler (göstergeler) ve bölümlerle ilgili anlaşılır ve tanıdık kavramlarla çalışır. Ve bu, gereksinimleri toplama sürecini basit ve net bir şekilde oluşturmanıza olanak tanır - çeşitli departmanların temsilcileriyle iletişim kurarak bir dizi "bölüm ve gösterge matrisi" çizeriz. Ve sonra onu tek bir yapıya getiriyoruz - "analiz modeli": "ölçüm veriyolu"nu oluşturuyoruz ve bunlar üzerinde tanımlanan olguları tanımlıyoruz. Bu arada, hiyerarşiler ve toplama kuralları üzerinde çalışıyoruz.

Ardından, DBMS'nin özelliklerini dikkate alarak optimizasyon öğeleri ekleyerek fiziksel modele gitmek ç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.
Ayrıca, özel denormalizasyon gerekebilir - sorgu 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ü veri yükleme sırasında fazlalığın dikkate alınması ve sürdürülmesi gerekecektir). işlem). 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:

• çekirdek - sistem ve iş analizi - kavramsal (mantıksal) bir model oluşturma görevi - konu alanını araştırmak, ayrıntılara girmek 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 kavramsal (mantıksal) bir vitrin modeli;
• fiziksel modeller oluşturma görevi - veri artıklığı yönetimi, sorgular ve veri yükleme için DBMS'nin özelliklerini dikkate alan optimizasyon.

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, “güzel resimlerden” oluşan bir koleksiyon değildir ve tasarım süreci, onları çizme süreci değildir. Model, alana ilişkin anlayışımızı yansıtır. Ve onu derleme süreci, onu inceleme ve araştırma sürecidir. Bu zaman kaybıdır. Ve hiç de "çizmek ve boyamak" için değil.
• Bir veri modeli, bir tasarım eseridir, ekip üyeleri arasında yapılandırılmış bir şekilde bilgi alışverişi yapmanın bir yoludur. Bunu yapmak için herkes için açık (bu, gösterim ve açıklama ile sağlanır) ve erişilebilir (yayınlanmıştı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 belirliyoruz. Ve eğer görürsek onları değiştirebiliriz - nasıl daha iyi, daha kolay, daha verimli yapılır.
• Veri modeli (fiziksel), optimizasyona yönelik bir dizi en iyi uygulamayı birleştirmenize ve bunlardan yararlanmanı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. Ve onlara mimari yönün etkisi açısından bakalım. Bu tür projeler için bir mimari inşa etmek neden önemlidir ve en başından beri? Ve veri ambarı projesine esneklik kazandıran, işi sanatçılar arasında verimli bir şekilde dağıtmanıza ve aynı zamanda 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 standart BI paneli 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 depolarla çalışıyorum ve hiç böyle bir hikaye görmemiştim. Şirketin benzersiz özellikleriyle ilgili her zaman bazı nüanslar vardır - hem iş hem de BT ortamı. Bu nedenle, mimarinin çözümü sağlayan "satıcı" tarafından sağlanacağını ummak biraz pervasızlıktır. Bu tür sistemlerin mimarisi genellikle organizasyonun kendi içinde “olgunlaşır”. Veya projenin ana uygulayıcısı 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 onlarla son derece dikkatli olmanız gerekir. Özellikle, kaynak sistemler üzerindeki yükü en aza indirmek, "kullanılabilirlik ve kullanılamazlık" pencerelerini dikkate almak, mimarilerini dikkate alarak etkileşim arayüzlerini seçmek vb. gereklidir. Ardından depolama, verileri mümkün olduğunca erken ve gerekli sıklıkta alabilecektir. Aksi takdirde, en operasyonel frekansta güncellenmeyen bir yedekleme devresine "nakledileceksiniz".
Ayrıca “insan faktörü” de dikkate alınmalıdır. Entegrasyon sadece makinelerin etkileşimi ile ilgili değildir. Aynı zamanda insanlar arasındaki iletişimdir.

Veri Ambarı İşbirliğine Dayalı Bir Projedir

Büyük bir şirkette böyle bir sistem nadiren tek 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şlevin farklı yerlerde, farklı kişiler tarafından tekrarlanmasından kaçınırken, paralel çalışmalarını organize etme yeteneği 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 sistemin geliştirilmesine dahil olduğunda, kaçınılmaz olarak şu soru ortaya çıkar: aralarında iletişim ve bilgi etkileşimi nasıl oluşturulur. Ne kadar standart ve anlaşılır yaklaşımlar ve uygulamalar kullanılırsa, bu tür işleri organize etmek o kadar kolay, kullanışlı ve verimli olur. Ve diğer şeylerin yanı sıra, veri ambarları # 1 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şturmak için - 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çem 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 cüretkar bir fikir.

İkincisi, eğer depolama doğru mimariye sahipse, kaynak sistemlerin değişikliklerine, 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 duruma takılıp kalma riski olmadan uzun süre geliştirilebilir.

Kademeli yinelemeli geliştirme

Müşterinin, depolamayla ilgili hikayeye dahil olmak isteyeceği son şey, eksiksiz bir 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 - sistemin görevleri, hedefleri ve geliştirme ufku çok hacimlidir. Ve çoğu zaman müşteri, "bütçesi pahasına" BT departmanının bazı "kendi sorunlarını" çözeceğinden korkar. Ve yine, insanlar arasındaki etkileşim sorunu ve sakince pozisyonumuzu ifade etme ve müzakere etme yeteneği sorunuyla karşı karşıyayız.

Yetkili mimari yaklaşımlar, bir 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.

Her ne kadar "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 tarihsel verilerdir - bilgi işleme kurallarının mevcut olanlardan farklı olabileceği eski dönemler için. Bu nedenle, analitik çalışma, 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 alır.

Veri ambarları - "çoklu proje hikayesi"

Bir veri ambarı için tek bir iş müşterisini seçmek zordur. Ve (sebepsiz değil) bir depolama tesisi inşa etme 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 projenin parçası olarak oluşturulur ve geliştirilir. Tipik olarak, veri konsolidasyonu ve analitiği için farklı 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ı gözden geçirmenin zamanı geldi. Ayrıca, bu hem teknolojik platformlar hem de bunlara dayanan uygulamalı sistemlerin mimarisi için geçerlidir.

Burada bir denge kurmak ve hem kaynaklara hem de depolanan bilgilere oldukça “yeşil” bir yaklaşımı sürdürmek önemlidir. Aksi takdirde, depoyu çok hızlı bir şekilde yarı yapılandırılmış bir "çöplük" haline getirebilirsiniz; bunun içinde, eğer bunu anlamak mümkün olacaksa, o zaman oldukça fazla çaba harcayarak.
Evet, daha fazla fırsatımız var, ancak bu, nasıl ve neden kullanılacağı açık olan tüm birikmiş ve zaman içinde test edilmiş uygulamaları reddetmemiz ve yalnızca puslu hayalet tarafından yönlendirilen "tüm kötü haberlere dalmamız" gerektiği anlamına gelmez. "yenilikler".
Dengeyi korumak, yeni fırsatlara kapı açan yeni yöntemler ve yaklaşımlar kullanmak, ancak aynı zamanda eski kanıtlanmış olanları kullanmak anlamına gelir - iptal edilmemiş acil sorunları çözmek için.
Uygulama çözümlerinin 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 teknolojik platform 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 ortaya çıkar.

Ancak bu, bunun sonu 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. Başlangıçta yalnızca genel olarak "iş bilgilerini" depolamak ve işlemek için değil, belirli görevler için de "keskinleştirilmeleri" önemlidir.

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. Örneğin, 90'lı yıllarda Michael Stonebreaker, dünyanın veritabanları dünyasında başka bir devrime ihtiyaç duymadığı fikrini açıkça ifade eden Nesil III 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ı ilan ettiği çalışmaları yayınlar - uzmanlıklarına dayanarak.
Ortak evrensel DBMS'lerin, donanım platformlarındaki değişiklikleri veya uygulamaların daha optimal bir şekilde bulabileceğiniz sınıflara bölünmesini hesaba katmayan "herkese uyan tek boyutlu" bir mimari üzerine inşa edildiği gerçeğine odaklanıyor. evrensel gereksinimleri uygulamaktan daha fazla çözüm.
Ve bu fikir doğrultusunda bir takım projeler geliştirmeye başlar. Bunlardan biri - C-Store - paylaşılan hiçbir şey (SN) mimarisinde tasarlanmış, orijinal olarak özellikle veri ambarları sınıfındaki sistemler için oluşturulmuş sütunlu bir DBMS'dir. Bu ürün daha sonra HP Vertica olarak pazarlandı.

Görünüşe göre şimdi veri ambarlarının geliştirilmesi konusu yeni bir geliştirme aşamasına kaymış durumda. Yeni teknolojiler, yaklaşımlar ve araçlar ortaya çıkıyor. Çalışmaları, testleri ve akıllı uygulamaları, gerçekten ilginç ve kullanışlı çözümler oluşturmamı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ği” 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ı geçmişlere, geçmişlere ve konumlara sahip.
Örneğin, tipik yönetim soruları "ne zaman mimar işe alınmalı?", "Mimarlık ne zaman yapılmalı?" şeklindedir. bizim için ses (geliştiriciler, tasarımcılar) oldukça garip, çünkü bizim için sistemin mimarisi onun doğuşuyla ortaya çıkıyor - bunun farkında olup olmamamız önemli değil. Ve bir projede bir mimarın resmi bir rolü olmasa bile, normal bir geliştirici her zaman “kendi iç mimarını içerir”.

Genel olarak, mimarın rolünü tam olarak kimin yerine getirdiği önemli değildir - birinin benzer sorular sorması ve cevapları araştırması önemlidir. Mimar açıkça seçiliyorsa, bu yalnızca sistemden ve gelişiminden öncelikle onun sorumlu olduğu anlamına gelir.
"Antifrajilite" konusunu neden bu konuyla alakalı buldum?

"Kırılganlık önlemenin benzersizliği, bilinmeyenle çalışmamıza, ne yaptığımızı anlamadığımız koşullarda bir şeyler yapmamıza ve başarıya ulaşmamıza izin vermesidir."/ Nassim N.Taleb /

Dolayısıyla kriz ve yüksek derecede belirsizlik, mimarlığın yokluğu için bir mazeret değil, mimarinin ihtiyacını pekiştiren unsurlardır.

Endüstri veri modelleri

Modellerin temel amacı, veri alanında yönlendirmeyi kolaylaştırmak ve iş geliştirme için önemli olan ayrıntıların vurgulanmasına yardımcı olmaktır. Günümüz ortamında başarılı bir iş için çeşitli bileşenler arasındaki bağlantıları net bir şekilde anlamak ve organizasyonun genel resmi hakkında iyi bir fikre sahip olmak zorunludur. 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 sunulduğunu 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 dünya 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çinde daha iyi iletişime izin verir ve böylece daha esnek ve istikrarlı bir uygulama ortamı yaratır.

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

Kural olarak, daha yüksek düzeyde (ve içerikte daha genel) ve daha düşük (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 (yani ilişkiler) arasındaki ilişkileri tanımlar. İş modelleme terminolojisi henüz tam olarak oturmadığından, çeşitli İngilizce kaynaklarda, kavramsal veri modelleri konu alanı modeli (alan modeli olarak tercüme edilebilir) veya konu kurumsal veri modeli (konu kurumsal verisi) olarak da adlandırılabilir. modeller).

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 işletme tarafından kullanılan bilgileri iş perspektifinden 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ının anlamasını kolaylaştıracak şekilde sunar. Mantıksal bir modelde, bir veri sözlüğü ayırt 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, kesin tanımlarıyla birlikte tüm varlıkların bir listesi. Bir sonraki, daha düşük modelleme seviyesi, belirli yazılım ve teknik platformlar kullanılarak mantıksal modelin fiziksel uygulamasıdır.

Mantıksal model, genellikle normalleştirilmiş bir model şeklini alan ayrıntılı bir kurumsal iş kararı içerir. Normalleştirme, bir 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 bir süreçtir. Veri öğeleri, benzersiz kimliklerine göre gruplar halinde düzenlenir. Veri öğelerini yöneten iş kuralları, önceden doğrulama ve doğrulama ile normalleştirilmiş modele tam olarak dahil edilmelidir. Örneğin, Müşteri Adı gibi bir veri öğesinin Ad ve Soyadı olarak bölünmesi ve diğer ilgili veri öğeleriyle birlikte birincil anahtar Müşteri Kimliği olan bir Müşteri varlığında gruplandırılması muhtemeldir.

Mantıksal veri modeli, veritabanları, ağ teknolojileri veya raporlama araçları gibi uygulama teknolojilerinden ve bunların fiziksel uygulama araçlarından bağımsızdır. Bir kuruluşta 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, bir kurumsal iş çözümünü temsil eder ve anlamsal veri modeli, uygulanan bir 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 görü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 mantıksal veri modelinde Müşteri varlığı tamamen normalize edilecek ve data mart için semantik modelde çok boyutlu bir yapı olarak gösterilebilir.

Bir şirketin kurumsal mantıksal veri modeli oluşturmanın iki yolu olabilir: bağımsız olarak 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, böyle bir modele genellikle basit bir kurumsal mantıksal model denir. Bir kuruluş profesyonel bir tedarikçiden hazır bir ürü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ığı modeli, hem stratejik hem de taktiksel iş sorularını yanıtlamak için bir kurumsal Veri Ambarı'nda bulunması 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ümlerinden bağımsızdır. 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 yapılandırılmıştır. Bu modeller birçok tedarikçi tarafından çok çeşitli faaliyet alanları için geliştirilmektedir: finans, üretim, turizm, sağlık, sigorta vb.

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

Endüstri mantıksal veri modelleri, önemli miktarda soyutlama içerir. Soyutlamalar, benzer kavramların Etkinlik veya Katılımcı gibi ortak isimler altında birleştirilmesi anlamına gelir. Bu, endüstri modellerine esneklik ve tekdüzelik katar. Bu nedenle, bir Etkinlik kavramı tüm endüstriler için geçerlidir.

İş Zekası Uzmanı Steve Hoberman, bir endüstri veri modeli edinip edinmemeye karar verirken göz önünde bulundurulması gereken beş faktör tanımlıyor. Birincisi, modeli oluşturmak için gereken zaman ve paradır. Bir kuruluşun hızlı bir şekilde sonuçlara ulaşması gerekiyorsa, endüstri modeli faydalı olacaktır. Bir endüstri modeli kullanmak, tüm organizasyonun bir resmini hemen sağlamayabilir, ancak önemli miktarda zaman kazandırabilir. Kendini modellemek yerine, mevcut yapıları endüstri modeliyle ilişkilendirmek ve onu organizasyonun ihtiyaçlarına göre en iyi şekilde nasıl özelleştirebileceğimizi tartışmak için zaman harcanacaktır (örneğin, hangi tanımların değiştirilmesi ve hangi veri öğelerinin eklenmesi gerektiği).

İkinci faktör, modeli iyi çalışır durumda tutmak için gereken zaman ve paradır. Kurumsal veri modeli, doğruluğu ve modern standartlara uygunluğunu izlemenize izin veren bir metodolojinin parçası değilse, böyle bir model çok hızlı bir şekilde eski hale gelir. Endüstri veri modeli, dış kaynaklarla güncel tutulduğu için bu riskin oluşmasını ö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çisi tarafından modelde yeniden üretilecektir.

Üçüncü faktör, risk değerlendirme ve modelleme deneyimidir. Kurumsal bir veri modelinin oluşturulması, hem işletmeden hem de BT personelinden nitelikli kaynaklar gerektirir. Kural olarak, yöneticiler ya bir bütün olarak organizasyonun çalışmalarının ya da belirli bir bölümün faaliyetlerinin farkındadır. Çok azı işleriyle ilgili hem geniş (şirket çapında) hem de derin (departmanlar içinde) bilgiye sahiptir. Çoğu yönetici genellikle yalnızca bir alanı iyi bilir. Bu nedenle, genel kurumsal resmi elde etmek için önemli iş kaynaklarına ihtiyaç vardır. Bu aynı zamanda BT personeli üzerindeki talepleri de artırmaktadır. Bir model oluşturmak ve test etmek için ne kadar fazla iş kaynağı gerekiyorsa, o kadar deneyimli analistler olmalıdır. Sadece işletme personelinden nasıl bilgi alınacağını bilmekle kalmamalı, aynı zamanda tartışmalı alanlarda ortak bir bakış açısı bulabilmeli ve tüm bu bilgileri bütünleşik bir şekilde sunabilmelidir. Modeli oluşturan kişi (çoğu durumda aynı analist) iyi modelleme becerilerine sahip olmalıdır. Kurumsal mantık modelleri oluşturmak, "gelecek için" modelleme ve karmaşık işi kelimenin tam anlamıyla "karelere ve çizgilere" dönüştürme becerisini gerektirir.

Öte yandan, endüstri modeli, dış uzmanlığın kullanılmasına 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ılarak oluşturulur.

Dördüncü faktör, mevcut uygulama altyapısı ve tedarikçi ilişkileridir. Bir kuruluş zaten aynı tedarikçiden birçok araç kullanıyorsa ve onunla ilişkiler kurduysa, ondan sipariş vermek mantıklı ve endüstri modelidir. Bu model aynı tedarikçinin diğer ürünleriyle özgürce çalışabilecek.

Beşinci faktör, endüstri içi bilgi alışverişidir. Bir şirketin aynı alanda çalışan diğer kuruluşlarla iletişim kurması gerekiyorsa, bu durumda endüstri modeli çok faydalı olabilir. Aynı sektördeki kuruluşlar benzer yapısal bileşenleri ve terminolojiyi kullanır. Günümüzde çoğu sektörde şirketler başarılı bir şekilde iş yapabilmek için veri alışverişi yapmak zorunda kalıyor.

En etkili olanları, profesyonel tedarikçiler tarafından sunulan endüstri modelleridir. Bu modellerin önemli düzeyde ayrıntı ve doğruluğu nedeniyle kullanımlarının yüksek verimliliği 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 uygulamaların benimsenmesinin önünde önemli bir engel olduğunu buldu. Aksine, veri entegrasyonunun uygulanması şirket için somut bir gelir sağlar.

Endüstri veri modeli, mevcut sistemlere bağlanmanı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 görünümünü elde etmek için etkili bir araçtır. Mantıksal modellerin kullanılması, kurumsal veri ambarlarının oluşturulmasına yönelik gerekli bir adım gibi görünmektedir.

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