Techopedia Staff tarafından, 28 Eylül 2016
Paket Servisi: Host Rebecca Jozwiak, OSTHUS'tan Eric Little, First San Francisco Partners'dan Malcolm Chisholm ve IDERA'dan Ron Huizenga ile veri mimarisi çözümlerini tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Rebecca Jozwiak: Bayanlar ve baylar, merhaba ve 2016 Hot Technologies'e hoş geldiniz. Bugün “İş Odaklı Bir Veri Mimarisi Oluşturmak” konusunu kesinlikle tartışıyoruz. Benim adım Rebecca Jozwiak, bugünün web yayını için sunucunuz olacağım. # HotTech16 hashtag'i ile tweet yapıyoruz, bu yüzden zaten Twitter'daysanız, lütfen buna katılmaktan çekinmeyin. Herhangi bir sorunuz varsa, lütfen bunları ekranınızın sağ alt kısmındaki Soru-Cevap bölmesine gönderin; yanıtlandıklarından emin olacağız. Değilse, konuklarımızın sizin için aldıklarından emin olacağız.
Bugün gerçekten büyüleyici bir kadroya sahibiz. Bugün bizimle bir sürü ağır vurucu var. OSTHUS veri bilimi başkan yardımcısı Eric Little'ımız var. First San Francisco Partners için gerçekten harika bir unvan olan baş yenilik memuru Malcolm Chisholm'umuz var. Ve IDERA'nın kıdemli ürün müdürü Ron Huizenga var. Ve bilirsiniz, IDERA gerçekten eksiksiz bir veri yönetimi ve modelleme çözümleri grubudur. Ve bugün bize çözümünün nasıl çalıştığı hakkında bir demo verecek. Ama buna başlamadan önce, Eric Little, topu sana vereceğim.
Eric Little: Tamam, çok teşekkürler. Bu yüzden burada Ron'un konuşmasıyla ilgili olacağını düşündüğüm birkaç konudan geçeceğim ve umarım bu konuların bazıları için de bazı soru-cevaplar için zemin hazırlayacağım.
Beni IDERA'nın yaptığı şeyle ilgilendiren şey, günümüzde karmaşık ortamların gerçekten çok fazla iş değeri yarattığını doğru bir şekilde işaret ettiklerini düşünüyorum. Karmaşık ortamlarla, karmaşık veri ortamlarını kastediyoruz. Ve teknoloji gerçekten hızlı ilerliyor ve günümüzün iş ortamında yetişmek zor. Dolayısıyla, teknoloji alanlarında çalışan insanlar genellikle, “Büyük verileri nasıl kullanırım? Anlambilimi nasıl dahil edebilirim? Bu yeni şeylerden bazılarını eski verilerimle nasıl ilişkilendirebilirim? ”Vb. Ve bu tür günümüzde bizi birçok insanın oldukça tanıdığı bu dört büyük veriye yönlendiriyor ve dörtten fazla olabileceğini anlıyorum bazen - sekiz ya da dokuz kadar gördüm - ama normalde, insanlar büyük veri gibi şeylerden bahsederken ya da büyük veri hakkında konuşuyorsanız, genellikle kurumsal ölçekli bir şeye bakıyorsunuzdur. Ve böylece insanlar, normalde odak noktası olan verilerinizin hacmini düşünün derler. Verilerin hızı ya onu ne kadar hızlı hareket ettirebileceğim ya da ne kadar hızlı sorgulayabileceğim ya da cevapları alabileceğim gibi. Ve kişisel olarak bunun sol tarafının birçok farklı yaklaşımla nispeten hızlı bir şekilde çözülüp ele alınan bir şey olduğunu düşünüyorum. Ancak sağ tarafta, geliştirme için çok fazla yetenek ve gerçekten ön plana çıkan birçok yeni teknoloji görüyorum. Ve bu gerçekten üçüncü sütun olan veri çeşitliliği ile ilgilidir.
Başka bir deyişle, günümüzde çoğu şirket yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verilere bakmaktadır. Görüntü verileri sıcak bir konu olmaya başlıyor, bu nedenle bilgisayar vizyonunu kullanabilmek, piksellere bakabilmek, metin kazıyabilmek, NLP, varlık çıkarma, istatistiksel modellerden çıkan veya semantikten gelen grafik bilgileriniz var modellerde, tablolarda var olan ilişkisel verileriniz var vb. Ve böylece tüm bu verileri bir araya getirmek ve tüm bu farklı türler gerçekten büyük bir meydan okumayı temsil ediyor ve bunu Gartner'da ve sektördeki eğilimleri takip eden diğer insanlarda göreceksiniz.
Ve sonra insanların büyük verilerde bahsettikleri son şey, genellikle verilerinizin belirsizliği, belirsizliği olan bu voracity nosyonudur. Verilerinizin ne hakkında olduğunu ne kadar iyi biliyorsunuz, orada ne olduğunu ne kadar iyi anlıyorsunuz ve biliyor musunuz? İstatistikleri kullanabilme ve bildikleriniz etrafında bir tür bilgiyi kullanabilme veya bir bağlamı kullanabilme yeteneği burada değerli olabilir. Ve böylece verilere ne kadar sahip olduğunuz, ne kadar hızlı hareket ettirmeniz veya ona ulaşmanız gerektiği, kuruluşunuzda sahip olabileceğiniz tüm veri türleri ve nerede olduğunuz konusunda ne kadar emin olduğunuz açısından verilere bu şekilde bakma yeteneği bu, ne olduğu, hangi kalitede olduğu vb. Bu, artık verilerini etkili bir şekilde yönetmek için birçok kişi arasında büyük ve koordineli bir çaba gerektiriyor. Bu nedenle, verilerin modellenmesi günümüz dünyasında giderek daha fazla önem kazanmaktadır. Bu nedenle, iyi veri modelleri kurumsal uygulamalarda gerçekten çok başarılı oluyor.
Söylediğimiz gibi, gerçekten çok farklı entegrasyon türleri gerektiren çeşitli kaynaklardan veri kaynaklarınız var. Bu nedenle, hepsini bir araya getirmek, örneğin çok sayıda veri kaynağı arasında sorgu çalıştırabilmek ve bilgileri geri çekmek için gerçekten yararlıdır. Ancak bunu yapmak için iyi haritalama stratejilerine ihtiyacınız vardır ve bu nedenle bu tür verileri haritalamak ve bu haritalara uymak gerçek bir zorluk olabilir. Ve sonra, eski verilerimi tüm bu yeni veri kaynaklarına nasıl bağlarım? Diyelim ki grafiğim var, tüm ilişkisel verilerimi alıp grafiğe koyabilir miyim? Genellikle bu iyi bir fikir değildir. Peki insanlar nasıl oluyor da tüm bu tür veri modellerini yönetebiliyorlar? Analiz gerçekten bu farklı veri kaynakları ve kombinasyonlarının birçoğunda yürütülmelidir. Bundan çıkan cevaplar, insanların gerçekten iyi iş kararları almak için ihtiyaç duydukları cevaplar kritiktir.
Yani bu sadece teknoloji uğruna teknoloji inşa etmekle ilgili değil, gerçekten, ne yapacağım, onunla ne yapabilirim, ne tür bir analiz yapabilirim ve bu nedenle, zaten yaptığım gibi yetenek hakkında konuşmak, bu şeyleri bir araya getirmek, bütünleştirmek gerçekten çok önemli. Ve bu tür analizlerden biri federe arama ve sorgu gibi şeyler üzerinde çalışır. Bu gerçekten bir zorunluluk haline geliyor. Sorgularınız normalde birden fazla türde kaynakta işlenmeli ve bilgileri güvenilir bir şekilde geri almalıdır.
Sık sık, özellikle insanların semantik teknolojiler gibi önemli şeylere bakacağı tek önemli unsur - ve bu Ron'un IDERA yaklaşımında biraz konuşacağını umduğum bir şey - veri katmanından veri katmanından, bu ham verilerden model katmanı? Veri katmanında veritabanlarınız olabilir, belge verileriniz olabilir, elektronik tablo verileriniz olabilir, görüntü verileriniz olabilir. İlaç endüstrisi gibi alanlardaysanız, çok miktarda bilimsel veriye sahipsiniz. Ve sonra bu insanların üstünde normalde bu verileri hızlı bir şekilde entegre etmelerini sağlayan bir model oluşturmanın bir yolunu ararlar ve gerçekten veri ararken artık tüm verileri model katmanınıza çekmek istemezsiniz., model katmanına bakacağınız şey, size, şeylerin ne olduğu hakkında güzel bir mantıksal temsil, ortak kelimeler, ortak varlık ve ilişkiler türleri ve verilerin bulunduğu yere gerçekten ulaşma yeteneği vermektir. Bu yüzden ne olduğunu söylemek zorunda ve nerede olduğunu söylemek zorunda ve nasıl getirileceğini ve geri getireceğini söylemek zorunda.
Dolayısıyla bu, semantik teknolojilerin ileriye doğru itilmesinde oldukça başarılı olan bir yaklaşım oldu, bu da çok çalıştığım bir alan. Ron için poz vermek istediğim ve soru-cevap bölümünde faydalı olacağını düşündüğüm bir soru, bunun IDERA platformu tarafından nasıl başarıldığını görmek mi? Model katmanı aslında veri katmanından ayrı mı? Daha entegre mi? Bu nasıl çalışır ve yaklaşımlarından gördükleri sonuç ve faydalardan bazıları nelerdir? Bu nedenle referans verileri gerçekten de kritik hale geliyor. Dolayısıyla, bu tür veri modellerine sahip olacaksanız, bir şeyler birleştirip arayabilecekseniz, gerçekten iyi referans verilere sahip olmanız gerekir. Ancak sorun referans verilerinin korunması gerçekten zor olabilir. Bu nedenle, çoğu zaman kendi başlarına standartları adlandırmak zor bir iştir. Bir grup X, bir grup Y diyecek ve şimdi bu tür bilgileri ararken birinin X ve Y'yi nasıl bulduğu sorunu var mı? Onlara verilerin bir kısmını vermek istemediğiniz için, onlara ilgili her şeyi vermek istersiniz. Aynı zamanda terimler değişir, yazılım kullanımdan kaldırılır ve bu şekilde zaman içinde bu referans verilerini nasıl koruyabilir ve koruyabilirsiniz?
Ve yine, semantik teknolojiler, özellikle taksonomiler ve kelime hazineleri, veri sözlükleri gibi şeyleri kullanarak, bunu yapmak için standart bir alan yolu sağladı, ki bu gerçekten çok sağlam, belirli standart türlerini kullanıyor, ancak veritabanı topluluğu bunu uzun bir süre, sadece farklı şekillerde. Buradaki anahtarlardan birinin belki de varlık-ilişki modellerinin nasıl kullanılacağını, belki de grafik modellerin nasıl kullanılacağını veya burada gerçekten umarım referans verilerinizi işlemek için standart aralıklı bir yol verecek bir yaklaşım türünü düşünmek olduğunu düşünüyorum. Ve sonra elbette referans verilere sahip olduğunuzda, haritalama stratejileri çok çeşitli isimleri ve varlıkları yönetmelidir. Dolayısıyla konu uzmanları genellikle kendi terimlerini kullanmaktan hoşlanırlar.
Bu yüzden her zaman bir zorluk, birisine nasıl bilgi verirsiniz, ancak bunu nasıl konuştukları ile alakalı hale getirirsiniz? Yani bir grubun bir şeye bakmanın bir yolu olabilir, örneğin, bir ilaç üzerinde çalışan bir kimyager olabilirsiniz ve aynı ilaç üzerinde çalışan bir yapısal biyolog olabilirsiniz ve aynı tür varlıklar için farklı isimler olabilir sizin alanınızla ilgili. Bu kişiselleştirilmiş terminolojileri bir araya getirmenin yollarını bulmalısınız, çünkü diğer yaklaşım, insanları terimlerini bırakmaya ve genellikle sevmedikleri başkalarının terimlerini kullanmaya zorlamalısınız. Buradaki başka bir nokta da, çok sayıda eşanlamlıyı ele almak zorlaşıyor, bu yüzden birçok insanın verilerinde aynı şeye işaret edebilecek birçok farklı kelime var. Burada birebir ilişkiler kümesi kullanarak bir başvuru sorununuz var. Uzmanlaşmış terimler endüstriden sanayiye değişir, bu nedenle bu tür veri yönetimi için kapsayıcı bir çözüm bulursanız, bir projeden veya bir uygulamadan diğerine ne kadar kolay taşınabilir? Bu başka bir zorluk olabilir.
Otomasyon önemlidir ve aynı zamanda bir zorluktur. Referans verilerini elle işlemek pahalıdır. El ile eşlemeye devam etmek pahalı ve konu uzmanlarının günlük işlerini yapmayı bırakmaları ve veri sözlüklerini sürekli olarak düzeltmeleri ve tanımları yeniden güncellemeleri vb. Tekrarlanabilir sözcük dağarcığı gerçekten çok değer veriyor. Bunlar çoğu zaman kuruluşunuzun dışında bulabileceğiniz kelime dağarcığıdır. Örneğin ham petrolde çalışıyorsanız, açık kaynak alanlarından ödünç alabileceğiniz, ilaçlarla aynı, bankacılık endüstrisi ile aynı ve finansal, bu tür alanların birçoğu ile aynı türden ödünç alabileceğiniz belirli türlerde kelimeler olacak. İnsanlar yeniden kullanılabilir, jenerik, tekrarlanabilir kelime dağarcığı kullanıyor.
Ve yine, IDERA aracına bakarak, bu tür standartları kullanma açısından bunu nasıl ele aldıklarını merak ediyorum. Anlambilim dünyasında, ilişkilerden en az daha geniş / daha dar standartlar sağlayan SKOS modelleri gibi şeyleri sık sık görürsünüz ve bu şeylerin ER modellerinde yapılması zor olabilir, ancak biliyorsunuz, imkansız değil, bunun ne kadarına bağlı makine ve bu tür sistemlerde işleyebileceğiniz bağlantı.
Son olarak, sektörde gördüğüm bazı semantik motorlarla bir karşılaştırma yapmak istedim ve Ron'a IDERA'nın sisteminin herhangi bir semantik teknolojiyle birlikte nasıl kullanıldığından bahsetmek için biraz sormasını istedim. Üçlü mağazalar, grafik veritabanları ile entegre edilebilir mi? Semantik dünyadaki bu tür şeyler genellikle SPARQL Bitiş Noktaları kullanılarak ödünç alınabildiğinden, harici kaynakları kullanmak ne kadar kolay? RDF veya OWL modellerini doğrudan modelinize aktarabilirsiniz - onlara geri dönün - böylece, örneğin, kendi yönetişim yapısı ile kendi alanında bir yerde yaşayabilen gen ontolojisi veya protein ontolojisi ve hepsini içe aktarabilirim veya bunun bir parçası olarak kendi modellerime ihtiyacım var. IDERA'nın bu konuya nasıl yaklaştığını merak ediyorum. Her şeyi dahili olarak korumak zorunda mısınız, yoksa başka tür standart modeller kullanmak ve onları çekmek için yollar var mı ve bu nasıl çalışıyor? Ve burada bahsettiğim son şey, sözlükleri ve meta veri depolarını oluşturmak için ne kadar manuel çalışmanın gerçekten dahil olduğudur?
Ron'un bize bu tür şeyler hakkında gerçekten ilginç olacak demolar göstereceğini biliyorum. Ancak sık sık müşterilere danıştığımı gördüğüm problemler, insanlar kendi tanımlarında veya kendi meta verilerinde yazıyorlarsa birçok hata oluşmasıdır. Yani yanlış yazımlar alıyorsunuz, şişman parmak hataları alıyorsunuz, bu bir şey. Ayrıca, sadece Wikipedia'dan veya tanımınızda isteyebileceğiniz kaliteye sahip olmayan bir kaynaktan bir şey alabilecek insanlara sahip olursunuz veya tanımınız yalnızca bir kişinin bakış açısındandır, bu yüzden tam değildir ve o zaman net değildir. yönetişim süreci nasıl işliyor. Yönetişim, elbette, referans verilerden bahsederken ve bunun birisinin ana verilerine nasıl uyduğundan, meta verilerini nasıl kullanacağından ve her zaman konuştuğunuzda çok, çok büyük bir sorun olmak ve yakında.
Bu yüzden bu konuların bazılarını ortaya koymak istedim. Bunlar, birçok farklı danışmanlık sözleşmesi ve birçok farklı alanda iş alanında gördüğüm öğelerdir ve Ron'un bu konulardan bazılarını belirtmek için IDERA ile bize neler göstereceğini gerçekten görmek istiyorum. . Çok teşekkür ederim.
Rebecca Jozwiak: Çok teşekkürler Eric ve yorumunuzu beğendim, insanlar kendi tanımlarını veya meta verilerini yazıyorlarsa birçok hata oluşabilir. Gazetecilik dünyasında “pek çok gözün hata yapmadığı bir mantra” olduğunu biliyorum, ancak pratik uygulamalar söz konusu olduğunda, çerez kavanozundaki çok fazla el sizi çok fazla kırık kurabiye bırakma eğilimindedir, değil mi?
Eric Little: Evet ve mikroplar.
Rebecca Jozwiak: Evet. Bununla devam edip Malcolm Chisholm'a göndereceğim. Malcolm, yer senin.
Malcolm Chisholm: Çok teşekkür ederim Rebecca. Eric'in ne hakkında konuştuğuna biraz bakmak istiyorum ve bilirsiniz, Ron'un “İş Odaklı Veri Mimarisine Doğru” konusunda da yanıt vermeyi umabileceği birkaç gözlem eklemek istiyorum. ”- iş odaklı olmak ne demektir ve bu neden önemlidir? Yoksa sadece bir tür hype mı? Ben öyle düşünmüyorum.
Bildiğiniz gibi, ana bilgisayar bilgisayarları şirketler için - yani 1964 civarında - bugün için gerçekten kullanılabilir hale gelirse, bugüne kadar birçok değişiklik olduğunu görebiliriz. Ve bu değişiklikleri süreç odaklılıktan veri odaklılığa doğru bir değişim olarak özetleyeceğim. İşte iş odaklı veri mimarilerini bugün için bu kadar önemli ve alakalı kılan da budur. Ve bence, bilirsiniz, bu sadece bir sözcük değil, kesinlikle gerçek bir şey.
Ancak tarihe daldığımızda biraz daha fazla takdir edebiliriz, bu yüzden zamana, 1960'lara kadar geri dönüp bir süre sonra ana çerçeveler hakim oldu. Bunlar daha sonra PC'ler geldiğinde kullanıcılara gerçekten isyan ettiğiniz PC'lere yol açtı. İhtiyaçlarını karşılamadığını düşündükleri merkezi BT'ye karşı isyan yeterince çevik değildi. Bu, bilgisayarlar birbirine bağlandığında hızlı bir şekilde dağıtılmış bilgi işleme yol açtı. Ve daha sonra, işletmenin sınırlarını bulanıklaştıran internet olmaya başladı - şimdi daha önce gerçekleşmemiş olan veri alışverişi açısından kendi dışındaki taraflarla etkileşime girebilir. Ve şimdi bulutun ve altyapının metalaştıran platformlar olduğu bulut ve büyük veri çağına girdik ve bu yüzden büyük veri merkezleri çalıştırma ihtiyacının IT'sini bırakıyoruz çünkü biliyorsunuz, biz Bulut kapasitesini bize ulaştı ve Eric'in sahip olduğu büyük verilerle eşzamanlı olarak çok iyi tartışıldı. Ve genel olarak, gördüğümüz gibi, teknolojideki değişim gerçekleştikçe, veri merkezli hale geldi, veriye daha fazla önem veriyoruz. İnternette olduğu gibi, verilerin nasıl paylaşıldığı. Büyük verilerle, verilerin kendisinin dört veya daha fazla v'si.
Aynı zamanda ve belki de daha önemlisi, iş kullanım durumları değişti. Bilgisayarlar ilk tanıtıldığında, kitaplar ve kayıtlar gibi şeyleri otomatikleştirmek için kullanıldılar. Ve manuel bir süreç olan, defterleri veya bunun gibi şeyleri içeren her şey, esasen evde programlandı. Bu 80'lerde operasyonel paketlerin kullanılabilirliğine geçti. Artık kendi bordronuzu yazmanıza gerek yoktu, bunu yapan bir şey satın alabilirsiniz. Bu, birçok BT departmanında o sırada büyük bir küçülme veya yeniden yapılandırma ile sonuçlandı. Ancak daha sonra 90'lı yıllarda veri ambarları gibi şeylerle iş zekası ortaya çıktı. Bunu tabii ki büyük bir çılgınlık olan dotcom iş modelleri izledi. Sonra MDM. MDM ile otomasyon hakkında düşünmediğimizi görmeye başlarsınız; aslında verileri veri olarak iyileştirmeye odaklanıyoruz. Ve sonra analitik, verilerden elde edebileceğiniz değeri temsil eder. Analitikte, temel iş modeli veriler etrafında dönen çok başarılı şirketleri görüyorsunuz. Google, Twitter, Facebook bunun bir parçası olurdu, ancak Walmart'ın da olduğunu iddia edebilirsiniz.
Ve iş şimdi verileri gerçekten düşünüyor. Verilerden nasıl değer alabiliriz? Verilerin işi, stratejiyi nasıl yönlendirebileceği ve verilerin altın çağındayız. Öyleyse, veri artık uygulamaların arka ucundan çıkan egzoz olarak kabul edilmiyorsa, ancak iş modellerimizin merkezinde yer alıyorsa, veri mimarimiz açısından neler oluyor? Bunu başarmada yaşadığımız sorunun bir kısmı, BT'nin erken yaşlarında bu süreç otomasyon aşamasıyla hızlı bir şekilde başa çıkmanın ve çalışmanın bir sonucu olan sistem geliştirme yaşam döngüsüyle geçmişte gerçekten sıkışmış durumda. projeler benzer bir şeydir. BT'ye - ve bu biraz karikatür - ama söylemeye çalıştığım şey, iş odaklı bir veri mimarisi elde etmenin önündeki bazı engellerin, BT'de bir kültürü eleştirel olarak kabul etmememiz. geçmiş yaştan türemiştir.
Yani her şey bir proje. Gereksinimlerinizi ayrıntılı olarak anlatın. İşler işe yaramazsa, bunun nedeni bana gereksinimlerinizi söylemediniz. Bu, bugün verilerle çalışmaz, çünkü otomatik olmayan manuel süreçlerle başlamıyoruz veya iş süreçlerinin teknik bir dönüşümü ile başlamıyoruz, zaten denediğimiz mevcut üretim verileriyle çok sık başlıyoruz değer almak. Ancak veri merkezli bir projeye sponsor olan hiç kimse bu verileri derinlemesine anlamıyor. Veri keşfi yapmalıyız, kaynak veri analizi yapmalıyız. Ve bu, sistem geliştirme ile gerçekten uyuşmuyor, bilirsiniz - şelale, SDLC yaşam döngüsü - Agile'ın koruyacağı, bunun bir tür daha iyi bir versiyonu.
Ve odaklanılan şey veri değil teknoloji ve işlevselliktir. Örneğin, bir test aşamasında test yaptığımızda, tipik olarak, işlevselliğim işe yarıyor mu, diyelim ki ETL'm, ancak verileri test etmiyoruz. Gelen kaynak verilerle ilgili varsayımlarımızı test etmiyoruz. Eğer olsaydık, belki daha iyi durumda olurduk ve veri ambarı projeleri yapan ve yukarı yönlü değişiklikler yapan, ETL'leri bozan biri olarak bunu takdir ediyorum. Aslında, görmek istediğimiz, sürekli üretim veri kalitesi izlemenin ön adımı olarak test etmektir. Burada, iş odaklı veri mimarisine ulaşmanın zor olduğu bir sürü tutumumuz var, çünkü süreç odaklılık çağına bağlıyız. Veri odaklılığa geçiş yapmamız gerekiyor. Ve bu tam bir geçiş değil, bilirsiniz, hala orada yapılacak çok fazla işlem var, ama gerçekten ihtiyaç duyduğumuzda veri merkezli terimlerle düşünmüyoruz ve gerçekten bunu yapmak zorunda.
Şimdi iş, verilerin değerini fark ediyor, verilerin kilidini açmak istiyorlar, peki bunu nasıl yapacağız? Peki geçişi nasıl yapacağız? Verileri geliştirme süreçlerinin merkezine koyduk. Ve işin bilgi gereksinimleriyle liderlik etmesine izin veriyoruz. Ve projenin başlangıcında hiç kimsenin mevcut kaynak verilerini anlamadığını anlıyoruz. Veri yapısının ve verinin kendisinin sırasıyla BT ve operasyonlar yoluyla oraya geldiğini iddia edebilirsiniz, bu yüzden bunu bilmeliyiz, ama gerçekten bilmiyoruz. Bu veri merkezli bir gelişmedir. Bu nedenle, veri merkezli bir dünyada nerede ve nasıl modelleme yapacağımızı düşünürken, veri keşfi ve veri profili oluşturma gibi kullanıcılara bilgi gereksinimlerini artırma açısından geri bildirim döngüleri oluşturmak zorundayız., kaynak veri analizini öngörebilir ve yavaş yavaş verilerimiz hakkında daha fazla kesinliğe sahip oluruz. Ve şimdi bir MDM merkezi veya veri ambarı gibi daha geleneksel bir projeden bahsediyorum, illa ki büyük veri projeleri olmak zorunda değil, buna rağmen hala buna çok yakınım. Ve böylece bu geri bildirim döngüleri, veri modelcilerini içerir, bilirsiniz, veri modellerini yavaş yavaş ilerletir ve kullanıcı gereksinimlerini, daha iyi anladıkça kaynak verilerden neyin mümkün olduğuna, neyin mevcut olduğuna dayanarak iyileştirildiğinden emin olmak için kullanıcılarla etkileşimde bulunur. artık veri modelinin bir örneği değil, bilirsiniz, orada olmayan ya da tamamen yapılan bir durumda, yavaş yavaş buna odaklanılması.
Benzer şekilde, daha aşağı yönde ise, verilerin varsayımlarda bulunduğumuz parametreler dahilinde olduğundan emin olmak için veri kalitesi testi için kurallar geliştirdiğimiz kalite güvencesine sahibiz. İçeri girerken Eric, olabilecek referans verilerindeki değişikliklerden bahsediyordu. Olduğu gibi, o bölgede bir tür yönetilmeyen değişikliğin aşağı kurbanı olmak istemezsiniz, böylece kalite güvence kuralları üretim sonrası, sürekli veri kalitesi izlemesine girebilir. Böylece, veri merkezli olup olmayacağımızı, veri merkezli geliştirmeyi nasıl yaptığımızı işlevselliğe dayalı SDLC ve Agile'dan oldukça farklı görmeye başlayabilirsiniz. Sonra iş görüşlerine de dikkat etmeliyiz. Veritabanımız için bir veri hikayesi taslağını tanımlayan bir veri modelimiz var - ve aynı zamanda bu kavramsal modellere, geleneksel olarak yapılmayan verilerin iş görüşlerine ihtiyacımız var - ve yine bu, geçmiş. Bazen veri modelinin her şeyi yapabileceğini düşündük, ancak kavramsal görünüme, anlambilime ve verilere bakmamız, depolama modelini işletmeye çeviren bir soyutlama katmanı haline getirmemiz gerekiyor. görünüm. Ve yine, Eric'in anlambilim açısından bahsettiği her şey bunu yapmak için önemli hale geliyor, bu yüzden aslında ek modelleme görevlerimiz var. Sanırım bu, benim gibi bir veri modelleyici olarak tekrar sıralarsanız ve yine yeni bir şey çıkarırsanız ilginç.
Son olarak, daha büyük mimarinin de bu yeni gerçeği yansıtması gerektiğini söylemek istiyorum. Örneğin geleneksel müşteri MDM'si, tamam, müşteri verilerimizi, arka ofis uygulamaları için gerçekten sadece veri kalitesi açısından anlamlandırabileceğimiz bir merkez haline getirelim. Bir iş stratejisi açısından bir tür esnektir. Ancak bugün, yalnızca statik verilerde değil, müşteri işlem uygulamaları ile gerçekten çift yönlü bir arayüze sahip olan ek müşteri profili verisi olan müşteri MDM merkezlerine bakıyoruz. Evet, hala arka ofisi destekliyorlar, ancak şimdi müşterilerimizin bu davranışlarını da biliyoruz. Bu inşa etmek daha pahalıdır. Bu inşa etmek daha karmaşıktır. Ancak, geleneksel müşteri MDM'sinin olmadığı bir şekilde iş odaklı. Uygulanması daha kolay olan daha basit tasarımlara karşı işe yöneliyorsunuz, ancak iş için görmek istedikleri şey bu. Gerçekten yeni bir çağdayız ve bence iş odaklı veri mimarisine yanıt vermemiz gereken birkaç seviye var ve bence bir şeyler yapmak için çok heyecan verici bir zaman.
Çok teşekkür ederim, sana geri Rebecca.
Rebecca Jozwiak: Teşekkürler Malcolm, ve veri modelleri hakkında söylediklerinizden gerçekten zevk aldım, çünkü iş görüşünü beslemeliyiz, çünkü söylediklerinizin aksine, BT'nin dizginleri bu kadar uzun süre tuttuğu ve artık bu durumda değil ve kültürün değişmesi gerekiyor. Ve eminim arka planda% 100 sizinle aynı fikirde olan bir köpek vardı. Ve bununla topu Ron'a vereceğim. Demoyu görmek gerçekten heyecanlı. Ron, zemin senin.
Ron Huizenga: Çok teşekkür ederim ve buna girmeden önce, birkaç slayttan sonra biraz demodan geçeceğim çünkü Eric ve Malcolm'un işaret ettiği gibi, bu çok geniş ve derin bir konudur ve bugün bahsettiğimiz şeyle sadece yüzeyini kazıyorduk çünkü iş odaklı bir mimariden gerçekten düşünmemiz ve bakmamız gereken çok fazla yön ve çok şey var. Ve yaklaşımımız, bu model tabanlı ve modellerden gerçek değeri elde etmektir, çünkü bunları bir iletişim aracı olarak ve diğer sistemleri etkinleştirmek için bir katman olarak kullanabilirsiniz. İster hizmet odaklı mimari, isterse başka şeyler yapıyor olun, model, etrafındaki tüm meta veriler ve işinizde sahip olduğunuz verilerle gerçekten neler olup bittiğinin can damarı haline gelir.
Bununla ilgili konuşmak istediğim, bunu neredeyse bir adım geriye atıyor, çünkü Malcolm çözümlerin gelişmesinin bazı tarihçelerine ve bu tür şeylere değinmişti. Sağlam bir veri mimarisine sahip olmanın ne kadar önemli olduğunu belirtmenin bir yolu, bir ürün yönetimi rolüne girmeden önce danışmanlık yaparken çok sık karşılaştığım bir kullanım durumudur ve bu, organizasyonlara girerdim ister iş dönüşümü yapıyorlar, ister sadece bazı mevcut sistemleri ve bu tür şeyleri değiştiriyorlardı ve kuruluşların kendi verilerini ne kadar kötü anladıkları çok hızlı bir şekilde ortaya çıktı. Bunun gibi özel bir kullanım örneği alırsanız, bir danışman giriyor olsanız da, belki de bir kuruluşla yeni başlamış bir kişi olsanız da, kuruluşunuz yıllar içinde farklı şirketler edinerek inşa edilmiştir, ne yaparsanız yapın eski teknolojiler, ERP çözümleri ve diğer her şeyin yanı sıra bir dizi yeni farklı teknolojiyle çok hızlı bir şekilde çok karmaşık bir ortamdır.
Modelleme yaklaşımımızla gerçekten yapabileceğimiz şeylerden biri, tüm bunları nasıl anlamlandırabilirim? Bilgileri gerçekten bir araya getirmeye başlayabiliriz, böylece işletme sahip olduğumuz bilgileri doğru şekilde kullanabilir. Ve ortaya çıkıyor, bu ortamlarda orada ne var? Modelleri, ihtiyacım olan bilgiyi dışarı çıkarmak ve bu bilgileri daha iyi anlamak için nasıl kullanabilirim? Ve sonra ilişkisel veri modelleri gibi tüm farklı şeyler için geleneksel meta veri türlerine sahibiz ve tanımlamalar ve veri sözlükleri, bilirsiniz, veri türleri ve bu tür şeyler gibi şeyleri görmeye alışkınız. Peki, gerçekten daha fazla anlam vermek için yakalamak istediğiniz ek meta verilere ne dersiniz? Hangi varlıklar gerçekten referans veri nesneleri olması gereken adaylardır, bunlar ana veri yönetimi nesneleri ve bu tür şeyler olmalı ve bunları birbirine bağlamalı. Ve bilgi kuruluştan nasıl akar? Veriler, hem süreç açısından nasıl tüketildiklerinden hem de işletmelerimiz aracılığıyla bilgi yolculuğu ve farklı sistemler veya veri depoları aracılığıyla nasıl ilerlediğine göre veri soyundan akar, bu yüzden biliyoruz ki gerçekte eldeki görev için doğru bilgileri tükettiğimiz I-çözümlerini veya bu tür şeyleri oluştururken.
Ve daha da önemlisi, tüm bu paydaşların ve özellikle de iş paydaşlarının nasıl işbirliği yapmasını sağlayabiliriz, çünkü bu verilerin ne olduğu hakkında bize gerçek anlamını veren onlar. İş, günün sonunda verilere sahiptir. Eric'in bahsettiği kelime dağarcığı ve şeyler için tanımları sağlarlar, bu yüzden hepsini birbirine bağlayacak bir yere ihtiyacımız var. Bunu yapma şeklimiz veri modelleme ve veri deposu mimarilerimiz aracılığıyla gerçekleşir.
Birkaç şeye değineceğim. ER / Studio Enterprise Team Edition hakkında konuşacağım. Öncelikle veri modelleme ve bu tür bir şey yaptığımız veri mimarisi ürünü hakkında konuşacağım, ancak paketin çok kısa bir süre içinde değineceğim diğer birçok bileşeni var. İş Mimarının kavramsal modeller yapabileceğimiz bir parçasını göreceksiniz, ancak iş süreci modelleri de yapabiliriz ve bu süreç modellerini veri modellerimizde bulunan gerçek verileri bağlamak için bağlayabiliriz. Bu bağı bir araya getirmemize gerçekten yardımcı oluyor. Software Architect, bahsettiğimiz diğer sistem ve süreçlerin bazılarına destekleyici mantık vermek için bazı UML modelleme ve bu tür şeyler gibi ek yapılar yapmamıza izin verir. Ama çok önemlisi, aşağı inerken depo ve takım sunucumuz var ve ben de aynı şeyin iki yarısı gibi konuşacağım. Depo, iş sözlükleri ve şartları açısından modellenen tüm meta verileri ve tüm iş meta verilerini depoladığımız yerdir. Ve bu depo tabanlı ortama sahip olduğumuz için, tüm bu farklı şeyleri aynı ortamda birleştirebiliriz ve daha sonra bunları sadece teknik kişiler için değil, iş adamları için de tüketimler için kullanılabilir hale getirebiliriz. İşte bu şekilde işbirliğini artırmaya başlıyoruz.
Ve sonra kısaca konuşacağım son parça, bu ortamlara girdiğinizde, sadece orada bulunan veritabanları değil. Bir dizi veritabanına, veri deposuna sahip olacaksınız, aynı zamanda bir sürü, ne diyeceğim, eski eserlere de sahip olacaksınız. Belki insanlar bazı şeyleri haritalamak için Visio ya da diğer diyagramları kullanmışlardır. Belki başka modelleme araçları ve bu tür şeyler vardı. MetaWizard ile yapabileceğimiz şey aslında bu bilgilerin bir kısmını çıkarmak ve bunları modellerimize getirmek, güncel hale getirmek ve onu kullanabilmek yerine mevcut bir şekilde tekrar kullanabilmek. Şimdi çok önemli olan çalışma modellerimizin aktif bir parçası oluyor.
Dediğim gibi, bir organizasyona girdiğinizde orada birçok farklı sistem var, bir çok ERP çözümü, uyumsuz departman çözümleri. Birçok kuruluş aynı zamanda harici olarak kontrol edilen ve yönetilen SaaS çözümlerini de kullanıyor, bu nedenle veritabanlarını ve ana bilgisayarlardaki bu tür şeyleri bunlarda kontrol etmiyoruz, ancak yine de bu verilerin neye benzediğini bilmemiz gerekiyor ve elbette, bunun üstündeki meta veriler. Ayrıca bulduğumuz şey, Malcolm'un bahsettiği proje tabanlı yaklaşım nedeniyle temizlenmemiş eski eski sistemler. Son yıllarda kuruluşların projeleri nasıl hızlandıracakları, bir sistemi veya çözümü nasıl değiştirecekleri şaşırtıcı, ancak genellikle eski çözümleri devre dışı bırakmak için yeterli proje bütçesi yok, bu yüzden şimdi sadece yolundalar. Ve çevremizde gerçekte nelerden kurtulabileceğimizi ve ileride faydalı olanı bulmalıyız. Ve bu zayıf hizmetten çıkarma stratejisine bağlanır. Bu aynı şeyin parçası ve parselidir.
Ayrıca bulduğumuz şey, tüm bu farklı çözümlerden çok sayıda kuruluş kurulduğundan, birçok yerde dolaşan birçok veriye sahip çok sayıda noktadan noktaya arayüz görüyoruz. Doğru bilgileri sunmak için hizmet odaklı mimarinin kullanımı, kurumsal hizmet otobüsleri ve bu tür şeyler gibi daha uyumlu bir stratejiye sahip olabilmemiz için bunu rasyonelleştirebilmeli ve daha önce kısaca bahsettiğim veri soyunu anlayabilmeliyiz. işimizde doğru şekilde kullandığımız bir yayınla ve abone ol modeline. Ve sonra, ister veri ambarları, ister geleneksel ETL'li veri pazarları kullanıyor olun ister yeni veri göllerinden bazılarını kullansak da, elbette bir çeşit analiz yapmamız gerekiyor. Her şey aynı şeye iniyor. Tüm veriler, büyük veriler olsun, ilişkisel veritabanlarındaki geleneksel veriler olsun, tüm verileri bir araya getirmemiz gerekir, böylece bunları yönetebilir ve modellerimiz boyunca neyle uğraştığımızı biliriz.
Yine yapacağımız karmaşıklık, yapabilmek istediğimiz birkaç adımımız var. Her şeyden önce, içeri girersiniz ve bu bilgi manzarasının nasıl göründüğüne dair taslaklarınız olmayabilir. ER / Studio Data Architect gibi bir veri modelleme aracında, ilk önce orada bulunan veri kaynaklarına işaret edip, onları getirip daha sonra onları daha temsili bir araya getirme açısından çok fazla ters mühendislik yapacaksınız. tüm işletmeyi temsil eden modeller. Önemli olan, bu modelleri iş kollarında da parçalayabilmek istiyoruz, böylece onlarla iş adamlarımızın da ilişki kurabileceği daha küçük parçalarla ve iş analistlerimiz ile çalışan diğer paydaşlarımızla bağlantı kurabiliriz. üstünde.
Adlandırma standartları son derece önemlidir ve burada birkaç farklı yoldan bahsediyorum. Modellerimizde şeyleri nasıl adlandırdığımız açısından standartları adlandırmak. Modellerimiz için iyi bir adlandırma kuralına ve iyi bir veri sözlüğüne sahip olduğumuz mantıksal modellerde yapmak oldukça kolaydır, ancak daha sonra, getirdiğimiz bu fiziksel modellerin çoğu için farklı adlandırma kuralları görüyoruz. tersine mühendis, sıklıkla kısaltılmış isimler ve konuşacağım bu tür şeyleri görüyoruz. Ve çevrede sahip olduğumuz tüm bu veri parçalarının ne olduğunu anlayabilmemiz için bunları iş için anlamlı anlamlı İngilizce isimlere dönüştürmeliyiz. Ve sonra evrensel eşlemeler onları nasıl birleştirdiğimizdir.
Bunun üzerine, daha sonra belgeleyeceğiz ve daha ayrıntılı tanımlayacağız ve verilerimizi Ekler adı verilen bir şeyle daha da sınıflandırabileceğimiz, size birkaç slayt göstereceğim. Ve sonra döngüyü kapatarak, iş sözlüğümüzde bağlandığımız ve bunları farklı model eserlerimize bağlayabildiğimiz iş anlamını uygulamak istiyoruz, bu yüzden biliyoruz ki, belirli bir iş teriminden bahsederken, kuruluşumuzdaki verilerimize uygulanmaktadır. Ve son olarak, zaten tüm bunların çok fazla işbirliği ve yayınlama kapasitesine dayanan bir depoya ihtiyacımız olduğu gerçeğinden bahsettim, böylece paydaşlarımız bunu kullanabilir. Tersine mühendislik hakkında oldukça hızlı bir şekilde konuşacağım. Sana bununla ilgili çok hızlı bir vurgu yaptım. Size gerçek bir demoda göstereceğim ve size oraya getirebileceğimiz bazı şeyleri göstereceğim.
Ve bu tür bir senaryoda üreteceğimiz bazı farklı model türleri ve diyagramları hakkında konuşmak istiyorum. Açıkçası kavramsal modelleri pek çok durumda yapacağız; Bunun için fazla zaman harcamayacağım. Gerçekten mantıksal modeller, fiziksel modeller ve yaratabileceğimiz özel tip modeller hakkında konuşmak istiyorum. Bunları aynı modelleme platformunda oluşturabilmemiz önemlidir, böylece bunları bir araya getirebiliriz. Boyutsal modelleri ve ayrıca size göstereceğim NoSQL gibi yeni veri kaynaklarından bazılarını kullanan modelleri içerir. Ve sonra, veri köken modeli neye benziyor? Ve bu verileri bir iş süreci modeline nasıl ekleriz, bundan sonra bahsedeceğimiz şeydir.
Size çok yüksek ve hızlı bir genel bakış sunmak için burada bir modelleme ortamına geçeceğim. Ve şimdi ekranımı görebilmen gerektiğine inanıyorum. Her şeyden önce sadece geleneksel bir veri modeli türü hakkında konuşmak istiyorum. Modelleri getirirken modelleri organize etmek istediğimiz yol, onları parçalayabilmek istiyoruz. Burada sol tarafta gördüğünüz, bu model dosyasında mantıksal ve fiziksel modellerimiz var. Bir sonraki şey, onu iş ayrışmaları boyunca parçalayabilmemizdir, bu yüzden klasörleri görüyorsunuz. Açık mavi olanlar mantıklı, yeşil olanlar ise fiziksel modellerdir. Ve biz de detaya inebiliriz, bu yüzden ER / Studio'da, bir iş ayrışmanız varsa, istediğiniz kadar derin veya alt modele gidebilirsiniz ve daha düşük seviyelerde yaptığınız değişiklikler otomatik olarak daha yüksek seviyelere yansır. seviyeleri. Böylece çok hızlı bir şekilde çok güçlü bir modelleme ortamı haline gelir.
Bu bilgiyi bir araya getirmeye başlamanın çok önemli olduğunu belirtmek istediğim bir şey de, bir mantıksal modele karşılık gelen birden fazla fiziksel modelimiz olabilir. Çoğu zaman mantıklı bir modeliniz olabilir, ancak farklı platformlarda ve bu tür şeylerde fiziksel modelleriniz olabilir. Belki biri SQL Server örneğidir, belki diğeri Oracle örneğidir. Tüm bunları aynı modelleme ortamında bir araya getirme yeteneğine sahibiz. Ve yine, burada elde ettiğim şey, yine aynı modelleme ortamında olabilen ya da depoda yer alan ve farklı şeylere bağlayabilen gerçek bir veri ambarı modeli.
Size bu konuda gerçekten göstermek istediğim şey, girdiğimiz modellerin diğer şeyleri ve diğer varyantları. Dolayısıyla, bunun gibi geleneksel bir veri modeline girdiğimizde, sütunlarla ve meta verilerle ve bu tür bir şeyle tipik varlıkları görmeye alışırız, ancak bu yeni NoSQL teknolojilerinden bazılarıyla uğraşmaya başladığımızda bu bakış açısı çok hızlı değişir. veya bazı insanlar hala onları aramak istedikleri gibi, büyük veri teknolojileri.
Şimdi diyelim ki çevremizde Hive var. Bir Hive ortamından mühendis tersine çevirirsek - ve bu aynı modelleme aracıyla Hive'dan mühendisleri iletebilir ve tersine çevirebilirsek - biraz farklı bir şey görürüz. Tüm verileri hala orada yapılar olarak görüyoruz, ancak TDL'lerimiz farklı. SQL'i görmeye alışkın olanlar, şimdi göreceğiniz şey, Hive QL'dir, bu da çok SQL'e benzer, ancak aynı araçtan farklı komut dilleriyle çalışmaya başlayabilirsiniz. Bu nedenle bu ortamda modelleme yapabilir, Hive ortamına dönüştürebilirsiniz, ancak en önemlisi, tanımladığım senaryoda, hepsini tersine mühendislik yapabilir ve anlamlandırabilir ve birlikte dikmeye başlayabilirsiniz. .
Biraz farklı bir tane daha alalım. MongoDB, yerel olarak desteklediğimiz bir diğer platformdur. Ve belge depolarınız olan JSON ortam türlerine girmeye başladığınızda, JSON farklı bir hayvandır ve içinde ilişkisel modellere uymayan yapılar vardır. Yakında JSON'u sorgulamaya başladığınızda gömülü nesneler ve nesnelerin gömülü dizileri gibi kavramlarla başa çıkmaya başlayacaksınız ve bu kavramlar geleneksel ilişkisel gösterimde mevcut değil. Burada yaptığımız şey aslında gösterimi ve kataloğumuzu aynı ortamda ele alabilmek için genişlettik.
Burada sol tarafa bakarsanız, varlık ve tablo gibi şeyleri görmek yerine, onlara nesne diyoruz. Ve farklı gösterimler görüyorsunuz. Burada tipik referans gösterimi türlerini hala görüyorsunuz, ancak bu şemada gösterdiğim bu mavi varlıklar aslında gömülü nesneler. Ve farklı kardinaliteler gösteriyoruz. Elmas kardinalitesi, bunun bir ucunda bir nesne olduğu anlamına gelir, ancak birinin kardinalitesi, bu ilişkiyi takip edersek, yayıncı içinde gömülü bir adres nesnesine sahip olduğumuz anlamına gelir. JSON'u sorgularken, kullanıcının içine gömülü olan nesnelerin tam olarak aynı yapısını bulduk, ancak aslında bir nesne dizisi olarak gömülü. Bunu yalnızca konektörlerin kendileri üzerinden değil, gerçek varlıklara bakarsanız, kullanıcı altında adresleri de bir dizi nesne olarak sınıflandırdığınızı göreceksiniz. Bunu nasıl getirebileceğiniz konusunda çok açıklayıcı bir bakış açısı elde edersiniz.
Ve yine, şu ana kadar sadece birkaç saniye içinde gördüğümüz, çok seviyeli geleneksel ilişkisel modeller, Hive ile aynı şeyi yapabiliriz, MongoDB ve diğer büyük veri kaynakları ile aynı şeyi yapabiliriz. iyi. Yapabileceğimiz şey, ve size bunu çok hızlı bir şekilde göstereceğim, diğer alanlardan bir şeyler getirme gerçeğinden bahsettim. Bir veritabanından bir modeli içe aktaracağımı veya ters mühendislik uygulayacağımı varsayacağım, ancak harici meta verilerden getireceğim. Size getirmeye başlayabileceğimiz tüm farklı şeylere hızlı bir bakış açısı kazandırmak için.
Gördüğünüz gibi, aslında meta verileri modelleme ortamımıza getirebileceğimiz sayısız şeyimiz var. Amazon Redshift, Cassandra, diğer büyük veri platformlarının birçoğu gibi şeylerle başlayarak, listelenenlerin çoğunu görüyorsunuz. Bu alfabetik sırada. Birçok büyük veri kaynağı ve bu tür bir şey görüyoruz. Ayrıca, bu meta verileri aslında aktarabileceğimiz birçok geleneksel veya eski modelleme ortamı görüyoruz. Buradan geçersem - ve her birine zaman geçirmeyeceğim - modelleme platformları ve veri platformları açısından onu getirebileceğimiz birçok farklı şey görüyoruz. Burada fark edilmesi gereken çok önemli bir şey, veri soyu hakkında konuşmaya başladığımızda yapabileceğimiz başka bir kısımdır, Enterprise Team Edition'da, Talend veya SQL Server Bilgi Hizmetleri eşlemeleri gibi şeyler olsun, ETL kaynaklarını da sorgulayabiliriz. aslında bunu veri soy diyagramlarımıza başlamak ve bu dönüşümlerde neler olduğuna dair bir resim çizmek. Kutudan çıktığı haliyle, aslında Enterprise Team Edition ürününün bir parçası olan 130'dan fazla farklı köprüye sahibiz, bu yüzden tüm eserleri tek bir modelleme ortamında çok hızlı bir şekilde bir araya getirmemize yardımcı oluyor.
Son olarak, veri ambarı veya herhangi bir analitik yapıyorsak, diğer yapı türlerine ihtiyacımız olduğu gerçeğini de gözden kaçıramayacağımız hakkında konuşmak istiyorum. Halen olgu tablolarımız olduğu ve boyutlarımız ve bu tür şeylere sahip olduğumuz boyutsal modeller gibi şeyler yapabilmek istiyoruz. Size de göstermek istediğim bir şey, meta verilerimizde, boyut türleri ve diğer her şeyi kategorize etmemize yardımcı olan uzantılarımız olabileceğidir. Dolayısıyla, burada boyutsal veri sekmesine bakarsam, örneğin bunlardan birinde, gördüğü model desenine göre aslında otomatik olarak algılar ve size bir boyut mu yoksa bir boyut mu olduğunu düşünüp düşünmediği konusunda bir başlangıç noktası verir. olgu tablosu. Ancak bunun ötesinde, yapabileceğimiz boyutlar içinde ve bu tür şeylerde, veri ambarı türündeki bir ortamda verileri sınıflandırmak için kullanabileceğimiz farklı boyut türlerine bile sahibiz. O kadar güçlü yetenekler ki bunu hep birlikte dikiyoruz.
Şu anda demo ortamında olduğumdan ve slaytlara geri dönmeden önce size birkaç şey göstereceğim için buna atlayacağım. ER / Studio Data Architect'e yakın zamanda eklediğimiz şeylerden biri, durumlarla karşılaştığımız - ve bu projeler üzerinde çalışırken çok yaygın bir kullanım örneğidir - geliştiriciler nesneler açısından düşünürken, verilerimiz modelciler tablolar ve varlıklar ve bu tür şeyler açısından düşünme eğilimindedir. Bu çok basit bir veri modelidir, ancak geliştiricilerin, hatta iş analistlerinin veya iş kullanıcılarının bunları farklı nesneler veya iş kavramları olarak düşünebilecekleri birkaç temel kavramı temsil eder. Bunları şimdiye kadar sınıflandırmak çok zor oldu, ancak 2016 sürümünde ER / Studio Enterprise Team Edition'da gerçekte yaptığımız şey, şimdi Business Data Objects adlı bir konseptimiz var. Yapmamızı sağlayan şey, varlık veya tablo gruplarını gerçek iş nesnelerine kapsüllememize izin vermesidir.
Örneğin, bu yeni görünümde burada aldığımız şey Satınalma Siparişi başlığı ve Sipariş Hattı artık bir araya getirilmiş, bir nesne olarak kapsüllenmiş, verileri sakladığımızda bunları bir iş birimi olarak düşünürüz ve onları bir araya getiriyoruz, böylece bunu farklı kitlelerle ilişkilendirmek artık çok kolay. Modelleme ortamında yeniden kullanılabilirler. Onlar sadece bir çizim yapısı değil, gerçek bir nesnedir, aynı zamanda modelleme perspektifinden iletişim kurduğumuzda, bunları seçici bir şekilde daraltabilir veya genişletebileceğimiz ve böylece belirli paydaş kitleleriyle diyaloglar için özetlenmiş bir görünüm üretebileceğimiz, ve elbette, burada daha fazla teknik kitle için gördüğümüz gibi daha ayrıntılı bir görünümü koruyabiliriz. Bize gerçekten iyi bir iletişim aracı sağlıyor. Şimdi gördüğümüz, çok sayıda farklı model türünü birleştirmek, bunları iş verisi nesneleri kavramı ile zenginleştirmek ve şimdi bu tür şeylere gerçekte nasıl daha fazla anlam uyguladığımız ve bunları nasıl birleştirdiğimiz hakkında konuşacağım. genel ortamlar.
Bunu yapabilmem için buraya WebEx'imi bulmaya çalışıyorum. Ve işte Hot Tech slaytlarına geri dönüyoruz. Burada birkaç slayt daha ileriye gideceğim, çünkü bunları model gösterisinde zaten görmüştünüz. Standartları hızlı bir şekilde adlandırmaktan bahsetmek istiyorum. Farklı adlandırma standartlarını uygulamak ve uygulamak istiyoruz. Yapmak istediğimiz şey, temelde bu anlamı kelimeler veya kelime öbekleri veya kısaltmalar yoluyla oluşturmak ve bunları anlamlı bir İngilizce kelime türüne bağlamak için adlandırma standartları şablonlarını depolarımızda saklayabilme yeteneğimiz var. İş terimlerini, her biri için kısaltmaları kullanacağız ve siparişi, vakaları belirleyebilir ve ön ekler ve sonekler ekleyebiliriz. Bunun tipik kullanım durumu tipik olarak insanların mantıklı bir model oluşturdukları ve daha sonra aslında kısaltmaları ve diğer her şeyi kullanıyor olabilecekleri fiziksel bir model oluşturdukları zamandır.
Güzel olan şey, bunun tersi kadar güçlü, hatta daha güçlü olması, tersine mühendislik yaptığımız bazı fiziksel veritabanlarında bu adlandırma standartlarının bazılarının ne olduğunu söyleyebilirsek, bu kısaltmaları alabilir, daha uzun hale getirebiliriz kelimeleri geri getirin ve İngilizce ifadelere geri getirin. Artık verilerimizin neye benzediğine uygun isimler türetebiliyoruz. Dediğim gibi, tipik kullanım durumu, ileriye, mantıklı ve fiziksel olarak veri depolarını ve bu tür şeyleri haritalamamızdır. Sağ taraftaki ekran görüntüsüne bakarsanız, kaynak adlarından kısaltılmış adların olduğunu ve bir adlandırma standartları şablonu uyguladığımızda, aslında daha fazla tam adımız olduğunu görürsünüz. Kullandığımız adlandırma standartları şablonuna bağlı olarak, istersek boşluklar ve her şeyi koyabiliriz. Görünmesini sağlayabiliriz, ancak modellerimize getirilmesini istiyoruz. Sadece bir şeyin ne dediğini bildiğimizde, aslında ona tanımlar eklemeye başlayabiliriz, çünkü ne olduğunu bilmedikçe, ona nasıl bir anlam verebiliriz?
Güzel olan şey, aslında her türlü şeyi yaparken bunu çağırabiliriz. Tersine mühendislikten bahsettim, tersine mühendislik yaparken standart şablon isimlerini aynı anda çağırabiliriz. Yani bir sihirbazdaki bir dizi adımda yapabileceğimiz şey, eğer sözleşmelerin ne olduğunu bilersek, fiziksel bir veritabanını tersine çevirebiliriz, onu bir modelleme ortamında fiziksel modeller olarak geri getirecektir ve bu adlandırma kurallarını da uygulayacak. Bu yüzden, çevrede karşılık gelen mantıksal modelde isimlerin İngilizce benzeri temsillerinin neler olduğunu göreceğiz. Ayrıca bunu yapabilir ve XML Şeması oluşturma ile birleştirebiliriz, böylece SOA çerçeveleri veya bu tür bir şey yapıyor olsak da, bir model alabilir ve hatta kısaltmalarımızla itebiliriz, böylece farklı adlandırma kurallarını da ekleyebiliriz aslında modelin kendisinde sakladık. Bize çok güçlü yetenekler sunuyor.
Yine, bir şablonum olsaydı nasıl görüneceğine bir örnek. Bu aslında isimlendirme standartları sözleşmesinde “çalışan” için EMP, “maaş için SAL”, “plan” için PLN olduğunu gösteriyor. Model oluştururken ve bir şeyler koyarken onları etkileşimli olarak çalıştırmak için de uygulayabilirim. Bu kısaltmayı kullanıyordum ve varlık adına “Çalışan Maaş Planı” yazsaydım, adlandırma standartları şablonuyla hareket ederdi Burada tanımladım, varlıkları oluştururken bana EMP_SAL_PLN verirdi ve bana hemen karşılık gelen fiziksel isimleri verirdi.
Yine, tasarım ve ileri mühendislik yaparken de çok iyi. Çok benzersiz bir konseptimiz var ve bu ortamları gerçekten bir araya getirmeye başladığımız yer burası. Buna Evrensel Eşlemeler denir. Tüm bu modelleri çevremize, ne yapabiliriz, şimdi bu adlandırma kurallarını uyguladığımızı ve bulmaları kolay olduğunu varsayarak, şimdi ER'de Evrensel Eşlemeler adlı bir yapı kullanabiliriz. /Stüdyo. Varlıkları modeller arasında bağlayabiliriz. “Müşteri” yi her nerede görürsek görelim - muhtemelen birçok farklı sistemde ve birçok farklı veritabanında “müşteri” olacağız - hepsini birbirine bağlamaya başlayabiliriz, böylece onunla tek bir modelde çalışırken diğer modellerde müşterilerin tezahürlerinin nerede olduğunu görebilir. Ve bunu temsil eden model katmanına sahip olduğumuz için, onu veri kaynaklarına bağlayabilir ve bunları, hangi veritabanlarının bunları da içinde kullandığı kullanılan sorgulamalara da getirebiliriz. Gerçekten tüm bunları birbirine çok uyumlu bir şekilde bağlama yeteneği veriyor.
Size iş verileri nesnelerini gösterdim. Ekler olarak adlandırdığımız meta veri uzantıları hakkında da çok hızlı bir şekilde konuşmak istiyorum. Bunun yaptığı, bize model nesnelerimiz için ek meta veriler oluşturma yeteneği kazandırmasıdır. Çoğu zaman bu tür özellikleri veri yönetişimi ve veri kalitesi perspektifinden bir sürü farklı şey çıkarmak ve aynı zamanda ana veri yönetimi ve veri saklama politikaları konusunda bize yardımcı olmak için kurarım. Temel fikir, bu sınıflamaları oluşturmak ve bunları istediğiniz yerde, tablo düzeyinde, sütun düzeyinde, bu tür şeylere ekleyebilirsiniz. En yaygın kullanım durumu, elbette, varlıkların tablolar olması ve sonra tanımlayabilirim: ana veri nesnelerim, referans tablolarım, işlem tablolarım nelerdir? Veri kalitesi açısından bakıldığında, veri temizleme çabalarına ve bu tür şeylere öncelik verebilmemiz için iş açısından önem açısından sınıflandırmalar yapabilirim.
Sıklıkla gözden kaçan bir şey, kuruluşumuzdaki farklı veri türleri için saklama politikası nedir? Bunları kurabiliriz ve bunları modelleme ortamımızdaki ve elbette depomuzdaki farklı bilgi yapay yapılarına ekleyebiliriz. Güzellik şu ki, bu ekler veri sözlüğümüzde yaşıyor mu, bu yüzden çevrede kurumsal veri sözlüklerini kullandığımızda, bunları birden çok modele ekleyebiliriz. Onları yalnızca bir kez tanımlamamız gerekir ve onları ortamımızdaki farklı modellerde tekrar tekrar kullanabiliriz. Bu, bir eki ne zaman yaptığınızı, hangi parçaların eklemek istediğinizi gerçekten belirtebileceğinizi gösteren hızlı bir ekran görüntüsüdür. Ve buradaki örnek aslında bir değerler listesidir, bu yüzden içeri girdiklerinde bir değer listesinden seçim yapabilir, modelleme ortamında toplanan şeyin çok fazla kontrolüne sahip olabilirsiniz ve hatta varsayılanın ne olduğunu ayarlayabilirsiniz. değer, bir değer seçilmezse olur. Yani orada çok fazla güç var. Veri sözlüğünde yaşıyorlar.
Bu ekranda size biraz daha göstermek istediğim bir şey, ek olarak üst kısımda eklerin gösterildiğini görüyorsunuz, altında veri güvenliği bilgilerini görüyorsunuz. Veri güvenliği politikalarını aslında ortamdaki farklı bilgilere de uygulayabiliriz. Farklı uyumluluk eşleştirmeleri, veri güvenliği sınıflandırmaları için, bunları oluşturabileceğiniz ve kullanmaya başlayabileceğiniz bir dizi kutuyu göndeririz, ancak kendi uyumluluk eşlemelerinizi ve standartlarınızı da tanımlayabilirsiniz. İster HIPAA ister dışarıdaki diğer girişimlerden birini yapın. Ve gerçekten bu çok zengin meta veri kümesini ortamınızda oluşturmaya başlayabilirsiniz.
Ve sonra Sözlük ve Terimler - iş anlamının bağlandığı yer burasıdır. Orada sık sık bir kuruluşun sözlükleri çıkarmaya başlamak için başlangıç noktası olarak kullandığına dair veri sözlüklerimiz vardır, ancak terminoloji ve söz genellikle çok teknik. Yapabileceğimiz şey, eğer dilersek, bunları sözlükleri dışarı atmak için bir başlangıç noktası olarak kullanabiliriz, ancak işin bunlara sahip olmasını gerçekten istiyoruz. Takım sunucusu ortamında yaptığımız şey, insanlara iş tanımları oluşturma yeteneği verdiğimizden sonra bunları modelleme ortamında da karşılık geldikleri farklı model yapılarına bağlayabiliriz. Daha önce tartışılan noktayı da biliyoruz, yani ne kadar çok kişi yazıyorsanız, insan hatası için daha fazla potansiyel var. Sözlük yapımızda da yaptığımız şey, bir, bir sözlük hiyerarşisini destekliyoruz, bu yüzden kuruluşta farklı sözlük türlerine veya farklı türlere sahip olabiliriz, ancak en önemlisi, zaten bu kaynaklardan bazılarına sahipseniz terimler ve tanımlanan her şeyle birlikte, bunları modelleme ortamımıza ve ekip sunucumuza veya sözlüğümüze çekmek için aslında bir CSV içe aktarma yapabiliriz ve oradan bağlantı kurmaya başlayabiliriz. Ve bir şey her değiştiğinde, tanımlar ve diğer her şey açısından, görüntülerin önceki ve sonraki ne olduğuna dair tam bir denetim izi vardır ve çok yakın bir gelecekte geleceğini göreceğiniz şey de bir yetkilendirme iş akışıdır. bu nedenle, yönetim sürecini ilerledikçe daha da sağlam hale getirmek için, kimin sorumlu olduğunu, komitelerin veya bireylerin onaylarını ve bu tür şeyleri gerçekten kontrol edebiliriz.
Bunun bizim için yaptığı, ekip sunucusu sözlüğümüzde bu sözlük terimlerine sahip olduğumuzda, bu, buraya getirdiğim modelin kendisinde bir düzenleme örneğidir. Bağlantılı terimler olabilir, ancak burada yaptığımız şeylerin notlarında veya açıklamalarında yer alan kelimeler varsa, bunlar otomatik olarak daha açık köprülü bir renkte gösterilirse ve fareyle üzerine gelince, aslında işletme sözlüğünün tanımını da görebiliriz. Hatta, bilginin kendisini tüketirken, orada bulunan tüm sözlük terimleriyle bize daha zengin bilgiler verir. Deneyimi zenginleştirmek ve anlamını birlikte çalıştığımız her şeye uygulamak gerçekten yardımcı oluyor.
Yani, yine, bu çok hızlı bir uçuştu. Açıkçası farklı bölümleri araştırdığımızda günler geçirebiliriz, ancak bu yüzey üzerinde çok hızlı bir uçuş. Gerçekten yapmaya çalıştığımız şey, bu karmaşık veri ortamlarının neye benzediğini anlamak. Tüm bu veri yapılarının görünürlüğünü artırmak ve bunları ER / Studio ile yürütmek için işbirliği yapmak istiyoruz. Daha verimli ve otomatik veri modelleme sağlamak istiyoruz. Bu, büyük veri, geleneksel ilişkisel veri, belge depoları veya başka bir şey olsun, bahsettiğimiz her türlü veri. Ve yine başardık, çünkü farklı platformlar ve orada sahip olabileceğiniz diğer araçlar için güçlü ileri ve geri mühendislik yeteneklerimiz var. Ve her şey, ilgili tüm paydaşlarla kuruluş genelinde paylaşım ve iletişim kurmakla ilgilidir. Burada standartları adlandırma yoluyla anlam uygularız. Daha sonra tanımları ticari sözlüklerimiz aracılığıyla uyguluyoruz. Ardından, veri kalitesi uzantıları, ana veri yönetimi sınıflandırmaları veya bu verilere uygulamak istediğiniz diğer sınıflandırma türleri gibi meta veri uzantılarıyla diğer tüm yönetim yeteneklerimiz için daha fazla sınıflandırma yapabiliriz. Daha sonra, özellikle modelciler ve geliştiriciler arasındaki farklı paydaş kitleleriyle iş verileri nesneleriyle daha fazla özetleyebilir ve iletişimi daha da artırabiliriz.
Ve yine, bununla ilgili çok önemli olan şey, her şeyin arkasında çok güçlü değişim yönetimi yeteneklerine sahip entegre bir havuz olmasıdır. Bugün gösterecek zamanım yoktu, çünkü oldukça karmaşıklaştı, ancak havuzun çok güçlü değişiklik yönetimi yetenekleri ve denetim izleri var. Adlandırılmış sürümler yapabilir, adlandırılmış sürümler yapabilirsiniz ve ayrıca değişiklik yönetimi yapanlarınız için yeteneğimiz var, bunu doğrudan görevlerinize bağlayabiliriz. Bugün, geliştiricilerin kod değişikliklerini de çalıştıkları görevlerle veya kullanıcı hikayeleriyle ilişkilendirmesi gibi, görevleri yerine koyma ve model değişikliklerinizi görevlerle ilişkilendirme yeteneğine sahibiz.
Yine, bu çok hızlı bir bakıştı. Umarım ileride ilerlerken bu konuların bazılarını ayırma konusunda çok daha derin sohbetler yapabiliriz. Zaman ayırdığınız için teşekkürler ve size geri döndük Rebecca.
Rebecca Jozwiak: Teşekkürler, Ron, bu harikaydı ve seyirciden birkaç sorum var, ama analistlerimize söylediklerine dişlerini batırma şansı vermek istiyorum. Eric, devam edeceğim ve belki de bu slayda ya da başka bir slayda hitap etmek istiyorsanız, neden önce devam etmiyorsunuz? Veya başka bir soru.
Eric Little: Tabii. Üzgünüm, soru neydi Rebecca? Belirli bir şey sormamı mı istiyorsun yoksa…?
Rebecca Jozwiak: Ron için başlangıçta bazı soruların olduğunu biliyorum. Şimdi onlardan herhangi birini, ya da bazılarını slaytınızdan ya da sormak istediğiniz ilginizi çeken başka bir şeyle ilgilenmesini istiyorsanız? IDERA'nın modelleme işlevleri hakkında.
Eric Little: Evet, şeylerden biri, Ron, nasılsınız, gösterdiğiniz diyagramlar normalde veritabanı yapımında kullandığınız gibi genel varlık ilişkisi diyagramları gibi görünüyor, değil mi?
Ron Huizenga: Evet, genel olarak konuşursak, ama tabii ki belge depoları ve bu tür şeyler için genişletilmiş tiplerimiz var. Aslında sadece saf ilişkisel gösterimden farklıyız, aslında bu diğer mağazalar için de ek gösterimler ekledik.
Eric Little: Grafik tabanlı modelleme türlerini kullanmanın bir yolu var mı, bu yüzden örneğin en üst kadran, TopBraid besteci aracı gibi bir şeyim olduğunu entegre etmenin bir yolu var mı yoksa bir şey yaptım Protégé'de veya FIBO'daki finans adamları gibi, anlambilimde, RDF öğelerinde çok fazla iş yapıyorlar - bu tür varlık-ilişki grafik türü modellemesini bu araca getirmenin ve kullanmanın bir yolu var mı? o?
Ron Huizenga: Aslında grafikleri nasıl ele alabileceğimize bakıyoruz. Bugün grafik veritabanlarını ve bu tür şeyleri açıkça ele almıyoruz, ancak meta verilerimizi genişletmek için bunu yapabileceğimiz yollara bakıyoruz. Demek istediğim, en azından bir başlangıç noktası olarak getirmek için en azından bir çeşit XML yorumlaması yapabilirsek, şu anda XML ve bu tür şeyleri getirebiliriz. Ama bunu getirmenin daha zarif yollarını arıyoruz.
Ayrıca, orada da sahip olduğumuz tersine mühendislik köprüleri listesini de gösterdim, bu yüzden her zaman belirli platformlar için de bu köprüler için uzantılar almaya çalışıyoruz. Bu yeni yapıların ve oradaki farklı platformların birçoğunu kucaklamaya başlamak, eğer mantıklıysa, sürekli ve sürekli bir çaba. Ama bunu kesinlikle ön planda tuttuğumuzu söyleyebilirim. Örneğin, MongoDB ve bu tür şeylerde gösterdiğim şeyler, bunu kendi ürünümüzde doğal olarak yapan ilk veri modelleme satıcısıyız.
Eric Little: Tamam, evet. Dolayısıyla, sizin için başka bir soru yönetişim ve bakımını korumaktı - örneği kullandığınızda olduğu gibi, “çalışan” olan kişinin örneğini gösterdiğinizde, bunun bir “ maaşı "ve sonra bir" planınız "var, bir yol var mı, örneğin farklı insan türlerini nasıl yönetiyorsunuz - büyük bir mimariye sahip olduğunuzu varsayalım, doğru, büyük bir kuruluşunuz olduğunu varsayalım ve insanlar bir şeyleri bu araçta bir araya getirmeye başlar ve burada “çalışan” kelimesi olan bir grubunuz ve burada “işçi” kelimesi olan bir grubunuz var ve buradaki bir kişi “maaş” diyor ve başka bir kişi "ücret."
Bu tür farklılıkları nasıl uzlaştırır, yönetir ve yönetirsiniz? Çünkü bunu grafik dünyasında nasıl yapacağımızı biliyorum, bilirsiniz, eşanlamlı listeler kullanırsınız ya da bir kavram olduğunu söyler ve birkaç özelliği vardır ya da SKOS modelinde tercih ettiğim bir etikete sahip olduğumu söyleyebilirim. kullanabileceğim çok sayıda alternatif etiket. Bunu nasıl yapıyorsunuz?
Ron Huizenga: Bunu birkaç farklı şekilde yapıyoruz ve öncelikle önce terminoloji hakkında konuşalım. Yaptığımız şeylerden biri, elbette, tanımlanmış veya yaptırım uygulanan terimlere sahip olmak istiyoruz ve iş sözlüğünde açıkça onları istediğimiz yer. Ve iş sözlüğündeki eşanlamlılara da bağlantılara izin veriyoruz, böylece yapabileceğiniz şey, işte benim terimim, ancak bunların tüm eşanlamlılarının ne olduğunu da tanımlayabilirsiniz.
Şimdi ilginç olan şey, elbette, bu geniş veri ortamına oraya sahip olduğunuz tüm bu farklı sistemlerle bakmaya başladığınızda, oraya gidip karşılık gelen tabloları ve bu tür şeyleri değiştiremezsiniz. Bu adlandırma standardına karşılık gelir, çünkü satın aldığınız bir paket olabilir, bu nedenle veritabanını veya herhangi bir şeyi değiştirme üzerinde hiçbir kontrole sahip değilsiniz.
Orada yapabileceğimiz, sözlük tanımlarını ilişkilendirebilmenin yanı sıra, bahsettiğim evrensel eşlemeler, ne yapacağımız ve bir tür önerilen yaklaşım, neyi ortaya koyan kapsayıcı bir mantık modeline sahip olmaktır. bu farklı iş kavramları sizin bahsettiğiniz şeydir. İş sözlüğü terimlerini bunlara bağlayın ve güzel olan şey şu anda mantıklı bir varlığı temsil eden bu yapıya sahip olmanızdır, daha sonra bu mantıksal varlıktan o mantıksal varlığın tüm uygulamalarına bağlanmaya başlayabilirsiniz. farklı sistemler.
O zaman buna ihtiyaç duyduğunuz yerde, buradaki “kişi” nin “sistem” olarak anıldığını görebilirsiniz. Buradaki “maaş” bu diğer sistemde “ücret” olarak adlandırılıyor. Çünkü bunu göreceksiniz, bunların tüm farklı tezahürlerini göreceksiniz, çünkü onları birbirine bağladınız.
Eric Little: Tamam harika, evet, anladım. Bu anlamda, bunun nesne yönelimli yaklaşımlardan bazıları gibi olduğunu söylemek güvenli mi?
Ron Huizenga: Biraz. Sanırım söyleyebileceğinden biraz daha yoğun. Yani, el ile bağlantı kurma ve bunlardan geçme ve bunları inceleme ve yapma yaklaşımını benimseyebilirsiniz. Gerçekten konuşma şansı bulamadığım tek şey - çünkü yine çok fazla yeteneğimiz var - Veri Mimar aracının kendisinde de tam bir otomasyon arayüzüne sahibiz. Ve bir makro yeteneği, bu gerçekten araçta bir programlama dilidir. Yani aslında makro yazma gibi şeyler yapabilir, dışarı çıkıp sorgulayabilir ve sizin için bağlantılar oluşturabiliriz. Bunu bilgileri içe ve dışa aktarmak için kullanırız, bir şeyleri değiştirmek veya öznitelikler eklemek için kullanabiliriz, modelin kendisine dayalı bir olay veya gerçekte dışarı çıkıp sorgulamak ve aslında farklı yapıları doldurmak için toplu olarak çalıştırmak için kullanabiliriz. modeli. Yani insanların da yararlanabileceği tam bir otomasyon arayüzü var. Ve bunlarla evrensel eşlemeler kullanmak bunu yapmanın çok güçlü bir yolu olacaktır.
Rebecca Jozwiak: Tamam, teşekkürler Ron ve teşekkürler Eric. Bunlar harika sorulardı. Bir saatin biraz ötesine koştuğumuzu biliyorum, ama Malcolm'a Ron'un yoluyla ilgili bazı soruları sorma şansı vermek istiyorum. Malcolm?
Malcolm Chisholm: Teşekkürler Rebecca. Ron, çok ilginç, burada bir sürü yetenek var. Çok ilgilendiğim alanlardan biri, diyelim ki bir geliştirme projemiz varsa, veri modelleyiciyi bu yetenekleri kullanarak nasıl görüyorsunuz ve iş analistleriyle, bir veri profilcisi ile, bir veri kalitesi analisti ile nasıl daha işbirliği içinde çalışıyorsunuz? ve nihayetinde projedeki gerçek bilgi gereksinimlerinden sorumlu olacak iş sponsorlarıyla. Veri modelleyici, baktığımız yeteneklerle projeyi nasıl daha etkili ve verimli hale getiriyor?
Ron Huizenga: Sanırım orada yapmanız gereken ilk şeylerden biri veri modelleyici - ve bazı modelcileri seçmek istemiyorum, ama yine de yapacağım - bazı insanlar hala bir izlenim var veri modelleyici gerçekten ağ geçidi denetleyicisi gibi bir rol, nasıl çalıştığını tanımlıyoruz, her şeyin doğru olduğundan emin olan muhafızlarız.
Şimdi bunun bir yönü var, sağlam bir veri mimarisi ve diğer her şeyi tanımladığınızdan emin olmalısınız. Ama daha önemli olan şey bir veri modelleyici - ve bunu danışmanlık yaparken biraz açık bir şekilde buldum - bir kolaylaştırıcı olmak zorundasınız, bu yüzden bu insanları bir araya getirmelisiniz.
Önde bir tasarım olmayacak, üretecek, veritabanları oluşturamayacak - yapabilmeniz gereken şey, tüm bu farklı paydaş gruplarıyla çalışabilmeniz, tersine mühendislik, bilgi içe aktarma, sahip olma ister sözlükte isterse belgelerinde olsun, diğer insanlar işbirliği yapar ve bunu depoya çekmek ve kavramları depoda birbirine bağlamak ve bu insanlarla çalışmak için kolaylaştırıcı olun.
Gerçekten, görevlerin tanımlanması, hatta tartışma konuları veya ekip sunucusunda sahip olduğumuz bu tür şeylerin bile, insanların gerçekten işbirliği yapabileceği, soru sorabildiği ve nihai ürünlere ulaşabilecekleri işbirlikçi bir ortam türüdür. veri mimarisine ve organizasyonlarına ihtiyaç. Bu tür bir cevap verdi mi?
Malcolm Chisholm: Evet, katılıyorum. Biliyorum, kolaylaştırma becerisinin veri modelcilerinde gerçekten çok arzulanan bir şey olduğunu düşünüyorum. Bunu her zaman görmediğimizi kabul ediyorum, ancak bunun gerekli olduğunu düşünüyorum ve veri modellemenizi yaparken bazen köşede kalmanız için bir eğilim olduğunu öneririm, ancak gerçekten diğer paydaş gruplarıyla çalışırken dışarıda olmanız gerekir ya da sadece uğraştığınız veri ortamını anlamıyorsunuz ve bence model sonuç olarak acı çekiyor. Ama bu sadece benim görüşüm.
Ron Huizenga: Ve bu ilginç çünkü slaytta daha önce işletmelerin BT'den nasıl geri çevrildikleri hakkında bir şeyden bahsettiniz, çünkü çözümleri zamanında ve bu tür şeylerde sunmuyorlardı.
Daha sonraki danışmanlık işlerimde, ürün yöneticisi olmadan önce, bundan önceki son iki yıl içinde yaptığım projelerin çoğunun, işin sponsor olduğu ve gerçekten de onu yönlendiren işin ve veri mimarlarının ve modelciler BT'nin bir parçası değildi. Biz iş destekli bir grubun parçasıydık ve proje ekiplerinin geri kalanıyla çalışan kolaylaştırıcılar olarak oradaydık.
Malcolm Chisholm: Bence bu çok ilginç bir nokta. Sanırım iş dünyasında işin sorduğu ya da düşündüğüm bir değişim görmeye başlıyoruz, ne yaptığım kadar değil, süreç gibi olmak, ama aynı zamanda verilerin ne olduğunu düşünmeye de başlıyorlar. veri ihtiyacım var, veri olarak uğraştığım veriler nedir ve bu bakış açısını desteklemek için IDERA ürünlerini ve yeteneklerini ne ölçüde elde edebiliriz ve bence işletmenin ihtiyaçları, yine de biraz daha yeni.
Ron Huizenga: Sana katılıyorum ve sanırım bunun gittikçe daha fazla gittiğini görüyoruz. Bir uyanış gördük ve verilerin önemi açısından daha önce ona değindiniz. Verilerin önemini BT'de veya veritabanlarının evriminde erken gördük, sonra dediğiniz gibi, bu süreç yönetimi döngüsüne girdik - ve süreç son derece önemlidir, beni yanlış anlamayın - ama şimdi ne oldu bu gerçekleştiğinde, veri türü odak kaybını kaybetti.
Ve şimdi kuruluşlar verinin gerçekten odak noktası olduğunu fark ediyorlar. Veriler, işimizde yaptığımız her şeyi temsil eder, bu nedenle doğru verilere sahip olduğumuzdan, kararlarımızı vermek için ihtiyacımız olan doğru bilgileri bulabildiğimizden emin olmamız gerekir. Çünkü her şey tanımlanmış bir süreçten gelmiyor. Bilgilerin bir kısmı başka şeylerin bir yan ürünüdür ve yine de onu bulabilmemiz, ne anlama geldiğini bilmemiz ve orada gördüğümüz verileri sonuçta işlerimizi daha iyi yönlendirmek için kullanabileceğimiz bilgiye çevirebilmemiz gerekir.
Malcolm Chisholm: Doğru, ve şimdi mücadele ettiğim başka bir alan, veri yaşam döngüsü olarak adlandırdığım şeydir, bilirsiniz, bir kuruluştan geçen veri tedarik zincirine bakarsak, veri toplama veya veri yakalama, hangi veri girişi olabilir ama aynı şekilde olabilir, ben bazı veri satıcısından kuruluş dışından veri alıyorum.
Ve sonra veri yakalamadan, bu verileri standartlaştırmayı ve ihtiyaç duyulan yerlere göndermeyi düşündüğüm veri bakımına gidiyoruz. Ve sonra veri kullanımı, verinin gerçek olduğu noktalar, verilerden değer elde edeceksiniz.
Ve eski günlerde bunların hepsi tek bir tarzda yapılır, ancak bugün, bilirsiniz, örneğin bir analitik ortamı olabilir ve bunun ötesinde, artık artık olmadığımızda verileri koyduğumuz bir arşiv, bir mağaza olabilir ihtiyaç ve nihayet tasfiye bir süreç gerekir. Veri modellemenin, tüm veri yaşam döngüsünün yönetimine uygun olduğunu nasıl görüyorsunuz?
Ron Huizenga: Bu çok iyi bir soru ve bugün burada herhangi bir ayrıntıya girmek için gerçekten zamanım yoktu, gerçekten konuşmaya başladığımız şey veri soyudur. Gerçekte yapabileceğimiz şey, araçlarımızda bir veri köken kapasitesine sahip olmamız ve dediğim gibi, aslında bazılarını ETL araçlarından çıkarabiliriz, ancak bunu yalnızca köken çizerek de haritalayabilirsiniz. Yakaladığımız ve modellere getirdiğimiz bu veri modellerinden veya veritabanlarından herhangi biri, veri köken diyagramımızda yer alan yapılara başvurabiliriz.
Yapabileceğimiz, dediğiniz gibi, kaynaktan hedefe ve bu verilerin farklı sistemlerden nasıl geçtiği ve bulacağınız şeyin genel yaşam döngüsü boyunca bir veri akışı çizmektir. 'data - yıllar önce yaptığım bir projeye dayanarak favorilerimden biri. 30 farklı sistemde çalışan verisi olan bir organizasyonla çalıştım. Orada yaptığımız şey - ve Rebecca'nın veri hattı slaydını başlattı - bu oldukça basit bir veri hattı slaydı, ancak yapabileceğimiz tüm veri yapılarını getirmek, şemaya referans vermekti ve sonra biz aslında arasındaki akışların ne olduğuna ve bu farklı veri varlıkları bir akışta nasıl birbirine bağlandığına bakmaya başlayabilir mi? Ve bunun da ötesine geçebiliriz. Bu, burada gördüğümüz bir veri akışı veya köken şemasının bir parçasıdır. Bunun ötesine geçmek istiyorsanız, bu süitin iş mimarı da var ve orada da aynı şey geçerli.
Veri modelleme ortamında yakaladığımız veri yapılarından herhangi biri, iş modelleme aracında bunlara referans verilebilir, böylece iş modeli diyagramlarınızda veya iş süreci diyagramlarınızda bile, dışarı çıkmak isterseniz bireysel veri depolarına başvurabilirsiniz. veri modelleme ortamını kullanır ve bunları iş süreci modelinizdeki klasörlerde kullanırken, bunlarda CRUD'yi bile belirtebilirsiniz, bu bilgilerin nasıl tüketildiği veya üretildiğine ve sonra üretmeye başlayabiliriz. etki ve analiz gibi şeyler raporlar ve diyagramlar çıkar.
Ulaşmayı hedeflediğimiz ve şimdiden çok fazla yeteneğimiz var, ancak ileride araçlarımızı geliştirmeye devam ederken, baktığımız bir tür kale direği gibi, sahip olduğumuz şeylerden biri, bu uçtan uca, organizasyonel veri soyunu ve verinin tam yaşam döngüsünü ortaya koyabiliyor.
Malcolm Chisholm: Tamam. Rebecca, bir tane daha izin verdim mi?
Rebecca Jozwiak: Size bir tane daha izin vereceğim, Malcolm, devam et.
Malcolm Chisholm: Çok teşekkür ederim. Veri yönetimini ve veri modellemeyi düşünerek, bu iki grubun birlikte etkin bir şekilde çalışmasını ve birbirini anlamasını nasıl sağlayabiliriz?
Eric Little: İlginçtir, bence bu gerçekten organizasyona bağlı ve benim daha önceki konseptime geri dönüyor, inisiyatiflerin iş güdümlü olduğu organizasyonlarda tam olarak bağlıyız. Örneğin, bir veri mimarisine öncülük ediyordum iş kullanıcıları ile bağlandık ve aslında veri yönetimi programlarını desteklemelerine yardımcı oluyorduk. Yine, daha istişare bir yaklaşım ama gerçekten daha çok bir iş işlevidir.
Yapabilmeniz için gerçekten ihtiyacınız olan şey, işi gerçekten anlayan, işletme kullanıcıları ile ilgili olabilecek ve daha sonra, bunların etrafındaki yönetişim süreçlerini desteklemelerine yardımcı olabilecek veri modelcilerine ve mimarlara ihtiyacınız var. İş bunu yapmak istiyor, ancak genel olarak konuşursak, bu tür programları öne çıkarmalarına yardımcı olmak için teknoloji bilgisine sahibiz. Bunun gerçekten bir işbirliği olması gerekiyor, ancak işletmenin sahip olması gerekiyor.
Malcolm Chisholm: Tamam, bu harika. Teşekkür ederim.
Dr. Eric Little: Tamam.
Rebecca Jozwiak: Tamam, çok teşekkürler. İzleyici üyeleri, korkarım sorularınıza ulaşmadık, ama bugün on line uygun misafirimize yönlendirildiklerinden emin olacağım. Bugün konuklarımız olduğu için Eric, Malcolm ve Ron'a çok teşekkür ediyorum. Bu harika şeylerdi millet. Ve eğer bugünkü IDERA web yayınından hoşlanıyorsanız, IDERA da katılmak isterseniz, endeksleme ve Oracles'ın zorluklarını tartışmak için önümüzdeki Çarşamba günü Sıcak Teknolojiler'de olacak, bu yüzden başka ilginç bir konu.
Çok teşekkür ederim millet, kendine iyi bak, bir dahaki sefere görüşürüz. Güle güle.
