Autorius „Techopedia“ darbuotojai, 2016 m. Rugsėjo 28 d
Priėmimas: Priimančioji Rebecca Jozwiak aptaria duomenų architektūros sprendimus su Ericu Little'u iš OSTHUS, Malcolmu Chisholmu iš pirmojo San Francisko partnerių ir Ronu Huizenga iš IDERA.
Šiuo metu nesate prisijungęs. Jei norite pamatyti vaizdo įrašą, prisijunkite arba prisiregistruokite.
Rebecca Jozwiak: Ponios ir ponai, sveiki ir sveiki atvykę į 2016 m. Karštas technologijas. Šiandien mes diskutuojame apie „Verslo pagrįstos duomenų architektūros kūrimą“, be abejo, karštą temą. Mano vardas Rebecca Jozwiak, aš būsiu jūsų šios dienos internetinės transliacijos šeimininkas. Mes čiulbame su # HotTech16, kuriame jau esate „Twitter“, taigi, jei jau esate „Twitter“, maloniai prašome prisijungti ir prie to. Jei bet kada turite klausimų, atsiųskite juos į klausimų ir atsakymų sritį ekrano apačioje, dešinėje, ir mes įsitikinsime, kad į juos bus atsakyta. Jei ne, mes pasirūpinsime, kad svečiai gautų juos už jus.
Taigi šiandien turime tikrai žavią sudėtį. Šiandien mūsų laukia daug sunkių įvykių. Mes turime Ericą Little, VPD duomenų mokslą iš OSTHUS. Mes turime „Malcolm Chisholm“, vyriausiąjį inovacijų vadybininką, kuris „First San Francisco Partners“ vardu yra tikrai šaunus titulas. Mes turime Roną Huizengą, vyresnįjį IDERA produktų vadybininką. Ir jūs žinote, kad IDERA yra tikrai visas duomenų valdymo ir modeliavimo sprendimų rinkinys. Šiandien jis pateiks mums demonstracinę versiją apie tai, kaip veikia jo sprendimas. Bet prieš mums pasiekiant, Ericai Mažai, aš perduosiu jums kamuolį.
Erikas Mažasis: Gerai, labai ačiū. Taigi pereisiu keletą temų, kurios, manau, šiek tiek siejasi su Rono pokalbiu ir, tikiuosi, taip pat nustatys pagrindą kai kurioms iš šių temų, kai kurioms klausimų ir atsakymų temoms.
Taigi dalykas, kuris mane domino, ką veikia IDERA, yra tai, kad, manau, jie teisingai pabrėžia, kad šiais laikais sudėtinga aplinka iš tiesų skatina daug verslo vertybių. O sudėtingomis aplinkomis turime omenyje sudėtingas duomenų aplinkas. O technologijos iš tiesų greitai juda ir sunku neatsilikti nuo šiandienos verslo aplinkos. Taigi tie žmonės, kurie dirba technologinėse erdvėse, dažnai pamatys, kad turite klientų, kurie susiduria su problemomis: „Kaip naudoti didelius duomenis? Kaip įtraukti semantiką? Kaip susieti kai kuriuos šiuos naujus dalykus su senesniais duomenimis? “Ir pan., Ir toks būdas šiais laikais mus veda į šiuos keturis didelius duomenis, kuriuos daugelis žmonių yra gana gerai susipažinę ir suprantu, kad jų gali būti daugiau nei keturi. kartais - aš mačiau net aštuonis ar devynis - bet paprastai, kai žmonės kalba apie tokius dalykus kaip dideli duomenys arba jei jūs kalbate apie didelius duomenis, paprastai jūs žiūrite į tai, kas yra tokio masto įmonė. Taigi žmonės sakys: gerai, gerai, pagalvok apie tavo duomenų apimtį, kuriai paprastai skiriamas didžiausias dėmesys - būtent tiek ir turi. Duomenų sparta priklauso nuo to, ar greitai galiu juos perkelti, ar kaip greitai galiu jų užklausti, ar gauti atsakymus, ir taip toliau. Aš asmeniškai manau, kad kairiajame šone yra kažkas, kas gana greitai išspręsta ir išspręsta daugybe skirtingų požiūrių. Dešinėje pusėje aš matau daug tobulėjimo galimybių ir daug naujų technologijų, kurios iš tikrųjų ateina į priešakį. Ir tai iš tikrųjų yra susiję su trečiuoju stulpeliu, duomenų įvairove.
Kitaip tariant, dauguma bendrovių šiais laikais žiūri į struktūruotus, pusiau struktūruotus ir nestruktūrizuotus duomenis. Vaizdo duomenys pradeda tapti aktualia tema, todėl, naudodamiesi kompiuteriniu matymu, žvelgdami į taškus, mokėdami subraižyti tekstą, NLP, subjekto ištraukimą, turite grafiko informaciją, gaunamą iš statistinių modelių arba išeinančią iš semantikos. modelius, turite reliacinius duomenis, kurie egzistuoja lentelėse ir pan. Taigi sujungus visus šiuos duomenis ir visus šiuos skirtingus tipus iš tiesų kyla didelis iššūkis, ir jūs pamatysite tai, kaip jūs žinote, „Gartner“ ir kituose žmonėse, kurie tarsi seka pramonės tendencijas.
Ir tada galutinis dalykas, apie kurį žmonės kalba dideliais duomenimis, dažnai yra ši klaidingumo samprata, kuri iš tikrųjų yra jūsų duomenų netikrumas, jų neryškumas. Kaip gerai tu žinai, kokie yra tavo duomenys, kaip gerai supranti, kas ten yra, ir žinai? Čia gali būti naudinga galimybė naudoti statistiką ir galimybė naudoti tam tikros rūšies informaciją apie tai, ką galbūt žinote, arba naudoti tam tikrą kontekstą. Taigi galimybė tokiu būdu pažvelgti į duomenis atsižvelgiant į tai, kiek turite, kiek greitai turite juos perkelti ar gauti, visų tipų duomenys, kuriuos galite turėti savo įmonėje, ir kaip esate tikri, kur esate. tai yra, kas tai yra, kokia jo kokybė ir pan. Tai iš tikrųjų reikalauja didelių, suderintų pastangų, kurias dabar turi atlikti daugybė asmenų, kad efektyviai valdytų savo duomenis. Todėl šiuolaikiniame pasaulyje duomenų modeliavimas tampa vis svarbesnis. Taigi geri duomenų modeliai iš tiesų lemia didelę sėkmę įmonių programose.
Jūs turite duomenų šaltinių iš įvairių šaltinių, kaip mes sakėme, kuriems iš tikrųjų reikia daug įvairių integracijų. Taigi sutelkti viską kartu yra labai naudinga, jei reikia užklausų, pavyzdžiui, naudojant daugybę duomenų šaltinių, ir atkurti informaciją. Bet norint tai padaryti, jums reikia gerų žemėlapių sudarymo strategijų, taigi, surinkti tokio tipo duomenis ir neatsilikti nuo šių žemėlapių gali būti tikras iššūkis. Tada turite šį klausimą, kaip aš galiu susieti savo senus duomenis su visais šiais naujais duomenų šaltiniais? Taigi tarkime, kad aš turiu grafiką, ar aš paimu visus savo reliacinius duomenis ir sudedu juos į schemą? Paprastai tai nėra gera idėja. Taigi, kaip tai yra tai, kad žmonės sugeba valdyti visus šiuos duomenų modelius, kurie vyksta? Iš tikrųjų analizė turi būti atliekama daugelio šių rūšių duomenų šaltiniuose ir deriniuose. Taigi iš to išplaukiantys atsakymai, atsakymai, kurie žmonėms reikalingi norint iš tikrųjų priimti gerus verslo sprendimus, yra kritiniai.
Taigi tai nėra susiję tik su statybų technologijomis vardan technologijos, tai tikrai yra tai, ką aš darysiu, ką su ja galiu padaryti, kokią analizę galiu atlikti, ir galimybes, todėl, kaip jau esu šnekėti apie tai, integruoti tai labai svarbu. Ir tada viena iš šių analizės rūšių vykdoma tokiais dalykais kaip bendra paieška ir užklausos. Tai iš tikrųjų tampa būtina. Paprastai jūsų užklausos turi būti pateikiamos naudojant įvairius šaltinius, kad informacija būtų patikima.
Vienas esminis elementas, kuris dažnai, ypač žmonės, žvelgia į svarbiausius dalykus, tokius kaip semantinės technologijos - ir tai, tikiuosi, Ronas apie IDERA metodą šiek tiek papasakos, yra tai, kaip atskirti ar valdyti pavyzdinis jūsų duomenų sluoksnis iš paties duomenų sluoksnio, iš tų neapdorotų duomenų? Taigi, duomenų sluoksnyje, galbūt, turite duomenų bazes, dokumentų dokumentus, skaičiuoklės duomenis, vaizdų duomenis. Jei esate tokiose srityse kaip farmacijos pramonė, turite daugybę mokslinių duomenų. Be to, žmonės paprastai ieško būdo sukurti modelį, kuris leistų greitai integruoti tuos duomenis, o kai dabar ieškote duomenų, jūs nenorite visų duomenų surinkti į modelio sluoksnį., ką jūs žiūrite į modelio lygmenį, kurį turite padaryti, yra suteikti jums gražų loginį vaizdinį apie tai, kas yra daiktai, bendrą žodyną, įprastus esybių tipus ir ryšius bei galimybę iš tikrųjų pasiekti duomenis ten, kur yra. Taigi ji turi pasakyti, kas tai yra, ir pasakyti, kur ji yra, ir ji turi pasakyti, kaip ją sugrąžinti ir sugrąžinti.
Taigi tai buvo gana sėkmingas požiūris, verčiantis semantines technologijas judėti į priekį - šioje srityje daug dirbu. Taigi klausimas, kurį norėjau pateikti Roniui ir kuris, manau, bus naudingas klausimų ir atsakymų skyriuje, yra sužinoti, kaip tai įgyvendina IDERA platforma? Taigi ar modelio sluoksnis yra atskirai nuo duomenų sluoksnio? Ar jie labiau integruoti? Kaip tai veikia ir kokius rezultatus ir naudą jie mato iš savo požiūrio? Todėl pamatiniai duomenys iš tikrųjų tampa ir kritiški. Taigi, jei turėsite tokio tipo duomenų modelius, jei turėsite galimybę susiformuoti ir ieškoti įvairių dalykų, tikrai turite turėti gerus referencinius duomenis. Tačiau problema yra tai, kad pamatiniai duomenys gali būti sunkiai prižiūrimi. Taigi dažnai įvardyti standartus savaime yra sudėtingas iššūkis. Viena grupė vadinsis kažkuo X, o kita - kažkuo Y, o dabar kyla problema, kaip kažkas suranda X ir Y, kai ieško tokio tipo informacijos? Kadangi nenorite jiems duoti tik dalies duomenų, norite jiems suteikti viską, kas susiję. Kartu keičiasi terminai, programinė įranga netenka galios ir pan., Kaip laikui bėgant išlaikyti ir prižiūrėti šiuos pamatinius duomenis?
Ir vėlgi, semantinės technologijos, konkrečiai naudojančios tokius dalykus kaip taksonomijos ir žodynai, duomenų žodynai, suteikė standartinį erdvės atlikimo būdą, kuris iš tiesų yra labai tvirtas, jame naudojami tam tikri standartai, tačiau duomenų bazių bendruomenė tai padarė taip pat ilgą laiką, tik skirtingais būdais. Aš manau, kad vienas iš raktų čia yra galvoti apie tai, kaip panaudoti galbūt subjektų-santykių modelius, kaip naudoti galbūt grafinius modelius ar tam tikrą požiūrio tipą, kuris tikrai suteiks jums standartiniu būdu išdėstytą atskaitos duomenų tvarkymo būdą. Ir tada, žinoma, kai tik turite referencinius duomenis, žemėlapių sudarymo strategijos turi valdyti daugybę vardų ir subjektų. Taigi dalykų ekspertai dažnai mėgsta vartoti savo terminus.
Taigi iššūkis visada yra toks: kaip jūs kam nors pateikiate informaciją, bet ją pritaikote tam, kad jie apie tai kalbėtų? Taigi vienai grupei gali būti vienas būdas ką nors pažvelgti, pavyzdžiui, jūs galite būti chemikas, dirbantis dėl narkotikų, taip pat galite būti struktūrinis biologas, dirbantis su tuo pačiu narkotiku, o tos pačios rūšies subjektams gali būti skirtingi pavadinimai. kurie yra susiję su jūsų sritimi. Turite išsiaiškinti, kaip suderinti tuos suasmenintus terminus, nes kitas požiūris yra tas, kad jūs turite priversti žmones atsisakyti termino ir naudoti kažkieno terminą, kuris jiems dažnai nepatinka. Kitas dalykas - sudėtinga tvarkyti daugybę sinonimų, todėl daugelio žmonių duomenyse yra daug skirtingų žodžių, galinčių reikšti tą patį dalyką. Turite nuorodų problemą, naudodamiesi „vienas su kitu“ ryšių rinkiniu. Specializuoti terminai įvairiose pramonės šakose skiriasi, taigi, jei jūs sugalvosite tokio tipo duomenų valdymo visapusišką sprendimą, kaip lengvai jį perkelti iš vieno projekto ar iš vienos programos į kitą? Tai gali būti dar vienas iššūkis.
Automatizavimas yra svarbus ir tai taip pat iššūkis. Rankiniu būdu tvarkyti referencinius duomenis yra brangu. Brangu turėti rankinį žemėlapių sudarymą, o brangu, jei dalyko ekspertai nustos daryti savo kasdienius darbus ir turi eiti ir nuolat taisyti duomenų žodynus bei atnaujinti apibrėžimus ir pan., Ir taip toliau. Pakartotiniai žodynai išties rodo didelę vertę. Taigi tai dažnai būna jūsų organizacijos žodynai. Pavyzdžiui, jei dirbate su žalia nafta, bus tam tikrų rūšių žodynų, kuriuos galite pasiskolinti iš atvirojo kodo erdvių, tas pats su vaistais, tas pats su bankininkyste ir su finansiniais, tas pats su daugybe tokių sričių. Žmonės ten pateikia daugkartinius, bendrinius, pakartojamus žodynus, kad žmonės galėtų juos naudoti.
Ir vėl, žiūrint į IDERA įrankį, man įdomu sužinoti, kaip jie su tuo elgiasi, kalbėdami apie įvairius standartus. Semantikos pasaulyje dažnai matote tokius dalykus kaip SKOS modeliai, kurie numato bent jau platesnių nei / siauresnių nei santykiai standartus, ir tuos dalykus gali būti sunku padaryti ER modeliuose, bet, žinote, tai nėra neįmanoma, tiesiog priklauso nuo to, kiek to mechanizmai ir tas sujungimas, kurį galite valdyti tokio tipo sistemose.
Taigi galiausiai norėjau palyginti tam tikrus semantinius variklius, kuriuos matau pramonėje, ir paprašyti Roną truputį pakviesti jį pakalbėti apie tai, kaip IDERA sistema buvo naudojama kartu su bet kuriomis semantinėmis technologijomis. Ar ją galima integruoti į trigubas parduotuves, grafikų duomenų bazes? Kaip lengva naudoti išorinius šaltinius, nes tokius dalykus semantiniame pasaulyje dažnai galima pasiskolinti naudojant SPARQL galinius taškus? Galite importuoti RDF arba OWL modelius tiesiai į savo modelį - atsiųskite juos atgal - taigi, pavyzdžiui, genų ontologija arba baltymų ontologija, kurie gali gyventi kažkur savo erdvėje su savo valdymo struktūra ir aš galiu tiesiog importuoti visus arba dalį to, kaip man reikia, į savo modelius. Man įdomu sužinoti, kaip IDERA kreipiasi į šią problemą. Ar turite viską prižiūrėti iš vidaus, ar yra būdų, kaip naudoti kitokius standartizuotus modelius ir juos pritraukti, ir kaip tai veikia? Ir paskutinis dalykas, kurį čia paminėjau, yra tas, kiek iš tikrųjų reikia rankų darbo kuriant žodynėlius ir metaduomenų saugyklas?
Taigi aš žinau, kad Ronas parodys mums keletą tokių dalykų, kurie bus tikrai įdomūs. Tačiau problemų, kurias dažnai matau konsultuodamasi su klientais, problema yra ta, kad žmonės rašo savo apibrėžimus ar savo metaduomenis. Taigi, jūs gaunate klaidų, klaidų ir pirštų klaidų - tai vienas dalykas. Jūs taip pat priimate žmones, kurie gali ką nors paimti iš, jums žinomos, Vikipedijos ar šaltinio, kuris nebūtinai yra tokios kokybės, kokio jums gali prireikti apibrėžime, arba jūsų apibrėžimas pateiktas tik iš vieno asmens perspektyvos, todėl jis nėra išsamus ir tada nėra aiškus. kaip veikia valdymo procesas. Valdymas, be abejo, yra labai, labai svarbi problema, kai jūs kalbate apie informacinius duomenis ir bet kada, kai kalbate apie tai, kaip tai gali tilpti į kažkieno pagrindinius duomenis, kaip jie naudos savo metaduomenis ir t.
Taigi aš tiesiog norėjau pateikti kai kurias iš šių temų. Tai daiktai, kuriuos matau verslo erdvėje daugybe įvairių rūšių konsultavimo darbų ir daugybėje skirtingų sričių, ir man tikrai įdomu sužinoti, ką Ronas parodys mums su IDERA, norėdamas atkreipti dėmesį į kai kurias iš šių temų. . Taigi labai ačiū.
Rebecca Jozwiak: Labai ačiū, Ericai, ir man labai patinka jūsų komentaras, kad daug klaidų gali atsirasti, jei žmonės rašo savo apibrėžimus ar metaduomenis. Žinau, kad žurnalistikos pasaulyje egzistuoja mantra, kad „daugelis akių padaro nedaug klaidų“, tačiau kai reikia praktinių pritaikymų, per daug rankų į sausainių indelį paprastai palieka jums daug sudužusių sausainių, tiesa?
Erikas Mažasis: Taip, ir mikrobai.
Rebecca Jozwiak: Taip. Su tuo aš eisiu toliau ir perduosiu Malcolm Chisholm. Malcolm, jūsų grindys yra jūsų.
Malcolmas Chisholmas: Labai ačiū, Rebecca. Norėčiau šiek tiek pažvelgti į tai, apie ką Erikas kalbėjo, ir pridėti keletą pastabų, į kurias, žinote, Roniui taip pat gali reikėti reaguoti, kalbant apie „Verslo pagrįstų duomenų architektūros link“ “- ką reiškia būti verslu skatinamam ir kodėl tai svarbu? Ar tai yra tik tam tikra hipe forma? Nemanau, kad taip yra.
Jei pažvelgsime į tai, kas vyksta nuo tada, žinote, pagrindiniai kompiuteriai įmonėms iš tikrųjų tapo prieinami - tarkime, maždaug 1964 m. - iki šių dienų, matome, kad įvyko daug pokyčių. Šiuos pokyčius apibendrinčiau kaip perėjimą nuo į procesą orientuoto į duomenų centrą. Štai kodėl verslu grindžiamos duomenų architektūros yra tokios svarbios ir tokios aktualios šiandien. Ir aš manau, kad, jūs žinote, tai nėra vien tik žodis, tai yra visiškai tikras dalykas.
Bet mes galime tai įvertinti šiek tiek labiau, jei pasineriame į istoriją, taigi, grįždami į laiką, atgal į 1960-uosius ir dar kurį laiką po to, dominavo didieji kompiuteriai. Tuomet jie užleido vietą kompiuteriams, kuriuose iš tikrųjų sukilote prieš vartotojus, kai jie atsirado. Maištas prieš centralizuotą IT, kurie, jų manymu, neatitiko jų poreikių, nebuvo pakankamai judrūs. Tai greitai sukėlė paskirstytą kompiuterį, kai kompiuteriai buvo sujungti. Ir tada pradėjo atsirasti internetas, kuris užtemdė įmonės ribas - ji dabar galėjo bendrauti su šalimis, nepriklausančiomis sau, keisdamosi duomenimis, kokių dar nebuvo anksčiau. Dabar mes perėjome į debesų ir didžiųjų duomenų erą, kai debesis yra platformos, kurios iš tikrųjų paverčia infrastruktūrą, ir todėl mes tarsi paliekame IT poreikį valdyti didelius duomenų centrus, nes, žinote, mes „Debesies talpa buvo mums prieinama ir kartu su dideliais duomenimis, kuriuos Erikas, žinote, taip iškalbingai aptarė. Ir apskritai, kaip matome, pasikeitus technologijai, ji tapo labiau orientuota į duomenis, mums labiau rūpėjo duomenys. Kaip ir internetu keičiamasi duomenimis. Turint didelius duomenis, keturi ar daugiau duomenų yra patys.
Tuo pačiu metu, o galbūt dar svarbiau, verslo naudojimo atvejai pasikeitė. Kai pirmą kartą buvo pristatyti kompiuteriai, jie buvo naudojami automatizuoti tokius dalykus kaip knygos ir įrašai. Ir viskas, kas buvo rankinis procesas, apimanti pagrindinius žurnalus ar panašius dalykus, iš esmės buvo užprogramuota namuose. Dešimtajame dešimtmetyje tai pasikeitė dėl galimybės įsigyti operacinių paketų. Jums nebereikėjo rašyti savo darbo užmokesčio fondo, galėjote nusipirkti tai, kas tai padarė. Dėl to tuo metu daugelyje IT departamentų buvo sumažinta sumažinimas arba pertvarkymas. Bet tada atsirado verslo žvalgyba, tokia kaip duomenų saugyklos, dažniausiai 90-aisiais. Vėliau sekė „dotcom“ verslo modeliai, kurie, be abejo, buvo didelis nuojauta. Tada MDM. Su MDM jūs pamatysite, kad mes galvojame ne apie automatizavimą; mes tiesiog koncentruojamės į duomenų, kaip duomenų, kaupimą. Tada analizė, atspindinti vertę, kurią galite pašalinti iš duomenų. Analitikoje matote labai sėkmingas kompanijas, kurių pagrindinis verslo modelis pagrįstas duomenimis. „Google“, „Twitter“, „Facebook“ būtų to dalis, tačiau taip pat galite tvirtinti, kad „Walmart“ yra.
Taigi verslas dabar iš tikrųjų galvoja apie duomenis. Kaip mes galime gauti naudos iš duomenų? Kaip duomenys gali paskatinti verslą, strategiją ir mes esame auksiniame duomenų amžiuje. Taigi, atsižvelgiant į tai, kas vyksta mūsų duomenų architektūros atžvilgiu, jei duomenys nebelaikomi tiesiog išeikvojimu, kuris kyla iš užpakalinių programų pabaigos, bet yra tikrai svarbūs mūsų verslo modeliams? Na, dalis problemos, kurią turime pasiekti IT, iš tiesų yra įstrigę sistemų kūrimo gyvavimo cikle, kuris atsirado dėl to, kad ankstyvajame IT amžiuje reikėjo greitai susidoroti su tuo proceso automatizavimo etapu ir dirbti projektai yra panašus dalykas. IT - ir tai yra šiek tiek karikatūra - bet aš bandau pasakyti, kad kai kurios kliūtys gauti verslu pagrįstą duomenų architektūrą kyla todėl, kad mes, kažkodėl, nekritiškai priėmėme IT kultūrą. kuris kyla iš praėjusio amžiaus.
Taigi viskas yra projektas. Išsamiai papasakokite apie savo reikalavimus. Jei viskas neveikia, tai yra todėl, kad jūs man neišsakėte savo reikalavimų. Na, tai šiandien neveikia su duomenimis, nes mes nepradime neautomatizuotų rankinių procesų ar, žinoma, techninio verslo procesų konvertavimo, labai dažnai pradedame nuo jau esamų gamybos duomenų, kuriuos bandome. išgauti vertę iš. Bet niekas, kuris remia į duomenis orientuotą projektą, iš tikrųjų nesupranta tų duomenų. Turime atlikti duomenų atradimą, šaltinių duomenų analizę. Ir tai tikrai nesutampa su sistemų plėtra, jūs žinote - krioklys, SDLC gyvavimo ciklas - kurios, aš tvirtinu, „Agile“ yra savotiška geresnė to versija.
Daugiausia dėmesio skiriama technologijoms ir funkcionalumui, o ne duomenims. Pvz., Kai mes bandome bandymo etape, tai paprastai bus, ar mano funkcija veikia, tarkime, mano ETL, bet mes netikriname duomenų. Mes netikriname savo prielaidų dėl gaunamų šaltinių duomenų. Jei tai padarytume, būtume galbūt geresnės formos ir būčiau tai įvertinęs kaip asmuo, kuris yra įgyvendinęs duomenų saugyklos projektus ir nukentėjęs dėl ankstesnių pokyčių, apgadinęs mano ETL. Ir iš tikrųjų tai, ką mes norime pamatyti, yra bandymas, kaip išankstinis žingsnis į nuolatinę gamybos duomenų kokybės stebėseną. Taigi mes turime daug požiūrių, kai sunku pasiekti verslu pagrįstą duomenų architektūrą, nes mus sąlygoja į procesą orientuota era. Turime pereiti prie duomenų orientavimo. Tai nėra bendras perėjimas, jūs žinote, dar reikia atlikti daug proceso darbų, tačiau mes tikrai negalvojame į duomenis orientuotą terminą, kai to reikia, ir apie aplinkybes, kurios atsiranda, kai mes iš tikrųjų esame įpareigotas tai padaryti.
Dabar verslas supranta duomenų vertę, nori juos atrakinti, tad kaip mes tai padarysime? Taigi, kaip mes padarysime perėjimą? Na, mes pateikiame duomenis vystymosi procesų šerdyje. Ir mes leidžiame verslui vadovauti laikydamiesi informacijos reikalavimų. Ir mes suprantame, kad projekto pradžioje niekas nesupranta esamų šaltinių duomenų. Galima teigti, kad duomenų struktūra ir patys duomenys ten pateko atitinkamai per IT ir operacijas, todėl turėtume žinoti, bet tikrai to neturime. Tai į duomenis orientuota plėtra. Taigi, galvodami apie tai, kur mes ir kaip modeliaujame duomenis, orientuotus į duomenis orientuotame pasaulyje, turime turėti grįžtamojo ryšio linijas vartotojams, kad būtų patobulinti jų informacijos reikalavimai, nes mes atrandame duomenis ir formuojame duomenis., numatoma šaltinio duomenų analizė ir pamažu įgydami vis daugiau duomenų apie savo duomenis. Ir dabar aš kalbu apie tradiciškesnį projektą, pavyzdžiui, MDM centrą ar duomenų saugyklą, nebūtinai didžiųjų duomenų projektus, nors aš vis dar manau, kad jis yra gana artimas. Taigi, jūsų grįžtamasis ryšys apima duomenų modeliuotojus, jūs žinote, palaipsniui tobulindami savo duomenų modelį ir sąveikaudami su vartotojais, kad įsitikintumėte, jog informacijos reikalavimai yra patobulinti atsižvelgiant į tai, kas įmanoma, kas prieinama, iš šaltinio duomenų, nes jie geriau supranta, taigi Tai jau nebėra duomenų modelio atvejis, kurio, žinoma, nėra arba jo visiškai nėra, tai reikia laipsniškai atkreipti į tai dėmesį.
Panašiai, paskesnėje dalyje, mes turime kokybės užtikrinimą, kur mes parengiame duomenų kokybės tikrinimo taisykles, kad įsitikintume, jog duomenys atitinka parametrus, apie kuriuos darome prielaidas. Įėjęs Ericas užsiminė apie pamatinių duomenų pakeitimus, kurie gali įvykti. Jūs nenorite būti tarsi nevaldomas pokyčių toje srityje auka, taigi, kokybės užtikrinimo taisyklės gali būti įtrauktos į nuolatinę duomenų kokybės stebėseną. Taigi galite pradėti domėtis, ar mes orientuosimės į duomenis, kaip į duomenis orientuotas vystymasis skiriasi nuo funkcionalumo pagrįsto SDLC ir „Agile“. Tada turime atkreipti dėmesį ir į verslo požiūrius. Mes turime - ir tai vėlgi pakartoja tai, ką kalbėjo Ericas - mes turime duomenų modelį, apibrėžiantį duomenų bazės duomenų bazės projektą, tačiau tuo pat metu mums reikalingi tie konceptualūs modeliai, tie verslo požiūriai į duomenis, kurie tradiciškai nebuvo daromi praeitis. Mes kartais, manau, galvojome, kad duomenų modelis gali visa tai padaryti, bet mes turime turėti konceptualų vaizdą, semantiką ir įsigilinti į duomenis, pateikti juos per abstrakcijos sluoksnį, kuris saugojimo modelį paverčia verslu. vaizdas. Ir vėlgi, visi dalykai, apie kuriuos Ericas kalbėjo, kalbant apie semantiką, tampa svarbūs tai padaryti, todėl mes iš tikrųjų turime papildomų modeliavimo užduočių. Aš manau, kad tai, įdomu, jei tu pasirodei duomenų modeliuotojo gretose, kaip aš, ir vėl kažkas naujo.
Galiausiai norėčiau pasakyti, kad didesnė architektūra taip pat turėjo atspindėti šią naują realybę. Pavyzdžiui, tradicinis kliento MDM yra geras, gerai, pateiksime savo klientų duomenis į centrą, kuriame, žinokime, galime tai suprasti, kalbėdami apie tikrai teisingą duomenų apie „back office“ programas kokybę. Verslo strategijos požiūriu tai yra tarsi žiovulys. Tačiau šiandien mes žiūrime į klientų MDM centrus, kuriuose yra papildomų klientų profilio duomenų, ne tik statinių duomenų, kurie iš tikrųjų turi dvikryptę sąsają su kliento taikomosiomis operacijomis. Taip, jie vis dar palaiko „back office“, tačiau dabar mes taip pat žinome apie tokį mūsų klientų elgesį. Tai pastatyti yra brangiau. Tai pastatyti yra sudėtingiau. Tačiau tai yra verslas, kurio tradicinis klientas MDM neturi. Jūs orientuojatės į verslą prieš paprastesnius dizainus, kuriuos lengviau įgyvendinti, tačiau verslui tai yra tai, ką jie nori pamatyti. Mes iš tikrųjų esame naujoje eroje ir manau, kad yra keletas lygių, kuriuos turime reaguoti į verslą skatinančią duomenų architektūrą, ir manau, kad tai labai įdomus laikas daryti reikalus.
Taigi ačiū tau, Rebeka.
Rebecca Jozwiak: Ačiū Malcolmui, ir man labai patiko tai, ką jūs sakėte apie duomenų modelius, turi pateisinti verslo požiūrį, nes, skirtingai nei jūs sakėte, kur IT tiek ilgai laikė varžtus ir tiesiog nebe tas atvejis, o kad kultūrą reikia keisti. Ir aš esu gana tikras, kad fone buvo šuo, kuris su tavimi sutiko 100 proc. Ir kartu su tuo aš perleisiu kamuolį Ronui. Labai džiaugiuosi matydamas jūsų demonstracinę versiją. Ronai, grindys tavo.
Ronas Huizenga: Labai jums ačiū ir prieš pradėdami pereiti į keletą skaidrių ir po truputį demonstruoti, nes, kaip pažymėjo Ericas ir Malcolmas, tai labai plati ir gili tema, ir atsižvelgiant į tai, apie ką mes šiandien kalbame, mes tiesiog subraižome jo paviršių, nes yra tiek daug aspektų ir tiek daug dalykų, kuriuos tikrai turime apsvarstyti ir pažvelgti iš verslo orientuotos architektūros. Mūsų požiūris yra iš tikrųjų padaryti tą modelį pagrįstą ir iš modelių įgyti tikrąją vertę, nes jūs galite juos naudoti ir kaip komunikacijos priemonę, ir kaip sluoksnį, kad įgalintų kitas sistemas. Nesvarbu, ar darote į paslaugas orientuotą architektūrą, ar kitus dalykus, modelis iš tikrųjų tampa to, kas vyksta, esmė, su visais metaduomenimis, esančiais aplink jį, ir su jūsų įmonėje esančiais duomenimis.
Vis dėlto apie tai, apie ką noriu kalbėti, beveik imuosi šio žingsnio atgal, nes Malcolmas palietė istoriją, kaip vystėsi sprendimai, ir tokio tipo dalykus. Vienas iš būdų pabrėžti, kaip svarbu turėti patikimą duomenų architektūrą, yra naudojimo atvejis, į kurį aš dažnai susidurdavau konsultuodamasis prieš pradėdamas produkto valdymo vaidmenį, tai buvo, aš eidavau į organizacijas. ar jie vykdė verslo pertvarkymą, ar tiesiog pakeitė kai kurias esamas sistemas ir tokio tipo daiktus, ir labai greitai paaiškėjo, kaip prastai organizacijos supranta jų pačių duomenis. Jei pasirenkate konkretų naudojimo atvejį, tokį kaip šis, nesvarbu, ar esate konsultantas, ar einate į asmenį, kuris ką tik įkūrė organizaciją, ar jūsų organizacija per daugelį metų buvo suburta įsigyjant įvairias įmones, tuo jūs pasibaigsite „up with“ labai greitai sukuria labai sudėtingą aplinką, kurioje yra daugybė naujų skirtingų technologijų, taip pat senosios technologijos, ERP sprendimai ir visa kita.
Taigi vienas iš dalykų, kuriuos mes tikrai galime padaryti naudodami savo modeliavimo metodą, yra atsakymas į klausimą, kaip aš visa tai suprantu? Mes tikrai galime pradėti kaupti informaciją kartu, todėl verslas gali tinkamai panaudoti turimą informaciją. Ir paaiškėja, kas gi yra, kad mes ten esame toje aplinkoje? Kaip aš galiu naudoti modelius, kad ištraukčiau reikalingą informaciją ir geriau suprantu tą informaciją? Tada mes turime tradicinius visų skirtingų dalykų metaduomenų tipus, pavyzdžiui, reliacinius duomenų modelius, ir mes esame įpratę matyti tokius dalykus kaip apibrėžimai ir duomenų žodynai, žinote, duomenų tipai ir tokio tipo daiktai. Bet kaip su papildomais metaduomenimis, kuriuos norite užfiksuoti, kad jie iš tikrųjų suteiktų dar daugiau prasmės? Pavyzdžiui, kurie subjektai iš tikrųjų yra kandidatai, kurie turėtų būti atskaitos duomenų objektai, kurie turėtų būti pagrindiniai duomenų valdymo objektai ir tokio tipo daiktai bei juos susieti. O kaip informacija teka per organizaciją? Duomenys gaunami ne tik iš to, kaip jie sunaudojami, bet ir proceso požiūriu, taip pat duomenų linija, susijusi su informacijos kelione per mūsų verslą ir kaip ji keičiasi per skirtingas sistemas ar per duomenų saugyklas, taigi, mes žinome kurdami I sprendimus ar tokio tipo daiktus, faktiškai sunaudojame teisingą informaciją šiai užduočiai atlikti.
Ir tada labai svarbu, kaip mes galime pritraukti visus tuos suinteresuotuosius subjektus, ypač verslo suinteresuotuosius subjektus, nes jie būtent ir suteikia mums tikrąją to duomenų prasmę. Verslas, dienos pabaigoje, turi duomenis. Jie pateikia žodynų ir dalykų, apie kuriuos Erikas kalbėjo, apibrėžimus, todėl mums reikia vietos, kur visa tai susieti. Tai mes darome per duomenų modeliavimo ir duomenų saugyklų architektūrą.
Aš paliesiu keletą dalykų. Aš kalbėsiu apie „ER / Studio Enterprise Team Edition“. Pirmiausia kalbėsiu apie duomenų architektūros produktą, kuriame modeliuojame duomenis ir tokio tipo daiktus, tačiau yra daugybė kitų rinkinio komponentų, kuriuos aš labai trumpai paliesiu. Pamatysite vieną „Business Architect“ fragmentą, kuriame mes galime sudaryti konceptualius modelius, tačiau taip pat galime sudaryti verslo procesų modelius ir galime susieti tuos proceso modelius, kad susietume tikruosius duomenis, kuriuos turime savo duomenų modeliuose. Tai tikrai padeda mums suvienyti tą kaklaraištį. Programinės įrangos architektas leidžia mums atlikti papildomus konstrukcijas, pvz., Tam tikrą UML modeliavimą ir tokio tipo dalykus, kad suteiktume palaikomąją logiką kai kurioms toms sistemoms ir procesams, apie kuriuos mes kalbame. Bet labai svarbu, kai judame žemyn, turime saugyklą ir komandos serverį, ir aš kalbėsiu apie tai kaip apie dvi to paties dalyko puses. Saugykloje saugome visus modeliuotus metaduomenis, taip pat visus verslo metaduomenis verslo žodynėlių ir terminų prasme. Ir kadangi mes turime šią saugyklomis pagrįstą aplinką, mes galime visus šiuos skirtingus dalykus sujungti toje pačioje aplinkoje ir tada iš tikrųjų padaryti juos prieinamus ne tik technikos žmonėms, bet ir verslininkams. Ir būtent taip mes iš tikrųjų pradedame bendradarbiauti.
Ir tada paskutinis kūrinys, apie kurį trumpai kalbėsiu, yra tas, kad kai jūs einate į šią aplinką, turite ne tik duomenų bazes. Turėsite daugybę duomenų bazių, duomenų saugyklų, taip pat turėsite daugybę, ką aš pavadinčiau, senų artefaktų. Galbūt žmonės naudojo „Visio“ ar kitas diagramas, kad apibrėžtų kai kuriuos dalykus. Gal jie jau turėjo kitų modeliavimo įrankių ir tokio tipo daiktų. Taigi tai, ką mes galime padaryti su „MetaWizard“, yra išgauti dalį šios informacijos ir perkelti ją į mūsų modelius, padaryti ją aktualią ir sugebėti ją naudoti, vėl naudoti dabartiniu būdu, o ne tiesiog sėdėti lauke. Dabar tai tampa aktyvia mūsų darbo modelių dalimi, o tai labai svarbu.
Kai jūs einate į organizaciją, kaip jau sakiau, yra daugybė skirtingų sistemų, daugybė ERP sprendimų, nesuderinti departamentų sprendimai. Daugelis organizacijų taip pat naudoja „SaaS“ sprendimus, kurie taip pat yra išoriškai kontroliuojami ir valdomi, todėl mes nekontroliuojame duomenų bazių ir tokių dalykų, esančių jų pagrindiniuose kompiuteriuose, tačiau vis tiek turime žinoti, kaip tie duomenys atrodo, ir, žinoma, aplink tai esančius metaduomenis. Mes taip pat randame daug pasenusių senų sistemų, kurios nebuvo išvalytos dėl to projekto principo, apie kurį kalbėjo Malcolmas. Nuostabu, kaip pastaraisiais metais organizacijos suprojektuos projektus, pakeis sistemą ar sprendimą, tačiau pasenusiems sprendimams nutraukti dažnai trūksta projekto biudžeto, taigi dabar jie yra tik linkę. Ir mes turime išsiaiškinti, ko iš tikrųjų galime atsikratyti savo aplinkoje, taip pat to, kas naudinga ateityje. Ir tai yra susiję su prasta eksploatavimo nutraukimo strategija. Tai neatsiejama to paties dalyko dalis.
Ką mes taip pat randame, nes daugybė organizacijų buvo sukurtos remiantis visais šiais skirtingais sprendimais, ar mes matome daugybę tiesioginio ryšio sąsajų su daugybe duomenų, judančių daugybėje vietų. Turime sugebėti tai racionalizuoti ir išsiaiškinti duomenų liniją, apie kurią anksčiau trumpai užsiminiau, kad galėtume turėti darnesnę strategiją, pvz., Naudoti į paslaugas orientuotą architektūrą, įmonės paslaugų autobusus ir tokio tipo dalykus, kad pateiktume teisingą informaciją. prie modelio, kurį teisingai naudojame visame versle, leidimo ir prenumeratos. Ir tada, be abejo, vis tiek turime atlikti tam tikrą analizę, nesvarbu, ar mes naudojame duomenų sandėlius, duomenų žemėlapius su tradicine ETL ar kai kuriuos naujus duomenų ežerus. Viskas nutinka tuo pačiu dalyku. Tai yra visi duomenys, nesvarbu, ar tai dideli duomenys, ar tai tradiciniai duomenys reliacinėse duomenų bazėse. Turime visus šiuos duomenis sujungti, kad galėtume juos valdyti ir žinoti, su kuriais susiduriame visuose mūsų modeliuose.
Vėlgi, sudėtinga, kurią mes darysime, yra tai, kad turime keletą žingsnių, kuriuos norime atlikti. Visų pirma, jūs einate ir neturite tų brėžinių, kaip atrodo tas informacinis kraštovaizdis. Duomenų modeliavimo įrankyje, tokiame kaip „ER / Studio Data Architect“, pirmiausia atliksite daugybę atvirkštinių inžinerijų, atkreipkime dėmesį į esamus duomenų šaltinius, įtrauksime juos ir iš tikrųjų sujungsime juos į reprezentatyvesnius. modeliai, reprezentuojantys visą verslą. Svarbu tai, ar norime sugebėti tuos modelius ir suskaidyti pagal verslo linijas, kad galėtume juos susieti su mažesnėmis dalimis, su kuriomis gali susieti ir mūsų verslo žmonės, ir su mūsų verslo analitikais bei kitomis suinteresuotosiomis šalimis, kurios dirba ant jo.
Įvardijimo standartai yra nepaprastai svarbūs ir aš čia kalbu apie porą skirtingų būdų. Pavadinkite standartus, kaip pavadinti dalykus mūsų modeliuose. Tai gana lengva padaryti loginiuose modeliuose, kur turime gerą vardų suteikimo tvarką ir gerą savo duomenų duomenų žodyną, bet tada taip pat matome skirtingas daugelio šių fizinių modelių, kuriuos mes pristatome, pavadinimo tvarką. atvirkštinis inžinierius, gana dažnai matome sutrumpintus vardus ir tokio tipo daiktus, apie kuriuos aš kalbėsiu. Ir mes turime juos išversti į prasmingus verslui reikšmingus angliškus pavadinimus, kad suprastume, kokie visi šie duomenys yra aplinkoje. Ir tada universalus atvaizdavimas yra tai, kaip mes juos susiuvame.
Be to, mes tada dokumentuosime ir apibrėžsime toliau, o tada mes galime toliau klasifikuoti savo duomenis, vadindami priedus, kuriuos parodysiu jums pora skaidrių. Ir tada uždarydami ciklą norime pritaikyti tą verslo prasmę, kurią mes susiejame savo verslo žodynėliuose ir galime susieti juos su skirtingais mūsų modelio artefaksais, todėl žinome, kai kalbame apie tam tikrą verslo terminą, kur tai įgyvendinta mūsų duomenimis visoje organizacijoje. Ir galiausiai aš jau kalbėjau apie tai, kad mums reikia viso to, kad būtų duomenų saugykla, turinti daug bendradarbiavimo ir leidybos galimybių, kad mūsų suinteresuotosios šalys galėtų tuo pasinaudoti. Aš gana greitai kalbėsiu apie atvirkštinę inžineriją. Aš jau labai greitai jums parodžiau tai. Aš jums tai parodysiu realiame demonstraciniame stende, norėdamas tik parodyti jums kai kuriuos dalykus, kuriuos galime ten įnešti.
Ir aš noriu pakalbėti apie keletą skirtingų modelių tipų ir schemų, kuriuos mes parengtume pagal tokio tipo scenarijus. Akivaizdu, kad konceptualius modelius darysime daugeliu atvejų; Aš nesiruošiu tam skirti daug laiko. Aš tikrai noriu kalbėti apie loginius modelius, fizinius modelius ir specializuotus modelių tipus, kuriuos galime sukurti. Ir svarbu, kad galėtume juos visus susikurti toje pačioje modeliavimo platformoje, kad galėtume juos susiuvami. Tai apima matmenų modelius ir modelius, kuriuose naudojami kai kurie nauji duomenų šaltiniai, pavyzdžiui, „NoSQL“, kurį jums parodysiu. O tada, kaip atrodo duomenų linijos modelis? Apie tai, kaip susieti tuos duomenis į verslo proceso modelį, bus tai, apie ką mes kalbėsime toliau.
Čia pereisiu prie modeliavimo aplinkos, kad pateikčiau labai aukštą ir greitą apžvalgą. Ir aš tikiu, kad jūs turėtumėte pamatyti mano ekraną dabar. Pirmiausia noriu pakalbėti tik apie tradicinį duomenų modelio tipą. Ir kaip mes norime organizuoti modelius, kai mes juos įvedame, mes norime sugebėti juos suskaidyti. Taigi, ką jūs matote čia kairiajame krašte, turime konkretaus modelio failo loginius ir fizinius modelius. Kitas dalykas yra tai, ar galime tai suskaidyti pagal verslo skaidymąsi, todėl matote aplankus. Šviesiai mėlyni yra logiški modeliai, o žali - fiziniai. Mes taip pat galime išsiaiškinti, todėl „ER / Studio“ programoje, jei suskaidote verslą, galite pereiti kuo daugiau lygių giluminių ar submodelių, o žemesniuose lygmenyse atlikti pakeitimai automatiškai atsispindi aukštesniuose. lygiai. Taigi labai greitai tai tampa labai galinga modeliavimo aplinka.
Aš noriu pabrėžti, kad labai svarbu pradėti kaupti šią informaciją, nes mes galime turėti kelis fizinius modelius, kurie atitinka ir vieną loginį modelį. Gana dažnai jūs galite turėti loginį modelį, bet jūs galite turėti fizinius modelius skirtingose platformose ir tokio tipo daiktus. Gal vienas yra „SQL Server“ egzempliorius, galbūt kitas yra „Oracle“ egzempliorius. Mes turime galimybę visa tai susieti toje pačioje modeliavimo aplinkoje. Ir tai, ką aš čia gavau, yra tikrasis duomenų saugyklos modelis, kuris vėlgi gali būti toje pačioje modeliavimo aplinkoje arba mes galime jį laikyti saugykloje ir susieti ir su įvairiais dalykais.
Tai, ką aš tikrai norėjau jums parodyti, yra keletas kitų dalykų ir kitų modelių variantų, į kuriuos mes įsitraukiame. Taigi, kai mes pereiname prie tokio tradicinio duomenų modelio, mes įpratę matyti tipinius objektus su stulpeliais ir metaduomenimis bei tokio tipo daiktais, tačiau šis požiūris labai greitai kinta, kai pradedame nagrinėti kai kurias iš šių naujesnių „NoSQL“ technologijų. arba kai kurie žmonės vis dar mėgsta juos vadinti didžiųjų duomenų technologijomis.
Taigi dabar tarkime, kad savo aplinkoje taip pat turime avilį. Jei mes atsiversime inžinierių iš „Avilio“ aplinkos - ir galėsime į priekį ir atgal nukreipti inžinierių iš „Avilio“ naudodami tą patį modeliavimo įrankį - pamatysime tai, kas šiek tiek skiriasi. Vis dar matome visus duomenis kaip konstrukcijas, tačiau mūsų TDL skiriasi. Tie iš jūsų, kurie įpratę matyti SQL, tai, ką jūs dabar pamatytumėte, yra „Hive QL“, kuris yra labai panašus į SQL, tačiau iš to paties įrankio dabar galite pradėti dirbti su skirtingomis scenarijų kalbomis. Taigi jūs galite modeliuoti šioje aplinkoje, generuoti ją į „Avilio“ aplinką, tačiau taip pat svarbu, kad pagal mano aprašytą scenarijų jūs galite visa tai pakeisti ir įprasminti bei pradėti susiūti kartu. .
Paimkime dar vieną, kuris šiek tiek skiriasi. „MongoDB“ yra dar viena platforma, kurią mes palaikome savaime. Kai pradedate domėtis JSON tipų aplinka, kurioje yra dokumentų saugyklos, JSON yra kitoks gyvūnas ir jame yra konstrukcijų, kurios neatitinka reliacinių modelių. Kai tik pradedate tardyti JSON, netrukus pradėsite nagrinėti sąvokas, pvz., Įterptus objektus ir įdėtus objektų masyvus, o tradicinėse reliacinėse žymose tokių sąvokų nėra. Tai, ką mes padarėme, mes iš tikrųjų pratęsėme žymėjimą ir katalogą, kad galėtume tai tvarkyti toje pačioje aplinkoje.
Jei pažiūrėsite kairėje pusėje, užuot matę dalykus, pavyzdžiui, objektus ir lenteles, vadiname juos objektais. Jūs matote skirtingus ženklus. Čia vis dar matote tipinius nuorodų ženklų tipus, tačiau šie mėlyni subjektai, kuriuos rodau šioje konkrečioje diagramoje, iš tikrųjų yra įterpti objektai. Ir mes parodome skirtingus kardinalumus. Deimantinis kardinalumas reiškia, kad tai yra objektas iš vienos pusės, o vieno kardinalumas reiškia, kad leidykloje, jei mes sekame tą santykį, turime įterptą adreso objektą. Tardydami JSON, mes nustatėme, kad ji yra visiškai ta pati objektų struktūra, įdėta į globėją, tačiau tai iš tikrųjų yra įterpta kaip objektų masyvas. Mes tai matome ne tik per pačias jungtis, bet ir pažiūrėję į realius subjektus pamatysite, kad globojate adresus, kurie taip pat klasifikuojami kaip objektų masyvas. Gaunate labai apibūdinamą požiūrį, kaip galite tai įnešti.
Ir vėlgi, tai, ką mes matėme iki šiol tik per kelias sekundes, yra tradiciniai daugiapakopiai reliaciniai modeliai, tą patį galime padaryti ir su „Hive“, tą patį galime padaryti ir su „MongoDB“, ir kiti dideli duomenų šaltiniai, kaip gerai. Ką mes taip pat galime padaryti, ir aš tik greitai tai jums parodysiu, kalbėjau apie tai, kad daiktus atvežate iš kitų skirtingų sričių. Aš manau, kad importuosiu modelį iš duomenų bazės arba jį modifikuosiu, bet ketinsiu pateikti iš išorinių metaduomenų. Tiesiog norime pateikti labai greitą vaizdą apie įvairius dalykus, kuriuos galime pradėti pateikti.
Kaip matote, turime daugybę dalykų, su kuriais iš tikrųjų galime įnešti metaduomenis į savo modeliavimo aplinką. Pradedant tokiais dalykais, kaip „Amazon Redshift“, „Cassandra“, daugybe kitų didžiųjų duomenų platformų, taigi jūs matote daugybę tokių sąrašų. Tai yra abėcėlės tvarka. Mes matome daugybę didelių duomenų šaltinių ir tokio tipo dalykų. Taip pat matome daugybę tradicinių ar senesnių modeliavimo aplinkų, kurias iš tikrųjų galime pateikti tuos metaduomenis. Jei aš einu čia ir nesiruošiu skirti laiko kiekvienam iš jų, mes matome daug įvairių dalykų, kuriuos galime įnešti, kalbant apie modeliavimo platformas ir duomenų platformas. Ir tai, ką čia labai svarbu suvokti, yra dar viena dalis, kurią galime padaryti, kai pradedame kalbėti apie duomenų kilmę, „Enterprise Team Edition“ taip pat galime tardyti ETL šaltinius, nesvarbu, ar tai būtų tokie dalykai kaip „Talend“ ar „SQL Server Information Services“ žemėlapiai, mes galime iš tikrųjų atsineškite tai, kad pradėtumėte naudoti ir duomenų duomenų diagramas bei nubraižytumėte, kas vyksta per tas transformacijas. Iš viso turime daugiau kaip 130 šių skirtingų tiltų, kurie iš tikrųjų yra „Enterprise Team Edition“ produkto dalis, todėl tai iš tikrųjų padeda mums labai greitai visus daiktus surinkti į vieną modeliavimo aplinką.
Galiausiai noriu pakalbėti ir apie tai, kad mes negalime pamiršti to, kad mums reikia kitų tipų konstrukcijų, jei mes vykdome duomenų saugojimą ar bet kokio tipo analizę. Mes vis dar norime turėti galimybę daryti tokius dalykus kaip matmenų modeliai, kur turime faktų lenteles ir matmenis bei tokio tipo daiktus. Vieną dalyką, kurį noriu jums taip pat parodyti, yra tai, kad mes taip pat galime turėti savo metaduomenų plėtinius, kurie mums padeda suskirstyti į kategorijas, kas yra aspektų tipai, ir visa kita. Taigi, jei aš pažiūrėčiau, pavyzdžiui, į matmenų duomenų skirtuką čia, pavyzdžiui, į vieną iš jų, jis iš tikrųjų automatiškai aptinka, remdamasis modeliu, kurį mato, ir suteiks jums išeities tašką, ar, jo manymu, tai yra matmuo, ar faktų lentelė. Bet ne tik tai, ką mes galime padaryti, yra matmenų ribose, o tokio tipo daiktus mes netgi turime įvairių tipų matmenis, kuriuos galime naudoti klasifikuodami duomenis ir duomenų saugojimo tipo aplinkoje. Taigi labai galingos galimybės, su kuriomis mes visa tai sutramdome.
Aš pereisiu prie šio, nes šiuo metu esu demonstracinėje aplinkoje ir parodysiu dar keletą dalykų, prieš grįždamas prie skaidrių. Vienas iš dalykų, kuriuos neseniai pridėjome prie „ER / Studio Data Architect“, yra tai, kad susidūrėme su situacijomis - ir tai labai dažnas atvejis, kai dirbate su projektais - kūrėjai galvoja apie objektus, o mūsų duomenys modeliuotojai linkę mąstyti pagal lenteles ir subjektus bei tokio tipo daiktus. Tai labai supaprastintas duomenų modelis, tačiau jis atspindi keletą pagrindinių sąvokų, kai kūrėjai ar net verslo analitikai ar verslo vartotojai gali galvoti apie juos kaip skirtingus objektus ar verslo koncepcijas. Iki šiol buvo labai sunku juos klasifikuoti, bet ką mes iš tikrųjų padarėme „ER / Studio Enterprise Team Edition“, 2016 m. Laidoje, ar mes dabar turime koncepciją, vadinamą verslo duomenų objektais. O tai leidžia mums apjungti subjektų grupes ar lenteles į tikrus verslo objektus.
Pvz., Ką mes matėme šiame naujame rodinyje, yra tai, kad pirkimo užsakymo antraštė ir užsakymo eilutė yra sujungtos dabar, jie yra kapsuliuoti kaip objektas, mes laikysime juos darbo vienetu, kai išliksime duomenys, ir mes suartiname juos, todėl dabar labai lengva tai susieti su įvairiomis auditorijomis. Jie yra daugkartinio naudojimo visoje modeliavimo aplinkoje. Jie yra tikras objektas, ne tik piešimo konstrukcija, bet taip pat turime papildomą naudą, kad realiai bendraudami iš modeliavimo perspektyvos galime juos pasirinktinai žlugti arba išplėsti, kad galėtume sudaryti apibendrintą dialogą su tam tikromis suinteresuotomis šalimis, ir mes, be abejo, galime išlaikyti išsamesnį vaizdą, kokį matome čia, jei norite daugiau techninės auditorijos. Tai iš tikrųjų suteikia mums tikrai gerą susisiekimo priemonę. Tai, ką mes matome dabar, yra derinti kelis skirtingus modelių tipus, papildyti juos verslo duomenų objektų sąvoka, ir dabar aš kalbėsiu apie tai, kaip mes iš tikrųjų pritaikome šio tipo daiktams šiek tiek daugiau prasmės ir kaip juos susiejame savo bendra aplinka.
Aš tiesiog bandau čia surasti savo „WebEx“, kad galėčiau tai padaryti. Ir ten mes einame atgal į „Hot Tech“ skaidres. Aš tiesiog paspartinsiu keletą skaidrių čia, nes jūs jas jau matėte pačioje modelio demonstracijoje. Apie standartų įvardijimą noriu kalbėti labai greitai. Norime pritaikyti ir įgyvendinti skirtingus įvardijimo standartus. Ką mes norime padaryti, mes turime galimybę iš tikrųjų saugyklose saugoti vardų standartų šablonus, kad iš esmės per žodžius ar frazes ar net santrumpas tą reikšmę sukurtų ir susietų su reikšmingu angliško tipo žodžiu. Mes naudosime verslo terminus, kiekvienos jų santrumpas ir galime nurodyti užsakymą, atvejus bei pridėti priešdėlius ir priesagas. Paprastai tai yra atvejis, kai žmonės sukuria loginį modelį ir tada iš tikrųjų eina kurti fizinio modelio, kuriame jie galėjo naudoti santrumpas ir visa kita.
Gražus dalykas yra tai, kad jis yra toks pat galingas, dar galingesnis atvirkščiai, jei galime tiesiog pasakyti, kokie kai kurie iš tų pavadinimų standartų buvo kai kuriose iš tų fizinių duomenų bazių, kurias mes sukūrėme atvirkščiai, mes galime paimti tas santrumpas, paversti jas ilgesnėmis žodžius, ir sugrąžinkite juos atgal į angliškas frazes. Iš tikrųjų dabar galime išvesti tinkamus pavadinimus, kaip atrodo mūsų duomenys. Kaip aš sakau, tipiškas naudojimo atvejis yra tas, kad mes judėtume pirmyn, logiškai ir fiziškai, ir žemėlapiuotume duomenų saugyklas ir tokio tipo daiktus. Jei pažiūrėsite ekrano kopiją dešinėje, pamatysite, kad iš šaltinių vardų yra sutrumpinti vardai, ir kai pritaikėme vardinimo standartų šabloną, iš tikrųjų turime daugiau pilnų vardų. Ir mes galėtume įterpti tarpus ir viską, kas panašu, jei norime, priklausomai nuo pavadinimo standartų šablono, kurį naudojome. Galime atrodyti taip, kaip norime, kad jis atrodytų mūsų modeliuose. Tik tada, kai žinome, kas yra vadinama, galime iš tikrųjų pradėti prie jo pridėti apibrėžimus, nes kaip žinoti, kas tai yra, jei nežinome, kas tai yra?
Puiku yra tai, kad mes iš tikrųjų galime tuo remtis darydami įvairius dalykus. Aš kalbėjau apie atvirkštinę inžineriją. Mes iš tikrųjų galime vienu metu remtis pavadinimų standartų šablonais, kai darome atvirkštinę inžineriją. Taigi, atlikdami vieną vedlio žingsnį, mes galime tai padaryti, jei žinome, kas yra susitarimai, galime pakeisti fizinės duomenų bazės inžinierių, ji grąžins ją kaip fizinius modelius modeliavimo aplinkoje ir taip pat ketinu taikyti tas įvardijimo konvencijas. Taigi pamatysime, kokie angliški pavadinimų vaizdai yra atitinkamame loginiame aplinkos modelyje. Mes taip pat galime tai padaryti ir derinti su XML schemų generavimu, kad galėtume paimti modelį ir net išstumti jį su savo sutrumpinimais, nesvarbu, ar darome SOA rėmus, ar tokio tipo daiktus, todėl galime išstumti ir skirtingas vardų darymo konvencijas. kuriuos mes iš tikrųjų išsaugojome pačiame modelyje. Tai suteikia mums labai daug galingų galimybių.
Vėlgi, štai pavyzdys, kaip atrodytų, jei turėčiau šabloną. Tai iš tikrųjų rodo, kad aš turėjau EMP „darbuotojui“, SAL „algai“, PLN „planui“ pavadinimų standartų konvencijoje. Aš taip pat galiu juos pritaikyti, kad jie veiktų interaktyviai, kai aš kuriu modelius ir dedu daiktus. Jei naudočiau šią santrumpą ir subjekto pavadinime įvesdavau į „Darbuotojų atlyginimų planą“, tai veiktų su pavadinimų standartų šablonu. Aš čia apibrėžiau, kad būtų buvę suteikta EMP_SAL_PLN, nes aš buvau sukūręs subjektus ir iškart davęs atitinkamus fizinius vardus.
Vėlgi, labai gerai, kai mes taip pat projektuojame ir tobuliname inžineriją. Mes turime labai unikalią koncepciją ir būtent čia mes pradedame derinti šią aplinką. Ir tai vadinama „Universal Mappings“. Įdiegę visus šiuos modelius į savo aplinką, ką galime padaryti, darant prielaidą, kad dabar pritaikėme šias įvardijimo konvencijas ir jas lengva rasti, dabar galime naudoti konstrukciją, vadinamą „Universal Mappings“, ER / Studija. Mes galime susieti subjektus įvairiuose modeliuose. Kad ir kur matytume „klientą“ - tikriausiai turėsime „klientą“ daugybėje skirtingų sistemų ir daugybėje skirtingų duomenų bazių - mes galime pradėti susieti visus tuos kartu, kad kai dirbu su juo vienu modeliu gali pamatyti, kur yra kitų modelių klientai. Ir kadangi mes turime modelio sluoksnį, kuris tai reprezentuoja, mes netgi galime jį susieti su duomenų šaltiniais ir susieti su mūsų naudojamais užklausomis, kuriose duomenų bazėse jie taip pat yra. Tai tikrai suteikia mums galimybę visa tai suderinti.
Parodžiau jums verslo duomenų objektus. Taip pat noriu labai greitai kalbėti apie metaduomenų plėtinius, kuriuos mes vadiname priedais. Kas tai daro, tai suteikia mums galimybę sukurti papildomus mūsų modelio objektų metaduomenis. Gana dažnai aš nustatyčiau tokio tipo savybes, kad iš duomenų valdymo ir duomenų kokybės perspektyvos būtų išleista daug įvairių dalykų, taip pat padėtų mums pagrindiniai duomenų tvarkymo ir duomenų saugojimo principai. Pagrindinė idėja yra sukurti šias klasifikacijas ir jas pridėti visur, kur norite, lentelių ir stulpelių lygyje. Dažniausiai pasitaikantis naudojimo atvejis, žinoma, yra tai, kad subjektai yra lentelės, ir tada aš galiu apibrėžti: kas yra mano pagrindiniai duomenų objektai, kas yra mano atskaitos lentelės, kas yra mano operacijų lentelės? Duomenų kokybės požiūriu galiu klasifikuoti pagal svarbą verslui, kad galėtume teikti pirmenybę duomenų tvarkymo pastangoms ir tam tikram dalykui.
Tai, kas dažnai nepastebima, kokia yra įvairių tipų duomenų saugojimo politika mūsų organizacijoje? Mes galime juos nustatyti ir iš tikrųjų galime juos pridėti prie įvairių tipų informacijos artefaktų mūsų modeliavimo aplinkoje ir, be abejo, ir mūsų saugykloje. Grožis yra tas, ar šie priedai yra mūsų duomenų žodyne, taigi, kai aplinkoje naudojame įmonių duomenų žodynus, galime juos pridėti prie kelių modelių. Turime juos apibrėžti tik vieną kartą ir galime juos vėl ir vėl panaudoti skirtinguose mūsų aplinkos modeliuose. Tai yra tik greita ekrano kopija, parodanti, kad iš tikrųjų galite nurodyti, kai darote priedą, prie kurių visų dalių norite pridėti. Ir čia pateiktas pavyzdys iš tikrųjų yra vertybių sąrašas, todėl kai jie vyksta, galite pasirinkti iš vertybių sąrašo, modeliavimo aplinkoje galite daug valdyti, kas yra renkama, ir netgi galite nustatyti, koks yra numatytasis vertė yra, jei vertė nėra pasirinkta. Taigi ten daug jėgų. Jie gyvena duomenų žodyne.
Kažką, ką noriu jums parodyti šiek tiek toliau šiame ekrane, be to, viršutinėje dalyje matote priedų rūšis, po kuriomis matote duomenų saugos informaciją. Duomenų saugos politiką faktiškai galime pritaikyti ir skirtingoje aplinkoje esančioje informacijoje. Norėdami atlikti skirtingus atitikties žemėlapius, duomenų saugumo klasifikacijas, daugelį jų išsiųsime iš dėžutės, kurią galite tiesiog sugeneruoti ir pradėti naudoti, tačiau taip pat galite apibrėžti savo atitikties žemėlapius ir standartus. Nesvarbu, ar darote HIPAA, ar bet kurią kitą iniciatyvą. Ir jūs tikrai galite pradėti kurti šį labai turtingą metaduomenų rinkinį savo aplinkoje.
Ir tada „Žodynas ir terminai“ - čia yra susieta verslo prasmė. Mes gana dažnai turime duomenų žodynus, kuriuos gana dažnai organizacija naudoja kaip atskaitos tašką norėdami išrašyti žodynus, tačiau terminija ir žodžių junginys yra dažnai labai techninis. Taigi, ką galime padaryti, mes galime, jei norime, naudoti juos kaip atskaitos tašką žodynėliams kurti, tačiau labai norime, kad verslas juos turėtų. Tai, ką padarėme komandos serverio aplinkoje, yra tai, kad žmonėms suteikėme galimybę kurti verslo apibrėžimus ir tada galėsime juos susieti su skirtingais modelio artefaksais, kuriuos jie atitinka ir modeliavimo aplinkoje. Mes taip pat suprantame anksčiau aptartą mintį, kad kuo daugiau žmonių rašote, tuo daugiau galimybių žmogiškoms klaidoms atsirasti. Savo žodynėlių struktūroje mes taip pat remiamės žodynėlių hierarchija, todėl organizacijoje galime turėti skirtingus žodynėlių tipus ar įvairius dalykus, tačiau ne mažiau svarbu yra tai, jei jau turite kelis iš šių šaltinių. ten su apibrėžtais terminais ir viskuo, mes iš tikrųjų galime atlikti CSV importą, kad įtrauktume juos į savo modeliavimo aplinką, taip pat į komandos serverį ar žodynėlį, ir tada pradėtume susieti iš ten. Kiekvieną kartą keičiant ką nors, yra visa audito seka, kokie buvo ankstesni ir kiti vaizdai, atsižvelgiant į apibrėžimus ir visa kita, ir tai, ką pamatysite artimiausiu metu, tai taip pat daugiau yra leidimų suteikimo darbo eiga. taigi mes tikrai galime kontroliuoti, kas už tai atsakingi, komitetų ar asmenų patvirtinimus ir tokio tipo dalykus, kad valdymo procesas būtų dar tvirtesnis einant į priekį.
Tai daro ir mums, kai turime šiuos terminų žodyno terminus savo komandos serverio žodynėlyje. Tai yra redagavimo paties modelio, kurį aš čia pateikiau, pavyzdys. Galbūt ji susiejo terminus, bet mes taip pat darome tai, jei tame žodynėlyje yra žodžių, kurie atsiranda pastabose ar aprašymuose, ką turime čia esančių subjektų, jie automatiškai parodomi šviesesne hipersaito spalva, o jei mes Jei pelės žymeklis virš jų, apibrėžimą iš tikrųjų galime pamatyti ir verslo žodynėlyje. Tai netgi suteikia mums turtingesnės informacijos, kai vartojame pačią informaciją su visais ten esančiais žodynėlių terminais. Tai tikrai padeda praturtinti patirtį ir pritaikyti prasmę viskam, su kuo dirbame.
Taigi, vėlgi, tai buvo labai greitas flyby. Akivaizdu, kad mes galime tam praleisti dienas, kai gilinamės į skirtingas dalis, tačiau tai labai greitas flyby virš paviršiaus. Mes iš tikrųjų siekiame suprasti, kaip atrodo ta sudėtinga duomenų aplinka. Norime pagerinti visų tų duomenų artefaktų matomumą ir bendradarbiauti, kad išstumtume juos iš „ER / Studio“. Norime įgalinti efektyvesnį ir automatizuotą duomenų modeliavimą. Ir tai yra visų rūšių duomenys, apie kuriuos mes kalbame, nesvarbu, ar tai yra dideli duomenys, tradiciniai ryšių duomenys, dokumentų saugyklos ar dar kas nors. Ir tai dar kartą pasiekėme, nes turime galingas įvairių platformų ir kitų įrankių, kurias galite turėti, pirmyn ir atgal inžineriją. Viskas priklauso nuo to, ar organizacija gali keistis informacija ir bendrauti su visomis suinteresuotomis šalimis. Štai kur mes taikome prasmę įvardydami standartus. Tada taikome apibrėžimus naudodamiesi verslo žodynėliais. Tada mes galime toliau klasifikuoti visas mūsų kitas valdymo galimybes, naudodamiesi metaduomenų plėtiniais, tokiais kaip duomenų kokybės plėtiniai, pagrindinių duomenų tvarkymo klasifikacijos ar bet kurios kitos rūšies klasifikacijos, kurias norite pritaikyti tiems duomenims. Tada mes galime dar labiau apibendrinti ir dar labiau sustiprinti ryšį su verslo duomenų objektais, su įvairiomis suinteresuotomis šalimis, ypač tarp modeliuotojų ir kūrėjų.
Ir vėlgi, kas čia yra labai svarbu, už viso to slypi integruota saugykla, turinti labai patikimas pokyčių valdymo galimybes. Aš neturėjau laiko to parodyti šiandien, nes jis tampa gana sudėtingas, tačiau saugykla turi labai patikimas pokyčių valdymo galimybes ir audito pėdsakus. Galite daryti įvardintus leidimus, taip pat ir įvardytas versijas. Mes taip pat galime tiems, kurie tvarko pokyčių valdymą, mes galime tai susieti su jūsų užduotimis. Šiandien turime galimybę sudėti užduotis ir susieti jūsų modelio pakeitimus su užduotimis, lygiai kaip kūrėjai savo kodo pakeitimus susies su užduotimis ar vartotojų istorijomis, su kuriomis jie taip pat dirba.
Tai vėlgi buvo labai greita apžvalga. Tikiuosi, kad pakako sujaudinti apetitą, kad galėtume pradėti daug gilesnius pokalbius išskaidydami kai kurias iš šių temų ateityje. Ačiū už jūsų laiką ir vėl jums, Rebeka.
Rebecca Jozwiak: Ačiū, Ronai, tai buvo fantastiška ir turiu nemažai klausytojų klausimų, tačiau aš noriu suteikti mūsų analitikams galimybę pasnausti dantis į tai, ką jūs turėjote pasakyti. Erikai, aš eisiu į priekį ir galbūt, jei norite atkreipti dėmesį į šią ar kitokią skaidrę, kodėl jūs pirmiau neišeinate? Arba kitas klausimas.
Erikas Mažasis: Tikrai. Atsiprašome, koks buvo klausimas, Rebeka? Norite, kad paklausčiau kažko konkretaus ar …?
Rebecca Jozwiak: Aš žinau, kad iš pradžių turėjote keletą klausimų Ronui. Jei norite paprašyti, kad jis kreiptųsi į bet kurį iš tų asmenų ar kai kuriuos iš jų jūsų skaidrėje ar dar ką nors, kas sukėlė jūsų susidomėjimą ir apie kuriuos norite paklausti? Apie IDERA modeliavimo funkcijas.
Erikas Mažasis: Taip, vienas iš dalykų, Ronai, taigi, kaip jūs, vaikinai, atrodo, kad diagramos, kurias rodydavote, yra bendro pobūdžio subjektų santykių diagramos, kurias paprastai naudotumėte kurdami duomenų bazę, ar teisinga?
Ronas Huizenga: Taip, paprastai kalbant, bet, žinoma, turime išplėstines dokumentų saugyklų rūšis ir tokio tipo daiktus. Mes iš tikrųjų skyrėmės nuo gryno reliacinio žymėjimo, mes iš tikrųjų pridėjome papildomų žymėjimų ir toms kitoms parduotuvėms.
Erikas Mažasis: Ar yra koks nors būdas, kaip jūs, vaikinai, galite naudoti grafikais paremtus modeliavimo tipus, taigi, ar yra būdas integruoti, tarkime, tarkime, kad aš turiu kažką panašaus į aukščiausią kvadrantą, „TopBraid“ kompozitoriaus įrankį ar aš ką nors padariau Protėže arba, kaip žinote, kaip FIBO finansininkai, jie dirba daug darbų semantikos srityje, RDF dalykus - ar yra būdas įtraukti šį subjekto ir santykio grafiko tipo modeliavimą į šį įrankį ir panaudoti jį tai?
Ronas Huizenga: Mes iš tikrųjų žiūrime, kaip galėtume tvarkyti grafikus. Šiandien mes neaiškiai tvarkome grafikų duomenų bazes ir tokio tipo dalykus, tačiau ieškome būdų, kaip tai padaryti, kad praplėstume metaduomenis. Aš turiu omenyje, kad mes galime įnešti daiktus per XML ir tokio tipo daiktus dabar, jei galime bent jau padaryti kokį nors XML perdavimą, kad tai būtų atskaitos taškas. Bet mes ieškome elegantiškesnių būdų tai įnešti.
Aš taip pat parodžiau jums tą atvirkštinės inžinerijos tiltų sąrašą, kurį mes taip pat turime, todėl mes visuomet ieškome galimybių išplėsti tuos tiltus ir tam tikroms platformoms. Tai yra nuolatinės pastangos, jei tai yra prasminga, kad pradėtų aprėpti daugybę šių naujų konstrukcijų ir įvairių platformų. Bet galiu pasakyti, kad mes tikrai esame priešakyje tai darydami. Daiktai, kuriuos rodžiau, pavyzdžiui, „MongoDB“ ir tokio tipo daiktai, mes esame pirmieji duomenų modeliavimo tiekėjai, faktiškai tai padarę savo gaminyje.
Erikas Mažasis: Gerai, taip. Taigi kitas klausimas, kurį aš jums pateikiau, buvo susijęs su valdymu ir išlaikymu, pavyzdžiui, kai naudojote pavyzdį, kai rodydavote asmens, kuris yra „darbuotojas“, pavyzdį, manau, kad tai buvo „ atlyginimas “, ir tada jūs turite„ planą “. Ar yra būdas, kaip suvaldyti, pavyzdžiui, įvairius žmones, kurie gali turėti - tarkime, kad turite didelę architektūrą, tiesa, tarkime, kad turite didelę įmonę ir žmonės pradeda derinti dalykus naudodamiesi šiuo įrankiu, ir jūs čia turite vieną grupę, kurioje yra žodis „darbuotojas“, ir vieną grupę, kurioje yra žodis „darbuotojas“. Čia vienas žmogus sako „atlyginimas“, o kitas sako „Atlyginimas“.
Kaip jūs, vaikinai, suderinate ir valdote bei valdote tokius skirtumus? Kadangi aš žinau, kaip mes tai padarytume grafikų pasaulyje, žinote, jūs naudositės sinonimų sąrašais arba jūs sakytumėte, kad yra viena sąvoka ir ji turi kelis požymius, arba galite pasakyti, kad SKOS modelyje aš turiu pageidaujamą etiketę ir turiu. daugybė alternatyvių etikečių, kurias galiu naudoti. Kaip jūs, vaikinai, tai darote?
Ronas Huizenga: Mes darome tai keliais skirtingais būdais, pirmiausia kalbėkime apie terminiją. Be abejo, vienas iš dalykų, kuriuos darome, yra tai, kad norime turėti apibrėžtus ar sankcionuotus terminus, o verslo žodynėlyje akivaizdu, kad jų norime. Verslo žodynėlyje taip pat leidžiame pateikti nuorodas į sinonimus, taigi jūs galite pasakyti, štai mano terminas, bet taip pat galite apibrėžti, kas yra visi tų sinonimai.
Dabar, be abejo, įdomus dalykas yra tai, kad pradėję ieškoti šio plataus duomenų kraštovaizdžio su visomis šiomis skirtingomis sistemomis, kurių jūs ten buvote, jūs negalite tiesiog išeiti iš ten ir pakeisti atitinkamas lenteles ir tuos dalykus į atitinka tą įvardijimo standartą, nes tai gali būti jūsų įsigytas paketas, taigi jūs negalite kontroliuoti duomenų bazės keitimo ar nieko.
Tai, ką mes ten galėtume padaryti, be to, kad galime susieti žodynėlio apibrėžimus, yra per tuos visuotinius žemėlapius, apie kuriuos aš kalbėjau, ką mes darytume, ir tam tikras rekomenduojamas požiūris yra turėti visa apimantį loginį modelį, kuriame išdėstoma, kas šios skirtingos verslo koncepcijos yra tos, apie kurias jūs kalbate. Susiekite verslo žodynėlio terminus į tuos, o gražus dalykas yra tai, kad gavę šį konstrukciją, kuris reprezentuoja loginį subjektą, koks jis buvo, galite pradėti susieti iš to loginio subjekto su visais to loginio subjekto įgyvendinimais skirtingas sistemas.
Tada, kur jums reikia, galite pamatyti, oi, „asmuo“ šioje sistemoje vadinamas „darbuotoju“. Šioje kitoje sistemoje „atlyginimas“ čia vadinamas „darbo užmokesčiu“. Matydami tai, pamatysite visas skirtingas tų apraiškas, nes juos susiejote.
Erikas Mažasis: Gerai, puiku, taip, gavau. Ta prasme, ar galima sakyti, kad tai panašiai kaip kai kurie į objektą orientuoti požiūriai?
Ronas Huizenga: Šiek tiek. Tai šiek tiek intensyviau, nei, manau, galima sakyti. Aš turiu galvoje, kad jūs galėtumėte pasirinkti rankinį ryšį, pereiti ir tikrinti bei atlikti juos visus. Vienas dalykas, apie kurį nelabai turėjau progos pasikalbėti - nes vėlgi, mes turime labai daug galimybių - pačiame „Data Architect“ įrankyje taip pat turime visą automatikos sąsają. Ir makrokomandos galimybė, kuri iš tikrųjų yra programavimo kalba įrankyje. Taigi mes iš tikrųjų galime daryti tokius darbus, kaip rašyti makrokomandas, leisti tai uždaryti ir tardyti bei kurti nuorodas jums. Mes naudojame ją importuodami ir eksportuodami informaciją, galime ją naudoti keičiant dalykus arba pridedant atributus, įvykius, paremtus pačiame modelyje, arba galime naudoti jį paleisti paketus, kad iš tikrųjų išeitų ir tardytų dalykus bei iš tikrųjų apgyvendintų skirtingus konstrukcijas. modelis. Taigi yra visa automatikos sąsaja, kuria žmonės taip pat gali pasinaudoti. Tai būtų labai efektyvus būdas panaudoti universalius žemėlapius su tais.
Rebecca Jozwiak: Gerai, ačiū Ronui ir Ericai. Tai buvo puikūs klausimai. Aš žinau, kad bėgame šiek tiek anksčiau nei valandos viršūnė, bet aš norėčiau suteikti Malcolmui galimybę mesti keletą klausimų Rono būdu. Malcolmas?
Malcolmas Chisholmas: Ačiū, Rebeka. Taigi, Roni, tai labai įdomu, matau, kad čia yra labai daug galimybių. Viena iš sričių, kuri mane labai domina, tarkime, jei turime plėtros projektą, kaip jūs matote, kaip duomenų modeliuotojas naudojasi šiomis galimybėmis ir galbūt bendradarbiauja su verslo analitikais, su duomenų profiliuotoju, su duomenų kokybės analitiku, ir su verslo rėmėjais, kurie galiausiai bus atsakingi už faktinius informacijos reikalavimus projekte. Kaip, jūsų žiniomis, duomenų modeliuotojas iš tiesų padaro projektą efektyvesnį ir efektyvesnį, naudodamiesi mūsų galimybėmis?
Ronas Huizenga: Aš manau, kad vienas iš pirmųjų dalykų, kurį turite padaryti, yra duomenų modeliuotojas - ir aš neketinu pasirinkti kai kurių modeliuotojų, bet aš vis tiek tai padarysiu - ar kai kurie žmonės vis dar mano, kad duomenų modeliuotojas iš tikrųjų yra vartininkas, kurio vaidmuo yra panašus, mes apibrėžiame, kaip jis veikia, mes esame sargai, kurie įsitikina, kad viskas teisinga.
Dabar yra tam tikras aspektas, kad jūs turite įsitikinti, kad apibrėžiate patikimą duomenų architektūrą ir visa kita. Tačiau svarbesnis dalykas yra duomenų modeliuotojas - ir aš tai gana akivaizdžiai sužinojau konsultuodamasis - ar jūs turite tapti tarpininku, taigi jūs turite suburti šiuos žmones.
Tai nebebus dizainas iš anksto, generuokite ir kurkite duomenų bazes. Tai, ką turite padaryti, turite mokėti su visomis šiomis skirtingomis suinteresuotomis grupėmis, daryti tokius veiksmus kaip atvirkštinė inžinerija, importuoti informaciją, turėti kiti žmonės bendradarbiauja, nesvarbu, ar tai yra žodynėliuose, ar dokumentuose, viskas panašu - ir būkite tarpininku, kai galite tai pritraukti į saugyklą, susieti sąvokas saugykloje ir dirbti su tais žmonėmis.
Tai tikrai yra labiau bendradarbiavimo tipo aplinka, kai net apibrėždami užduotis ar net diskusijų gijas ar tokius dalykus, kuriuos turime komandos serveryje, žmonės iš tikrųjų gali bendradarbiauti, užduoti klausimus ir pasiekti galutinius galutinius produktus, kuriuos jie jų duomenų architektūros ir organizavimo poreikis. Ar toks atsakymas buvo?
Malcolmas Chisholmas: Taip, aš sutinku. Žinote, aš manau, kad palengvinimo įgūdžiai yra kažkas, ko iš tiesų labai reikia duomenų modeliuotojams. Sutinku, kad ne visada tai matome, bet manau, kad to reikia, ir siūlyčiau, kad kartais yra tendencija likti jūsų kampe atliekant jūsų duomenų modeliavimą, tačiau jums tikrai reikia būti ten, dirbant su kitomis suinteresuotomis grupėmis. arba tiesiog nesuprantate duomenų aplinkos, su kuria susiduriate, ir aš manau, kad dėl to modelis kenčia. Bet tai tik mano nuomonė.
Ronas Huizenga: Ir tai yra įdomu, nes jūs jau paminėjote ką nors savo skaidrėje apie istoriją, kaip įmonės tarsi nusitraukia nuo IT, nes jos laiku nepateikė sprendimų ir tokio tipo daiktų.
Labai įdomu, kad vykdant vėlesnes konsultacijas, prieš tapdamas produkto vadovu, dauguma projektų, kuriuos įgyvendinau per pastaruosius dvejus metus prieš tai, buvo remiami versle, kur tikrai buvo verslas, kuris jį paskatino, ir duomenų architektai. modeliuotojai nebuvo IT dalis. Mes buvome verslo remiamos grupės dalis ir buvome kaip tarpininkai, dirbantys su likusiomis projekto komandomis.
Malcolmas Chisholmas: Taigi manau, kad tai labai įdomus dalykas. Aš manau, kad mes pradedame pastebėti pokyčius verslo pasaulyje, kuriame verslas prašo ar galvoja, gal ne tiek apie tai, ką darau, tiek, kiek vyksta procesas, bet jie taip pat pradeda galvoti apie tai, kas yra duomenys su kuriais dirbu, kokie mano duomenų poreikiai, kokie duomenys yra tvarkomi kaip duomenys ir kokiu mastu galime gauti IDERA produktus ir galimybes palaikyti tą požiūrį, ir aš manau, kad verslo poreikiai, net nors tai vis dar šiek tiek atsirandantis.
Ronas Huizenga: Aš sutinku su jumis ir manau, kad mes matome, kad jis eina vis labiau ir labiau tuo keliu. Mes matėme pabudimą ir jūs jau anksčiau apie tai kalbėjote dėl duomenų svarbos. Mes matėme duomenų svarbą ankstyvoje IT ar duomenų bazių raidoje, tada, kaip jūs sakote, mes tarsi įsitraukėme į visą šio proceso valdymo ciklą - ir procesas yra nepaprastai svarbus, nesupraskite manęs neteisingai - bet dabar kas atsitiko kai tai atsitiko, duomenys prarado dėmesį.
Ir dabar organizacijos supranta, kad svarbiausias dalykas yra duomenys. Duomenys atspindi viską, ką darome savo versle, todėl turime įsitikinti, kad turime tikslius duomenis, kad galime rasti teisingą informaciją, kuri mums reikalinga priimant sprendimus. Nes ne viskas kyla iš apibrėžto proceso. Dalis informacijos yra šalutinis kitų dalykų šaltinis, ir mes vis tiek turime sugebėti ją rasti, žinoti, ką ji reiškia, ir sugebėti turimus duomenis išversti į žinias, kurias galėtume panaudoti geriau verslui palaikyti.
Malcolmas Chisholmas: Teisinga, ir dabar dar viena sritis, su kuria aš kovoju, yra tai, ką aš pavadinčiau duomenų gyvavimo ciklu, tai yra, žinote, jei mes pažvelgtume į tai, kokia duomenų tiekimo grandinė eina per įmonę, mes pradėtume nuo duomenų rinkimas ar duomenų rinkimas, kuris gali būti duomenų įvedimas, tačiau taip pat gali būti, kad duomenis iš įmonės tiekėjų gaunu iš įmonės ribų.
Tada, rinkdami duomenis, pereiname prie duomenų priežiūros, kur galvoju apie šių duomenų standartizavimą ir gabenimą į vietas, kur jų reikia. Tada naudodamiesi duomenimis, faktiniais taškais, kur yra duomenys, gausite naudos iš duomenų.
Ir senais laikais visa tai buvo daroma pagal individualų stilių, tačiau šiandien tai gali būti, pavyzdžiui, analitinė aplinka, o paskui - archyvas, parduotuvė, kur mes įdedame duomenis, kai nebetinkame. reikia to ir pagaliau išgryninimo tipo procesą. Kaip, jūsų nuomone, duomenų modeliavimas tinka viso šio duomenų gyvavimo ciklo valdymui?
Ronas Huizenga: Tai labai geras klausimas ir vienas dalykas, kurio aš iš tikrųjų šiandien neturėjau laiko įsigilinti į jokias detales, yra tai, apie ką mes iš tikrųjų pradedame kalbėti, yra duomenų linija. Taigi, ką mes iš tikrųjų galime padaryti, yra tai, kad savo įrankiuose turime duomenų linijų pajėgumą ir, kaip aš sakau, mes iš tikrųjų galime kai kuriuos iš jų išgauti iš ETL įrankių, bet jūs taip pat galite jį susieti, tik brėždami liniją. Bet kurį iš šių duomenų modelių ar duomenų bazių, kuriuos mes užfiksavome ir įtraukėme į modelius, galėtume remtis konstruktais, pateiktais duomenų linijos schemoje.
Ką mes galime padaryti, tai surinkti duomenų srautą, kaip jūs sakote, nuo šaltinio iki tikslo ir per visą gyvenimo ciklą, kaip tie duomenys perduodami per skirtingas sistemas ir ką rasite, imkime darbuotojus 'duomenys - tai vienas iš mano mėgstamiausių remiantis projektu, kurį įgyvendinau prieš kelerius metus. Aš dirbau su organizacija, kuri turėjo darbuotojų duomenis 30 skirtingų sistemų. Tai, ką mes ten padarėme - ir Rebecca iškėlė duomenų duomenų skaidrę, čia yra gana supaprastinta duomenų linija, tačiau mes sugebėjome įnešti visas duomenų struktūras, nurodyti jas diagramoje ir tada mes iš tikrųjų gali pradėti ieškoti, kokie yra srautai tarp ir kaip tie skirtingi duomenų subjektai yra susieti sraute? Ir mes taip pat galime tai peržengti. Tai yra duomenų srauto arba linijos schemos, kurią mes matome čia, dalis. Jei norite peržengti tai, mes taip pat turime šio rinkinio verslo architekto dalį ir ten galioja tas pats.
Bet kuri iš duomenų struktūrų, kurias mes užfiksavome duomenų modeliavimo aplinkoje, gali būti nurodoma verslo modeliavimo įrankyje, kad net savo verslo modelio schemose ar verslo proceso schemose galėtumėte nurodyti atskiras duomenų saugyklas, jei norite, kad jų neliktų. duomenų modeliavimo aplinką, o jūs juos naudojate savo verslo proceso modelio aplankuose, taip pat netgi galite nurodyti CRUD, apie tai, kaip ta informacija sunaudojama ar kuriama, tada galime pradėti kurti tokie dalykai kaip poveikio ir analizės ataskaitos bei diagramos.
Tai, ko siekiame pasiekti, ir jau turime labai daug galimybių, tačiau vienas iš dalykų, kuriuos mes turime, yra tarsi saugykla, į kurią žiūrime, nes toliau tobuliname savo įrankius, geba nubrėžti tą galo, organizacijos duomenų liniją ir visą duomenų gyvavimo ciklą.
Malcolmas Chisholmas: Gerai. Rebeka, ar man leidžiama dar viena?
Rebecca Jozwiak: Aš leisiu jums dar vieną, Malcolmai, pirmyn.
Malcolmas Chisholmas: Labai ačiū. Galvodami apie duomenų valdymą ir galvodami apie duomenų modeliavimą, kaip priversti šias dvi grupes efektyviai dirbti kartu ir suprasti viena kitą?
Erikas Mažasis: Na, įdomu, manau, kad tai tikrai priklauso nuo organizacijos, ir grįžtama prie mano ankstesnės idėjos, kad tose organizacijose, kuriose iniciatyvos buvo skatinamos verslo, mes buvome susieti. Pavyzdžiui, aš vadovavau duomenų architektūrai. komanda, bet mes buvome susieti su verslo vartotojais ir mes iš tikrųjų padėjome jiems sukurti savo duomenų valdymo programą. Vėlgi, tai labiau konsultacinis požiūris, bet tai tikrai daugiau kaip verslo funkcija.
Tai, ko jums tikrai reikia, kad tai būtų, jums reikia duomenų modeliuotojų ir architektų, kurie iš tikrųjų supranta verslą, gali būti susieti su verslo vartotojais ir tada padėjo jiems atsistoti aplink vykstančius valdymo procesus. Verslas nori tai padaryti, bet paprastai kalbant, mes turime žinių apie technologijas, kad galėtume padėti jiems išsiskirti iš tokio tipo programų. Tai tikrai turi būti bendradarbiavimas, tačiau tai turi priklausyti verslui.
Malcolmas Chisholmas: Gerai, kad puiku. Ačiū.
Dr Ericas Little: Gerai.
Rebecca Jozwiak: Gerai, labai ačiū. Klausytojų nariai, bijau, kad nesigilinome į jūsų klausimus, tačiau įsitikinsiu, kad jie bus persiųsti tinkamam svečiui, kurį šiandien turėjome linijoje. Noriu labai padėkoti Erikui, Malcolmui ir Ronui už tai, kad jie šiandien buvo mūsų svečiai. Tai buvo puikūs dalykai, žmonės. Jei jums patiko šiandienos „IDERA“ internetinė transliacija, „IDERA“ kitą trečiadienį taip pat dalyvaus „Hot Technologies“ laidoje, jei norite prisijungti, aptardama indeksavimo ir „Oracles“ iššūkius, taigi, dar viena žavi tema.
Labai ačiū, žmonės, rūpinkitės ir mes susitiksime kitą kartą. Iki.
