Paket servisi: Ev sahibi Rebecca Jozwiak, OSTHUS'tan Eric Little, First San Francisco Ortakları'ndan 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 kaydolun.
Rebecca Jozwiak: Bayanlar ve baylar, merhaba ve 2016'nın Sıcak Teknolojileri'ne hoş geldiniz. Bugün kesinlikle “İş Odaklı Veri Mimarisi Oluşturmak” konusunu tartışıyoruz. Adım Rebecca Jozwiak, bugünün web yayını için sunucunuz olacağım. # HotTech16 etiketiyle tweet yapıyoruz, bu yüzden zaten üyeyseniz, lütfen buna katılmaktan çekinmeyin. Herhangi bir zamanda sorunuz varsa, lütfen ekranınızın sağ alt köşesindeki Soru ve Cevap bölmesine girin; onların yanıtlandığından emin olacağız. Değilse, misafirlerimizin onları sizin için aldığından emin olacağız.
Yani bugün gerçekten büyüleyici bir sanatçımız var. Bugün bizimle birlikte çok fazla ağır tetikçi var. OSTHUS'tan veri biliminin yardımcısı Eric Little'e sahibiz. First San Francisco Ortakları için gerçekten harika bir başlık olan yenilikçilik şefi Malcolm Chisholm’a sahibiz. IDERA'dan kıdemli ürün müdürü Ron Huizenga'ya sahibiz. Ve bildiğiniz gibi, IDERA gerçekten eksiksiz bir veri yönetimi ve modelleme çözümleri paketidir. Bugün ise çözümünün nasıl çalıştığı hakkında bize bir demo verecek. Ama buna başlamadan önce, Eric Little, topu sana vereceğim.
Eric Küçük: Tamam, çok teşekkürler. Bu yüzden burada, Ron’un konuşmasıyla ilgili olacağını düşündüğüm birkaç konuyu inceleyeceğim ve umarım bu konulardan bazıları için bazı soru cevaplar için bir sahne hazırlayacağım.
Bu yüzden IDERA’nın yaptıklarıyla ilgilendiğim şey, günümüzde karmaşık ortamların gerçekten çok sayıda işletme değeri yarattığını doğru bir şekilde gösterdiklerini düşünüyorum. Ve karmaşık ortamlar ile karmaşık veri ortamları kastediyoruz. Ve teknoloji gerçekten hızlı hareket ediyor ve günümüz iş ortamında yetişmek zor. Böylece, teknoloji alanlarında çalışanlar sık sık sorun yaşayan müşterilere sahip olduğunuzu göreceklerdir, “Büyük verileri nasıl kullanırım? Anlambilimi nasıl birleştiririm? Bu yeni şeylerin bazılarını eski verilerimle nasıl ilişkilendiririm? ”Ve böyle devam ediyor ve bu tür bir günümüzde bizi birçok insanın oldukça aşina olduğu bu büyük ve büyük verilerden haberdar ediyor ve dörtten fazla olabileceğini anlıyorum bazen - sekiz ya da dokuz kadar gördüm - ama normalde, insanlar büyük veriler gibi şeyler hakkında konuşurken ya da büyük veriler hakkında konuşurken o zaman genellikle bir tür kurumsal ölçekte bir şeye bakıyorsunuzdur. Böylece insanlar derler ki, tamam, peki, verilerinizin hacmini düşünün, bu normalde odak noktasıdır - bu ne kadarına sahip olduğunuzdur. Verilerin hızı, ne kadar hızlı hareket ettirebileceğimi veya ne kadar hızlı sorgulayabileceğimi ya da cevapları alabileceğimle alakalı. Ve şahsen, bunun sol tarafının, birçok farklı yaklaşımla nispeten hızlı bir şekilde çözülen ve ele alınan bir şey olduğunu düşünüyorum. Ancak sağ tarafta iyileştirme için çok fazla yetenek ve gerçekten ön plana çıkan birçok yeni teknoloji görüyorum. Ve bunun üçüncü sütunda veri çeşitliliği ile gerçekten ilgisi var.
Başka bir deyişle, bugünlerde çoğu şirket yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verilere bakıyor. Görüntü verileri popüler bir konu olmaya başlıyor, bu yüzden bilgisayar vizyonunu kullanabiliyor, piksellere bakabiliyor, kazıyabiliyor, NLP, varlık çıkarımı yapabiliyorsunuz, her iki istatistiksel modelden çıkan veya semantik modellerden çıkan grafik bilginiz var. , tablolarda var olan ilişkisel verileriniz vb. var. Ve böylece tüm bu verileri ve tüm bu farklı türleri bir araya getirmek gerçekten büyük bir zorluğu temsil ediyor ve bunu Gartner'de ve sektördeki eğilimleri takip eden diğer insanlarda göreceksiniz.
Ve sonra insanların büyük verilerde bahsettiği son şey, genellikle verilerinizin belirsizliği, belirsizliği olan bu boşluk kavramı. Verilerinizin ne hakkında olduğunu ne kadar iyi biliyorsunuz, orada ne olduğunu ne kadar iyi anlıyorsunuz ve biliyorsunuz? İstatistikleri kullanabilme ve bazı bilgileri kullanabilmeniz veya bir con kullanabilmek için kullanabilmek, orada değerli olabilir. Böylece verilere ne kadar sahip olduğunuz, ne kadar hızlı hareket etmeniz veya ne kadar hızlı hareket etmeniz gerektiği, kuruluşunuzda sahip olabileceğiniz her türlü veri türü ve nerede olduğunuz konusunda ne kadar kesin olduğunuza bağlı olarak verilere bakma yeteneği. bu, ne olduğu, hangi kalitede olduğu vb. Bu gerçekten de, birçok insanın verilerini etkili bir şekilde yönetebilmesi için büyük ve koordine bir çaba gerektiriyor. Dolayısıyla, verilerin modellenmesi günümüz dünyasında giderek daha önemlidir. Bu nedenle, iyi veri modelleri, kurumsal uygulamalarda gerçekten büyük bir başarı yaratıyor.
Söylediğimiz gibi, gerçekten çok fazla farklı türde entegrasyon gerektiren çeşitli kaynaklardan veri kaynaklarınız var. Bu yüzden hepsini bir araya getirmek, örneğin birçok veri kaynağı türünde sorguları yürütebilmek ve bilgileri geri çekebilmek için gerçekten yararlıdır. Ancak bunu yapabilmek için iyi haritalama stratejilerine ihtiyacınız var ve bu yüzden bu tür verileri haritalamak ve bu haritalamaları takip etmek gerçekten zor olabilir. Ve sonra bu sorunu çözdünüz, eski verilerimi tüm bu yeni veri kaynaklarına nasıl bağlarım? Öyleyse, grafiğim olduğunu varsayalım, tüm ilişkisel verilerimi alıp grafiğe koyabilir miyim? Genelde bu iyi bir fikir değildir. Peki, insanlar devam etmekte olan tüm bu tür veri modellerini nasıl yönetebiliyorlar? Analiz gerçekten bu farklı veri kaynakları ve kombinasyon türlerinin çoğunda yapılmalıdır. Bu yüzden çıkan cevaplar, insanların gerçekten iyi iş kararları vermeleri için gereken cevaplar çok önemlidir.
Yani bu sadece teknoloji uğruna teknolojiyi oluşturmakla ilgili değil, gerçekten, ne yapacağım, bununla ne yapabilirim, ne gibi analizler yapabilirim ve bu nedenle de zaten yeteneğim var Bu şeyleri bir araya getirmek, bütünleştirmek gerçekten çok önemli. Ve bu tür analizlerden biri daha sonra federe arama ve sorgulama gibi şeylerle çalışır. Bu gerçekten bir zorunluluk haline geliyor. Sorgularınız normalde birden fazla kaynak türü arasında ele alınmalı ve bilgileri güvenilir bir şekilde geri çekmelidir.
Sık sık, özellikle insanlar anlamsal teknolojiler gibi önemli şeylere bakacak olan temel unsurlardan biri - ve bu Ron'un IDERA yaklaşımında biraz konuşacağını umduğum bir şey - Veri katmanının kendisinden, o ham verilerden verilerinizin model katmanı? Dolayısıyla veri katmanında veritabanlarınız olabilir, belge verileriniz olabilir, elektronik tablo verileriniz olabilir, resim verileriniz olabilir. İlaç endüstrisi gibi alanlardaysanız, çok miktarda bilimsel verilere sahipsiniz. Ve sonra bu kişilerin üzerinde normalde bu verileri hızlı bir şekilde entegre etmelerine izin veren 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 neler olduğunu, ortak kelimeleri, ortak varlık türlerini ve ilişkilerini ve gerçekte bulunduğu veriye gerçekten ulaşma yeteneğini güzel bir şekilde yansıtmaktır. Bu yüzden onun ne olduğunu söylemesi ve nerede olduğunu söylemesi ve onu nasıl alıp geri getirmesi gerektiğini söylemesi gerekir.
Yani bu, çok çalıştığım bir alan olan anlamsal teknolojilerin ilerletilmesinde oldukça başarılı bir yaklaşım oldu. Öyleyse Ron'a sormak 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? Peki 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 de gerçekten kritik hale geliyor. Dolayısıyla, bu tür veri modellerine sahip olacaksanız, bir şeyleri birleştirip araştırabilecekseniz, gerçekten iyi referans verileriniz olmalıdır. Ancak sorun, referans verilerinin sürdürülmesi gerçekten zor olabilir. Bu yüzden çoğu zaman kendi içinde standartları isimlendirmek zor bir iştir. Bir grup X'e bir şey diyecek ve bir grup Y'ye bir şey diyecek ve şimdi birileri bu tür bir bilgi ararken X ve Y'yi nasıl bulabilir? Onlara verinin sadece bir kısmını vermek istemediğiniz için, onlara ilgili her şeyi vermek istersiniz. Aynı zamanda, şartlar değiştiğinde, yazılım kullanımdan kaldırılır ve böyle devam eder, bu referans verilerini zaman içinde nasıl tutar ve sürdürürsünüz?
Ve yine anlambilimsel teknolojiler, özellikle taksonomiler ve sözlükler, veri sözlükleri gibi şeyleri kullananlar, bunu yapmanın standart bir alan yolunu sağladılar, bu gerçekten çok sağlam, bazı standartlar kullanıyor, ancak veritabanı topluluğu bunu bir uzun zamandır, 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ı ya da burada gerçekten umut verici bir şekilde referans verilerinizi ele almanın standart aralıklı bir yolunu verecek bir yaklaşımın nasıl olacağını düşünüyorum. Ve tabii ki referans verisine sahip olduğunuzda, haritalama stratejilerinin çok çeşitli isimleri ve varlıkları yönetmesi gerekir. Bu yüzden konu uzmanları sıklıkla kendi terimlerini kullanmaktan hoşlanırlar.
Öyleyse, bu konuda her zaman bir meydan okuma var, birisine nasıl bilgi verirsiniz, ancak bunun hakkında konuşma biçimleriyle ilgili kılan nedir? 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ı varlık türleri için farklı isimleriniz olabilir. bu senin alanınla alakalı. Bu kişiselleştirilmiş terminolojileri bir araya getirmenin yollarını bulmalısınız, çünkü diğer yaklaşım, insanları terimlerini bırakmaya ve sık sık sevmedikleri bir başkasını kullanmaya zorlamanız gerektiğidir. Buradaki bir diğer nokta, çok sayıda eş anlamlı kullanımı zorlaşır, bu nedenle birçok kişinin verilerinde aynı şeyi ifade edebilecek birçok farklı kelime vardır. Orada bire bir ilişki kümesi kullanarak bir başvuru probleminiz var. İhtisas terimleri sanayiden sanayiye değişebilir, bu nedenle, bu tür bir veri yönetimi için bir tür genel çö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 manuel olarak ele almak pahalıdır. Manuel olarak haritalandırmaya devam etmek pahalı ve konu uzmanlarının günlük işlerini bırakmalarını ve veri sözlüklerini girip sürekli düzeltmeleri ve tanımları yeniden güncellemesi vb. Tekrarlanabilir kelimeler gerçekten çok fazla değer gösterir. Demek ki bunlar, örgütünüzün dışında bulabileceğiniz çoğu zaman sözlükler. Örneğin ham petrolde çalışıyorsanız, açık kaynaklı alanlardan ödünç alabileceğiniz, ilaç sektörüyle aynı, bankacılık sektörüyle aynı ve finansal alanlarla, bu tür alanların çoğuyla aynı olacak bazı kelimeler olabilir. İnsanlar, insanların kullanması için tekrar kullanılabilir, genel, tekrarlanabilir kelimeler ortaya koyuyor.
Ve yine, IDERA aracına baktığımda, bu tür standartları kullanmada bunu nasıl yürüttüklerini görmeyi merak ediyorum. Anlam dünyasında, en azından daha geniş / daha dar standartlar sağlayan SKOS modelleri gibi şeyleri sık sık görüyorsunuz ve bu şeylerin ER modellerinde yapılması zor olabilir, ama bildiğiniz gibi, imkansız değil, sadece bunun ne kadar olduğuna bağlı. makine ve bu tür sistemlerde idare edebileceğiniz bağlantı.
Son olarak, sektörde gördüğüm bazı anlamsal motorlarla bir karşılaştırma yapmak istedim ve Ron'a sordum ve belki de IDERA’nın herhangi bir anlamsal teknolojiyle bağlantılı olarak nasıl kullanıldığı hakkında konuşmasını biraz istemiştim.Üçlü mağazalar, grafik veritabanları ile entegre edilebilir mi? Dış kaynakları kullanmak ne kadar kolaydır çünkü semantik dünyadaki bu tür şeyler genellikle SPARQL Endpoints kullanılarak ödünç alınabilir mi? RDF veya OWL modellerini doğrudan modelinize aktarabilirsiniz - bunlara geri dönün - yani, örneğin kendi yönetişim yapısıyla kendi alanında bir yerde yaşayabilecek olan gen ontolojisi veya protein ontolojisi, Bunun bir kısmını kendi modellerime ihtiyacım olduğu gibi. IDERA'nın bu konuya nasıl yaklaştığını bilmek de merak ediyorum. Her şeyi dahili olarak mı sürdürmek zorundasınız, yoksa başka tür standart modeller kullanıp bunları içeri çekmenin yolu var mı? Ve burada bahsettiğim son şey, sözlükleri ve meta veri depolarını oluşturmak için ne kadar manuel çalışmanın yer aldığı?
Bu yüzden Ron’un bize gerçekten ilginç olacak bu tür şeyler hakkında bazı demolar göstereceğini biliyorum. Ancak müşterilerle sıkça danışmanlık yaptığım sorunlar, insanlar kendi tanımlarını veya kendi meta verilerini yazarken çok fazla hata meydana geldiğidir. Böylece yanlış hecelenme, şişman parmak hatalarınız olur, bu da bir şey. Ayrıca, yalnızca Wikipedia'dan veya tanımınızda isteyebileceğiniz kalitede olması gerekmeyen bir kaynaktan veya tanımınız yalnızca bir kişinin perspektifinden alınabilecek, yani tamamlanmadığı ve net olmadığı belli olan insanları elde edersiniz. Yönetişim sürecinin nasıl çalıştığı. Yönetişim, elbette, referans verilerinden bahsettiğiniz ve ne zaman birinin ana verilere uygun olabileceği, meta verilerini nasıl kullanacakları hakkında konuştuğunuz zaman, çok, çok büyük bir sorun olmak ve yakında.
Bu yüzden sadece bu konuların bazılarını oraya koymak istedim. Bunlar, birçok farklı danışmanlık anlaşması ve birçok farklı alandaki iş alanında gördüğüm öğeler ve Ron'un bize bu konuların bazılarını belirtmek için IDERA ile neler göstereceğini görmekle gerçekten ilgileniyorum. . Çok teşekkür ederim.
Rebecca Jozwiak: Çok teşekkürler Eric, ve insanların kendi tanımlarını veya meta verilerini yazması durumunda birçok hatanın meydana gelebileceği şeklindeki yorumunuzu gerçekten beğendim. Gazetecilik dünyasında “birçok gözün çok az hata yaptığı” bir mantra olduğunu biliyorum, ancak pratik uygulamalara gelince, kurabiye kavanoğunda çok fazla el sizi çok fazla kırılmış kurabiye ile bırakma eğilimindedir, değil mi?
Eric Küçük: Evet ve mikroplar.
Rebecca Jozwiak: Evet. Bununla devam edip Malcolm Chisholm'a göndereceğim. Malcolm, yer senin.
Malcolm Chisholm: Çok teşekkürler Rebecca. Eric'in neden bahsettiğine biraz bakmak istiyorum ve Ron'un bildiğiniz gibi “İş Odaklı Veri Mimarisine Doğru” konusuna cevap verebileceği bir kaç gözlem daha eklemek istiyorum. ”- iş odaklı olmak ne anlama geliyor ve bu neden önemli? Yoksa bu sadece bir tür yutturmaca mı? Sanmıyorum.
Bildiğiniz gibi, anabilgisayar bilgisayarları şirketlere - 1964 civarında - bugünden günümüze kadar - ulaşılabiliyorsa, pek çok değişiklik olduğunu görebiliriz. Ve bu değişiklikler, süreç odaklılıktan veri odaklılığa geçiş olarak özetleyeceğim. İşte, iş odaklı veri mimarilerini günümüzde bu kadar önemli ve önemli kılan şey de bu. Ve bence, bilirsin, bu sadece bir terim değil, kesinlikle gerçek bir şey.
Ancak tarihe dalarsak, biraz daha fazla değerlendirebiliriz, bu nedenle zamanda geriye, 1960'lara kadar geri gidersek, bir süre boyunca ana bilgisayarlar hâkim oldu. Bunlar daha sonra, PC'ler geldiğinde kullanıcıların isyanını duyduğunuz PC'lere yol açtı. İhtiyaçlarını karşılamadığını düşündükleri merkezi BT'ye isyan etmek yeterince çevik değildi. Bu, PC'ler birbirine bağlandığında, hızlı bir şekilde dağıtılmış hesaplamaya yol açtı. Ve sonra internet, işletmenin sınırlarını bulanıklaştırmaya başladı - şimdi daha önce gerçekleşmemiş olan veri alış verişi açısından kendi dışındaki taraflarla etkileşim kurabiliyordu. Ve şimdi bulutun ve büyük veri çağına girdik, burada bulut gerçekten altyapıyı destekleyen platformlardı ve böylece büyük veri merkezlerini yönetme ihtiyacının IT'sini olduğu gibi bırakıyoruz çünkü bulut kapasitemizi bize ulaştırdık ve Eric'in bildiğiniz kadarıyla tartışmış olduğu bu büyük verilerle birlikte. Ve genel olarak, gördüğümüz gibi, teknolojideki değişim gerçekleştikçe, bu daha veri merkezli hale geldi, verilere daha çok önem veriyoruz. İnternet gibi, verilerin nasıl değiş tokuş edildiği. Büyük verilerle, verilerin kendisinin dört veya daha fazlası.
Aynı zamanda ve belki de daha önemlisi, iş kullanımı davaları değişti. Bilgisayarlar ilk tanıtıldığında, kitaplar ve kayıtlar gibi şeyleri otomatikleştirmek için kullanılıyorlardı. Ve manuel bir süreç olan, defterleri veya bunun gibi şeyleri içeren herhangi bir şey, esasen evde programlandı. 80'li yıllarda operasyonel paketlerin mevcudiyetine geçti. Artık kendi maaş bordronuzu yazmanıza gerek yoktu, bunu yapan bir şey satın alabilirsiniz. Bu, birçok BT departmanında o zaman büyük bir küçülme ya da yeniden yapılanma ile sonuçlandı. Ancak, daha sonra 90'lı yıllarda veri ambarları gibi şeyler olan iş zekası ortaya çıktı. Elbette, büyük bir çılgınlık olan dotcom iş modelleri izledi. Sonra MDM. MDM ile otomasyon hakkında düşünmeyi düşünmediğimizi görmeye başlarsınız; biz aslında sadece verileri veri olarak değerlendirmeye odaklanıyoruz. Sonra veriden elde edebileceğiniz değeri temsil eden analitik. Ayrıca, analitikte, temel iş modeli veriler etrafında dönen çok başarılı şirketleri görüyorsunuz. Google, bunun bir parçası olur, ancak Walmart'ın da olduğunu iddia edebilirsiniz.
Ve bu yüzden iş şimdi gerçekten veriler hakkında düşünüyor. Veriden nasıl değer alabiliriz? Verilerin işletmeyi, stratejiyi nasıl etkileyebileceği ve verinin altın çağındayız. Öyleyse, veriler artık uygulamaların arka ucundan çıkan egzoz olarak kabul edilmiyorsa, ancak iş modellerimiz için gerçekten merkezi ise, veri mimarimiz açısından neler oluyor? Peki, bunu başarmamızdaki problemin bir kısmı geçmişte gerçekten de BT'nin erken yaşlarında bu süreç otomasyon aşaması ile hızlı bir şekilde uğraşmak zorunda kalmanın bir sonucu olan sistem geliştirme yaşam döngüsü ile sıkıştı. projeler benzer bir şeydir. BT'ye - ve bu biraz karikatürize - ama söylemeye çalıştığım iş odaklı bir veri mimarisi elde etmenin önündeki bazı engellerin BT'de eleştirel olarak kabul gören bir kültür olduğu için Bu geçmiş bir yaştan türemiştir.
Yani her şey bir proje. İhtiyaçlarınızı detaylı olarak anlatın. İşler işe yaramazsa, bana gereksinimlerinizi söylememeniz gerekir. Bugün bu verilerle çalışmıyor çünkü otomatik olmayan manuel işlemlerle başlamıyoruz ya da iş süreçlerinin teknik bir dönüşümü ile başlıyoruz, zaten denediğimiz mevcut üretim verileriyle çok sık başlıyoruz. değerini almak için. Ancak veri merkezli bir projeye sponsor olan hiç kimse bu verileri derinlemesine anlamıyor. Veri keşfi yapmalı, kaynak veri analizi yapmalıyız. Ve bu, sistem gelişimi ile gerçekten eşleşmiyor, biliyorsunuz - şelalesi, SDLC yaşam döngüsü - ki bunun sürdüreceği Agile bunun daha iyi bir versiyonu.
Odaklanılan nokta ise veri değil, teknoloji ve işlevselliktir. Örneğin, bir test aşamasında test yaptığımızda normalde olur, işlevlerim çalışır mı, Diyelim Diyelim ki, ancak verileri test etmiyoruz. Gelen veri kaynaklarıyla ilgili varsayımlarımızı test etmiyoruz. Olsaydı, belki daha iyi durumda olurduk ve veri ambarı projeleri yapan ve yukarı yönde yapılan değişiklikler yüzünden acı çeken, ETL'leri bozan biri olarak bunu takdir ediyorum. Aslında, görmek istediğimiz şey, sürekli üretim verisi kalite izlemesinin ön aşaması olarak test yapmaktır. Bu yüzden buraya, iş odaklı veri mimarisini elde etmenin zor olduğu yerlerde çok fazla tutum getirdik, çünkü süreç odaklılık çağının şartı var. Veri merkezliliğine bir geçiş yapmamız gerekiyor. Ve bu tam bir geçiş değil, biliyorsunuz, hala orada yapılacak çok fazla işlem çalışması var, ancak gerektiğinde veri merkezli terimlerle ve gerçekte ne zaman olduğumuzda meydana gelen koşulları düşünmüyoruz. Bunu yapmak zorunda.
Şimdi iş, verinin değerini anlıyor, verilerin kilidini açmak istiyor, peki bunu nasıl yapacağız? Peki geçişi nasıl yapacağız? Veri geliştirme süreçlerinin kalbine yerleştirdik. İşin bilgi gereklilikleriyle liderlik etmesine izin veriyoruz. Ve projenin başlangıcında mevcut kaynak verilerini kimsenin anlamadığını biliyoruz. Veri yapısının ve verilerin kendisine sırasıyla BT ve işlemler aracılığıyla ulaştığını iddia edebilirsiniz, bu yüzden bunu bilmeliyiz, ama gerçekten yapmıyoruz. Bu veri merkezli bir gelişmedir. Dolayısıyla, veri merkezli bir dünyada veri modellemesini nerede ve nasıl yaptığımızı düşünürken, veri keşfi ve veri profillemesi yaparken, bilgi gereksinimlerini iyileştirme konusunda kullanıcılara geri bildirim döngülerine sahip olmalıyız. , kaynak veri analizini öngörün ve yavaş yavaş verilerimizle ilgili daha fazla kesinlik kazandıkça. Ve şimdi bir MDM merkezi veya veri ambarı gibi daha geleneksel bir projeden bahsediyorum, mutlaka büyük veri projeleri değil, buna rağmen, hala buna yakınım. Ve böylece bu geri bildirim döngüleri, veri modelleyicilerini içerir, bilirsiniz, veri modellerini aşamalı olarak ilerletir ve bilgi gereksinimlerinin daha iyi anladıkları şekilde kaynak verilerden elde edilebilir olana dayanarak, bilgi gereksinimlerinin rafine edildiğinden emin olmak için kullanıcılarla etkileşime girer. artık veri modelinin var olmadığı bir durum değil, biliyorsunuz, orada olmayan ya da tamamen yapılmış bir durumda, buna odaklanarak yavaş yavaş ilerliyor.
Benzer şekilde, daha sonraki veriler, verilerin varsayımlar yaptığımız parametreler dahilinde olduğundan emin olmak için veri kalitesi testi için kurallar geliştirdiğimiz kalite güvencesine sahibiz. Girerken, Eric olabilecek referans verilerindeki değişikliklerden bahsediyordu. Bu alanda olduğu gibi yönetilmeyen bir değişimin aşağı havza 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şimi nasıl yaptığımızı işlevsellik temelli SDLC ve Agile'den oldukça farklı görmeye başlayabilirsiniz. Ve sonra iş görüşlerine de dikkat etmek zorundayız. Biz - ve bu da Eric’in söylediklerini tekrarlıyor - veritabanımız için mavi bir veri hikayesini tanımlayan bir veri modelimiz var, ancak aynı zamanda geleneksel olarak yapılmayan verilerin iş görüşlerine, bu kavramsal modellere ihtiyacımız var. geçmiş. Bazen, veri modelinin hepsini yapabileceğini düşündük, ancak kavramsal bakış açısına, anlamsallığa ve verilere bakmaya ihtiyacımız var, ancak depolama modelini işletmeye dönüştüren bir soyutlama katmanı haline getirmemiz gerekiyor. görünüm. Ve yine, Eric'in anlambilim açısından konuştuğu her şey, bunu yapmak için önem kazanıyor, bu yüzden aslında ek modelleme görevlerimiz var. Sanırım benim yaptığım gibi bir veri modelleyicisi olarak sıralamaya girdiyseniz ve yine yeni bir şey yaptıysanız, bunun ilginç olduğunu düşünüyorum.
Sonunda, daha büyük mimarinin bu yeni gerçeği yansıtması gerektiğini söylemek isterim. Örneğin, geleneksel müşteri MDM'si tamamdır, tamam, müşteri verimizi, arka ofis uygulamaları için gerçekten sadece veri kalitesi anlamında bildiğimiz, bildiğimiz bir merkeze alalım. Hangi bir iş stratejisi bakış açısından bir esneme türüdür. Ancak bugün, müşterilerin işlem uygulamalarıyla iki yönlü bir arayüze sahip olan sadece statik verilere değil, içinde ek müşteri profili verisine sahip müşteri MDM merkezlerine bakıyoruz. Evet, arka ofisleri hala destekliyorlar, ancak şimdi müşterilerimizin de bu davranışlarını biliyoruz. Bu inşa etmek daha pahalıdır. Bu inşa etmek daha karmaşıktır. Ancak, geleneksel MDM müşterisinin olmadığı bir şekilde iş odaklı. İşletmeyi yönlendirmesi, işletmesi daha kolay olan basit tasarımlara karşı işlem görüyorsunuz, ancak iş için görmek istedikleri bu. Gerçekten yeni bir çağdayız ve bence iş sürüşü veri mimarisine yanıt vermemiz gereken bir takım seviyeler var ve bence iş yapmanın çok heyecan verici bir zaman olduğunu düşünüyorum.
Teşekkür ederim, size geri dön Rebecca.
Rebecca Jozwiak: Teşekkürler Malcolm, ve veri modelleri hakkında söylediklerinizden gerçekten çok memnun oldum, çünkü, söylediklerinizden farklı olarak, BT'nin dizginleri uzun süre tuttuğu ve bu artık böyle bir şey değil. değişmesi gerekiyor. Ve arka planda% 100 sizinle aynı fikirde olan bir köpek olduğundan eminim. Ve bununla topu Ron'a geçireceğim. Demo'nuzu gördüğüme çok sevindim. Ron, yer senin.
Ron Huizenga: Çok teşekkür ederim ve buna başlamadan önce, bir kaç slayttan sonra biraz demo geçeceğim çünkü Eric ve Malcolm'un da belirttiği gibi, bu çok geniş ve derin bir konu ve Bugün hakkında konuşuyoruz, biz sadece onun yüzeyini kazıyoruz çünkü iş odaklı bir mimariden gerçekten göz önünde bulundurmamız ve göz önünde bulundurmamız gereken çok şey var. Ve yaklaşımımız gerçekten bu modeli temelli yapmak ve modellerden gerçek bir değer elde etmektir, çünkü bunları diğer sistemleri mümkün kılmak için bir iletişim aracı ve bir katman olarak kullanabilirsiniz. Servis odaklı bir mimari ya da başka şeyler yapıyor olsanız da, model, etrafındaki tüm meta veriler ve işinizde sahip olduğunuz verilerle, gerçekte olanların can damarı olur.
Bununla birlikte, konuşmak istediğim şey neredeyse geri adım atmak, çünkü Malcolm, çözümlerin nasıl geliştiğinin ve bu tür şeylerin tarihinin bazılarına değinmişti. Sağlam bir veri mimarisine sahip olmanın ne kadar önemli olduğunu gerçekten vurgulamanın bir yolu, bir ürün yönetimi rolüne girmeden önce danışmanlık yaparken sıkça karşılaştığım bir kullanım durumuydu. İş dönüşümü yapıp yapmadıklarını veya sadece mevcut bazı sistemleri ve bu tür şeyleri değiştirip değiştirmediklerini ve kuruluşların kendi verilerini ne kadar zayıf anladıkları çok hızlı bir şekilde ortaya çıktı. Bunun gibi özel bir dava alırsanız, içeri giren bir danışman olsanız da, belki de bir kuruluşla yeni başlayan bir kişi veya kuruluşunuz yıllar geçtikçe farklı şirketler satın alarak, ne kurdunuz Çok sayıda yeni teknolojinin yanı sıra eski teknoloji, ERP çözümleri ve diğer her şeyle birlikte çok hızlı bir şekilde çok karmaşık bir ortam.
Yani modelleme yaklaşımımızla gerçekten yapabileceğimiz şeylerden biri, tüm bunları nasıl anlayabilirim sorusuna cevap vermek. Bilgileri bir araya getirmeye başlayabiliriz, böylece işletme sahip olduğumuz bilgileri doğru şekilde kullanabilir. Ve ortaya çıkıyor, bu ortamlarda orada sahip olduğumuz şey nedir? Modelleri, ihtiyaç duyduğum bilgileri çıkarmak ve bu bilgileri daha iyi anlamak için nasıl kullanabilirim? Daha sonra ilişkisel veri modelleri gibi tüm farklı şeyler için geleneksel meta veri türlerine sahibiz ve tanımları ve veri sözlükleri, bildiğiniz, veri tipleri ve bu tür şeyler gibi şeyleri görmeye alışkınız. Ancak, gerçekten daha da fazla anlam vermek için yakalamak istediğiniz ek meta veriler ne durumda? Mesela, hangi varlıkların gerçekten referans veri nesneleri olması gereken, ana veri yönetimi nesneleri ve bu tür şeylerin olması ve bunları birbirine bağlaması gereken adaylar gibi. Bilgi kurum içinde nasıl akıyor? Veriler, hem süreç açısından nasıl tüketildiklerine, hem de işletmelerimizden geçen bilgi yolculuğuna ve farklı sistemler veya veri depolarına nasıl geçtiğini açıklar. I-çözümleri veya bu tür şeyleri inşa ederken, eldeki görev için doğru bilgiyi kullandığımızı.
Ve sonra çok önemlisi, tüm bu paydaşları ve özellikle de ticari paydaşları işbirliğine nasıl sokabiliriz, çünkü bize bu verinin ne olduğunun gerçek anlamını verenler onlardır. Günün sonunda, işletme verilere sahip. Eric'in konuştuğu kelime ve terimlerin tanımlarını veriyorlar, bu yüzden hepsini bir araya getirecek bir yere ihtiyacımız var. Ve bunu yapma şeklimiz veri modelleme ve veri havuzu mimarilerimizden geçiyor.
Birkaç şeye dokunacağım. ER / Studio Enterprise Team Edition hakkında konuşacağım. Öncelikle, veri modellemesini yaptığımız veri mimarisi ürününden ve bu tip şeylerden bahsedeceğim, ancak süitte kısaca değineceğim çok fazla başka bileşen var. Kavramsal modelleri yapabileceğimiz Business Architect'in bir snippet'ini göreceksiniz, ancak aynı zamanda iş süreci modellerini de yapabiliriz ve veri modellerimizdeki gerçek verileri bağlamak için bu işlem modellerini bağlayabiliriz. Bu bağı bir araya getirmemize gerçekten yardımcı oluyor. Yazılım Mimarı, bazı UML modellemeleri ve bahsettiğimiz diğer sistem ve işlemlerin bazılarına destekleyici mantıklar vermek için bu tür şeyler gibi ek yapılar yapmamıza izin veriyor. Fakat en önemlisi, aşağı indikçe depo ve ekip sunucusuna sahibiz ve bunun aynı şeyden iki yarısı gibi bahsedeceğim. Depo, modellenen meta verilerin yanı sıra tüm işletme meta verilerini işletme sözlükleri ve terimler açısından sakladığımız yerdir. Ve bu depoya dayalı bir ortama sahip olduğumuz için, tüm bu farklı şeyleri aynı ortamda bir araya getirebiliriz ve daha sonra bunları yalnızca teknik kişiler için değil, iş adamları için de tüketimler için kullanılabilir hale getirebiliriz. Ve işte işbirliğini gerçekten bu şekilde başlatmaya başlıyoruz.
Ve sonra kısaca bahsedeceğim son parça, bu ortamlara girdiğinizde, sadece orada bulunan veritabanları değil. Çok sayıda veritabanına, veri deposuna sahip olacaksınız, benim de ne diyeceğim, eski eserler de olacak. Belki insanlar bazı şeyleri ortaya çıkarmak için Visio veya diğer diyagramları kullanmışlardır. Belki başka modelleme araçlarına ve bu tür şeylere sahiplerdi.Yani MetaWizard ile yapabileceğimiz şey aslında bu bilgilerin bir kısmını çıkarmak ve bunları modellerimize getirmek, güncel hale getirmek ve kullanabilmek, tüketebilmek, tekrar o anda oturmak yerine, şimdiki şekilde kullanmak. Artık çalışma modellerimizin aktif bir parçası haline geliyor, bu çok önemli.
Bir organizasyona girdiğinizde, dediğim gibi, birçok farklı sistem var, birçok ERP çözümü, uyumsuz departman çözümü. Birçok kurum aynı zamanda harici olarak kontrol edilen ve yönetilen SaaS çözümlerini kullanıyor, bu nedenle veritabanlarındaki veritabanları ve bunlar üzerindeki ana bilgisayar türlerini kontrol etmiyoruz, ancak yine de bu verilerin neye benzediğini ve tabii ki bilmemiz gerekiyor. Bunun etrafındaki meta veriler. Ayrıca bulduğumuz şey, Malcolm'un bahsettiği bu proje temelli yaklaşım nedeniyle temizlenmemiş olan birçok eski miras sistemi. Son yıllarda kuruluşların projeleri nasıl bir araya getirecekleri şaşırtıcı, bir sistemin veya çözümün yerini alacaklar, ancak eski çözümleri ortadan kaldırmak için genellikle yeterli proje bütçesi kalmadı, bu yüzden şimdi tam yolundalar. Ve çevremizdeki gerçekte neyin kurtulabileceğimizi ve ileriye yararlı olan şeyleri bulmak zorundayız. Ve bu, fakir kötüye kullanma stratejisine bağlanır. Bu aynı şeyin parçası ve paketi.
Ayrıca bulduğumuz, çünkü tüm bu farklı çözümlerden bir çok organizasyon oluşturulduğundan, birçok yerde dolaşan bir sürü veri ile birçok noktadan noktaya arayüzler görüyoruz. Bunu rasyonelleştirebilmemiz ve daha önce kısaca bahsettiğim veri soyunu çözmemiz gerekir; böylece hizmet odaklı mimarinin kullanılması, kurumsal servis otobüsleri ve bu tür şeylerin doğru bir şekilde iletilmesi gibi daha uyumlu bir stratejiye sahip olabiliriz. işimiz boyunca doğru kullandığımız bir modelin yayınlanması ve abone olması. Ve sonra, tabii ki, veri ambarlarını, geleneksel ETL ile veri martlarını veya bazı yeni veri göllerini kullanıyor olsak da, yine de bir tür analitik yapmamız gerekiyor. Her şey aynı şeylere iniyor. Tüm veriler, büyük veriler, ilişkisel veritabanlarındaki geleneksel veriler olup olmadığına bakılmaksızın, tüm verileri bir araya getirmemiz gerekir, böylece bunları yönetebilir ve modellerimizde neyle uğraştığımızı öğrenebiliriz.
Yine, yapacağımız karmaşıklık yapmak istediğimiz birkaç adımın olması. Her şeyden önce içeri giriyorsunuz ve bu bilgi manzarasının neye benzediğine dair bu maviler olmayabilir. ER / Studio Data Architect gibi bir veri modelleme aracında, ilk önce oradaki veri kaynaklarına bakalım, onları içeri sokun ve daha sonra onları daha temsili haline getirin; tüm işi temsil eden modeller. Önemli olan, bu modelleri iş kolları boyunca da ayrıştırabilmemiz, böylece iş adamlarımızla ilgili olabilecek daha küçük parçalarla ve iş analistlerimizle ve çalışan diğer paydaşlarımızla ilişki kurabilmemizdir. üstünde.
Adlandırma standartları son derece önemlidir ve burada birkaç farklı yoldan bahsediyorum. Modellerimizdeki şeyleri nasıl adlandırdığımız açısından standartları adlandırma. Mantıksal modellerde yapmak oldukça kolaydır, burada iyi bir adlandırma kuralına ve modellerimiz için iyi bir veri sözlüğüne sahibiz, ancak daha sonra, getirdiğimiz bu fiziksel modellerin çoğu için farklı adlandırma kurallarına rastlıyoruz. tersine mühendis, sık sık kısaltılmış isimler ve bahsedeceğim bu tür şeyler görüyoruz. Ve bunları çevreye ne sahip olduğumuzu anlayabilmemiz için iş için anlamlı olan anlamlı İngilizce isimlere çevirmemiz gerekiyor. Ve sonra evrensel eşlemeler onları nasıl birleştireceğimizdir.
Bunun üzerine daha sonra belgeleyip tanımlayacağız ve bu, verilerinizi Ekler adında bir şeyle daha fazla sınıflandırabileceğimiz, size bir kaç slayt göstereceğim. Ve sonra döngüyü kapattıktan sonra, işletme sözlüklerimize bağladığımız ve bunları farklı model yapılarımıza bağlayabildiğimiz bu işletme anlamını uygulamak istiyoruz. Verilerimizde kuruluş genelinde uygulanmaktadır. Ve son olarak, çok sayıda işbirliği ve yayınlama kabiliyetine dayanarak tüm bunların depolanması için ihtiyaç duyduğumuz gerçeğinden bahsettim, böylece paydaşlarımız faydalanabilir. Oldukça hızlı bir şekilde tersine mühendislik hakkında konuşacağım. Size şimdiden bunu çok hızlı bir şekilde vurguladım. Bunu size gerçek bir demo olarak göstereceğim, sadece size getirebileceğimiz bazı şeyleri göstermek için.
Ve bu tip bir senaryoda üreteceğimiz farklı model tiplerinden ve diyagramlarından bahsetmek istiyorum. Açıkçası, kavramsal modelleri birçok durumda yapacağız; Bunun için fazla zaman harcamayacağım. Gerçekten mantıksal modeller, fiziksel modeller ve yaratabileceğimiz özel modeller hakkında konuşmak istiyorum. Bunları bir araya getirebilmemiz için hepsini aynı modelleme platformunda oluşturmamız önemlidir. Bu, boyutsal modelleri ve ayrıca size göstereceğim NoSQL gibi bazı yeni veri kaynaklarını kullanan modelleri de içerir. Ve sonra, veri hattı modeli neye benziyor? Ve bu verileri bir iş süreci modeline nasıl ekleriz, bundan sonra bahsedeceğimiz şey budur.
Size çok yüksek ve hızlı bir genel bakış sağlamak için burada bir modelleme ortamına geçeceğim. Ve şimdi ekranımı görebilmeniz gerektiğine inanıyorum. Öncelikle sadece geleneksel tipte bir veri modeli hakkında konuşmak istiyorum. Ve modelleri getirdiğimizde organize etme şeklimiz, onları ayrıştırabilmek istiyoruz. Yani burada sol tarafta gördüğünüz şey bu özel model dosyasında mantıksal ve fiziksel modellere sahip olmamız. Bir sonraki şey, işi ayrıştırma boyunca bozabileceğimizden, bu yüzden klasörleri görüyorsunuz. Açık mavi olanlar mantıksal modeller ve yeşil olanlar fiziksel modellerdir. Ayrıca, ER / Studio'da, bir iş ayrışmasına sahipseniz, istediğiniz kadar derin veya alt modellere gidebilir ve daha düşük seviyelerde yaptığınız değişiklikler otomatik olarak daha yüksek oranda yansıtılabilir. 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, aynı zamanda bir mantıksal modele de karşılık gelen birden fazla fiziksel modele sahip olabileceğimizdir. Çoğu zaman mantıklı bir modeliniz olabilir, ancak farklı platformlarda ve bu tür şeylerde fiziksel modelleriniz olabilir. Belki biri SQL Server örneği, belki de bir Oracle örneğidir. Hepsini aynı modelleme ortamında birbirine bağlama yeteneğine sahibiz. Ve yine burada, elde ettiğim şey, yine aynı modelleme ortamında olabilen veya depoda bulabilen ve farklı şeyler arasında ilişkilendirebilen gerçek bir veri ambarı modeli.
Bu konuda size göstermek istediğim şey, girdiğimiz modellerin bazıları ve diğer değişkenlerden bazıları. Dolayısıyla böyle bir geleneksel veri modeline girdiğimizde, sütunlarla, meta verilerle ve bu tür şeylerle tipik varlıkları görmeye alışkını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şiyor veya bazı insanlar hala onları aramak istiyorsa, büyük veri teknolojileri.
Şimdi diyelim ki, çevremizde de Hive var. Mühendisleri bir Hive ortamından tersine çevirirsek - ve bu aynı modelleme aracıyla Hive'dan mühendisleri ileri ve geri alabiliriz - biraz daha farklı bir şey görüyoruz. Hala tüm verileri orada bir yapı olarak görüyoruz, ancak TDL’niz farklı. SQL'i görmeye alışık olanlarınız, şimdi göreceğiniz şey, Hive QL, çok SQL benzeri ama şu anda farklı komut dosyası dilleriyle çalışmaya başlayabileceğiniz aynı araçtan. Böylece, bu ortamda modelleyebilir, Hive ortamına çıkarabilirsiniz, ancak en önemlisi, açıkladığım senaryoda, her şeyi 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 başka platform. Ayrıca, JSON'un belge depolarının bulunduğu ortamlara girmeye başladığınızda, JSON farklı bir hayvandır ve bunda ilişkisel modellere karşılık gelmeyen 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 uğraşmaya başlarsınız ve bu kavramlar geleneksel ilişkisel gösterimde yoktur. Burada yaptığımız şey, aynı ortamda bununla başa çıkabilmek için gösterimi ve kataloğumuzu genişlettiğimiz.
Burada sola bakarsanız, varlıklar ve tablolar gibi şeyleri görmek yerine, onlara nesne diyoruz. Ve farklı gösterimler görüyorsunuz. Burada hala tipik referans notasyonu türlerini görüyorsunuz, ancak bu belirli şemada gösterdiğim mavi varlıklar aslında gömülü nesneler. Ve farklı kardinaliteler gösteriyoruz. Elmas kardinalite, bir ucunda bir nesne olduğu anlamına gelir, ancak bir kardinalite, bu ilişkiyi takip edersek yayıncının içinde bir gömülü adres nesnesine sahip olduğumuz anlamına gelir. JSON'u sorgularken, tam olarak kullanıcının içine yerleştirilmiş, ancak aslında bir nesne dizisi olarak gömülmüş nesnelerin yapısının aynı olduğunu gördük. Bunu yalnızca bağlayıcıların kendileri aracılığıyla değil, aynı zamanda gerçek varlıklara bakarsanız, aynı zamanda bir nesne dizisi olarak sınıflandırılmış adresleri kullanıcı altında gördüğünüzü göreceksiniz. Bunu nasıl getirebileceğinize dair çok açıklayıcı bir bakış açısı elde edersiniz.
Ve şimdi, birkaç saniye içinde şimdiye kadar gördüğümüz şey çok seviyeli geleneksel ilişkisel modeller, Hive ile aynı şeyi yapabiliriz, MongoDB ile aynı şeyi yapabiliriz ve diğer büyük veri kaynaklarıyla iyi. Ayrıca yapabileceğimiz şey, ve size bunu çok hızlı bir şekilde göstereceğim, şeyleri diğer alanlardan getirmenin gerçeğinden bahsettim. Bir veritabanından bir model ithal edeceğimi veya tersine mühendislik yapacağımı varsayacağım, ancak harici meta verilerden getireceğim. Sadece size getirmeye başlayabileceğimiz farklı türden şeylerin hızlı bir bakış açısını vermek için.
Gördüğünüz gibi, meta verilerini modelleme ortamımıza dahil edebileceğimiz sayısız şey var. Amazon Redshift, Cassandra, hatta diğer büyük veri platformlarından birçoğu gibi şeylerle başlayarak, bunların birçoğunu listelediğinizi görüyorsunuz. Bu alfabetik sırada. Çok fazla büyük veri kaynağı ve bu tür bir şey görüyoruz. Ayrıca, bu meta verileri gerçekten getirebileceğimiz çok sayıda geleneksel veya eski modelleme ortamı görüyoruz. Buradan geçersem - ve hepsine zaman harcayamayacağım - modelleme platformları ve veri platformları açısından onu getirebileceğimiz birçok farklı şey görüyoruz. Ve burada gerçekleşmesi çok önemli bir şey, veri sohbeti hakkında konuşmaya başladığımızda yapabileceğimiz bir başka bölüm, Enterprise Team Edition'da, Talend veya SQL Server Bilgi Servisleri eşleşmeleri gibi şeyler yapabiliriz, ETL kaynaklarını da sorgulayabiliriz. aslında bunu veri lineage diyagramlarımıza başlatabilir ve bu dönüşümlerde neler olduğuna dair bir resim çizebiliriz. Kutudan çıktığımızda, aslında Enterprise Team Edition ürününün bir parçası olan bu farklı köprülerin 130'undan fazlasına sahibiz, bu yüzden tüm eserleri bir modelleme ortamına çok hızlı bir şekilde çekmemize gerçekten yardımcı oluyor.
Son fakat en az değil, aynı zamanda veri ambarlama veya herhangi bir analitik türünü yaparsak diğer yapı türlerine ihtiyaç duyduğumuz gerçeğini görme yeteneğimizi kaybedemeyeceğimizden de bahsetmek istiyorum. Halen boyut tabloları, boyut tabloları ve bu tür şeylerin olduğu boyutsal modeller gibi şeyler yapabilmek istiyoruz. Size göstermek istediğim bir şey de, meta veride boyutların türlerini ve diğer her şeyi kategorize etmemize yardımcı olacak uzantılarımız olabilir. Bu yüzden, eğer buradaki boyutsal veri sekmesine bakarsam, örneğin bunlardan birinde, gördüğü model desenine dayanarak aslında otomatik olarak algılar ve bunun bir boyut mu yoksa bir boyut mu düşündüğü konusunda bir başlangıç noktası verir. olgu tablosu. Ancak bunun ötesinde, yapabileceğimiz şey boyutlar içindedir ve bu tür bir şeyin, verileri veri depolama ortamındaki bir türde de sınıflandırmak için kullanabileceğimiz farklı boyut türlerine bile sahibiz. Bu, birlikte dikiş attığımız çok güçlü yetenekler.
Şu anda demo ortamında bulunduğumdan bu işe atlayacağım ve slaytlara geri dönmeden önce size birkaç şey daha göstereceğim. Yakın zamanda ER / Studio Data Architect'e eklediğimiz şeylerden biri de durumlarla karşılaştığımız - ve projeler üzerinde çalışırken bu çok yaygın bir kullanım durumudur - geliştiriciler nesneler açısından düşünürken verilerimizdir. 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 ve hatta iş analistlerinin veya iş kullanıcılarının onları farklı nesneler veya iş kavramları olarak düşünebilecekleri birkaç temel kavramı temsil eder. Bunları şimdiye dek sınıflandırmak çok zor oldu, ancak 2016 sürümünde ER / Studio Enterprise Team Edition'da gerçekten yaptığımız şey şu anda İş Verileri Nesneleri adlı bir konsepte sahibiz. Yapmamızı sağlayan şey, varlık gruplarını veya tabloları gerçek iş nesnelerine kapsüllememize izin vermesidir.
Mesela, bu yeni görüşde burada elde ettiğimiz şey, Satınalma Siparişi başlığı ve Sipariş Hattı artık bir araya getirilmiş, bir nesne olarak kapsüllenmiş durumdalar, verileri sürdürdüğümüzde bunları bir iş birimi olarak düşünürüz. ve onları bir araya getiriyoruz, böylece bunu farklı izleyicilerle ilişkilendirmek artık çok kolay. Modelleme ortamı boyunca tekrar kullanılabilirler. Onlar sadece bir çizim kurgusu değil, aynı zamanda gerçek bir objedir, ayrıca modelleme perspektifinden iletişim kurarken onları seçmeli olarak daraltabilir veya genişletebiliriz, böylece belirli paydaş kitleleriyle diyaloglar için özetlenmiş bir görünüm oluşturabiliriz. ve elbette, teknik izleyici kitlesi için burada gördüğümüz gibi daha ayrıntılı bir görünüme sahip olabiliriz. Bize gerçekten iyi bir iletişim aracı veriyor. Şu an gördüğümüz, birden fazla farklı model tipini birleştirmek, onları iş veri nesneleri kavramı ile güçlendirmek ve şimdi bu tip şeyler için gerçekte nasıl daha fazla anlam ifade ettiğimiz ve bunları nasıl bir araya getirdiğimiz hakkında konuşacağım. genel ortamlar
Sadece WebEx'imi burada bulmaya çalışıyorum, böylece bunu yapabildim. Ve işte başlıyoruz, Hot Tech slaytlarına geri dönüyoruz. Burada birkaç slaytı ileri saracağım, çünkü bunları zaten model gösterisinde gördünüz. Standartları çok hızlı bir şekilde adlandırmak hakkında konuşmak istiyorum. Farklı adlandırma standartlarını uygulamak ve uygulamak istiyoruz. Yapmak istediğimiz şey, temelde bu anlamı kelimelerle ya da ifadelerle ya da kısaltmalar yoluyla inşa etmek için isimlendirme standartları şablonlarını depolarımızda saklayabilmemiz ve onları anlamlı bir İngilizce sözcük türüne bağlayabilmemizdir. İş terimlerini, her birinin kısaltmasını kullanacağız ve siparişi, vakaları ve ön ekleri ve sonekleri ekleyebiliriz. Bunun için tipik kullanım örneği, tipik olarak insanlar mantıklı bir model oluştururken ve daha sonra, aslında kısaltmaları ve diğer her şeyi kullanabilecekleri fiziksel bir model oluşturmak için ilerlediğindedir.
Güzel olan şey şu ki, geriye dönük olarak daha güçlü, hatta daha güçlü, eğer bu adlandırma standartlarının bazılarının tersine çevirdiğimiz fiziksel veritabanlarının bazılarında ne olduğunu söyleyebilirsek, bu kısaltmaları alabilir, daha uzun sürebiliriz. kelimeleri ve İngilizce kelimeleri içine geri getirin. Aslında şimdi verilerimizin neye benzediğine göre uygun adlar türetebiliriz. Dediğim gibi, tipik kullanım durumu, fiziksel olarak mantıklı, veri depolarını ve bu tür şeyleri haritaya doğru ilerletmek. Sağ taraftaki ekran görüntüsüne bakarsanız, kaynak adlarından kısaltılmış adlar olduğunu göreceksiniz ve bir adlandırma standartları şablonu uyguladığımızda, aslında daha fazla tam adımız var. Ve eğer istersen, kullandığımız adlandırma standartları şablonuna bağlı olarak boşluklar ve bunun gibi her şeyi koyabiliriz. Görünmesini sağlayabiliriz, ancak modellerimizi içine sokmasını istiyoruz. Sadece bir şeyin ne dendiğini bildiğimizde, aslında tanımları eklemeye başlayabiliriz, çünkü ne olduğunu bilmiyorsak, ona nasıl bir anlam uygulayabiliriz?
Güzel olan şu ki, her türlü şeyi yaptığımızda bunu gerçekten çağırabiliriz. Tersine mühendislik hakkında konuştum, tersine mühendislik yaparken aynı anda adlandırma standartları şablonlarını çağırabiliriz. Yani bir sihirbaz aracılığıyla atılan adımlardan birinde, yapabileceğimiz şey, sözleşmelerin ne olduğunu bilirsek, fiziksel bir veritabanını tersine çevirebiliriz, onu modelleme ortamında fiziksel modeller olarak geri getirecek ve bu Ayrıca bu adlandırma kurallarını uygulayacağım. Böylece isimlerin İngilizce benzeri temsillerinin çevrede ilgili mantıksal modelde ne olduğunu göreceğiz. Ayrıca bunu yapabilir ve XML Schema nesliniyle birleştirebiliriz, böylece bir model alabilir ve hatta SOA çerçeveleri ya da bu tür bir şey yapsak da kısaltmalarımıza çıkarabiliriz, böylece farklı adlandırma kurallarını da kaldırabiliriz. aslında modelin kendisinde sakladık. Bize çok güçlü yetenekler kazandırıyor.
Yine, burada bir şablonum olsaydı nasıl görüneceğinin bir örneği. Bu, bir isimlendirme standartları sözleşmesinde “çalışan” için “ÇYP”, “maaş için” PLN, “plan için” PLN olduğumu gösteriyor. Modelleri oluştururken ve bir şeyler koyarken etkileşimli olarak çalıştırmaları için onları da uygulayabilirim. Bu kısaltmayı kullanıyor olsaydım ve işletme adına "Çalışan Maaş Planı" yazarsam, adlandırma standartları şablonu ile hareket ederdi. Burada tanımlamıştım, varlıkların yaratılması ve bana hemen karşılık gelen fiziksel isimleri verdiğim için EMP_SAL_PLN verecekti.
Yine, mühendisliği tasarladığımız ve ileri götürdüğümüz zamanlar için çok iyi. Çok özel bir konsepte sahibiz ve bu ortamları gerçekten bir araya getirmeye başladık.Ve buna Evrensel Eşlemeler denir. Bu modellerin tümünü çevremize, ne yapabileceğimize karar verdikten sonra, şimdi bu adlandırma kurallarını uyguladığımızı ve kolayca bulabildiklerini varsayarsak, şimdi ER'de Evrensel Eşlemeler adlı bir yapı kullanabiliriz. /Stüdyo. Varlıkları modeller arasında bağlayabiliriz. “Müşteri” yi gördüğümüz her yerde - muhtemelen bir çok farklı sistemde ve bir çok farklı veritabanında “müşterimiz” olacak - tüm bunları bir araya getirmeye başlayabiliriz; Diğer modellerde müşterilerin tezahürlerinin nerede olduğunu görebilir. Ve bunu temsil eden bir model katmanına sahip olduğumuz için, onu veri kaynaklarına bağlayabilir ve bunları, hangi veritabanlarının içinde bulundukları sorulan sorgularımızda bulabiliriz. Bu bize gerçekten bütün bunları birbirine çok bağlı bir şekilde bağlayabilmemizi sağlıyor.
Size işletme veri nesnelerini gösterdim. Ayrıca, Ek olarak adlandırdığımız meta veri uzantıları hakkında çok hızlı bir şekilde konuşmak istiyorum. Bu, bize model nesnelerimiz için ek meta veriler oluşturma yeteneği veriyor. Sık sık, veri yönetimi ve veri kalitesi perspektifinden birçok farklı şeyi ortaya çıkarmak ve ayrıca ana veri yönetimi ve veri saklama politikaları konusunda bize yardımcı olmak için bu tür özellikleri kurardım. Temel fikir, bu sınıflamaları yaratmanızdır ve bunları istediğiniz yerde, tablo düzeyinde, sütun düzeyinde, bu tür şeyleri ekleyebilirsiniz. Tabii ki en yaygın kullanım durumu, varlıkların tablo olmasıdır ve ardından tanımlayabilirim: ana veri nesnelerim nelerdir, referans tablolarım nelerdir, işlem tablolarım nelerdir? Veri kalitesi perspektifinden iş açısından önem açısından sınıflandırmalar yapabilirim, böylece veri temizleme çabalarına ve bu tür şeylere öncelik verebiliriz.
Genellikle göz ardı edilen bir şey de, kuruluşumuzdaki farklı veri türleri için saklama politikası nedir? Bunları kurabiliriz ve onları modelleme ortamımızdaki ve tabii ki depomuzdaki farklı bilgi eserleri türlerine ekleyebiliriz. İşin aslı, bu ekler veri sözlüğümüzde yaşamaktadır, bu nedenle çevrede kurumsal veri sözlüklerini kullanırken, bunları birden fazla modele ekleyebiliriz. Onları yalnızca bir kez tanımlamamız gerekir ve onları çevremizdeki farklı modellerde tekrar tekrar kaldırabiliriz. Bu, ne zaman ek yapılacağını, ekleyeceğiniz parçaların ne olduğunu gerçekten belirtebileceğinizi gösteren hızlı bir ekran görüntüsüdür. Ve buradaki bu örnek aslında bir değerler listesidir, bu yüzden içeri girdiklerinde bir değer listesinden seçim yapabilirsiniz, seçildikleri modelleme ortamında çok fazla kontrol sahibi olursunuz ve hatta varsayılanın ne olduğunu bile belirleyebilirsiniz. değer, bir değer seçilmediyse olur. Yani orada çok fazla güç. Veri sözlüğünde yaşıyorlar.
Bu ekranda size biraz daha göstermek istediğim bir şey var, ek olarak üst kısımda göründüğü ekleri görüyorsunuz, altında veri güvenliği bilgilerini görüyorsunuz. Veri güvenliği politikalarını, ortamdaki farklı bilgilere de uygulayabiliriz. Farklı uyumluluk eşlemeleri, veri güvenliği sınıflandırmaları için, bunları üretebileceğiniz ve kullanmaya başlayabileceğiniz bir dizi kutudan gönderiyoruz, ancak kendi uygunluk eşlemelerini ve standartlarını da tanımlayabilirsiniz. HIPAA veya başka bir girişimde bulunup bulunmadığınız. Ve gerçekten bu çok zengin meta veri kümesini ortamınızda oluşturmaya başlayabilirsiniz.
Ve sonra Terimler Sözlüğü ve Terimler - iş anlamının bağlandığı yer burasıdır. Sık sık veri sözlüklerimiz var. Bir örgütün sözlükleri çıkarmaya başlamak için başlangıç noktası olarak kullandığı sık sık veri sözlüklerimiz var, ancak terminoloji ve sözler genellikle çok teknik. Öyleyse yapabileceğimiz, eğer istersen, bunları sözlükleri yok etmek için bir başlangıç noktası olarak kullanabiliriz, ancak gerçekten işletmelerin bunlara sahip olmasını istiyoruz. Ekip sunucusu ortamında yaptığımız şey, insanlara işletme tanımları oluşturma becerisi vermemiz ve ardından bunları modelleme ortamında karşılaştıkları farklı model yapılarına bağlayabilmemizdir. Ayrıca daha önce tartışılan noktayı da kabul ediyoruz; bu da yazdıkça ne kadar çok insan olursa, insan hatası için o kadar fazla potansiyel var. Sözlük yapımızda ayrıca yaptığımız şey şudur: birincisi, sözlük hiyerarşisini destekliyoruz, bu nedenle organizasyonda farklı sözlük türlerine veya farklı türlere sahip olabiliriz, ama en önemlisi, bu kaynaklardan bazılarına sahipseniz Orada tanımlanmış terimler ve tanımlanmış her şeyle, aslında bunları modelleme ortamımıza ve ekip sunucumuza ya da sözlüğümüze çekmek için bir CSV ithalatı yapabilir ve ardından oradan bağlantı vermeye başlayabiliriz. Her ne zaman bir şey değiştirilirse, önceki ve sonraki görüntülerin ne olduğu, tanımlamalar ve diğer her şey açısından tam bir denetim izi vardır ve çok yakın bir gelecekte geleceğini göreceğiniz şey aynı zamanda daha fazla yetkilendirme iş akışıdır. Bu nedenle, yönetişim sürecini ilerledikçe daha da sağlam kılmak için kimin sorumlu olduğunu, komiteler veya bireylerin onaylarını ve bu tür bir şeyi gerçekten kontrol edebiliriz.
Bunun bizim için de yaptığı şey, takım sözlük sözlüğümüzde bu sözlük terimlerimiz olduğunda, bu, burada ortaya çıkardığım modelin kendisindeki bir varlıkta düzenleme örneğidir. Bağlantılı terimler olabilir, fakat aynı zamanda yaptığımız şey bu sözlükte yer alan ve buradaki varlıklarımızda sahip olduğumuz notların açıklamalarında veya açıklamalarında görünen kelimeler varsa, bunlar otomatik olarak daha açık renkli bir renkte gösterilirse ve fare üzerindeyken, aslında sözlük sözlükteki tanımı da görebiliriz. Orada bulunan tüm sözlük terimlerle bilgiyi kendimiz tüketirken bize daha zengin bilgiler bile veriyor. Gerçekten bu deneyimi zenginleştirmek ve birlikte çalıştığımız her şeye anlam uygulamak için yardımcı olur.
Yani, yine, bu çok hızlı bir uçtu. Açıkçası, farklı parçalara dalaştıkça bunun üzerinde günler harcayabiliriz, ancak bu, yüzey üzerinde çok hızlı bir uçucudur. Gerçekten yapmak istediğimiz şey, bu karmaşık veri ortamlarının nasıl göründüğünü anlamak. Tüm bu veri eserlerinin görünürlüğünü arttırmak ve ER / Studio ile birlikte onları uzaklaştırmak için işbirliği yapmak istiyoruz. Daha verimli ve otomatik veri modelleme sağlamak istiyoruz. Ve bu, büyük veriler, geleneksel ilişkisel veriler, belge depoları veya başka bir şey olsun, bahsettiğimiz her tür veridir. Ve yine başardık, çünkü farklı platformlar ve orada bulunabilecek diğer araçlar için güçlü ileri ve geri mühendislik yeteneklerine sahibiz. Tüm mesele organizasyondaki tüm paydaşlarla paylaşmak ve iletişim kurmaktır. Bu, adlandırma standartlarını kullanarak anlam uygulayacağımız yer. Daha sonra tanımları iş sözlüklerimizle uygularız. Daha sonra, veri kalitesi uzantıları, ana veri yönetimi için 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ş kitleleri ile iş veri nesneleriyle daha da özetleyebilir ve iletişimi daha da artırabiliriz.
Ve yine, bu konuda çok önemli olan, hepsinin arkasında, çok sağlam değişiklik yönetimi yeteneklerine sahip entegre bir depo. Bugün bunu gösterecek zamanım olmadı çünkü oldukça karmaşıklaşıyor, ancak depoda çok sağlam değişiklik yönetimi yetenekleri ve denetim izleri var. Adlandırılmış sürümleri yapabilirsiniz, adlandırılmış sürümleri yapabilirsiniz ve ayrıca değişim yönetimi yapanlarınız için de yeteneğimize sahibiz, bunu doğrudan görevlerinize bağlayabiliriz. Bugün geliştiricilerde görevler ekleme ve model değişikliklerinizi görevlerle ilişkilendirme yeteneğine sahibiz, tıpkı geliştiricilerin kod değişikliklerini birlikte çalıştıkları görevler veya kullanıcı hikayeleriyle ilişkilendirmeleri gibi.
Yine, bu çok hızlı bir genel bakıştı. Umarım iştahınızı açmak için yeterli olmuştur, böylece ileride ilerledikçe bu konuların bazılarını ayırma konusunda daha derin konuşmalar yapabiliriz. Vakit ayırdığınız için teşekkür ederim ve size döneceğim Rebecca.
Rebecca Jozwiak: Teşekkürler, Ron, bu harikaydı ve seyircilerden epeyce sorum var, ancak analistimize dişlerini söylediklerine batırma şansı vermek istiyorum. Eric, devam edeceğim ve belki de bu slaytı ele almak istersen ya da başka bir tane, neden önce devam etmiyorsun? Ya da başka bir soru.
Eric Küçük: Elbette. Üzgünüm, soru neydi Rebecca? Özel bir şey sormamı mı istiyorsun?
Rebecca Jozwiak: Başlangıçta Ron için bazı soruların olduğunu biliyorum. Şimdi onlardan herhangi birini ya da bazılarını slaydınızdan ya da ilginizi çeken başka bir şeyden bahsetmesini isteyip istemediğinizi sormak ister misiniz? IDERA’nın modelleme işlevleri hakkında.
Eric Küçük: Evet, öyleyse bunlardan biri, Ron, nasılsınız beyler, gösterdiğiniz şemalar normalde veri tabanı yapımında kullanacağınız gibi genel varlık ilişkisi şemaları gibi görünüyor, doğru mu?
Ron Huizenga: Evet, genel olarak konuşursak, elbette, belge depoları için genişletilmiş türlere ve bu tür şeylere sahibiz. Aslında sadece saf ilişkisel gösterimden farklı olduk, aslında bu diğer mağazalar için ek notlar da ekledik.
Eric Küçük: Grafik tabanlı modelleme modellerini kullanmanın bir yolu var mı, bu nedenle, örneğin bir üst kadranda, TopBraid besteci aracı gibi bir şey yaptığımı veya Protégé'de bir şey yaptığımı varsayalım. Bilirsiniz, FIBO’daki finansal adamlar gibi, anlambilimde çok fazla çalışma yapıyorlar, RDF işleri - bu tür varlık-ilişki grafik tipi modellemeyi bu araca sokmanın ve kullanmanın bir yolu var mı?
Ron Huizenga: Aslında grafikleri nasıl idare edebileceğimize bakıyoruz. Bugün açıkça grafik veritabanlarını ve bu tür şeyleri işlemiyoruz, ancak meta verilerimizi genişletmek için yapabileceğimiz yöntemlere 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 şeyler aracılığıyla bir şeyler getirebiliriz. Ama bunu getirmenin daha zarif yollarını arıyoruz.
Ayrıca size sahip olduğumuz tersine mühendislik köprülerinin listesini de gösterdim, bu yüzden her zaman belirli platformlar için bu köprülere uzantıları bulmaya bakıyoruz. Bu yeni yapıları ve buradaki farklı platformların çoğunu kucaklamaya başlamak, mantıklıysa, sürekli ve devam eden bir çabadır. Ancak şunu söyleyebilirim ki kesinlikle bunu yapmanın ön saflarındayız. Örneğin, MongoDB'de ve bu türde şeylerde gösterdiğim şeyler, aslında bunu kendi ürünümüzde yapan ilk veri modelleme satıcısıyız.
Eric Küçük: Tamam, evet Öyleyse, sana sorduğum diğer soru, yönetişim ve bunun korunması - örneğini kullandığınız gibi, “çalışan” örneğini gösterdiğinizde olduğu gibi, “ maaş ”ve sonra bir“ planınız ”var, bir yolu var, örneğin, sahip olabilecek farklı tür insanları nasıl yönetirsiniz - hadi büyük bir mimariye sahip olduğunuzu varsayalım, doğru, büyük bir girişiminiz olduğunu varsayalım ve insanlar bu araçta bir şeyler bir araya getirmeye başlarlar ve burada “çalışan” kelimesini içeren bir grup ve burada “çalışan” kelimesini içeren bir grup vardır. Ve buradaki bir kişi “maaş” diyor ve bir başkası diyor "ücret."
Bu tür ayrımları nasıl uzlaştırır, yönetir ve yönetirsiniz? Çünkü bunu grafik dünyasında nasıl yapacağımızı biliyorum, biliyorsunuz, eş anlamlı listelerini kullanırdınız ya da tek bir kavram olduğunu söylersiniz ve birkaç özelliği vardır, ya da SKOS modelinde tercih edebileceğiniz bir etiket olduğunu söyleyebilirim. Kullanabileceğim çok sayıda alternatif etiket. Bunu nasıl yapıyorsunuz?
Ron Huizenga: Bunu birkaç farklı yolla yapıyoruz ve öncelikle terminoloji hakkında konuşalım. Yaptığımız şeylerden biri, elbette, tanımlanmış veya onaylanmış terimlere sahip olmak istiyoruz ve işletme sözlüğünde açıkça onları istediğimiz yer. Ayrıca, sözlük sözlükteki eş anlamlılara bağlantılara izin veriyoruz, böylece yapabilecekleriniz söyleyebiliyorsunuz, işte benim terimim, ancak bunlar için tüm eş anlamlıları da tanımlayabilirsiniz.
Şimdi, ilginç olan, elbette, bu geniş veri ortamına, oradaki tüm bu farklı sistemlerle bakmaya başladığınızda, oraya çıkamaz ve karşılık gelen tabloları ve bu tür şeyleri değiştiremezsiniz. Aldığınız bir paket olabileceğinden, bu adlandırma standardına karşılık gelir, böylece veritabanını veya herhangi bir şeyi değiştirmeyi kontrol edemezsiniz.
Burada yapabileceğimiz, sözlük tanımlarını ilişkilendirebilmenin yanı sıra, bahsettiğim evrensel eşlemeler, ne yapacağımızı ve önerilen bir yaklaşımı kullanarak, neyi ortaya koyan kapsamlı bir mantıksal modele sahip olmaktır. Bu farklı iş kavramları hakkında konuşuyorsun. Ticari terimler sözlüğü terimlerini bunlarla ilişkilendirin ve güzel olan şudur ki, şimdi olduğu gibi mantıksal bir varlığı temsil eden bu yapıya sahipseniz, o zaman bu mantıksal varlıktan bu mantıksal varlığın tüm uygulamalarına bağlanmaya başlayabilirsiniz. farklı sistemler.
Öyleyse, bunun üzerinde ihtiyaç duyduğunuz yerde, oh, burada “kişi” olarak adlandırılan bu sistemde “çalışan” olarak adlandırılır. Buradaki “maaş” bu diğer sistemde “ücret” olarak adlandırılmaktadır. Çünkü bunu göreceksiniz, bunların tüm farklı tezahürlerini göreceksiniz, çünkü onları birbirine bağladınız.
Eric Küçük: Tamam harika, evet, anladım. Bu anlamda, nesneye yönelik yaklaşımlardan bazılarına benzer olduğunu söylemek güvenli midir?
Ron Huizenga: Biraz. Sanırım söyleyebileceğinden biraz daha yoğun. Demek istediğim, hepsini elle de bağlama ve geçme, denetleme ve yapma yaklaşımını benimseyebilirsin. Bir şey hakkında gerçekten konuşma şansım olmadı - çünkü yine de çok fazla kapasitemiz var - Data Architect aracının kendisinde de tam bir otomasyon arayüzümüz var. Ve gerçekten de araçtaki bir programlama dili olan bir makro yetenek. Böylece aslında makro yazma, bazı şeyleri sorgulama ve sizin için bağlantılar oluşturma gibi şeyler yapabiliriz. Bilgi almak ve vermek için kullanıyoruz, bir şeyleri değiştirmek veya nitelikler eklemek için kullanabiliriz, modelin kendisinde bulunan olayı yapabiliriz veya bunları gerçekten dışarı çıkıp sorgulamak ve aslında farklı yapıları doldurmak için gruplar halinde kullanabiliriz. modeli. Böylece, insanların da faydalanabileceği tam bir otomasyon arayüzü var. Ve evrensel haritalamaların bunlarla kullanılması, 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ı. Biliyorum, saatin biraz üstünde koşuyoruz, ama Malcolm'a Ron'un yolunda bazı soruları sorma şansı vermek istiyorum. Malcolm?
Malcolm Chisholm: Sağol Rebecca. Öyleyse Ron, çok ilginç, burada çok fazla yetenek olduğunu görüyorum. Çok ilgi duyduğum alanlardan biri, bir geliştirme projemiz varsa, bu özellikleri kullanan ve iş analistleriyle, veri profil uzmanıyla, veri kalitesi analistiyle daha işbirlikçi bir şekilde çalışan veri modelleyicisini nasıl görüyorsunuz? ve nihayetinde projedeki gerçek bilgi gereksinimlerinden sorumlu olacak işletme sponsorlarıyla. Veri modelleyicisi aslında, bildiğiniz gibi, araştırdığımız yeteneklerle projeyi nasıl daha verimli ve verimli hale getiriyor?
Ron Huizenga: Yapmanız gereken ilk şeylerden birinin bir veri modelleyicisi olduğunu düşünüyorum - ve bazı modelleyicileri seçmek istemiyorum, ama yine de yapacağım - bazı insanlar hala veri modelleyicisinin olduğu izlenimini uyandırıyor. Gerçekten de bekçinin rolü gibi bir şey, 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. Fakat en önemli şey bir veri modelleyicisi olarak - ve bunu danışmanlık yaparken oldukça açık bir şekilde buldum - bir kolaylaştırıcı olmanız gerekiyor, bu yüzden bu insanları bir araya getirmelisiniz.
Artık bir ön tasarım, oluşturma, veri tabanı oluşturma olmayacak - yapmanız gereken tek şey, tüm bu farklı paydaş gruplarıyla çalışabilmeniz, tersine mühendislik, bilgi alma, içeri alma gibi diğer insanlar, sözlüklerde ya da belgelerde olsun, bunun gibi her şeyde işbirliği yapar - ve bunu depoya çekmek ve depodaki kavramları birbirine bağlamak ve bu insanlarla çalışmak için kolaylaştırıcı olur.
Gerçekten de, görev tanımları veya tartışma konuları ya da ekip sunucusunda sahip olduğumuz bu tür şeyler aracılığıyla bile, insanların gerçekten birlikte çalışabilecekleri, sorular sorabilecekleri ve nihai ürünlerine gelebilecekleri, işbirliğine dayalı bir ortam türü. veri mimarisi ve organizasyonu için ihtiyaç. Cevap bu mu?
Malcolm Chisholm: Evet katılıyorum. Bilirsin, kolaylaştırma becerisinin veri modelleyicilerinde gerçekten çok istenen bir şey olduğunu düşünüyorum. Bunu her zaman göremediğimize katılıyorum, ancak bunun gerekli olduğunu düşünüyorum ve veri modellemenizi yaparken bazen köşenizde kalmaya meyilli olduğunuzu düşünüyorum, ama orada gerçekten diğer paydaş gruplarıyla çalışmanı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 düşüncem.
Ron Huizenga: Bu ilginç, çünkü işletmelerin BT’den nasıl geri çevrildiğine dair geçmişiniz hakkında daha önce bahsettiğiniz bir şeyden bahsettiniz, çünkü çözümleri zamanında ve bu tür şeylerde sunmadılar.
Daha sonraki danışmanlık faaliyetlerimde, ürün yöneticisi olmadan önce, son iki yıl içinde yaptığım projelerin çoğunun, işletme sponsoru olması, aslında onu yönlendiren işin ve veri mimarlarının olduğu çok ilginçti. ve modelleyiciler BT'nin bir parçası değildi. İş sponsorluğundaki bir grubun parçasıydık ve geri kalan proje ekipleriyle çalışan kolaylaştırıcılar olarak oradaydık.
Malcolm Chisholm: Bu yüzden bunun çok ilginç bir nokta olduğunu düşünüyorum.Sanırım iş dünyasında işin sorduğu, belki de düşündüğü, ne yaptığım kadar değil, süreç gibi bir değişim görmeye başlıyoruz ama aynı zamanda verilerin ne olduğunu düşünmeye başlıyorlar. birlikte çalıştığım, veri ihtiyaçlarım neler, veri olarak uğraştığım veriler nedir ve bu bakış açısını desteklemek için IDERA ürünlerini ve kapasitelerini ne ölçüde alabiliriz ve işin ihtiyaçlarını bile Yine de biraz aceleyle geliyor.
Ron Huizenga: Sizinle aynı fikirdeyim ve sanırım gittikçe daha fazla ilerlediğini görüyoruz. Bir uyanış gördük ve verinin önemi açısından daha önce ona dokundunuz. Bilişim teknolojisinin başlarında veya veritabanlarının evriminde verinin önemini gördük, daha sonra dediğiniz gibi, tüm bu süreç yönetimi döngüsüne girdik - ve süreç son derece önemli, beni yanlış anlama - ama şimdi ne oldu Bu gerçekleştiğinde, veri türünün odağını kaybetti.
Ve şimdi kuruluşlar verinin gerçekten odak noktası olduğunun farkındalar. Veriler, işimizde yaptığımız her şeyi temsil eder; bu nedenle, doğru verilere sahip olduğumuzdan emin olmamız gerekir, kararlarımızı almak için gereken doğru bilgiyi bulabiliriz. Çünkü her şey tanımlanmış bir süreçten gelmez. Bilgilerin bir kısmı başka şeylerin bir yan ürünüdür ve hala orada bulabildiğimiz, ne anlama geldiğini öğrenebileceğimiz ve sonuçta orada gördüğümüz verileri işlerimizi daha iyi sürdürebilmek için kullanabileceğimiz bilgiye çevirebilmemiz gerekir.
Malcolm Chisholm: Doğru ve şimdi uğraştığım başka bir alan da veri yaşam döngüsü dediğim şeydir, yani, bilirsiniz, bir kuruluştan geçen bir veri tedarik zincirine bakarsak, veri toplamaya başlarız ya da veri girişi olabilir, ancak aynı şekilde olabilir, veri toplama, bazı veri satıcısından kurum dışından veri alıyorum.
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ır, verinin asıl noktaları, verilerden değer elde edersiniz.
Ve eski günlerde bunların hepsi tek bir tarzda yapılır, ama bugün, örneğin, bir analitik ortamı olabilir, ve daha sonra artık bir veri toplayamadığımız bir arşivi, bir mağazaya, ihtiyaç ve nihayet bir tasfiye işlemi. Bu veri yaşam döngüsünün tümünün yönetimine uygun veri modellemeyi nasıl görüyorsunuz?
Ron Huizenga: Bu çok iyi bir soru ve bugün burada hiçbir ayrıntıya girmek için vaktim olmadığım bir şey, gerçekte konuşmaya başladığımız şey veri soyudur. Yani gerçekte yapabileceğimiz şey, araçlarımızda bir veri soyu kabiliyetim kabiliyetimiz var ve dediğim gibi, aslında ETL araçlarından bir kısmını çıkarabiliriz, ancak aynı zamanda sadece soyu çizerek de haritalandırabilirsiniz. Elde ettiğimiz ve modele getirdiğimiz bu veri modellerinden veya veritabanlarından herhangi biri, yapıları veri lineage diyagramımızda referans olarak alabiliriz.
Yapabileceğimiz tek şey, sizin dediğiniz gibi, kaynaktan hedefe ve bu verilerin farklı sistemler arasında nasıl iletildiğinin ve bulacağınız şeyin genel yaşam döngüsü boyunca bir veri akışı çizmektir. 'veri - bu yıllar önce yaptığım bir projeye dayanarak favorilerimden biri. Çalışan verileri olan 30 farklı sistemde çalışan bir organizasyonla çalıştım. Orada yaptığımız şey - ve Rebecca'nın veri soyunma slaydını açtı - bu oldukça basit bir veri soyağacı slaydı, ancak yapabileceğimiz şey tüm veri yapılarını getirip şemada referans vermekti. gerçekte aralarındaki akışlara bakmaya başlayabilir ve bu farklı veri varlıkları bir akışta birbirine nasıl bağlanır? Ve bunun ötesine de gidebiliriz. Bu, burada gördüğümüz bir veri akışı veya soy diyagramının bir parçasıdır. Bunun ötesine geçmek istiyorsanız, bu süitin iş mimarı kısmına da sahibiz ve burada da aynı şey geçerli.
Veri modelleme ortamında yakaladığımız herhangi bir veri yapısından herhangi biri, iş modelleme aracında referans gösterilebilir, böylece iş modeli şemalarınızda veya iş süreci şemalarınızda bile veri modelleme ortamı ve bunları iş süreci modelinizdeki klasörlerde kullanırken, bu bilgilerin nasıl tüketildiği veya üretildiğine ilişkin olarak CRUD'ları da belirtebilirsiniz ve sonra üretmeye başlayabiliriz. Etki ve analiz gibi şeyler raporlar ve bunun diyagramlarıdır.
Neye ulaşmak istediklerimiz ve zaten çok fazla kapasitemiz var, ancak ilerlemekte olan araçlarımızı geliştirmeye devam ederken, aradığımız bir tür hedef hedefimizden biri. bu uçtan uca, örgütsel veri soyunu ve verilerin tam yaşam döngüsünü tespit edebiliyor.
Malcolm Chisholm: Tamam. Rebecca, bir kişiye daha izin verebilir miyim?
Rebecca Jozwiak: Sana bir tane daha izin vereceğim Malcolm, devam et.
Malcolm Chisholm: Çok teşekkür ederim. Veri yönetişimi hakkında düşünmek ve veri modelleme hakkında düşünmek, bu iki grubun birlikte etkili bir şekilde çalışmasını ve birbirini anlamasını nasıl sağlayabiliriz?
Eric Küçük: İlginçtir, gerçekten organizasyona bağlı olduğunu düşünüyorum ve girişimlerin iş odaklı olduğu kuruluşlarda, doğrudan bağlı kaldık. Daha önceki konseptime dayanıyor. Örneğin, bir veri mimarisi ekibine liderlik ediyordum ama biz iş kullanıcıları ile doğrudan ilişkiliydi ve aslında veri yönetişim programlarını kurmalarına yardımcı oluyorduk. Yine, daha fazla danışma yaklaşımı, ancak bu gerçekten bir işletme fonksiyonudur.
Bunu yapabilmek için gerçekten ihtiyacınız olan şey, işi gerçekten anlayan, işletme kullanıcıları ile ilişki kurabilen ve daha sonra etrafındaki yönetim süreçlerini kaldırmalarına yardımcı olan veri modelleyicileri ve mimarlara ihtiyaç duymanızdır. İş yapmak istiyor, ancak genel olarak konuşursak, bu tür programları önleme konusunda onlara yardımcı olabilecek teknoloji bilgisine sahibiz. Gerçekten bir işbirliği olması gerekiyor, ancak işletmeye sahip olması gerekiyor.
Malcolm Chisholm: Tamam bu harika. Teşekkür ederim.
Eric Little: Tamam.
Rebecca Jozwiak: Tamam, çok teşekkürler. Seyirci üyeleri, sorularınızı alamadığımızdan korktum, ancak bugün onlardan uygun misafirlere yönlendirildiklerinden emin olacağım. Bugün misafirlerimiz olduğu için Eric, Malcolm ve Ron'a çok teşekkür ederim. Bu harikaydı, millet. Ve bugünün IDERA web yayınını beğendiyseniz, IDERA da katılmak istiyorsanız, indeksleme ve Oracles'ın zorluklarını tartışan, yani büyüleyici bir konu olan Tartışmalar önümüzdeki Çarşamba günü Hot Technologies'de olacak.
Çok teşekkür ederim millet, kendinize iyi bakın, bir dahaki sefere görüşürüz. Güle güle.