De personalul Techopedia, 28 septembrie 2016
Take away : Gazda Rebecca Jozwiak discută soluții de arhitectură a datelor cu Eric Little din OSTHUS, Malcolm Chisholm din First San Francisco Partners și Ron Huizenga de la IDERA.
În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.
Rebecca Jozwiak: Doamnelor și domnilor, salut și bine ați venit la Hot Technologies din 2016. Astăzi discutăm „Construirea unei arhitecturi de date bazate pe afaceri”, cu siguranță un subiect fierbinte. Numele meu este Rebecca Jozwiak, voi fi gazda dvs. pentru transmisia web de astăzi. Facem un tweet cu un hashtag de # HotTech16, așa că dacă sunteți deja pe Twitter, vă rugăm să nu ezitați să vă alăturați și la asta. Dacă aveți întrebări în orice moment, vă rugăm să le trimiteți în panoul Q&A din partea dreaptă jos a ecranului și ne vom asigura că vor primi răspunsuri. Dacă nu, ne vom asigura că oaspeții noștri le vor primi pentru tine.
Așadar, astăzi avem o gamă cu adevărat fascinantă. Astăzi o mulțime de lovituri grele cu noi. Avem Eric Little, VP de știință a datelor de la OSTHUS. Avem Malcolm Chisholm, ofițer șef de inovație, care este un titlu cu adevărat interesant, pentru First San Francisco Partners. Și îl avem pe Ron Huizenga, senior product manager de la IDERA. Și, știți, IDERA are o suită foarte completă de gestionare a datelor și soluții de modelare. Și azi ne va oferi o demonstrație despre cum funcționează soluția lui. Dar înainte să ajungem la asta, Eric Little, am să-ți transmit mingea.
Eric Little: Bine, mulțumesc mult. Așadar, voi parcurge câteva subiecte aici, care cred că se vor referi puțin la discuțiile lui Ron și, sper, să stabilesc scena și pentru unele dintre aceste subiecte, unele Q&A.
Așadar, lucrul care m-a interesat în ceea ce face IDERA este că cred că subliniază corect că mediile complexe conduc într-adevăr o mulțime de valori de business în zilele noastre. Și prin medii complexe ne referim la medii complexe de date. Și tehnologia se mișcă cu adevărat rapid și este greu să ții pasul în mediul de afaceri de astăzi. Așadar, acei oameni care lucrează în spații tehnologice vor vedea adesea că aveți clienți cu care se confruntă probleme: „Cum folosesc date mari? Cum incorporez semantica? Cum pot face legătura dintre aceste lucruri noi cu datele mele mai vechi? ”Și așa mai departe, și acest fel ne conduce în zilele noastre în aceste patru versiuni de date mari cu care mulți oameni sunt destul de familiarizați și înțeleg că pot exista mai mult de patru uneori - am văzut până la opt sau nouă - dar, în mod normal, când oamenii vorbesc despre lucruri precum date mari sau dacă vorbești despre date mari, de obicei te uiți la ceva care este un fel de scara întreprinderii. Și așa oamenii vor spune, bine, bine, gândiți-vă la volumul datelor dvs., care este în mod normal accentul - tocmai cât aveți. Viteza datelor are legătură cu cât de repede o pot deplasa sau cu cât de repede o pot interoga sau pentru a primi răspunsurile etc. Și personal cred că partea stângă este ceva care este rezolvat și gestionat relativ repede de o mulțime de abordări diferite. Dar pe partea dreaptă văd multă capacitate de îmbunătățire și o mulțime de noi tehnologii care vin cu adevărat în prim plan. Și asta are de-a face cu a treia coloană, varietatea de date.
Cu alte cuvinte, majoritatea companiilor analizează date structurate, semi-structurate și nestructurate. Datele de imagine încep să devină un subiect fierbinte, astfel încât să poți folosi viziunea computerului, să te uiți la pixeli, să poți razi text, NLP, extragerea entității, ai informații grafice care ies din modele statistice sau care ies din semantice. modele, aveți date relaționale existente în tabele și așa mai departe. Așadar, colectarea tuturor acestor date și toate aceste tipuri diferite reprezintă într-adevăr o provocare mare și veți vedea acest lucru în Gartner și în alte persoane care urmează un fel de tendințe în industrie.
Și atunci ultimul lucru despre care vorbesc oamenii în date mari este adesea această noțiune de voracitate, care este cu adevărat incertitudinea datelor dvs., neplăcerile acestora. Cât de bine știți despre ce este vorba despre datele dvs., cât de bine înțelegeți ce este acolo și știți? Posibilitatea de a folosi statistici și capacitatea de a folosi un tip de informație în jurul a ceea ce ați putea ști sau de a folosi un anumit context, poate fi de valoare aici. Și deci abilitatea de a privi datele în acest mod în termeni de cât de mult aveți, de cât de repede trebuie să-l mutați sau să ajungeți la acestea, toate tipurile de date pe care le puteți avea în întreprinderea dvs. și cât de sigur sunteți de unde este, ce este, în ce calitate este și așa mai departe. Acest lucru necesită într-adevăr un mare efort coordonat acum între o mulțime de indivizi pentru a-și gestiona datele în mod eficient. Prin urmare, modelarea datelor este din ce în ce mai importantă în lumea de azi. Așa că modelele de date bune conduc cu adevărat mult succes în aplicațiile de întreprindere.
Aveți surse de date dintr-o varietate de surse, cum spuneam, ceea ce necesită într-adevăr multe tipuri de integrare diferite. Așadar, tragerea tuturor la un loc este cu adevărat utilă pentru a putea rula interogări, de exemplu, pe numeroase tipuri de surse de date și pentru a trage informațiile înapoi. Dar, pentru a face asta, aveți nevoie de strategii de mapare bune, astfel încât cartografierea acestor tipuri de date și păstrarea acestor mapări poate fi o adevărată provocare. Și atunci aveți această problemă, cum pot să leg datele de moștenire la toate aceste noi surse de date? Deci, să presupunem că am grafic, iau toate datele mele relaționale și le pun în grafic? De obicei, nu este o idee bună. Deci, cum se face că oamenii sunt capabili să gestioneze toate aceste tipuri de modele de date care se întâmplă? Analiza trebuie să fie efectuată pe o mulțime de aceste tipuri diferite de surse de date și combinații. Deci, răspunsurile care ies din asta, răspunsurile de care oamenii au nevoie pentru a lua cu adevărat decizii bune de afaceri sunt critice.
Deci nu este vorba doar de construirea tehnologiei de dragul tehnologiei, ci de fapt, ce voi face, ce pot face cu ea, ce fel de analiză pot rula și capacitatea, prin urmare, așa cum am făcut deja Am vorbit despre, pentru a reuni aceste lucruri, pentru a-l integra este într-adevăr, într-adevăr important. Și unul dintre aceste tipuri de analize rulează apoi lucruri precum căutarea și interogarea federată. Asta devine cu adevărat o necesitate. În mod normal, întrebările dvs. trebuie să fie trecute pe mai multe tipuri de surse și să trageți informațiile într-un mod fiabil.
Unul dintre elementele cheie pe care deseori, în special oamenii vor analiza lucrurile cheie precum tehnologiile semantice - iar acest lucru sper că Ron va vorbi un pic în abordarea IDERA - este modul în care vă separați sau gestionați modelul stratului de date din stratul de date în sine, din datele brute? Deci, în stratul de date este posibil să aveți baze de date, este posibil să aveți date de documente, puteți avea date de foi de calcul, puteți avea date de imagine. Dacă vă aflați în domenii precum industria farmaceutică, aveți cantități vaste de date științifice. Și apoi, pe deasupra, acești oameni caută în mod normal o modalitate de a construi un model care să le permită să integreze rapid aceste date și chiar atunci când cauți date acum nu cauți să tragi toate datele în stratul de model., ceea ce te uiți la stratul de model de făcut este să îți oferi o reprezentare logică plăcută a ceea ce sunt lucrurile, vocabularele comune, tipurile comune de entități și relații și capacitatea de a ajunge cu adevărat la datele unde se află. Deci, trebuie să spună ce este și trebuie să spună unde se află și trebuie să spună cum să o aducă și să o aducă înapoi.
Așadar, aceasta a fost o abordare care a avut un succes destul de mare în propulsarea tehnologiilor semantice înainte, care este un domeniu în care lucrez foarte mult. Așadar, o întrebare pe care am vrut să o pun pentru Ron și care cred că va fi utilă în secțiunea Q&A, este de a vedea cum se realizează acest lucru prin platforma IDERA? Deci stratul model este separat de fapt de stratul de date? Sunt mai integrate? Cum funcționează asta și care sunt unele dintre rezultatele și beneficiile pe care le văd din abordarea lor? Prin urmare, datele de referință devin într-adevăr critice. Așadar, dacă veți avea aceste tipuri de modele de date, dacă veți putea să vă conferați și să căutați în diverse lucruri, trebuie să aveți cu adevărat date de referință bune. Dar problema este că datele de referință pot fi cu adevărat greu de întreținut. Deci, de multe ori, numirea standardelor în și în sine sunt o provocare dificilă. Un grup va numi ceva X și un grup va numi ceva Y și acum aveți problema cum găsește cineva X și Y când caută acest tip de informații? Deoarece nu doriți să le oferiți doar o parte din date, doriți să le oferiți tot ce are legătură. În același timp, se schimbă termenii, software-ul devine învechit și așa mai departe, cum păstrați și mențineți datele de referință în timp?
Și, din nou, tehnologiile semantice, folosind în mod special lucruri precum taxonomiile și vocabularile, dicționarele de date, au oferit un mod de spațiu standard pentru a face acest lucru, care este într-adevăr puternic, utilizează anumite tipuri de standarde, dar comunitatea bazei de date a făcut acest lucru pentru o mult timp, de asemenea, doar în diferite moduri. Cred că una dintre cheile de aici este să ne gândim la cum să folosești poate modele cu relații de entitate, cum să folosești poate modele grafice sau un tip de abordare aici, ceea ce îți va oferi într-adevăr un mod distanțat de manipulare a datelor de referință. Și, desigur, odată ce aveți datele de referință, strategiile de mapare trebuie să gestioneze o mare varietate de nume și entități. Așadar, adesea experții în materie le place să-și folosească propriii termeni.
Așadar, o provocare în acest sens este întotdeauna, cum să oferiți informațiilor cuiva, dar să o faceți relevantă pentru modul în care vorbește despre asta? Deci, un grup poate avea o modalitate de a privi ceva, de exemplu, este posibil să fiți un chimist care lucrează la un medicament și puteți fi un biolog structural care lucrează la același medicament și puteți avea nume diferite pentru aceleași tipuri de entități care se referă la domeniul tău. Trebuie să descoperiți modalități de a reuni acele terminologii personalizate, deoarece cealaltă abordare este aceea, trebuie să forțați oamenii să renunțe la termenul lor și să le folosească pe altcineva, ceea ce de multe ori nu le place. Un alt punct aici este că manipularea unui număr mare de sinonime devine dificilă, așa că există multe cuvinte diferite în datele multor oameni care se pot referi la același lucru. Aveți o problemă de referință acolo folosind un set de relații mult-la-unu. Termenii specializați diferă de la industrie la industrie, astfel încât dacă veți găsi un fel de soluție generală pentru acest tip de gestionare a datelor, cât de ușor este de portabil de la un proiect sau de la o aplicație la alta? Aceasta poate fi o altă provocare.
Automatizarea este importantă și este, de asemenea, o provocare. Este scump să gestionați manual datele de referință. Este scump să trebuiască să păstrați manual cartografierea și este scump ca experții în materie să înceteze să își facă treburile de zi cu zi și să fie nevoiți să intri și să repare constant dicționarele de date și să re-actualizeze definițiile și așa mai departe, etc. Vocabularile replicabile arată într-adevăr multă valoare. Deci, acestea sunt vocabulare de multe ori pe care le puteți găsi externe organizației. Dacă lucrați în țiței, de exemplu, vor exista anumite tipuri de vocabulare pe care le puteți împrumuta din spații open-source, la fel cu produsele farmaceutice, la fel cu industria bancară și financiar, la fel și cu multe astfel de domenii. Oamenii pun acolo vocabulare reutilizabile, generice, replicabile, pentru a le folosi.
Și, din nou, uitându-mă la instrumentul IDERA, sunt curioasă să văd cum gestionează acest lucru în ceea ce privește utilizarea tipurilor de standarde. În lumea semanticii vezi adesea lucruri precum modelele SKOS care oferă standarde pentru relații cel puțin mai mari decât / mai restrânse decât relațiile, iar aceste lucruri pot fi dificil de făcut în modelele ER, dar, știi, nu este imposibil, depinde doar de cât de mult din asta utilaje și acea legătură pe care o puteți gestiona în acele tipuri de sisteme.
Așadar, în sfârșit, am vrut doar să fac o comparație cu niște motoare semantice pe care le văd în industrie și să-l rog un pic pe Ron și să-l încredințez puțin pentru a vorbi despre modul în care sistemul IDERA a fost utilizat în combinație cu orice tehnologii semantice. Este capabil să fie integrat cu magazine triple, baze de date grafice? Cât de ușor este să folosești surse externe, deoarece aceste tipuri de lucruri din lumea semantică pot fi împrumutate adesea folosind SPARQL Endpoints? Puteți importa modele RDF sau OWL direct în modelul dvs. - consultați-le înapoi - deci, de exemplu, ontologia genică sau ontologia proteică, care poate trăi undeva în spațiul propriu cu propria sa structură de guvernare și pot pur și simplu importa toate sau o parte din asta așa cum am nevoie în propriile mele modele. Și sunt curios să știu cum abordează IDERA această problemă. Trebuie să mențineți totul intern sau există modalități de a utiliza alte tipuri de modele standardizate și să le trageți și cum funcționează? Și ultimul lucru pe care l-am menționat aici este cât de multă activitate manuală este implicată într-adevăr pentru a construi glosarele și depozitele de metadate?
Știu că Ron o să ne arate câteva demo-uri despre aceste tipuri de lucruri care vor fi cu adevărat interesante. Însă problemele pe care le văd adesea consultându-se cu clienții este că apar multe erori dacă oamenii scriu în propriile definiții sau în propriile lor metadate. Deci, primiți greșeli de greșeli, primiți erori cu degetul gras, acesta este un lucru. De asemenea, obțineți oameni care ar putea lua ceva, știți, doar Wikipedia sau o sursă care nu este neapărat de calitatea pe care o puteți dori în definiția dvs. sau definiția dvs. este doar din perspectiva unei persoane, deci nu este completă și nu este clar atunci cum funcționează procesul de guvernare. Guvernanța, desigur, fiind o problemă foarte, foarte mare de fiecare dată când vorbești despre date de referință și oricând vorbești despre modul în care acestea se pot încadra în datele de bază ale cuiva, despre cum vor folosi metadatele lor și curând.
Așa că am vrut doar să pun câteva dintre aceste subiecte acolo. Acestea sunt elemente pe care le văd în spațiul de afaceri pe mai multe tipuri diferite de angajamente de consultanță și o mulțime de spații diferite și sunt foarte interesat să văd ce ne va arăta Ron cu IDERA pentru a sublinia unele dintre aceste subiecte . Deci mulțumesc foarte mult.
Rebecca Jozwiak: Mulțumesc foarte mult, Eric și îmi place foarte mult comentariul tău potrivit căruia multe erori pot apărea dacă oamenii își scriu propriile definiții sau metadate. Știu că în lumea jurnalismului există o mantră care „mulți ochi fac puține erori”, dar când vine vorba de aplicații practice, prea multe mâini în borcanul cu cookie-uri tind să te lase cu o mulțime de cookie-uri sparte, nu?
Eric Little: Da, și germeni.
Rebecca Jozwiak: Da. Cu asta o să merg mai departe și o voi transmite lui Malcolm Chisholm. Malcolm, podeaua este a ta.
Malcolm Chisholm: Mulțumesc foarte mult, Rebecca. Aș dori să arunc un pic o privire asupra a ceea ce vorbește Eric și să adaug la câteva observații cărora, știi, Ron ar putea să le răspundă, vorbind despre „Spre arhitectura de date condusă de afaceri ”- ce înseamnă să fii condus de afaceri și de ce este atât de important? Sau este doar o formă de hype? Nu cred că este.
Dacă ne uităm la ce se întâmplă, de vreme ce, știți, computerele mainframe au devenit cu adevărat disponibile pentru companii - să spunem, în jurul anului 1964 - până astăzi, putem vedea că au fost multe schimbări. Și aceste modificări le-aș rezuma ca fiind o schimbare de la centricitatea procesului la centrarea datelor. Și asta este ceea ce face arhitecturile de date bazate pe afaceri atât de importante și atât de relevante pentru astăzi. Și cred că, știți, nu este doar un cuvânt de cuvânt, ci ceva care este absolut real.
Dar îl putem aprecia puțin mai mult dacă ne scufundăm în istorie, deci revenind în timp, înapoi în anii 1960 și pentru o perioadă de timp după aceea, majoritatea cadrelor au dominat. Acestea au cedat apoi PC-urilor unde aveți o rebeliune a utilizatorilor la intrarea PC-urilor. Rebeliunea împotriva IT-ului centralizat, care credeau că nu își îndeplinește nevoile, nu au fost suficient de agili. Acest lucru a dat naștere rapid la calcularea distribuită, când PC-urile erau legate între ele. Și atunci internetul a început să se întâmple, care a estompat limitele întreprinderii - acum putea interacționa cu părțile din afara sa în ceea ce privește schimbul de date, ceea ce nu se întâmplase până acum. Și acum am intrat în era cloud și a datelor mari în care cloud-ul este platforme care într-adevăr comercializează infrastructura și astfel, lăsăm, așa cum s-a spus, IT-ul necesității de a rula centre de date mari pentru că, știți, noi Avem la dispoziție capacitatea de cloud și concomitent cu acele date mari despre care Eric știe, atât de elocvent, discutat. Și, în general, așa cum vedem, pe măsură ce schimbarea tehnologiei s-a produs, a devenit mai centrată pe date, ne pasă mai mult de date. La fel ca în internet, cum se schimbă datele. Cu date mari, cele patru sau mai multe versiuni ale datelor în sine.
În același timp, și poate mai important, cazurile de utilizare a afacerilor s-au schimbat. Când au fost introduse computerele pentru prima dată, au fost folosite pentru a automatiza lucrurile precum cărțile și înregistrările. Și orice a fost un proces manual, care a inclus leduri sau lucruri de genul acesta, au fost programate, în esență, în casă. Aceasta a trecut în anii 80 la disponibilitatea pachetelor operaționale. Nu mai aveai nevoie să-ți mai scrii propria salariu, poți cumpăra ceva care să facă asta. Acest lucru a dus la o reducere redusă la acea vreme sau la restructurarea în multe departamente IT. Dar apoi informațiile de afaceri, cu lucruri precum depozitele de date au apărut, mai ales în anii 90. Urmați modele de afaceri dotcom, care au fost, desigur, o mare frenezie. Apoi MDM. Cu MDM începeți să vedeți că nu ne gândim la automatizare; ne concentrăm doar pe curatarea datelor ca date. Și apoi analitice, reprezentând valoarea pe care o puteți scoate din date. Și în cadrul analizelor vedeți companii care au un mare succes, al cărui model de business principal se învârte în jurul datelor. Google, Twitter, Facebook ar face parte din asta, dar puteți argumenta și faptul că Walmart este.
Așadar, afacerea se gândește cu adevărat la date. Cum putem obține valoare din date? Modul în care datele pot conduce afacerea, strategia și suntem în epoca de aur a datelor. Așadar, având în vedere faptul, ce se întâmplă în ceea ce privește arhitectura noastră de date, dacă datele nu mai sunt considerate ca fiind pur și simplu eșapamentul care iese din spatele aplicațiilor, ci este într-adevăr central pentru modelele noastre de afaceri? Ei bine, o parte din problema pe care o avem în realizarea faptului că este IT-ul este într-adevăr blocat în trecut cu ciclul de viață al dezvoltării sistemelor, care a fost o consecință a trebuit să se ocupe rapid de acea etapă de automatizare a proceselor la vârsta timpurie a IT și să lucreze în proiectele sunt un lucru similar. În ceea ce privește IT - și aceasta este un pic de caricatură - dar ceea ce încerc să spun este că unele dintre barierele pentru a obține o arhitectură de date bazată pe afaceri sunt pentru că am acceptat necritic o cultură în IT care derivă de la o vârstă trecută.
Deci, totul este un proiect. Spune-mi detaliat cerințele tale. Dacă lucrurile nu funcționează, este pentru că nu mi-ai spus cerințele tale. Ei bine, asta nu funcționează astăzi cu date, deoarece nu începem cu procese manuale neautomatizate sau, o știi, o conversie tehnică a proceselor de afaceri, începem foarte des cu date de producție deja existente pe care le încercăm pentru a obține valoare din. Dar nimeni care sponsorizează un proiect centrat pe date înțelege cu adevărat aceste date în profunzime. Trebuie să facem descoperirea datelor, trebuie să facem analiza datelor sursă. Și asta nu se potrivește cu dezvoltarea sistemelor, știți - cascadă, ciclul de viață SDLC - despre care Agile, aș menține, este un fel de versiune mai bună a acestui lucru.
Și pe ce se concentrează este tehnologia și funcționalitatea, nu datele. De exemplu, atunci când facem testarea într-o fază de testare, va fi de obicei, funcționalitatea mea funcționează, să spunem ETL-ul meu, dar nu testăm datele. Nu ne testăm ipotezele cu privire la datele sursă care intră. Dacă am face acest lucru, am fi într-o formă poate mai bună și, în calitate de cineva care a realizat proiecte de depozit de date și a suferit prin schimbări în amonte, au preluat ETL-urile mele, aș aprecia asta. Și, de fapt, ceea ce vrem să vedem este testarea ca o etapă preliminară pentru monitorizarea continuă a calității datelor de producție. Așadar, avem aici multe atitudini în care este dificil să realizăm arhitectura de date bazată pe afaceri, deoarece suntem condiționați de era centrării în proces. Trebuie să facem o tranziție către centrarea datelor. Și aceasta nu este o tranziție totală, știți, există încă o mulțime de lucrări de proces de făcut acolo, dar nu ne gândim cu adevărat în termeni centrați pe date când trebuie, și circumstanțele care apar atunci când suntem cu adevărat obligat să facă asta.
Acum, afacerea realizează valoarea datelor, vor să deblocheze datele, deci cum vom face asta? Deci, cum facem tranziția? Ei bine, punem datele în centrul proceselor de dezvoltare. Și lăsăm afacerea să conducă cu cerințe de informații. Și înțelegem că nimeni nu înțelege datele sursă existente la începutul proiectului. Ați putea argumenta că structura de date și datele în sine au ajuns acolo prin IT și, respectiv, operațiuni, așa că ar trebui să știm asta, dar într-adevăr, nu. Aceasta este o dezvoltare centrată pe date. Deci, trebuie să ne gândim unde facem și cum facem modelarea datelor într-o lume centrată pe date, trebuie să avem bucle de feedback pentru utilizatori în ceea ce privește rafinarea cerințelor lor de informații, în timp ce facem descoperirea datelor și profilarea datelor, previzualizăm analiza datelor sursă și, treptat, obținem din ce în ce mai multă certitudine cu privire la datele noastre. Și acum vorbesc despre un proiect mai tradițional precum un hub MDM sau un depozit de date, nu neapărat despre proiectele de date mari, deși acest lucru este încă, susțin, destul de aproape de asta. Și, astfel, aceste bucle de feedback includ modelatorii de date, știți, avansând treptat modelul lor de date și interacționând cu utilizatorii pentru a vă asigura că cerințele de informații sunt perfecționate pe baza a ceea ce este posibil, a ceea ce este disponibil, din datele sursă, deoarece acestea le înțeleg mai bine, deci nu mai este un caz al modelului de date fiind, știi, într-o stare care nu este acolo sau complet terminată, este o aducere treptată a acesteia.
În mod similar, mai în aval avem asigurarea calității atunci când dezvoltăm reguli pentru testarea calității datelor pentru a ne asigura că datele se încadrează în parametrii despre care facem presupuneri. Intrând, Eric se referea la modificările datelor de referință, care se pot întâmpla. Nu doriți să fiți, așa cum s-a spus, o victimă din aval, o schimbare neadministrată în zona respectivă, astfel încât normele de asigurare a calității pot intra în post-producție, monitorizare continuă a calității datelor. Așadar, puteți începe să vedeți dacă vom fi centrați pe date, modul în care facem dezvoltarea centrată pe date este destul de diferită de SDLC și Agile bazate pe funcționalitate. Și atunci trebuie să acordăm atenție și viziunilor de afaceri. Avem - și iarăși acest lucru răsună ceea ce spunea Eric - avem un model de date care definește un model de poveste de date pentru baza noastră de date, dar în același timp avem nevoie de acele modele conceptuale, acele opinii de afaceri ale datelor care, în mod tradițional, nu au fost realizate în trecutul. Ne-am gândit uneori, cred, că modelul de date poate face totul, dar trebuie să avem viziunea conceptuală, semantica și să analizăm datele, să o redăm printr-un strat de abstractizare care să transpună modelul de stocare în business. vedere. Și, din nou, toate lucrurile despre care vorbea Eric în ceea ce privește semantica, devin importante pentru a face acest lucru, așa că avem de fapt sarcini suplimentare de modelare. Cred că e interesant dacă ai venit pe rând ca modelator de date ca mine și, din nou, ceva nou.
Și în sfârșit aș dori să spun că arhitectura mai mare trebuie să reflecte și această nouă realitate. MDM-ul clienților tradiționali, de exemplu, este cam bun, bine, hai să aducem datele clienților noștri într-un hub în care putem, să știți, să-l înțelegem în ceea ce privește calitatea datelor doar pentru aplicațiile de back-office. Ceea ce din punct de vedere al strategiei de afaceri este un fel de căscat. Astăzi, însă, ne uităm la hub-urile MDM ale clienților care au în ele date suplimentare despre profilul clientului, nu doar datele statice, care atunci au într-adevăr o interfață bidirecțională cu aplicațiile de tranzacție ale clientului. Da, încă susțin back-office-ul, dar acum știm și despre aceste comportamente ale clienților noștri. Acest lucru este mai scump de construit. Acest lucru este mai complex de construit. Dar este bazat pe afaceri într-un mod în care MDM-ul clientului tradițional nu este. Voi tranzacționați o orientare către afacere împotriva unor modele mai simple, care sunt mai ușor de implementat, dar pentru afaceri, asta este ceea ce vor să vadă. Într-adevăr suntem într-o nouă eră și cred că există o serie de niveluri la care trebuie să răspundem arhitecturii de date bazate pe afaceri și cred că este un moment foarte interesant pentru a face lucrurile.
Vă mulțumesc, înapoi, Rebecca.
Rebecca Jozwiak: Mulțumesc Malcolm și chiar mi-a plăcut ceea ce ai spus despre modelele de date trebuie să alimenteze vederea business-ului, pentru că, spre deosebire de ceea ce spuneai, unde IT a ținut frâiele atât de mult timp și nu mai este un caz că cultura trebuie să se schimbe. Și sunt destul de sigur că în fundal a existat un câine care a fost de acord cu tine 100%. Și cu asta voi trece mingea lui Ron. Sunt foarte încântat să vă văd demo-ul. Ron, podeaua ta.
Ron Huizenga: Mulțumesc foarte mult și înainte să sarim în asta, voi parcurge câteva diapozitive și apoi un pic de demo, deoarece, așa cum au subliniat Eric și Malcolm, acesta este un subiect foarte larg și profund și cu ceea ce vorbim astăzi, doar ne zgâriem suprafața, deoarece există atât de multe aspecte și atât de multe lucruri pe care trebuie să le luăm în considerare și să le privim dintr-o arhitectură bazată pe afaceri. Iar demersul nostru este să facem cu adevărat acel model bazat pe model și să obținem adevărata valoare din modele, deoarece le puteți utiliza ca vehicul de comunicare, precum și ca strat pentru a permite alte sisteme. Indiferent dacă faceți o arhitectură orientată către servicii sau alte lucruri, modelul devine într-adevăr elementul de viață a ceea ce se întâmplă, cu toate metadatele din jurul său și datele pe care le aveți în afacerea dvs.
Despre ce vreau să vorbesc, este aproape că face acest pas înapoi, deoarece Malcolm a atins o parte din istoria modului în care soluțiile au evoluat și acest tip de lucruri. O modalitate de a sublinia cât de important este să aveți o arhitectură de date sănătoasă este un caz de utilizare pe care l-am folosit foarte des când consultam înainte de a intra într-un rol de management al produsului și, adică, aș intra în organizații. fie că făceau transformare de afaceri sau înlocuiau doar unele sisteme existente și acel tip de lucruri și a devenit foarte rapid evident modul în care organizațiile slab înțeleg propriile date. Dacă luați un caz particular de utilizare ca acesta, indiferent dacă sunteți un consultant sau poate este vorba despre o persoană care tocmai a început cu o organizație sau organizația dvs. a fost construită de-a lungul anilor cu achiziționarea de companii diferite, ceea ce încheiați este foarte rapid un mediu foarte complex, cu o serie de noi tehnologii diferite, precum și tehnologie veche, soluții ERP și orice altceva.
Așadar, unul dintre lucrurile pe care le putem face cu adevărat abordarea noastră de modelare este să răspundem la întrebarea, cum pot înțelege toate acestea? Putem începe cu adevărat să împărțim informațiile împreună, astfel încât afacerea să poată folosi informațiile pe care le avem în mod corespunzător. Și rezultă, ce anume avem acolo în acele medii? Cum pot folosi modelele pentru a extrage informațiile de care am nevoie și pentru a înțelege mai bine aceste informații? Și apoi avem tipurile tradiționale de metadate pentru toate lucrurile diferite, cum ar fi modelele relaționale de date și suntem obișnuiți să vedem lucruri precum definiții și dicționare de date, știți, tipuri de date și acel tip de lucru. Dar despre metadatele suplimentare pe care doriți să le capturați pentru a da cu adevărat și mai mult sens? Cum ar fi, ce entități sunt într-adevăr candidații care ar trebui să fie obiecte de date de referință, care ar trebui să fie obiecte de gestionare a datelor master și acele tipuri de lucruri și să le leagă între ele. Și cum curge informația prin organizație? Datele curg din modul în care sunt consumate atât din punct de vedere al procesului, dar și al liniei de date în ceea ce privește călătoria informației prin afacerile noastre și cum se face prin diferitele sisteme sau prin magazinele de date, așa că știm când construim soluțiile I sau acele tipuri de lucruri, consumăm informațiile corecte pentru sarcina la îndemână.
Și atunci este foarte important, cum putem face ca toți acești părți interesate să colaboreze, în special părțile interesate de afaceri, deoarece acestea sunt cele care ne oferă adevăratul sens al datelor care sunt. Afacerea, la sfârșitul zilei, deține datele. Ele furnizează definițiile vocabularilor și lucrurilor despre care vorbește Eric, așa că avem nevoie de un loc pentru a lega toate acestea. Și modul în care facem acest lucru este prin modelarea datelor noastre și arhitecturile de depozit de date.
Voi atinge câteva lucruri. Voi vorbi despre ER / Studio Enterprise Team Edition. În primul rând, voi vorbi despre produsul de arhitectură de date în care facem modelarea datelor și acel tip de lucruri, dar există o mulțime de alte componente ale suitei pe care o voi atinge foarte pe scurt. Veți vedea un fragment de Business Architect, care poate face modele conceptuale, dar putem face și modele de proces de afaceri și putem lega acele modele de proces pentru a conecta datele reale pe care le avem în modelele noastre de date. Ne ajută cu adevărat să reunim această legătură. Software Architect ne permite să facem construcții suplimentare, cum ar fi unele modelări UML și acele tipuri de lucruri, pentru a oferi logici de suport pentru unele dintre celelalte sisteme și procese despre care vorbim. Dar, foarte important, pe măsură ce coborâm, avem depozitul și serverul de echipă și voi vorbi despre asta ca fiind un fel de două jumătăți ale aceluiași lucru. Depozitul este locul în care stocăm toate metadatele modelate, precum și toate metadatele de afaceri, în termeni de glosare și termeni de afaceri. Și pentru că avem acest mediu bazat pe depozite, atunci putem împlini toate aceste lucruri diferite în același mediu și apoi le putem pune la dispoziție pentru consumări, nu numai pentru oamenii tehnici, ci și pentru oamenii de afaceri. Și așa începem cu adevărat să conducem colaborarea.
Și atunci ultima piesă despre care voi vorbi pe scurt este că, atunci când vă plimbați în aceste medii, nu este vorba doar de baze de date pe care le aveți acolo. Veți avea o serie de baze de date, magazine de date, veți avea, de asemenea, o mulțime de lucruri, ceea ce aș numi, artefacte moștenite. Poate că oamenii au folosit Visio sau alte diagrame pentru a descrie unele lucruri. Poate că au avut alte instrumente de modelare și acel tip de lucru. Așadar, ceea ce putem face cu MetaWizard este, de fapt, să extragem o parte din informațiile respective și să le introducem în modelele noastre, să le facem actuale și să le putem folosi, să le consumăm, în mod curent din nou, mai degrabă decât să le punem acolo. Acum devine o parte activă a modelelor noastre de lucru, ceea ce este foarte important.
Când intrați într-o organizație, așa cum am spus, există o mulțime de sisteme disparate, o mulțime de soluții ERP, soluții departamentale nepotrivite. Multe organizații folosesc și soluții SaaS, care sunt, de asemenea, controlate și gestionate extern, astfel încât nu controlăm bazele de date și acele tipuri de lucruri din gazde pe acestea, dar trebuie să știm în continuare cum arată aceste date și, desigur, metadatele din jurul acestui lucru. Ceea ce găsim, de asemenea, este o mulțime de sisteme moștenite învechite care nu au fost curățate din cauza acelei abordări bazate pe proiect despre care vorbise Malcolm. Este uimitor cum în ultimii ani organizațiile vor dezvolta proiecte, vor înlocui un sistem sau o soluție, dar de multe ori nu a mai rămas suficient bugetul proiectului pentru dezafectarea soluțiilor învechite, așa că acum sunt doar pe cale. Și trebuie să ne dăm seama ce putem scăpa de fapt în mediul nostru, precum și ce este util să mergem înainte. Și asta se leagă de slaba strategie de dezafectare. Aceeași chestie este parte integrantă.
Ceea ce găsim și pentru că, din toate aceste soluții diferite, au fost construite o mulțime de organizații, este că vedem o mulțime de interfețe punct la punct cu o mulțime de date care se deplasează în mai multe locuri. Trebuie să fim capabili să raționalizăm acest lucru și să ne dăm seama că linia de date pe care am menționat-o pe scurt, astfel încât să putem avea o strategie mai coezivă, cum ar fi utilizarea arhitecturii orientate către servicii, autobuzele de servicii pentru întreprinderi și acele tipuri de lucruri, pentru a furniza informațiile corecte la un tip de model de publicare și abonament pe care îl utilizăm corect pe parcursul activității noastre. Și atunci, desigur, mai trebuie să facem un fel de analiză, fie că folosim depozite de date, marts de date cu ETL tradițional sau folosim unele dintre noile lacuri de date. Totul se rezumă la același lucru. Este vorba despre toate datele, fie că sunt date mari, fie că sunt date tradiționale din bazele de date relaționale, trebuie să adunăm toate aceste date, astfel încât să le putem gestiona și să știm cu ce avem de-a face cu modelele noastre.
Din nou, complexitatea pe care o vom face este că avem o serie de pași pe care vrem să îi putem face. În primul rând, intrați și este posibil să nu aveți aceste planuri despre cum arată acel peisaj informațional. Într-un instrument de modelare a datelor, cum ar fi ER / Studio Data Architect, veți face mai întâi o mulțime de inginerie inversă în ceea ce privește să indicăm sursele de date care sunt acolo, să le aducem și apoi să le împletim în mai reprezentative. modele care reprezintă întreaga afacere. Important este că dorim să putem descompune acele modele și pe linii de afaceri, astfel încât să ne putem raporta la ele în bucăți mai mici, la care oamenii de afaceri se pot raporta și analistii de afaceri și alți actori care lucrează. pe el.
Standardele de denumire sunt extrem de importante și vorbesc despre asta în câteva moduri diferite aici. Denumirea standardelor în ceea ce privește modul în care numim lucrurile în modelele noastre. Este destul de ușor de făcut în modele logice, unde avem o convenție de denumire bună și un dicționar de date bun pentru modelele noastre, dar, de asemenea, vedem convenții de denumire diferite pentru o mulțime de modele fizice pe care le aducem. Când inginer invers, destul de des vedem nume prescurtate și acel tip de lucruri despre care voi vorbi. Și trebuie să le transpunem în nume engleze semnificative care sunt semnificative pentru afaceri, astfel încât să putem înțelege care sunt toate aceste date pe care le avem în mediul înconjurător. Și atunci mapările universale este modul în care le împletim.
În plus, ne vom documenta și defini mai departe și de aici putem clasifica datele noastre în continuare cu ceva numit atașamente, pe care vă voi arăta câteva diapozitive. Și apoi închiderea buclei, vrem să aplicăm acea semnificație de afaceri, care este locul în care ne legăm de glosarele noastre de afaceri și le putem lega de diferitele artefacte ale modelului nostru, așa că știm, când vorbim despre un anumit termen de afaceri, unde acesta este implementat în datele noastre în întreaga organizație. Și, în sfârșit, am vorbit deja despre faptul că avem nevoie de toate acestea pentru a fi depozitate bazate pe o mulțime de colaborări și capacități de publicare, astfel încât părțile interesate să le poată utiliza. Voi vorbi destul de repede despre inginerie inversă. Ți-am oferit deja o evidență foarte rapidă. Vă voi arăta asta într-o demonstrație reală doar pentru a vă arăta câteva dintre lucrurile pe care le putem aduce acolo.
Și vreau să vorbesc despre unele dintre diferitele tipuri de modele și diagrame pe care le-am produce în acest tip de scenariu. Evident, vom face modelele conceptuale în multe cazuri; Nu o să petrec mult timp pentru asta. Îmi doresc foarte mult să vorbesc despre modele logice, modele fizice și tipuri specializate de modele pe care le putem crea. Și este important să le putem crea pe toate în aceeași platformă de modelare, astfel încât să le putem lega împreună. Aceasta include modele dimensionale și, de asemenea, modele care utilizează unele dintre noile surse de date, cum ar fi NoSQL pe care vi le voi arăta. Și atunci, cum arată modelul de linie de date? Și despre cum vom stoca aceste date într-un model de proces de afaceri, despre ce vom vorbi în continuare.
Voi trece aici la un mediu de modelare doar pentru a vă oferi o imagine de ansamblu foarte înaltă și rapidă. Și cred că ar trebui să poți vedea ecranul meu acum. În primul rând vreau să vorbesc despre doar un tip tradițional de model de date. Iar modul în care dorim să organizăm modelele atunci când le aducem, este că vrem să le putem descompune. Deci, ceea ce vedeți aici în partea stângă este că avem modele logice și fizice în acest fișier model special. Următorul lucru este că îl putem descompune de-a lungul descompunerilor de afaceri, de aceea vedeți dosarele. Cele albastru deschis sunt modele logice, iar cele verzi sunt modele fizice. Și, de asemenea, putem descărca, astfel încât în cadrul ER / Studio, dacă aveți o descompunere de afaceri, puteți parcurge cât mai multe niveluri în profunzime sau sub-modele pe care doriți, iar modificările pe care le faceți la nivelele inferioare se reflectă automat la nivelul superior niveluri. Deci devine foarte rapid un mediu de modelare foarte puternic.
Ceva pe care vreau să-l subliniez, de asemenea, este foarte important pentru a începe să strângem aceste informații este faptul că putem avea mai multe modele fizice care corespund și unui singur model logic. De multe ori este posibil să aveți un model logic, dar este posibil să aveți modele fizice pe diferite platforme și acel tip de lucru. Poate este una dintre instanțele SQL Server, poate alta este o instanță Oracle. Avem capacitatea de a lega toate acestea împreună în același mediu de modelare. Și din nou, ceea ce am primit aici este un model de depozit de date care poate, din nou, să fie în același mediu de modelare sau îl putem avea în depozit și să-l legăm și în diferite lucruri.
Ce mi-am dorit cu adevărat să vă arăt în acest sens este câteva dintre celelalte lucruri și alte variante ale modelelor în care ajungem. Așadar, atunci când intrăm într-un model de date tradițional ca acesta, suntem obișnuiți să vedem entitățile tipice cu coloanele și metadatele și acel tip de lucru, dar acest punct de vedere variază foarte repede când începem să ne ocupăm de unele dintre aceste tehnologii NoSQL mai noi. sau, cum unii încă le mai spun, tehnologiile de date mari.
Deci, acum să spunem că avem și stup în mediul nostru. Dacă inversăm inginerul dintr-un mediu Hive - și putem transmite și inversa inginerii din Hive cu acest același instrument de modelare - vedem ceva care este puțin diferit. Încă vedem toate datele ca fiind construcții acolo, dar TDL-ul nostru este diferit. Cei dintre voi obișnuiți să vadă SQL, ceea ce ați vedea acum este Hive QL, care este foarte SQL, dar din același instrument pe care îl puteți începe acum să lucrați cu diferite limbaje de script. Așadar, puteți să modelați în acest mediu, să-l generați în mediul stup, dar la fel de important, în scenariul pe care l-am descris, puteți să îl inversați pe tot și să înțelegeți acest lucru și să începeți să-l împletiți împreună. .
Să luăm un altul care este puțin diferit. MongoDB este o altă platformă pe care o sprijinim nativ. Și când începi să intri în tipurile de medii JSON în care ai depozite de documente, JSON este un animal diferit și există construcții în asta, care nu corespund modelelor relaționale. În curând începeți să tratați concepte precum obiecte încorporate și tablouri de obiecte încorporate atunci când începeți să interogați JSON, iar acele concepte nu există în notația relațională tradițională. Ceea ce am făcut aici este că am extins de fapt notația și catalogul nostru pentru a putea gestiona asta în același mediu.
Dacă priviți în stânga aici, în loc să vedeți lucruri precum entități și tabele, le numim obiecte. Și vezi diferite notări. Încă vedeți tipurile tipice de notări de referință aici, dar aceste entități albastre pe care le arată în această diagramă particulară sunt de fapt obiecte încorporate. Și arătăm cardinalități diferite. Cardinalitatea diamantului înseamnă că este un obiect pe un capăt, dar cardinalitatea unuia înseamnă că avem, în cadrul editorului dacă urmăm această relație, avem un obiect de adresă încorporat. În interogarea JSON-ului am descoperit că este exact aceeași structură a obiectelor încorporate în patron, dar aceasta este de fapt încorporată ca o serie de obiecte. Vom vedea asta, nu numai prin conectorii înșiși, dar dacă te uiți la entitățile reale, vei vedea că vezi adrese sub patron, care îl clasifică și ca o serie de obiecte. Obțineți o perspectivă foarte descriptivă despre cum puteți aduce asta.
Și din nou, acum ceea ce am văzut până acum în doar câteva secunde sunt modelele relaționale tradiționale care sunt pe mai multe niveluri, putem face același lucru cu Hive, putem face același lucru cu MongoDB și alte surse mari de date ca bine. Ceea ce putem face și noi și vă voi arăta asta foarte repede este, am vorbit despre faptul că am adus lucrurile din alte domenii diferite. Urmează să presupun că voi importa un model dintr-o bază de date sau îl va inginer, dar o voi aduce din metadate externe. Doar pentru a vă oferi o perspectivă foarte rapidă a tuturor tipurilor de lucruri pe care le putem începe să le introducem.
După cum vedeți, avem o mulțime de lucruri cu care putem aduce metadatele în mediul nostru de modelare. Începând cu lucruri precum Amazon Redshift, Cassandra, o mulțime de alte platforme de date mari, așa că vedeți multe dintre acestea. Aceasta este în ordine alfabetică. Vedem o mulțime de surse de date mari și de acest tip de lucru. De asemenea, vedem o mulțime de medii de modelare tradiționale sau mai vechi, prin care putem aduce aceste metadate. Dacă trec pe aici - și nu o să petrec timp pentru fiecare dintre ele - vedem o mulțime de lucruri diferite pe care le putem aduce din, în ceea ce privește modelarea platformelor și a platformelor de date. Și ceva ce este foarte important să ne dăm seama aici este o altă parte pe care o putem face atunci când începem să vorbim despre linie de date, în Enterprise Team Edition putem interoga și surse ETL, indiferent dacă este vorba de mapări Talend sau SQL Server Information Information. aduce de fapt asta pentru a începe de asemenea diagrame de linie de date și a trage o imagine a ceea ce se întâmplă în acele transformări. În total, din cutie avem peste 130 de poduri diferite care fac parte din produsul Enterprise Team Edition, astfel încât ne ajută într-adevăr să reunim foarte repede toate artefactele într-un singur mediu de modelare.
Nu în ultimul rând, vreau să vorbesc despre faptul că nu putem pierde din vedere faptul că avem nevoie de celelalte tipuri de constructe dacă facem depozitare de date sau orice tip de analiză. Încă vrem să avem capacitatea de a face lucruri precum modele dimensionale, unde avem tabele de fapt și avem dimensiuni și aceste tipuri de lucruri. Un lucru pe care vreau să vi-l arăt și este că putem avea și extensii la metadatele noastre care ne ajută să clasificăm care sunt tipurile de dimensiuni și orice altceva. Așadar, dacă mă uit la fila cu date dimensionale aici, de exemplu, pe una dintre acestea, aceasta va detecta de fapt automat, pe baza modelului pe care îl vede, și vă va oferi un punct de plecare dacă consideră că este o dimensiune sau o tabel de fapt Dar, dincolo de asta, ceea ce putem face este în cadrul dimensiunilor și acel tip de lucruri avem chiar și diferite tipuri de dimensiuni pe care le putem folosi pentru a clasifica datele într-un tip de mediu de stocare a datelor. Capabilități atât de puternice, cu care ne împletim cu totul.
O să sar în acesta, de când sunt în mediul demo în acest moment și vă arăt câteva alte lucruri înainte de a sări înapoi la diapozitive. Unul dintre lucrurile pe care le-am adăugat recent la ER / Studio Data Architect este că ne-am confruntat cu situații - și acesta este un caz de utilizare foarte frecvent atunci când lucrezi la proiecte - dezvoltatorii gândesc în ceea ce privește obiectele, în timp ce datele noastre modelatorii tind să gândească în termeni de tabele și entități și acel tip de lucru. Acesta este un model de date foarte simplist, dar reprezintă câteva concepte de bază, în care dezvoltatorii sau chiar analiștii de afaceri sau utilizatorii de afaceri, ar putea să le considere obiecte sau concepte de afaceri diferite. A fost foarte dificil să le clasificăm până acum, dar ceea ce am făcut de fapt în ER / Studio Enterprise Team Edition, în versiunea 2016, este acum că avem un concept numit Business Data Objects. Și ceea ce ne permite să facem este că ne permite să încapsulăm grupuri de entități sau tabele în adevărate obiecte de afaceri.
De exemplu, ceea ce am obținut aici în această nouă vedere este antetul Comanda de cumpărare și Linia de comandă au fost reunite acum, sunt încapsulate ca obiect, ne-am gândi la ele ca o unitate de lucru atunci când persistăm datele și le aducem împreună, astfel încât acum este foarte ușor să le raportăm la publicuri diferite. Sunt reutilizabile în întregul mediu de modelare. Acestea sunt un adevărat obiect, nu doar o construcție de desen, dar avem și un plus de beneficiu că, atunci când comunicăm de fapt din perspectiva modelării, putem să le prăbușim sau să le extindem în mod selectiv, astfel încât să putem produce o vedere sumară pentru dialogurile cu anumite părți interesate, și, de asemenea, putem păstra viziunea mai detaliată, așa cum vedem aici pentru mai multe audiențe tehnice. Ne oferă cu adevărat un vehicul de comunicare foarte bun. Ceea ce vedem acum este combinarea mai multor tipuri diferite de modele, sporindu-le cu conceptul de obiecte de date de afaceri, iar acum voi vorbi despre modul în care aplicăm, de fapt, ceva mai mult pentru aceste tipuri de lucruri și despre modul în care le împletim împreună în medii generale.
Încerc doar să-mi găsesc WebEx-ul aici, astfel încât să pot face asta. Și acolo mergem, înapoi la diapozitivele Hot Tech. Voi înaintea rapid câteva diapozitive aici, deoarece le-ați văzut deja în demonstrația modelului în sine. Vreau să vorbesc despre denumirea standardelor foarte repede. Vrem să aplicăm și să aplicăm diferite standarde de denumire. Ceea ce vrem să facem este că avem capacitatea de a stoca de fapt șabloane de standarde în depozitele noastre, pentru a construi acest sens, prin cuvinte sau expresii sau chiar prescurtări, și să le legăm din nou de un tip de cuvânt englezesc semnificativ. Vom folosi termenii de afaceri, prescurtările pentru fiecare și putem specifica ordinea, cazurile și adăugați prefixe și sufixe. Cazul de utilizare tipic pentru acest lucru este de obicei atunci când oamenii au construit un model logic și apoi de fapt au avansat pentru a crea un model fizic unde ar fi putut utiliza abrevieri și orice altceva.
Lucrul frumos este că este la fel de puternic, chiar și mai puternic în sens invers, dacă putem spune doar ce au fost unele dintre aceste standarde de denumire pe unele din acele baze de date fizice pe care le-am conceput invers, putem lua acele abrevieri, le putem transforma în mai lungi cuvinte și aduceți-le înapoi în expresii engleze. Acum putem deriva nume adecvate pentru aspectul datelor noastre. Așa cum spuneam, cazul de utilizare tipic este să mergem înainte, logic spre fizic și să cartografiem stocările de date și acel tip de lucru. Dacă priviți ecranul din partea dreaptă, veți vedea că există nume prescurtate de la numele sursă și când am aplicat un șablon de standarde de denumire, de fapt, avem mai multe nume complete. Și am putea pune spații și tot așa, dacă dorim, în funcție de șablonul de standarde de denumire pe care l-am folosit. O putem face să pară, cu toate acestea, dorim să arate pentru a aduce modelele noastre. Doar atunci când știm cum se numește ceva, putem începe, de fapt, să-i atașăm definiții, pentru că, dacă nu știm ce este, cum îi putem aplica un sens?
Lucrul frumos este că putem invoca de fapt acest lucru atunci când facem tot felul de lucruri. Am vorbit despre inginerie inversă, putem invoca de fapt modele de standarde de denumire simultan atunci când facem tehnica inversă. Deci, într-un set de pași printr-un vrăjitor, ceea ce putem face este că, dacă știm care sunt convențiile, putem inversa o bază de date fizică, o vom readuce ca modele fizice într-un mediu de modelare și este de asemenea, va aplica acele convenții de denumire. Vom vedea deci care sunt reprezentările în nume englezesc ale modelelor în modelul logic corespunzător din mediu. Putem să o facem și să o combinăm cu generarea de scheme XML, astfel încât să putem lua un model și chiar să îl împingem cu prescurtările noastre, fie că facem cadre SOA sau acel tip de lucru, astfel încât să putem elimina și convenții de denumire diferite pe care le-am păstrat de fapt în modelul în sine. Ne oferă o mulțime de capacități foarte puternice.
Din nou, iată un exemplu despre cum ar arăta dacă aș avea un șablon. Acesta arată de fapt că aveam EMP pentru „angajat”, SAL pentru „salariu”, PLN pentru „plan” într-o convenție privind standardele de denumire. De asemenea, le pot aplica pentru ca acestea să funcționeze în mod interactiv în timp ce construiesc modele și introduc lucruri. Dacă foloseam această prescurtare și aș scrie „Planul de salarizare a angajaților” pe numele entității, ar acționa cu modelul de standarde de denumire. Am definit aici, mi-ar fi dat EMP_SAL_PLN pe măsură ce am creat entitățile și mi-ar fi dat imediat numele fizic corespunzător.
Din nou, foarte bine pentru când proiectăm și înaintăm și inginerie. Avem un concept foarte unic și de aici începem cu adevărat să reunim aceste medii. Și se numește mapări universale. După ce am adus toate aceste modele în mediul nostru, ce putem face, presupunând că acum am aplicat aceste convenții de denumire și sunt ușor de găsit, acum putem folosi o construcție numită Mappings Universal în ER /Studio. Putem conecta entități pe modele. Oriunde vedem „client” - probabil vom avea „client” într-o mulțime de sisteme diferite și o mulțime de baze de date diferite - putem începe să le conectăm pe toate împreună, astfel încât atunci când lucrez cu acesta într-un singur model I pot vedea unde sunt manifestările clienților din celelalte modele. Și pentru că avem un strat de model care îl reprezintă, putem chiar să-l legăm de sursele de date și să-l aducem la întrebările unde sunt utilizate și bazele de date. Ne oferă într-adevăr o capacitate de a lega toate acestea foarte coeziv.
V-am arătat obiectele de date de afaceri. De asemenea, vreau să vorbesc despre extensiile de metadate, pe care le numim atașamente, foarte repede. Ceea ce face este că ne oferă capacitatea de a crea metadate suplimentare pentru obiectele noastre de model. Destul de des, aș configura aceste tipuri de proprietăți pentru a conduce o mulțime de lucruri diferite dintr-o perspectivă de guvernare a datelor și a calității datelor și, de asemenea, pentru a ne ajuta cu gestionarea principală a datelor și politicile de păstrare a datelor. Ideea de bază este să creați aceste clasificări și să le puteți atașa oriunde doriți, la nivel de tabel, la nivel de coloană, acele tipuri de lucruri. Cel mai obișnuit caz de utilizare, desigur, este faptul că entitățile sunt tabele și atunci pot defini: care sunt obiectele mele de date principale, care sunt tabelele mele de referință, care sunt tabelele mele tranzacționale? Din perspectiva calității datelor, pot face clasificări în termeni de importanță pentru afaceri, astfel încât să putem acorda prioritate eforturilor de curățare a datelor și a acelui tip de lucru.
Ceea ce este adesea trecut cu vederea este, care este politica de păstrare a diferitelor tipuri de date din organizația noastră? Putem configura aceste elemente și le putem atașa de fapt la diferitele tipuri de artefacte informaționale din mediul nostru de modelare și, bineînțeles, și în depozitul nostru. Frumusețea este că aceste atașamente trăiesc în dicționarul nostru de date, astfel încât atunci când folosim dicționare de date despre întreprinderi din mediu, le putem atașa la mai multe modele. Trebuie doar să le definim o singură dată și le putem folosi din nou și din nou pe diferite modele din mediul nostru. Aceasta este doar o captură de ecran rapidă pentru a arăta că puteți specifica de fapt atunci când faceți un atașament, la care sunt toate piesele pe care doriți să le atașați. Și acest exemplu aici este de fapt o listă de valori, așa că atunci când intră puteți alege dintr-o listă de valori, aveți mult control în mediul de modelare a ceea ce este ales, și puteți chiar să setați ceea ce implicit valoarea este dacă nu se alege o valoare. Deci, multă putere acolo. Ei locuiesc în dicționarul de date.
Ceva ce vreau să vă arăt un pic mai jos pe acest ecran, în plus, vedeți atașamentele care apar în partea de sus, de sub el vedeți informații despre securitatea datelor. Putem aplica, de fapt, politici de securitate a datelor la diferitele informații din mediu. Pentru diferite mapări de conformitate, clasificări de securitate a datelor, le livrăm mai multe din caseta pe care o puteți genera și începe să le utilizați, dar puteți defini și mapări și standarde de conformitate. Indiferent dacă faci HIPAA sau oricare dintre celelalte inițiative de acolo. Și puteți începe cu adevărat să construiți acest set foarte bogat de metadate din mediul dvs.
Și apoi Glossarul și termenii - aici este legat sensul afacerii. Avem destul de des dicționare de date pe care destul de des o organizație le folosește ca punct de plecare pentru a începe să alunge glosare, dar terminologia și versiunea este adesea foarte tehnic. Așadar, ceea ce putem face este că, dacă dorim, le putem folosi ca punct de plecare pentru a aloca glosare, dar dorim cu adevărat ca întreprinderea să le dețină. Ceea ce am făcut în mediul serverului de echipă este că am dat posibilitatea oamenilor de a crea definiții de afaceri și apoi le putem conecta la diferite artefacte model la care corespund și în mediul de modelare. Recunoaștem, de asemenea, punctul despre care s-a discutat mai devreme care este, cu cât mai mulți oameni aveți tastarea, cu atât există mai mult potențial de eroare umană. Ceea ce facem și în structura noastră de glosar este, una, susținem o ierarhie a glosarului, deci putem avea diferite tipuri de glosar sau diferite tipuri de lucruri în organizație, dar la fel de important este dacă aveți deja unele dintre aceste surse Acolo, cu termenii și tot ce sunt definiți, putem efectua de fapt un import CSV pentru a-i atrage în mediul nostru de modelare și pe serverul echipei noastre sau la glosarul nostru, apoi să începem să facem legătura de acolo. Și de fiecare dată când se schimbă ceva, există o pistă de audit completă a ceea ce au fost imaginile înainte și după, în ceea ce privește definițiile și orice altceva, iar ceea ce veți vedea venind în viitorul apropiat este, de asemenea, mai mult un flux de lucru de autorizare. astfel încât să putem controla cu adevărat cine este responsabil de aceasta, aprobările comitetelor sau persoanelor fizice și acest tip de lucru, pentru a face procesul de guvernare și mai robust pe măsură ce mergem mai departe.
Ceea ce face acest lucru și pentru noi este când avem acești termeni în glosarul serverului de echipă, acesta este un exemplu de editare într-o entitate din modelul în sine pe care l-am adus aici. Este posibil să avem termeni legați, dar ceea ce facem noi este și dacă există cuvinte care sunt în acel glosar care apar în notele sau descrierile a ceea ce avem în entitățile noastre aici, aceștia sunt arătați automat într-o culoare hiperlegată mai ușoară și dacă mouse-ul peste ele, putem vedea de asemenea definiția din glosarul de afaceri. Ne oferă chiar informații mai bogate atunci când consumăm informațiile în sine, cu toți termenii glosarului care există. Chiar ajută la îmbogățirea experienței și la aplicarea sensului la tot ceea ce lucrăm.
Deci, din nou, acesta a fost un flyby foarte rapid. Evident, am putea petrece zile în acest sens în timp ce ne adâncim în diferite părți, dar acesta este un zbor foarte rapid pe suprafață. Ceea ce ne străduim cu adevărat să facem este să înțelegem cum arată acele medii complexe de date. Dorim să îmbunătățim vizibilitatea tuturor acestor artefacte de date și să colaborăm pentru a le aloca cu ER / Studio. Dorim să activăm modelarea mai eficientă și automatizată a datelor. Și acesta este tot tipul de date despre care vorbim, fie că este vorba despre date mari, date relaționale tradiționale, magazine de documente sau orice altceva. Și din nou, am realizat asta pentru că avem capacități puternice de inginerie înainte și invers pentru diferitele platforme și celelalte instrumente pe care le puteți avea acolo. Și este vorba despre împărtășirea și comunicarea între organizație cu toți factorii implicați. Acolo aplicăm sensul prin standardele de denumire. Apoi aplicăm definiții prin glosarele noastre de afaceri. Și apoi putem face clasificări suplimentare pentru toate celelalte capacități de guvernare cu extensiile de metadate, cum ar fi extensiile de calitate a datelor, clasificările pentru gestionarea datelor master sau orice alte tipuri de clasificări pe care doriți să le aplicați respectivelor date. Și apoi putem rezuma și îmbunătăți comunicarea cu atât mai mult cu obiectele de date de afaceri, cu diferitele audiențe ale părților interesate, în special între modelatori și dezvoltatori.
Și, din nou, ceea ce este foarte important în acest sens este, în spatele său, se află un depozit integrat, cu capacități foarte puternice de gestionare a schimbărilor. Nu am avut timp să-l arăt astăzi, deoarece devine destul de complex, dar depozitul are capacități foarte puternice de gestionare a schimbărilor și trasee de audit. Puteți face versiuni numite, puteți face versiuni numite și avem, de asemenea, capacitatea pentru aceia dintre voi care efectuează gestionarea modificărilor, putem lega acest drept în sarcinile dvs. Astăzi avem capacitatea de a pune sarcini și de a asocia modificările de model cu sarcinile, la fel cum dezvoltatorii ar asocia modificările de cod cu sarcinile sau poveștile utilizatorilor cu care lucrează.
Din nou, aceasta a fost o privire de ansamblu foarte rapidă. Sper că a fost suficient să vă stârniți pofta de mâncare, astfel încât să ne putem angaja în conversații mult mai profunde pentru a împărți unele dintre aceste subiecte pe măsură ce vom merge mai departe în viitor. Vă mulțumesc pentru timpul acordat și înapoi, Rebecca.
Rebecca Jozwiak: Mulțumesc, Ron, asta a fost fantastic și am destul de multe întrebări din partea publicului, dar vreau să le ofer analistilor noștri șansa de a-și scufunda dinții în ceea ce ai avut de spus. Eric, o să merg mai departe și poate dacă vrei să abordezi acest diapozitiv sau altul, de ce nu mergi mai întâi? Sau orice altă întrebare.
Eric Little: Sigur. Scuze, care a fost întrebarea, Rebecca? Vrei să întreb ceva anume sau …?
Rebecca Jozwiak: Știu că ai avut câteva întrebări inițial pentru Ron. Dacă vrei să-i ceri acum să se adreseze oricăruia, sau unora dintre ele de pe diapozitiv sau orice altceva care îți stârnește interesul despre care vrei să te întrebi? Despre funcționalitățile modelării IDERA.
Eric Little: Da, deci unul dintre lucrurile, Ron, deci cum, băieți, se pare că diagramele pe care le arătați sunt tipuri generale de diagrame de relații de entitate, așa cum le-ați folosi în mod normal în construcția bazei de date, corect?
Ron Huizenga: Da, în general, dar, desigur, avem tipurile extinse pentru magazinele de documente și acel tip de lucruri. De fapt, am variat de la doar o notație relațională pură, am adăugat, de asemenea, și notații suplimentare pentru alte magazine.
Eric Little: Există o modalitate prin care voi puteți utiliza tipuri de modelații bazate pe grafic, așa că există o modalitate de integrare, de exemplu, să presupunem că am ceva ca un cadran de top, un instrument de compozitor TopBraid sau am făcut ceva în Protégé sau, știți, ca băieții financiari din FIBO, lucrează foarte mult în semantică, chestii din RDF - există o modalitate de a introduce acel tip de model de grafic de relație entitate în acest instrument și de a utiliza aceasta?
Ron Huizenga: Ne uităm la modul în care putem gestiona graficele. Nu gestionăm în mod explicit bazele de date grafice și acel tip de lucruri astăzi, dar analizăm modalități prin care putem face asta pentru a ne extinde metadatele. Adică, putem aduce lucrurile prin XML și acel tip de lucruri în acest moment, dacă putem face cel puțin un fel de redare a XML pentru a le aduce ca punct de plecare. Dar ne uităm la modalități mai elegante de a aduce asta.
Și v-am arătat și acea listă de poduri de inginerie inversă pe care le avem acolo, de aceea ne uităm mereu la extinderea la aceste poduri și pentru platforme specifice. Este un efort continuu și continuu, dacă acest lucru are sens, să înceapă să îmbrățișeze o mulțime de aceste construcții noi și diferitele platforme de acolo. Dar pot spune că suntem cu siguranță în fruntea acestui lucru. Lucrurile pe care le-am arătat, de exemplu, pe MongoDB și pe acel tip de lucruri, suntem primul furnizor de modelare de date care face efectiv asta în propriul nostru produs.
Eric Little: Bine, da. Deci, cealaltă întrebare pe care am avut-o, atunci, a fost în ceea ce privește guvernanța și menținerea - ca atunci când ați folosit exemplul, când ați arătat exemplul persoanei care este „angajat”, cred că a fost „ salariu ”și apoi ai un„ plan ”, există o cale, cum reușești, de exemplu, diferite tipuri de oameni care ar putea avea - hai să presupunem că ai o arhitectură mare, nu, să presupunem că ai o întreprindere mare și oamenii încep să strângă lucrurile împreună cu acest instrument și ai aici un grup care are cuvântul „angajat” și un grup aici care are cuvântul „muncitor”. Și o persoană de aici spune „salariu” și o altă persoană spune "salariu."
Cum vă împăcați și gestionați și guvernați aceste tipuri de distincții? Pentru că știu cum am face-o în lumea grafică, știi, ai folosi liste de sinonime sau ai spune că există un concept și are mai multe atribute, sau ai putea spune că în modelul SKOS am o etichetă preferată și am numeroase etichete alternative pe care le pot folosi. Cum faci asta?
Ron Huizenga: O facem în câteva moduri diferite și, în primul rând, să vorbim mai întâi despre terminologie. Unul dintre lucrurile pe care le facem, desigur, este că dorim să avem termenii definiți sau sancționați, iar în glosarul de afaceri este, evident, locul în care le dorim. Și permitem link-uri către sinonime în glosarul de afaceri, deci ceea ce puteți face este să puteți spune, iată termenul meu, dar puteți defini, de asemenea, care sunt toate sinonimele pentru acestea.
Lucrul interesant, desigur, este când începi să cauți pe acest vast peisaj de date cu toate aceste sisteme diferite pe care le-ai obținut acolo, nu poți pur și simplu să ieși acolo și să schimbi tabelele corespunzătoare și acele tipuri de lucruri corespunde standardului de denumire, deoarece poate fi un pachet pe care l-ai cumpărat, deci nu ai controlul asupra modificării bazei de date sau a nimic deloc.
Ceea ce am putea face acolo, pe lângă faptul că putem asocia definițiile glosarului, este prin acele mapări universale despre care am vorbit, ceea ce am face și un fel de abordare recomandată, este să avem un model logic general, care să descrie ceea ce aceste concepte diferite de afaceri sunt despre care vorbești. Legați termenii glosarului de afaceri cu acei, iar lucrul frumos este acum că aveți acest construct care reprezintă o entitate logică așa cum a fost, puteți începe apoi să faceți legătura de la entitatea logică la toate implementările acelei entități logice din diferitele sisteme.
Apoi, unde trebuie să faceți asta, puteți vedea, oh, „persoana” aici se numește „angajat” în acest sistem. „Salariul” aici se numește „salariu” aici în acest alt sistem. Pentru că veți vedea asta, veți vedea toate manifestările diferite ale celor pentru că le-ați legat între ele.
Eric Little: Bine, bine, da. În acest sens, este sigur să spunem că sunt asemenea unor abordări orientate pe obiecte?
Ron Huizenga: Oarecum. Este ceva mai intensiv decât, cred că ai putea spune. Adică, ai putea să abordezi legătura și parcurgerea manuală și să le inspectezi și să le faci și pe toate. Singurul lucru despre care nu am avut nicio șansă să vorbesc - pentru că din nou, avem o mulțime de capacități - avem și o interfață completă de automatizare în instrumentul Data Architect. Și o capacitate macro, care este într-adevăr un limbaj de programare în instrument. Deci, putem face de fapt lucruri precum scrie macro-uri, să le ieșim și să interogăm lucrurile și să creăm linkuri pentru dvs. Îl utilizăm pentru importul și exportul de informații, îl putem folosi pentru schimbarea lucrurilor sau adăugarea de atribute, eveniment bazat în modelul în sine, sau îl putem folosi pentru a rula în loturi pentru a ieși și interoga lucruri și pentru a popula de fapt construcții diferite în model. Deci există o interfață completă de automatizare de care oamenii pot profita și ei. Iar utilizarea mapărilor universale cu acestea ar fi o modalitate foarte puternică de a face acest lucru.
Rebecca Jozwiak: Bine, mulțumesc Ron și mulțumesc Eric. Acestea au fost întrebări grozave. Știu că trecem puțin peste vârful orei, dar aș dori să-i dau lui Malcolm o șansă să arunce câteva întrebări în calea lui Ron. Malcolm?
Malcolm Chisholm: Mulțumesc, Rebecca. Deci, Ron, este foarte interesant, văd că aici sunt foarte multe capacități. Unul dintre domeniile care mă interesează foarte mult este să spunem dacă avem un proiect de dezvoltare, cum vedeți modelatorul de date utilizând aceste funcții și lucrează poate mai mult în colaborare cu analiștii de afaceri, cu un profilator de date, cu un analist al calității datelor și cu sponsorii de afaceri care vor fi în cele din urmă responsabili de cerințele reale de informații din proiect. Cum știi, într-adevăr, modelatorul de date, face proiectul mai eficient și mai eficient cu capacitățile pe care le analizăm?
Ron Huizenga: Cred că unul dintre primele lucruri pe care trebuie să le faci este ca modelator de date - și nu vreau să aleg pe unele dintre modele, dar oricum o voi face - este unii oameni care încă mai au impresia că modelatorul de date este de fapt rolul de tip gatekeeper, definim modul de funcționare, suntem paznicii care ne asigurăm că totul este corect.
Acum există un aspect al acestui lucru, că trebuie să vă asigurați că definiți o arhitectură de date sonore și orice altceva. Dar cel mai important lucru este ca modelator de date - și am constatat acest lucru destul de evident când am fost consultant - este necesar să deveniți un facilitator, așa că trebuie să îi strângeți pe acești oameni.
Nu va mai fi un design în față, nu va mai genera, construi baze de date - ceea ce trebuie să poți face este să fii capabil să lucrezi cu toate aceste diferite grupuri de părți interesate, făcând lucruri precum inginerie inversă, importul de informații în alte persoane colaborează, fie că este vorba despre glosare sau documentație, tot așa - și să fie un facilitator pentru a trage acest lucru în depozit și pentru a lega conceptele împreună în depozit și pentru a lucra cu acele persoane.
Este într-adevăr mult mai mult un tip de mediu colaborativ în care chiar și prin definirea sarcinilor sau chiar fire de discuție sau acel tip de lucru pe care îl avem în serverul de echipă, oamenii pot colabora de fapt, să pună întrebări și să ajungă la produsele finale finale pe care le nevoie de arhitectura de date și de organizarea lor. A răspuns un fel?
Malcolm Chisholm: Da, sunt de acord. Știți, cred că abilitatea de facilitare este ceva foarte de dorit pentru modelatorii de date. Sunt de acord că nu vedem întotdeauna acest lucru, dar cred că este necesar și aș sugera că există uneori înclinația de a rămâne în colțul tău în realizarea modelării datelor tale, dar chiar trebuie să fii acolo pentru a lucra cu celelalte grupuri de părți interesate. sau pur și simplu nu înțelegeți mediul de date cu care vă confruntați și cred că modelul suferă ca urmare. Dar aceasta este doar părerea mea.
Ron Huizenga: Și este interesant pentru că ai menționat ceva mai devreme în diapozitivul tău despre istoria despre cum întreprinderile sunt cam respinse de IT, pentru că nu furnizau soluțiile în timp util și acele tipuri de lucruri.
Este foarte interesant faptul că, în misiunile mele de consultanță ulterioară, înainte de a deveni manager de produse, majoritatea proiectelor pe care le-am făcut în ultimii doi ani înainte de asta au fost sponsorizate de afaceri, unde a fost cu adevărat afacerea care a condus-o și arhitecții de date. iar modelatorii nu făceau parte din IT. Am făcut parte dintr-un grup sponsorizat de afaceri și am fost acolo ca facilitatori care lucrează cu restul echipelor de proiect.
Malcolm Chisholm: Deci cred că acesta este un punct foarte interesant. Cred că începem să vedem o schimbare în lumea afacerilor în care afacerea întreabă sau poate ne gândim, nu atât la ce fac eu, cât sunt în proces, dar încep să se gândească și la ce sunt datele cu care lucrez, care sunt nevoile mele de date, care sunt datele cu care mă ocup ca date și în ce măsură putem obține produse și capacități IDERA pentru a susține acel punct de vedere și cred că nevoile afacerii, chiar deși este cam un pic încă născut.
Ron Huizenga: Sunt de acord cu tine și cred că vedem că merge din ce în ce mai mult în acest fel. Am văzut o trezire și ai atins-o mai devreme în ceea ce privește importanța datelor. Am văzut importanța datelor timpuriu în IT sau în evoluția bazelor de date, apoi, după cum spuneți, am intrat într-un întreg ciclu de gestionare a proceselor - iar procesul este extrem de important, nu mă înșelați acolo, dar acum s-a întâmplat este atunci când s-a întâmplat asta, un fel de date de focalizare pierdută.
Iar acum organizațiile își dau seama că datele sunt cu adevărat punctul central. Datele reprezintă tot ceea ce facem în afacerea noastră, așa că trebuie să ne asigurăm că avem date exacte, că putem găsi informațiile corecte de care avem nevoie pentru a lua deciziile noastre. Pentru că nu totul provine dintr-un proces definit. Unele dintre informații sunt un produs secundar al altor lucruri și trebuie să putem totuși să le găsim, să știm ce înseamnă și să putem traduce datele pe care le vedem acolo în cele din urmă în cunoștințe pe care le putem folosi pentru a ne conduce mai bine afacerile.
Malcolm Chisholm: Bine, iar acum un alt domeniu cu care m-am confruntat este ceea ce aș numi ciclul de viață a datelor, care este, știi, dacă ne uităm la tipul de lanț de furnizare de date care trece printr-o întreprindere, am începe achiziția de date sau captarea de date, care ar putea fi introducerea de date, dar ar putea fi în egală măsură, primesc date din afara întreprinderii de la un furnizor de date.
Și apoi de la captarea datelor mergem la întreținerea datelor unde mă gândesc să standardizez aceste date și să le trimit în jurul locurilor unde este nevoie. Și apoi utilizarea datelor, punctele reale în care se află datele, veți obține valoare din date.
Și pe vremuri, toate acestea se fac într-un stil individual, dar astăzi ar putea fi, știți, un mediu de analiză, de exemplu, și apoi dincolo de asta, o arhivă, un magazin, unde punem datele când nu mai avem nevoie de el și în final un proces de purjare. Cum vedeți că modelarea datelor se încadrează în gestionarea întregului ciclu de viață a datelor?
Ron Huizenga: Aceasta este o întrebare foarte bună și un lucru despre care nu am avut deloc timp să descopăr în niciun detaliu aici, azi, este despre care începem să vorbim despre linie de date. Deci, ceea ce suntem capabili să facem este să avem o capacitate de linie de date în instrumentele noastre și, așa cum spun eu, putem extrage o parte din ea din instrumentele ETL, dar puteți să o mapați doar desenând linia. Oricare dintre aceste modele de date sau baze de date pe care le-am capturat și adus în modele am putea face referire la construcțiile din cel din diagrama noastră de date.
Ceea ce putem face este să tragem un flux de date, cum spuneți voi, de la sursă la țintă și, prin ciclul general de viață a tranzitării datelor prin diferitele sisteme și ceea ce veți găsi este, să luăm angajați 'date - este unul dintre preferatele mele bazat pe un proiect pe care l-am făcut acum ani în urmă. Am lucrat cu o organizație care avea date despre angajați în 30 de sisteme diferite. Ce am ajuns să facem acolo - și Rebecca a apărut diapozitivul de linie de date - acesta este un diapozitiv de linie de date destul de simplist aici, dar ceea ce am putut să facem a fost să aducem toate structurile de date, să le trimitem în diagrama și apoi noi Poate începe să analizeze care sunt fluxurile între ele și cum sunt legate aceste entități diferite de date într-un flux? Și putem merge și dincolo de asta. Aceasta face parte dintr-un flux de date sau diagrama de linie pe care o vedem aici. Dacă doriți să depășiți asta, avem și arhitectul de business din această suită și același lucru se aplică și acolo.
Oricare dintre structurile de date pe care le-am capturat în mediul de modelare a datelor, acestea pot fi menționate în instrumentul de modelare a afacerii, astfel încât, chiar și în diagramele modelului de afaceri sau în diagramele procesului de afaceri, puteți face referire la magazinele de date individuale dacă doriți să ieșiți din mediul de modelare a datelor și, în timp ce le utilizați în folderele din modelul procesului dvs. de afaceri, puteți chiar să specificați CRUD pe acestea, în ceea ce privește modul în care aceste informații sunt fie consumate sau produse, apoi putem începe să genereze lucruri precum rapoarte de impact și analiză și diagrame din asta.
La care ne propunem să ajungem și avem deja o mulțime de capacități, dar unul dintre lucrurile la care avem un fel de obiectiv pe care îl privim, pe măsură ce continuăm să ne dezvoltăm instrumentele care merg înainte. este capabil să identifice acea linie de date organizatorică de la capăt la sfârșit și întregul ciclu de viață al datelor.
Malcolm Chisholm: Bine. Rebecca, îmi mai este permis?
Rebecca Jozwiak: Îți voi mai permite încă una, Malcolm, mergi mai departe.
Malcolm Chisholm: Mulțumesc mult. Gândindu-ne la guvernarea datelor și gândindu-ne la modelarea datelor, cum facem ca aceste două grupuri să lucreze eficient împreună și să se înțeleagă reciproc?
Eric Little: Păi este interesant, cred că depinde într-adevăr de organizație și se întoarce la conceptul meu anterior, în acele organizații în care inițiativele au fost conduse de afaceri, eram legați chiar. De exemplu, conduceam o arhitectură de date echipa, dar am fost corelați cu utilizatorii companiei și i-am ajutat de fapt să își susțină programul de guvernare a datelor. Din nou, mai mult o abordare consultativă, dar este mai degrabă o funcție de afaceri.
Ceea ce trebuie să fiți capabil să faceți asta este să aveți nevoie de modelatori și arhitecți de date care să înțeleagă cu adevărat afacerile, să poată lega de utilizatorii afacerii și apoi i-au ajutat să susțină procesele de guvernare din jurul acesteia. Afacerea vrea să o facă, dar, în general, avem cunoștințe tehnologice pentru a le putea ajuta să iasă în evidență aceste tipuri de programe. Chiar trebuie să fie o colaborare, dar trebuie să fie proprietatea afacerilor.
Malcolm Chisholm: Bine, este minunat. Mulțumesc.
Dr. Eric Little: Bine.
Rebecca Jozwiak: Bine, multumesc mult. Membrii audienței, mă tem că nu am ajuns la întrebările voastre, dar mă voi asigura că vor fi transmise invitatului corespunzător pe care l-am avut astăzi pe linie. Vreau să vă mulțumesc foarte mult lui Eric, Malcolm și Ron pentru că sunt astăzi oaspeții noștri. Asta a fost chestii grozave, oameni buni. Și dacă v-ați bucurat de transmisia web IDERA de astăzi, IDERA va fi, de asemenea, într-un Hot Technologies miercuri viitoare, dacă doriți să vă alăturați, discutând despre provocările indexării și Oracles, deci un alt subiect fascinant.
Mulțumesc mult, oameni buni, aveți grijă și ne vom revedea data viitoare. Pa! Pa.
