Izņemšana: Uzņēmēja Rebeka Jozvejaka pārrunā datu arhitektūras risinājumus ar Ēriku Magu no OSTHUS, Malkolmu Čišolmu no pirmā Sanfrancisko partnera un Ronu Huizengu no IDERA.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Rebeka Jozwiak: Dāmas un kungi, sveicināti un laipni gaidīti 2016. gada karstajā tehnoloģijā. Šodien mēs apspriežam karstu tēmu - “Uz uzņēmējdarbību balstītas datu arhitektūras veidošana”. Mans vārds ir Rebeka Jozvejaka, es būšu jūsu šodienas tīmekļa apraides vietne. Mēs strādājam ar čivināšanu ar # HotTech16 ar atsauci, tāpēc, ja jūs jau esat tajā, lūdzu, jūtieties brīvi pievienoties arī tam. Ja jums ir jautājumi jebkurā laikā, lūdzu, ievadiet tos jautājumu un atbilžu rūtī ekrāna apakšējā labajā stūrī, un mēs pārliecināsimies, ka uz viņiem tiks atbildēts. Ja nē, mēs pārliecināsimies, ka mūsu viesi tos saņems jums.
Tāpēc šodien mums ir patiešām aizraujošs sastāvs. Mūsdienās ir daudz smagu sitienu. Mums ir Ēriks Mazais, OSTHUS datu zinātnes viceprezidents. Mums ir Malcolm Chisholm, galvenais inovāciju darbinieks, un tas ir patiešām foršs tituls uzņēmumam First San Francisco Partners. Un mums ir IDERA vecākais produktu menedžeris Rons Huizenga. Un, jūs zināt, IDERA ir patiešām pilns datu pārvaldības un modelēšanas risinājumu komplekts. Un šodien viņš mums parādīs demonstrāciju par viņa risinājuma darbību. Bet, pirms mēs nonākam pie tā, Ēriks Mazais, es tev nodosīšu bumbu.
Ēriks Mazais: Labi, liels paldies. Tāpēc es šeit apskatīšu pāris tēmas, kuras, manuprāt, nedaudz saistīs ar Rona sarunu, un, cerams, iestatīšu scenāriju arī dažām no šīm tēmām, dažām Q&A.
Tāpēc tas, kas mani ieinteresēja IDERA darbībā, ir tas, ka es domāju, ka viņi pareizi norāda, ka mūsdienās sarežģītā vide patiešām veicina ļoti daudz biznesa vērtību. Un ar sarežģītām vidēm mēs domājam sarežģītas datu vides. Un tehnoloģijas patiešām strauji virzās uz priekšu, un mūsdienu biznesa vidē ir grūti sekot līdzi. Tātad tie cilvēki, kuri strādā tehnoloģiju telpā, bieži redzēs, ka jums ir klienti, kuri strādā ar problēmām: “Kā es varu izmantot lielos datus? Kā iekļaut semantiku? Kā es varu sasaistīt dažus no šiem jaunajiem materiāliem ar vecākajiem datiem? ”Un tā tālāk, un tas mūs mūs ved uz četriem lielajiem datiem, kurus daudzi cilvēki ir diezgan labi iepazinuši, un es saprotu, ka to var būt vairāk nekā četri dažreiz - esmu redzējis pat astoņus vai deviņus -, bet parasti, kad cilvēki runā par tādām lietām kā lieli dati vai ja jūs runājat par lieliem datiem, parasti jūs skatāties kaut ko tādu, kas ir sava veida uzņēmums. Un tāpēc cilvēki teiks: labi, labi, padomājiet par jūsu datu apjomu, kam parasti tiek pievērsta uzmanība - tas ir tieši tas, cik daudz jums ir. Datu ātrums ir saistīts ar to, cik ātri es varu tos pārvietot, vai arī cik ātri es varu tos vaicāt, vai saņemt atbildes utt. Un personīgi es domāju, ka tā kreisā puse ir kaut kas tāds, kas tiek risināts un salīdzinoši ātri apstrādāts ar daudzām un dažādām pieejām. Bet labajā pusē es redzu daudz spēju uzlabot un daudz jaunu tehnoloģiju, kas patiešām nāk priekšplānā. Un tas tiešām ir saistīts ar trešo kolonnu, datu dažādību.
Citiem vārdiem sakot, vairums uzņēmumu mūsdienās skatās uz strukturētiem, daļēji strukturētiem un nestrukturētiem datiem. Attēlu dati sāk kļūt par karstu tematu, tāpēc, lai varētu izmantot datora redzējumu, aplūkot pikseļus, spēt nokasīt, NLP, entītiju ekstrahēšanu, jums ir grafika informācija, kas nāk no vai nu no statistiskajiem modeļiem, vai arī no semantiskajiem modeļiem. , jums ir relāciju dati, kas pastāv tabulās utt. Visu šo datu apvienošana un visi šie dažādie veidi ir patiešām liels izaicinājums, un jūs redzēsit to Gartnerā un citos cilvēkos, kuri seko nozares tendencēm.
Un tad pēdējā lieta, par kuru cilvēki runā lielos datos, bieži ir šis neprecizitātes jēdziens, kas patiesībā ir jūsu datu nenoteiktība, tā izplūdums. Cik labi jūs zināt, par ko ir jūsu dati, cik labi jūs saprotat, kas tur atrodas, un, vai jūs zināt? Tajā var būt vērtīga spēja izmantot statistiku un spēja izmantot dažāda veida informāciju ap to, ko jūs varētu zināt, vai izmantot kādu mīnusu. Tātad spēja šādā veidā aplūkot datus, ņemot vērā to, cik daudz jums ir, cik ātri jums tas jāpārvieto vai jāapgūst, visu veidu dati, kas jums var būt jūsu uzņēmumā, un cik pārliecināts par to, kur atrodaties. tas ir, kas tas ir, kādā kvalitātē tas atrodas utt. Tas tiešām prasa lielus, koordinētus pūliņus, kas tagad notiek starp daudzām personām, lai efektīvi pārvaldītu savus datus. Tādēļ mūsdienu pasaulē arvien lielāka nozīme ir datu modelēšanai. Tik labi datu modeļi patiešām veicina daudzus panākumus uzņēmumu lietojumprogrammās.
Jums ir datu avoti no dažādiem avotiem, piemēram, kā mēs teicām, un tas tiešām prasa daudz dažādu integrācijas veidu. Tāpēc to visu apkopot ir patiešām noderīgi, lai varētu izpildīt vaicājumus, piemēram, daudzos datu avotos, un atgūt informāciju. Bet, lai to izdarītu, jums ir vajadzīgas labas kartēšanas stratēģijas, tāpēc šāda veida datu kartēšana un sekošana šīm kartēm var būt īsts izaicinājums. Un tad jums ir šis jautājums, kā es varu saistīt savus mantotos datus ar visiem šiem jaunajiem datu avotiem? Tātad, pieņemsim, ka man ir grafiks, vai es ņemu visus savus relāciju datus un ievietoju tos diagrammā? Parasti tā nav laba ideja. Tātad, kā tas ir, ka cilvēki spēj pārvaldīt visus šāda veida datu modeļus, kas notiek? Analīze tiešām jāveic daudziem šiem dažādajiem datu avotiem un kombinācijām. Tāpēc kritiskās ir atbildes, kas no tā izriet, un atbildes, kas cilvēkiem ir vajadzīgas, lai patiešām pieņemtu labus biznesa lēmumus.
Tātad tas nav saistīts tikai ar ēku celtniecību tehnoloģiju labad, tas tiešām ir tas, ko es izdarīšu, ko es ar to varu izdarīt, kāda veida analīzi es varu veikt, un tāpēc arī iespējām, kā es jau esmu Es runāju par to, ka apkopot šo lietu, integrēt to ir patiešām, ļoti svarīgi. Un viens no šiem analīzes veidiem tiek veikts tādās lietās kā apvienota meklēšana un vaicājumi. Tas patiešām kļūst par obligātu lietu. Jūsu vaicājumiem parasti ir jābūt savstarpēji saistītiem ar vairāku veidu avotiem, un informācija ir jāuztic atpakaļ.
Viens no galvenajiem elementiem, kas bieži, it īpaši cilvēki, pievērsīsies tādām svarīgām lietām kā semantiskās tehnoloģijas - un tas ir kaut kas, par ko es ceru, ka Rons mazliet runās IDERA pieejā -, ir tas, kā jūs atdalāt vai pārvaldāt jūsu datu modeļa slānis no paša datu slāņa, no šiem neapstrādātiem datiem? Tātad datu slānī, iespējams, ir datu bāzes, jums var būt dokumentu dati, jums var būt izklājlapu dati, jums var būt attēlu dati. Ja atrodaties tādās jomās kā farmācijas rūpniecība, esat ieguvis lielu daudzumu zinātnisko datu. Pēc tam cilvēki parasti meklē veidu, kā izveidot modeli, kas viņiem ļauj ātri integrēt šos datus, un patiesībā, kad jūs meklējat datus tagad, jūs nevēlaties visus datus ievilkt modeļa slānī. , ko jūs skatāties uz modeļa slāni, kas jādara, ir sniegt jums jauku loģisku priekšstatu par lietām, kopīgu vārdnīcu, kopīgu entitāšu un attiecību tipiem un iespēju reāli iekļūt datos, kur tas atrodas. Tāpēc tai ir jāsaka, kas tas ir, un tai, kur tā atrodas, un jāsaka, kā to atnest un atgriezt.
Tātad šī ir bijusi pieeja, kas ir bijusi diezgan veiksmīga, virzot uz priekšu semantiskās tehnoloģijas, kas ir joma, kurā es daudz strādāju. Tāpēc jautājums, kuru es gribēju uzdot Ronam un kurš, manuprāt, būs noderīgs jautājumu un atbilžu sadaļā, ir redzēt, kā to panāk IDERA platforma? Tātad modeļa slānis faktiski ir nodalīts no datu slāņa? Vai viņi ir vairāk integrēti? Kā tas darbojas, un kādi ir rezultāti un ieguvumi, ko viņi redz no savas pieejas? Tāpēc atsauces dati patiešām kļūst arī kritiski. Tātad, ja jums būs šāda veida datu modeļi, ja jums būs iespēja apvienoties un meklēt dažādas lietas, jums tiešām ir jābūt labiem atsauces datiem. Bet problēma ir atsauces dati, kurus var būt patiešām grūti uzturēt. Tāpēc nereti standartu nosaukšana pati par sevi ir grūts izaicinājums. Viena grupa sauks kaut ko X, bet otra grupa sauks kaut ko Y, un tagad jums rodas problēma, kā kāds atrod X un Y, kad meklē šāda veida informāciju? Tā kā jūs nevēlaties viņiem dot tikai daļu no datiem, vēlaties viņiem sniegt visu saistīto. Tajā pašā laikā mainās termini, programmatūra tiek novecojusi utt., Kā jūs laika gaitā sekojat un uzturējat šos atsauces datus?
Un atkal, semantiskās tehnoloģijas, īpaši izmantojot tādas lietas kā taksonomijas un vārdnīcas, datu vārdnīcas, ir nodrošinājušas standarta kosmosa veidu, kā to izdarīt, kas ir patiešām ļoti spēcīgs, tas izmanto noteikta veida standartus, bet datu bāzu kopiena to ir izdarījusi arī ilgu laiku, tikai dažādos veidos. Es domāju, ka viens no galvenajiem jautājumiem šeit ir domāt par to, kā izmantot, iespējams, entitāšu attiecību modeļus, kā izmantot varbūt grafikas modeļus vai kāda veida pieeju šeit, kas patiešām jums, cerams, sniegs standarta atstatuma veidu, kā rīkoties ar jūsu atsauces datiem. Un tad, protams, tiklīdz jums ir atsauces dati, kartēšanas stratēģijām jāpārvalda visdažādākie nosaukumi un entītijas. Tāpēc priekšmetu ekspertiem bieži patīk lietot savus terminus.
Tāpēc izaicinājums vienmēr ir tas, kā jūs kādam sniedzat informāciju, bet padarāt to atbilstošu tam, kā viņi par to runā? Tātad vienai grupai var būt viens veids, kā kaut ko apskatīt, piemēram, jūs varat būt ķīmiķis, kurš strādā pie narkotikām, un jūs varat būt struktūras biologs, kurš strādā pie vienas un tās pašas zāles, un jums var būt atšķirīgi nosaukumi vienāda veida entītijām. kas attiecas uz jūsu jomu. Jums ir jāizdomā veidi, kā apvienot personalizēto terminoloģiju, jo cita pieeja ir tā, ka jums ir jāpiespiež cilvēki atteikties no sava termiņa un izmantot kāda cita vārdu, kas viņiem bieži nepatīk. Vēl viens punkts šeit ir grūts, lai apstrādātu lielu skaitu sinonīmu, tāpēc daudzu cilvēku datos ir daudz dažādu vārdu, kas var atsaukties uz vienu un to pašu. Jums ir atsauces problēma, izmantojot daudzpusīgu attiecību kopumu. Specializētie termini dažādās nozarēs ir atšķirīgi, tāpēc, ja jūs nāksiet klajā ar visaptverošu risinājumu šāda veida datu pārvaldībai, cik viegli tas ir pārnēsājams no viena projekta vai no viena pieteikuma uz otru? Tas var būt vēl viens izaicinājums.
Automatizācija ir svarīga, un tā ir arī izaicinājums. Atsauces datu manuāla apstrāde ir dārga. Ir dārgi, ja manuāli jāveic kartēšana, un ir dārgi, ja priekšmetu eksperti pārtrauc ikdienas darbu un ir jāiet iekšā un pastāvīgi jālabo datu vārdnīcas un atkārtoti jāatjaunina definīcijas utt., Un tā tālāk. Atkārtojamās vārdnīcas tiešām parāda daudz vērtības. Tā bieži ir vārdu krājums, kuru jūs varat atrast ārpus savas organizācijas. Piemēram, ja jūs strādājat ar jēlnaftu, būs noteikta veida vārdnīcas, kuras varat aizņemties no atvērtā koda, tāpat kā ar farmācijas līdzekļiem, tāpat kā ar banku nozari un finanšu, tāpat kā ar daudzām šāda veida jomām. Cilvēki izlaiž atkārtoti lietojamas, vispārīgas un atkārtojamas vārdnīcas, kuras cilvēki var izmantot.
Un atkal, apskatot IDERA rīku, man ir interese uzzināt, kā viņi rīkojas ar šo, izmantojot dažāda veida standartus. Semantikas pasaulē jūs bieži redzat tādas lietas kā SKOS modeļi, kas nodrošina standartus vismaz plašākām / šaurākām nekā attiecībām, un šīs lietas var būt grūti izdarīt ER modeļos, bet, jūs zināt, nav neiespējami, tas vienkārši ir atkarīgs no tā, cik daudz no tā mašīnas un to savienošanu, ar kuru jūs varat rīkoties šāda veida sistēmās.
Visbeidzot, es gribēju tikai salīdzināt ar dažiem semantiskajiem dzinējiem, kurus es redzu šajā nozarē, un palūdziet Ronam un nedaudz pamudināt viņu, lai runātu par to, kā IDERA sistēma ir izmantota kopā ar visām semantiskajām tehnoloģijām.Vai to var integrēt ar trīskāršajiem veikaliem, grafu datu bāzēm? Cik viegli ir izmantot ārējos avotus, jo šāda veida lietas semantiskajā pasaulē bieži var aizņemties, izmantojot SPARQL parametrus? Jūs varat importēt RDF vai OWL modeļus tieši savā modelī - atsaukties uz tiem - tā, piemēram, gēnu ontoloģija vai olbaltumvielu ontoloģija, kas var dzīvot kaut kur savā telpā ar savu pārvaldības struktūru, un es varu vienkārši importēt visus vai daļēji tāpēc, ka man tas ir vajadzīgs savos modeļos. Un man ir interese uzzināt, kā IDERA risina šo jautājumu. Vai jums viss ir jāuztur iekšēji, vai ir kādi veidi, kā izmantot cita veida standartizētus modeļus un tos ievilkt, un kā tas darbojas? Un pēdējais, ko es šeit pieminēju, ir tas, cik daudz manuāla darba patiešām ir saistīts ar glosāriju un metadatu krātuvju izveidi?
Tāpēc es zinu, ka Rons mums parādīs dažas demonstrācijas par šāda veida lietām, kas būs patiešām interesantas. Bet problēmas, kuras es bieži saskatu konsultējoties ar klientiem, ir tas, ka ļoti daudz kļūdu rodas, ja cilvēki raksta paši savām definīcijām vai saviem metadatiem. Tātad jūs saņemat kļūdas, kā arī kļūdas pirkstos, tā ir viena lieta. Jūs saņemat arī cilvēkus, kuri kaut ko ņem no, jūs zināt, tikai no Wikipedia vai avota, kura ne vienmēr ir tāda kvalitāte, kādu jūs varētu vēlēties definīcijā, vai arī jūsu definīcija ir tikai no viena cilvēka viedokļa, tāpēc tā nav pilnīga, un tad nav skaidra kā darbojas pārvaldības process. Pārvaldība, protams, ir ļoti, ļoti liels jautājums, kad runājat par atsauces datiem un katru reizi, kad runājat par to, kā tas varētu ietilpt kāda cilvēka galvenajos datos, kā viņi izmantos savus metadatus un utt.
Tāpēc es tikai gribēju dažus no šiem tematiem izvietot. Šīs ir lietas, kuras es redzu biznesa telpā daudz dažādu veidu konsultāciju jomā un daudz dažādās jomās, un es tiešām esmu ieinteresēts redzēt, ko Rons mums parādīs ar IDERA, lai norādītu uz dažām no šīm tēmām . Tāpēc liels paldies.
Rebeka Jozwiak: Liels paldies, Ēriks, un man ļoti patīk jūsu komentārs, ka daudzas kļūdas var rasties, ja cilvēki raksta savas definīcijas vai metadatus. Es zinu, ka žurnālistikas pasaulē ir tāda mantrācija, ka “daudzas acis pieļauj maz kļūdu”, bet, kad runa ir par praktisku pielietojumu, pārāk daudz roku sīkdatņu burkā mēdz atstāt jūs ar daudziem salauztiem sīkdatnēm, vai ne?
Ēriks Mazais: Jā, un baktērijas.
Rebeka Jozwiak: Jā. Ar to es došos uz priekšu un nodošu to Malcolm Chisholm. Malkolm, grīda ir tava.
Malkolms Čišolms: Liels paldies, Rebeka. Es gribētu mazliet paskatīties uz to, ko Ēriks runā, un papildināt ar dažiem novērojumiem, uz kuriem, jūs zināt, Rons varētu vēlēties reaģēt arī, runājot par “Ceļā uz uzņēmējdarbību balstītu datu arhitektūru”. ”- ko nozīmē būt biznesam virzītam un kāpēc tas ir svarīgi? Vai arī tā ir tikai kāda veida hipe? Es nedomāju, ka tā ir.
Ja mēs paskatāmies uz notiekošo kopš tā laika, jūs zināt, lieldatoru datori uzņēmumiem šodien bija kļuvuši pieejami - teiksim, ap 1964. gadu -, mēs redzam, ka ir notikušas daudz izmaiņu. Un šīs izmaiņas es apkopotu kā pāreju no centrētības uz procesu uz datiem. Un tas ir tas, kas padara biznesa virzītu datu arhitektūru tik nozīmīgu un tik būtisku mūsdienām. Un es domāju, ka, jūs zināt, tas nav tikai burvju vārds, tas ir kaut kas absolūti reāls.
Bet mēs to varam novērtēt mazliet vairāk, ja ienirstam vēsturē, tāpēc, dodoties atpakaļ laikā, atpakaļ uz pagājušā gadsimta 60. gadiem un kādu laiku pēc tam, dominēja lieldatori. Pēc tam tie aizvietoja personālos datorus, kur jūs faktiski bijāt saceljušies no lietotājiem, kad ienāca personālie datori. Sacelšanās pret centralizētu IT, kas, viņuprāt, neizpildīja viņu vajadzības, nebija pietiekami veikla. Tas ātri radīja sadalītu skaitļošanu, kad personālie datori bija savienoti. Un tad sāka parādīties internets, kas izjauca uzņēmuma robežas - tas tagad varēja mijiedarboties ar partijām, kas atrodas ārpus sevis, attiecībā uz datu apmaiņu, kas iepriekš nebija noticis. Un tagad mēs esam nonākuši mākoņu un lielo datu laikmetā, kur mākonis ir platformas, kas patiešām izmanto infrastruktūru, un tāpēc mēs it kā atstājam IT vajadzību vadīt lielus datu centrus, jo, ziniet, mēs Mēs esam ieguvuši mākoņu ietilpību, kas mums ir pieejama, un vienlaikus ar tiem lielajiem datiem, kurus Ēriks, jūs zināt, ir tik daiļrunīgi apspriedis. Un kopumā, kā mēs redzam, kad notika tehnoloģiju maiņa, tā ir kļuvusi orientētāka uz datiem, mums rūp vairāk dati. Tāpat kā ar internetu, arī tas, kā notiek datu apmaiņa. Ja ir lieli dati, četri vai vairāk datu ir v.
Tajā pašā laikā, iespējams, vēl svarīgāk, biznesa izmantošanas gadījumi mainījās. Kad datori pirmo reizi tika ieviesti, tie tika izmantoti, lai automatizētu tādas lietas kā grāmatas un ierakstus. Un jebkas, kas bija manuāls process, iesaistot virsgrāmatas vai tamlīdzīgas lietas, būtībā tika ieprogrammēts mājā. 80. gados tas mainījās uz operatīvo pakešu pieejamību. Jums vairs nevajadzēja rakstīt savu algas lapu, jūs varētu iegādāties kaut ko tādu, kas to izdarīja. Tā rezultātā daudzos IT departamentos toreiz tika samazināts vai pārstrukturēts. Bet tad parādījās biznesa informācija, piemēram, datu noliktavas, galvenokārt 90. gados. Sekoja dotcom biznesa modeļi, kas, protams, bija liels neprāts. Tad MDM. Izmantojot MDM, jūs sākat redzēt, ka mēs domājam nevis par automatizāciju; mēs faktiski koncentrējamies tikai uz datu kā datu uzkrāšanu. Un tad analītika, kas atspoguļo vērtību, kuru varat iegūt no datiem. Analītikā jūs redzat ļoti veiksmīgus uzņēmumus, kuru pamatdarbības modelis balstās uz datiem. Google būtu daļa no tā, bet jūs varētu arī apgalvot, ka Walmart ir tāds.
Un tāpēc bizness tagad patiešām domā par datiem. Kā mēs varam iegūt vērtību no datiem? Kā dati var virzīt biznesu, stratēģiju, un mēs esam datu zelta laikmetā. Tātad, kas notiek attiecībā uz mūsu datu arhitektūru, ja datus vairs neuzskata par vienkārši izplūdi, kas rodas lietojumprogrammu aizmugurē, bet kas patiešām ir mūsu biznesa modeļu centrā? Daļa no problēmas, kas mums rodas IT sasniegšanā, patiešām ir iestrēdzis pagātnē sistēmu attīstības dzīves ciklā, kas bija sekas tam, ka IT agrīnajā vecumā bija ātri jātiek galā ar šo procesu automatizācijas posmu un jāstrādā projekti ir līdzīga lieta. IT jomā - un tas ir mazliet karikatūra -, bet es cenšos pateikt, ka daži no šķēršļiem, kas traucē iegūt uz biznesu balstītu datu arhitektūru, ir tāpēc, ka mēs savā ziņā esam nekritiski pieņēmuši IT kultūru. kas rodas no kādreizējā vecuma.
Tātad viss ir projekts. Sīkāk pastāstiet man par savām prasībām. Ja lietas nedarbojas, tas ir tāpēc, ka jūs nepateicāt man savas prasības. Tas nedarbojas šodien ar datiem, jo mēs neuzsākam ar neautomatizētiem manuāliem procesiem vai, zināt, biznesa procesu tehnisku pārveidošanu, mēs ļoti bieži sākam ar jau esošiem ražošanas datiem, kurus mēs cenšamies iegūt vērtību no. Bet neviens, kurš sponsorē uz datiem orientētu projektu, patiesībā nesaprot šos datus. Mums jādara datu atklāšana, jādara avotu datu analīze. Un tas īsti nesakrīt ar sistēmu attīstību, jūs zināt - ūdenskritums, SDLC dzīves cikls - kuras veikls, es teiktu, ir sava veida labāka šīs versijas versija.
Un tas, kas tiek koncentrēts, ir tehnoloģija un funkcionalitāte, nevis dati. Piemēram, ja mēs testējam testēšanas fāzē, kāds tas parasti ir, vai mana funkcionalitāte darbojas, pieņemsim, teiksim, mans ETL, bet mēs datus nepārbaudām. Mēs nepārbaudam savus pieņēmumus par avota datu ienākšanu. Ja mēs to darītu, mēs būtu varbūt labākā formā, un es to novērtētu kā personu, kas ir veikusi datu noliktavu projektus un cietusi no augšupējām izmaiņām, pārraujot manus ETL. Un faktiski tas, ko mēs vēlamies redzēt, ir pārbaude kā provizorisks solis nepārtrauktai produkcijas datu kvalitātes uzraudzībai. Tāpēc mums ir daudz attieksmes, kad ir grūti sasniegt uz uzņēmējdarbību balstītu datu arhitektūru, jo mūs ietekmē processorientācijas laikmets. Mums jāveic pāreja uz datu orientētību. Un tā nav pilnīga pāreja, jūs zināt, vēl joprojām ir jāveic daudz procesu, taču patiesībā mēs nedomājam uz datiem orientētā izteiksmē, kad tas mums vajadzīgs, un apstākļiem, kas rodas, kad mēs patiešām esam pienākums to darīt.
Tagad bizness apzinās datu vērtību, viņi vēlas tos atbloķēt, kā tad mēs to darīsim? Tātad, kā mēs veicam pāreju? Dati ir attīstības procesu centrā. Un mēs ļaujam biznesam vadīties pēc informācijas prasībām. Un mēs saprotam, ka projekta sākumā neviens nesaprot esošos avota datus. Varētu apgalvot, ka datu struktūra un paši dati tur nokļuva attiecīgi caur IT un operācijām, tāpēc mums tas jāzina, bet patiesībā tā nav. Šī ir uz datiem orientēta attīstība. Tāpēc mums, domājot par to, kur mēs atrodamies un kā mēs modelējam datus orientētā pasaulē, mums ir jābūt atgriezeniskās saites cilpām lietotājiem, lai uzlabotu viņu informācijas prasības, jo mēs veicam datu atklāšanu un datu profilēšanu , ir paredzēta avota datu analīze, un, pakāpeniski iegūstot arvien lielāku pārliecību par saviem datiem. Un tagad es runāju par tradicionālāku projektu, piemēram, MDM centru vai datu noliktavu, ne vienmēr par lielajiem projektiem, kaut arī es joprojām uzskatu, ka tas ir diezgan tuvu tam. Tātad, jūs zināt, ka tajās atgriezeniskās saites ķēdēs ietilpst datu modelētāji, pakāpeniski attīstot savu datu modeli un mijiedarbojoties ar lietotājiem, lai pārliecinātos, ka informācijas prasības tiek uzlabotas, pamatojoties uz to, kas ir iespējams, kas ir pieejams, no avota datiem, jo viņi to labāk saprot, tāpēc tas vairs nav gadījums, kad datu modelis ir, vai nu tā tur nav, vai arī tas ir pilnībā izveidots, tas tiek pakāpeniski fokusēts.
Līdzīgi, vairāk nekā pagātnē, mums ir kvalitātes nodrošināšana, kad mēs izstrādājam noteikumus datu kvalitātes pārbaudei, lai pārliecinātos, ka dati atbilst parametriem, par kuriem mēs darām pieņēmumus. Ejot, Ēriks atsaucās uz izmaiņām atsauces datos, kas var notikt. Jūs nevēlaties, lai tas būtu kā pakārtots upuris, kas saistīts ar nepārvaldītām pārmaiņām šajā jomā, tāpēc kvalitātes nodrošināšanas noteikumi var nonākt pēcapstrādes, pastāvīgā datu kvalitātes uzraudzībā. Tātad jūs varat sākt redzēt, vai mēs koncentrēsimies uz datiem, kā uz datiem orientēta attīstība ir diezgan atšķirīga no funkcionalitātes balstītas SDLC un Agile. Un tad mums jāpievērš uzmanība arī biznesa uzskatiem. Mums ir - un tas atkal atkārto to, ko Ēriks teica - mums ir datu modelis, kas mūsu datu bāzei nosaka zilu datu stāstu, bet tajā pašā laikā mums ir vajadzīgi tie konceptuālie modeļi, tie biznesa viedokļi par datiem, kas tradicionāli nav veikti pagātne. Mēs dažreiz, es domāju, esam domājuši, ka datu modelis to visu var paveikt, bet mums ir jābūt konceptuālam skatam, semantikai un, izpētot datus, tie jāveido caur abstrakcijas slāni, kas datu glabāšanas modeli pārveido biznesā skats. Un atkal, viss, ko Ēriks runāja semantikas ziņā, kļūst svarīgs, lai to izdarītu, tāpēc mums faktiski ir papildu modelēšanas uzdevumi. Es domāju, ka tas, jūs zināt, ir interesanti, ja jūs esat parādījies rindās kā datu modelētājs, tāpat kā es, un atkal kaut kas jauns.
Visbeidzot es gribētu teikt, ka arī lielākajai arhitektūrai ir jāatspoguļo šī jaunā realitāte. Piemēram, tradicionālais klientu MDM ir tāds, labi, ļaujiet mūsu klientu datiem nokļūt centrā, kur mēs, jūs zināt, varam to saprast, ņemot vērā patiesi datu kvalitāti back office lietojumprogrammām. Kas no biznesa stratēģijas viedokļa ir īgņa. Tomēr šodien mēs aplūkojam klientu MDM centrmezglus, kuros ir papildu klientu profila dati, nevis tikai statiskie dati, kuriem patiesībā ir divvirzienu saskarne ar klienta lietojumprogrammām. Jā, viņi joprojām atbalsta biroja darbību, bet tagad mēs zinām arī par šo klientu izturēšanos. Tas ir dārgāk būvējams. Šo būvēt ir sarežģītāk. Bet tas ir biznesa virzīts tādā veidā, kāds nav tradicionālajam klientam MDM. Jūs meklējat orientāciju uz biznesu pret vienkāršākiem dizainparaugiem, kurus ir vieglāk ieviest, taču biznesam tas ir tas, ko viņi vēlas redzēt. Mēs patiešām esam jaunā laikmetā, un es domāju, ka ir vairāki līmeņi, uz kuriem mums jāreaģē uz biznesa vadīšanas datu arhitektūru, un es domāju, ka tas ir ļoti aizraujošs laiks, kad darīt lietas.
Tāpēc paldies, jums Rebeka.
Rebeka Jozwiak: Paldies Malcolm, un man ļoti patika tas, ko jūs teicāt par datu modeļiem, ir jāpamato biznesa uzskats, jo atšķirībā no tā, ko sakāt, kur IT tik ilgi turēja grožus un tas vairs nav tikai šis gadījums un ka kultūra ir jāpāriet. Es esmu diezgan pārliecināts, ka fonā bija suns, kurš tev 100% piekrita. Un ar to es nodošu bumbu Ronam. Es ļoti priecājos redzēt jūsu demonstrāciju. Ron, grīda ir tava.
Rons Huizenga: Liels paldies jums un pirms mēs iedziļināties tajā, es pārdomāšu dažus slaidus un pēc tam mazliet demonstrāciju, jo, kā uzsvēra Ēriks un Malkolms, šī ir ļoti plaša un dziļa tēma, un, ņemot vērā to, ko mēs Mēs runājam par šodien, mēs tikai nokasām tā virsmu, jo ir tik daudz aspektu un tik daudz lietu, kas mums patiešām ir jāapsver un jāskatās no biznesa balstītas arhitektūras. Un mūsu pieeja ir padarīt šo modeli patiesībā pamatotu un iegūt modeļiem patiesu vērtību, jo jūs tos varat izmantot gan kā saziņas līdzekli, gan kā slāni, lai iespējotu citas sistēmas. Neatkarīgi no tā, vai jūs veidojat uz pakalpojumiem orientētu arhitektūru vai veicat citas lietas, modelis patiešām kļūst par dzīvības spēku tam, kas notiek, ar visiem metadatiem ap to un datiem, kas jums ir jūsu biznesā.
Tomēr tas, par ko es gribu runāt, ir gandrīz spert soli atpakaļ, jo Malcolm bija pieskāries dažām vēsturēm, kā risinājumi ir attīstījušies, un šāda veida lietām. Viens veids, kā patiesi norādīt uz to, cik svarīga ir pareiza datu arhitektūra, ir lietošanas gadījums, ar kuru es ļoti bieži saskāros, konsultējoties pirms stāšanās produktu vadības lomā, un tas bija, es ieeju organizācijās. neatkarīgi no tā, vai viņi veic uzņēmējdarbības pārveidi vai vienkārši aizstāj kādas esošās sistēmas un šāda veida lietas, un ļoti ātri kļuva skaidrs, cik slikti organizācijas izprot viņu pašu datus. Ja jūs izvēlaties konkrētu lietošanas gadījumu, piemēram, šo, neatkarīgi no tā, vai esat konsultants, vai arī tas ir cilvēks, kurš tikko ir sācis darbu ar organizāciju, vai arī jūsu organizācija gadu gaitā ir izveidojusies, iegādājoties dažādus uzņēmumus, ar ko jūs beidzaties līdz ar to ir ļoti sarežģīta vide ļoti ātri, ar vairākām jaunām atšķirīgām tehnoloģijām, kā arī ar mantotajām tehnoloģijām, ERP risinājumiem un visu pārējo.
Tātad viena no lietām, ko mēs patiešām varam darīt ar savu modelēšanas pieeju, ir atbildēt uz jautājumu, kā man to visu saprast? Mēs patiešām varam sākt apkopot informāciju, tāpēc bizness var izmantot mūsu rīcībā esošo informāciju. Un rodas jautājums, kas mums tur ir, šajās vidēs? Kā es varu izmantot modeļus, lai izvadītu nepieciešamo informāciju un labāk saprastu šo informāciju? Un tad mums ir tradicionālie metadatu tipi visām dažādajām lietām, piemēram, relāciju datu modeļiem, un mēs esam pieraduši redzēt tādas lietas kā definīcijas un datu vārdnīcas, jūs zināt, datu tipus un šāda veida lietas. Bet kā ir ar papildu metadatiem, kurus vēlaties tvert, lai tiem patiešām piešķirtu vēl lielāku nozīmi? Piemēram, kuras entītijas patiešām ir kandidāti, kurām vajadzētu būt atsauces datu objektiem, kuriem vajadzētu būt galvenajiem datu pārvaldības objektiem un šāda veida lietām, un sasaistīt tās. Un kā informācija plūst caur organizāciju? Dati plūst no tā, kā tie tiek patērēti, gan no procesa viedokļa, gan arī no datu līnijas attiecībā uz informācijas pārvietošanos caur mūsu uzņēmumiem un to, kā tā iet caur dažādām sistēmām vai caur datu krātuvēm, tāpēc mēs zinām Kad mēs veidojam I-risinājumus vai šāda veida lietas, mēs faktiski patērējam pareizo informāciju par konkrēto uzdevumu.
Un tad ļoti svarīgi ir tas, kā mēs varam panākt visu ieinteresēto pušu, īpaši biznesa ieinteresēto personu, sadarbību, jo tieši tās mums dod patieso nozīmi, kāda ir šie dati. Dienas beigās uzņēmumam pieder dati. Viņi sniedz vārdu krājuma un lietu definīcijas, par kurām Ēriks runāja, tāpēc mums ir vajadzīga vieta, kur to visu sasaistīt. Un tas, kā mēs to darām, ir mūsu datu modelēšana un datu krātuvju arhitektūras.
Es apskatīšu dažas lietas. Es runāšu par ER / Studio Enterprise Team Edition. Galvenokārt es runāšu par datu arhitektūras produktu, kurā mēs veicam datu modelēšanu un šāda veida lietas, bet ir arī daudz citu komplekta komponentu, kurus es ļoti īsi apskatīšu. Jūs redzēsit vienu fragmentu no biznesa arhitekta, kurā mēs varam izveidot konceptuālus modeļus, bet mēs varam arī izveidot biznesa procesu modeļus, un mēs varam saistīt šos procesu modeļus, lai sasaistītu faktiskos datus, kas ir mūsu datu modeļos. Tas patiešām palīdz mums šo saikni apvienot. Programmatūras arhitekts ļauj mums veikt papildu konstrukcijas, piemēram, kādu UML modelēšanu un šāda veida lietas, lai sniegtu atbalsta loģiku dažām no šīm citām sistēmām un procesiem, par kuriem mēs runājam. Bet ļoti svarīgi, virzoties lejup, mums ir repozitorijs un komandas serveris, un es runāšu par to kā par vienas un tā paša veida divām pusēm. Repozitorijā mēs glabājam visus modelētos metadatus, kā arī visus biznesa metadatus biznesa glosāriju un terminu izteiksmē. Tā kā mums ir šī uz glabātuvi balstītā vide, mēs varam visas šīs dažādās lietas salikt vienā un tajā pašā vidē, un tad mēs tās faktiski varam padarīt pieejamas patērēšanai ne tikai tehniskajiem ļaudīm, bet arī uzņēmējiem. Un tieši tā mēs patiešām sākam virzīt sadarbību.
Un tad pēdējais gabals, par kuru īsi runāšu, ir tas, ka, ieejot šajā vidē, tas nav tikai datu bāzes, kuras jums ir. Jums būs vairākas datu bāzes, datu krātuves, jums būs arī daudz mantojuma artefaktu, ko es sauktu. Varbūt cilvēki ir izmantojuši Visio vai citas diagrammas, lai kartētu dažas lietas. Varbūt viņiem ir bijuši citi modelēšanas rīki un šāda veida lietas.Tas, ko mēs varam darīt ar MetaWizard, ir faktiski iegūt šo informāciju un ievietot to mūsu modeļos, padarīt to aktuālu un spēt to izmantot, atkal patērēt, pašreizējā veidā, nevis tikai atstāt to ārā. Tagad tā kļūst par mūsu darba modeļu aktīvu sastāvdaļu, kas ir ļoti svarīgi.
Kad jūs ieejat organizācijā, kā es teicu, tur ir daudz atšķirīgu sistēmu, daudz ERP risinājumu, neatbilstīgi departamentu risinājumi. Daudzas organizācijas izmanto arī SaaS risinājumus, kas arī tiek ārēji kontrolēti un pārvaldīti, tāpēc mēs nekontrolējam datu bāzes un šāda veida lietas to resursdatoros, taču mums joprojām ir jāzina, kā šie dati izskatās, un, protams, ap to esošie metadati. Tas, ko mēs atrodam, ir arī daudz novecojušu sistēmu, kas nav iztīrītas tās projektētās pieejas dēļ, par kuru bija runājis Malkolms. Tas ir pārsteidzoši, kā pēdējos gados organizācijas izveidos projektus, aizstās sistēmu vai risinājumu, taču bieži vien novecojušo risinājumu atcelšanai nepietiek projekta budžeta, tāpēc tagad tie ir tikai ceļā. Un mums ir jāizdomā, no kā mēs patiesībā varam atbrīvoties savā vidē, kā arī no tā, kas ir noderīgs turpmākajai darbībai. Un tas ir saistīts ar slikto demontāžas stratēģiju. Tā ir viena un tā pati lietas sastāvdaļa.
Ko mēs arī atrodam, jo no visiem šiem dažādajiem risinājumiem ir izveidota liela daļa organizāciju, vai mēs redzam daudz punktu-punkta saskarnes un daudz datu, kas pārvietojas daudzās vietās. Mums jāspēj to racionalizēt un izdomāt datu līniju, kuru es jau iepriekš īsi pieminēju, lai mums būtu saskanīgāka stratēģija, piemēram, uz pakalpojumiem orientētas arhitektūras, uzņēmuma pakalpojumu autobusu un šāda veida lietu izmantošana, lai sniegtu pareizu informāciju. modeļa publicēšanas un abonēšanas veidam, kuru mēs pareizi izmantojam visā biznesā. Un tad, protams, mums joprojām ir jāveic kāda veida analīze, neatkarīgi no tā, vai mēs izmantojam datu noliktavas, datu kartes ar tradicionālo ETL vai arī dažus no jaunajiem datu ezeriem. Tas viss attiecas uz vienu un to pašu. Tie ir visi dati, neatkarīgi no tā, vai tie ir lieli dati, neatkarīgi no tā, vai tie ir tradicionālie dati relāciju datu bāzēs, mums visi šie dati ir jāapkopo, lai mēs tos varētu pārvaldīt un zināt, ar ko mēs saskaramies visos mūsu modeļos.
Atkal sarežģītība, ko mēs veiksim, ir tā, ka mums ir jāveic vairākas darbības, kuras mēs vēlamies veikt. Pirmkārt, jūs ejat iekšā, un jums, iespējams, nav šo blūzi, kā izskatās šī informācijas ainava. Datu modelēšanas rīkā, piemēram, ER / Studio Data Architect, jūs vispirms veiksit daudz reversās inženierijas, norādot uz tur esošajiem datu avotiem, ieviešot tos un pēc tam faktiski salīmējot tos reprezentatīvākos. modeļi, kas pārstāv visu biznesu. Svarīgi ir tas, vai mēs vēlamies arī šos modeļus sadalīt atbilstoši biznesa virzieniem, lai mēs varētu tos attiecināt mazākos gabalos, ar kuriem var attiekties arī mūsu biznesa cilvēki, un mūsu biznesa analītiķi un citas ieinteresētās personas, kas strādā uz tā.
Nosaukšanas standarti ir ārkārtīgi svarīgi, un es šeit runāju par to dažādos veidos. Nosauciet standartus attiecībā uz to, kā mēs modeļos saucam lietas. Tas ir diezgan viegli izdarāms loģiskos modeļos, kur mums ir laba nosaukumu piešķiršanas kārtība un laba datu vārdnīca mūsu modeļiem, taču arī daudzos šajos fiziskajos modeļos, kurus mēs ievedam, mēs redzam dažādas nosaukšanas konvencijas. reversais inženieris, diezgan bieži mēs redzam saīsinātus nosaukumus un šāda veida lietas, par kurām es runāšu. Un mums tie jātulko nozīmīgos angļu vārdos, kas ir nozīmīgi biznesam, lai mēs saprastu, kādi ir visi šie datu elementi, kas mums ir vidē. Un tad universāls kartējums ir veids, kā mēs tos saliekam.
Papildus tam mēs vēl vairāk dokumentētu un definētu, un tur mēs varam sīkāk klasificēt savus datus ar nosaukumu Pielikumi, kurus es parādīšu jums pāris slaidiem. Un tad, aizverot cilpu, mēs vēlamies pielietot šo biznesa nozīmi, kurā mēs sasaistām savus biznesa glosārijus un varam tos sasaistīt ar mūsu dažādajiem modeļa artefaktiem, tāpēc mēs zinām, kad mēs runājam par noteiktu biznesa terminu, kur tas ir ieviesta mūsu datos visā organizācijā. Visbeidzot, es jau runāju par faktu, ka mums tas viss ir jāveido ar krātuvi, kurai ir daudz sadarbības un publicēšanas iespēju, lai mūsu ieinteresētās puses to varētu izmantot. Es diezgan ātri runāšu par reverso inženieriju. Es jau esmu devis jums iespēju ātri to izcelt. Es jums to parādīšu faktiskā demonstrācijā, lai parādītu jums dažas lietas, kuras mēs tur varam ievest.
Un es gribu runāt par dažiem dažādiem modeļa tipiem un diagrammām, kuras mēs veidotu šāda veida scenārijos. Acīmredzot konceptuālos modeļus mēs darīsim daudzos gadījumos; Es tam negaidīšu daudz laika. Es tiešām gribu runāt par loģiskajiem modeļiem, fiziskajiem modeļiem un specializētajiem modeļu veidiem, kurus mēs varam izveidot. Un ir svarīgi, lai mēs tos visus varētu izveidot vienā un tajā pašā modelēšanas platformā, lai mēs varētu tos sasaistīt. Tas ietver dimensiju modeļus un arī modeļus, kas izmanto dažus jaunus datu avotus, piemēram, NoSQL, kuru es jums parādīšu. Un kā tad izskatās datu līnijas modelis? Un kā mēs šos datus iestrādāsim biznesa procesa modelī, par ko mēs runāsim tālāk.
Šeit es pāriet uz modelēšanas vidi tikai tāpēc, lai sniegtu ļoti augstu un ātru pārskatu. Un es uzskatu, ka jums vajadzētu būt iespējai redzēt manu ekrānu tagad. Pirmkārt, es gribu runāt tikai par tradicionālu datu modeļa veidu. Un veids, kā mēs vēlamies organizēt modeļus, kad tos ieviešam, ir tas, ka mēs vēlamies, lai mēs spētu tos sadalīt. Tātad, ko jūs redzat šeit kreisajā pusē, mums ir loģiski un fiziski modeļi šajā konkrētajā modeļa failā. Nākamā lieta ir, vai mēs to varam sadalīt, sadaloties biznesā, tāpēc jūs redzat mapes. Gaiši zilie ir loģiski modeļi, un zaļie ir fiziski modeļi. Mēs varam arī veikt izpēti, tāpēc ER / Studio ietvaros, ja notiek biznesa sadalīšana, varat pāriet pēc iespējas vairāk līmeņu vai apakšmodeļu, un izmaiņas, kuras veicat zemākajos līmeņos, automātiski atspoguļojas augstāk līmeņi. Tātad tas ļoti ātri kļūst par ļoti spēcīgu modelēšanas vidi.
Kaut kas, ko es arī gribu norādīt, ir ļoti svarīgi sākt apkopot šo informāciju, ir tas, ka mums var būt vairāki fiziski modeļi, kas arī atbilst vienam loģiskajam modelim. Diezgan bieži jums var būt loģisks modelis, bet jums var būt fiziski modeļi dažādās platformās un šāda veida lieta. Varbūt kāds ir SQL Server tā gadījums, varbūt cits ir Oracle piemērs. Mums ir visas iespējas to visu sasaistīt vienā un tajā pašā modelēšanas vidē. Un atkal es šeit ieguvu faktisko datu noliktavas modeli, kas atkal var būt tajā pašā modelēšanas vidē vai arī mums tas var būt krātuvē un sasaistāms arī ar dažādām lietām.
Tas, ko es patiešām gribēju jums parādīt šajā sakarā, ir dažas citas lietas un citi modeļu varianti, pie kuriem mēs nonākam. Tad, kad mēs nonākam pie tāda tradicionāla datu modeļa, mēs esam pieraduši redzēt tipiskas entītijas ar kolonnām un metadatiem un šāda veida lietām, taču šis skats mainās ļoti ātri, kad sākam nodarboties ar kādu no šīm jaunākajām NoSQL tehnoloģijām. vai kā dažiem cilvēkiem joprojām patīk tos saukt, lielo datu tehnoloģijas.
Tātad, pieņemsim, ka mēs esam arī stropu savā vidē. Ja mēs atgriežamies inženierus no stropu vides un mēs varam pāradresēt inženierus no stropiem un tieši ar to pašu modelēšanas rīku, mēs redzam kaut ko mazliet atšķirīgu. Mēs joprojām tur visus datus redzam kā konstrukcijas, taču mūsu TDL atšķiras. Tie no jums, kas pieraduši redzēt SQL, tas, ko jūs redzētu tagad, ir Hive QL, kas ir ļoti līdzīgs SQL, bet no tā paša rīka, ar kuru jūs tagad varat sākt strādāt ar dažādām skriptu valodām. Tātad jūs varat modelēt šajā vidē, ģenerēt to stropu vidē, bet tikpat svarīgi ir tas, ka aprakstītajā scenārijā jūs varat to visu pārveidot un izprast, kā arī sākt to sašūt kopā. .
Paņemsim vēl vienu, kas ir nedaudz savādāks. MongoDB ir vēl viena platforma, kuru mēs atbalstām vietējā līmenī. Kad jūs sākat nokļūt JSON tipu vidēs, kur ir dokumentu krātuves, JSON ir atšķirīgs dzīvnieks, un tajā ir konstrukcijas, kas neatbilst relāciju modeļiem. Drīz jūs sākat nodarboties ar tādiem jēdzieniem kā iegultiem objektiem un iegultiem objektu masīviem, kad sākat pratināt JSON, un šie jēdzieni tradicionālajā relāciju apzīmējumā neeksistē. Tas, ko mēs šeit esam paveikuši, ir tas, ka mēs faktiski esam paplašinājuši apzīmējumu un mūsu katalogu, lai ar to varētu rīkoties tajā pašā vidē.
Ja paskatāties šeit pa kreisi, tā vietā, lai redzētu tādas lietas kā entītijas un tabulas, mēs tos saucam par objektiem. Un jūs redzat dažādus apzīmējumus. Jūs joprojām redzat tipiskos atsauces apzīmējumu veidus, taču šie zilie entītiji, kurus es parādīju šajā konkrētajā diagrammā, faktiski ir iegultie objekti. Un mēs parādām dažādas kardinālības. Dimanta kardinalitāte nozīmē, ka tas ir objekts no vienas puses, bet viena kardinalitāte nozīmē, ka izdevējā, ja sekojam šīm attiecībām, mums ir iegults adreses objekts. Izpratot JSON, mēs esam atklājuši, ka tā ir tieši tāda pati objektu struktūra, kas iegulta patronim, bet kas faktiski ir iegulta kā objektu masīvs. Mēs to redzam ne tikai caur savienotājiem, bet arī tad, ja skatāmies uz faktiskajām entītijām, redzēsit, ka redzat adreses aizbildnim, kas to klasificē arī kā objektu masīvu. Jūs saņemat ļoti aprakstošu viedokli par to, kā jūs to varat ieviest.
Un atkal, tas, ko mēs līdz šim esam redzējuši tikai dažās sekundēs, ir tradicionālie daudzlīmeņu relāciju modeļi, mēs varam darīt to pašu ar Hive, mēs varam darīt to pašu ar MongoDB un citiem lieliem datu avotiem kā labi. Ko mēs arī varam darīt, un es tikai ļoti ātri to parādīšu, es runāju par faktu, ka lietas tiek ievestas no citām dažādām jomām. Es pieņemšu, ka es importēšu modeli no datu bāzes vai to pārveidotu, bet es to ievedīšu no ārējiem metadatiem. Tikai, lai sniegtu jums ļoti ātru skatu uz visiem dažādajiem veidiem, kurus mēs varam sākt ieviest.
Kā redzat, mums ir neskaitāmas lietas, ar kurām mēs faktiski varam ievietot metadatus mūsu modelēšanas vidē. Sākot ar lietām, piemēram, pat Amazon Redshift, Cassandra, daudzām citām lielajām datu platformām, tāpēc jūs redzat daudz no tām. Tas notiek alfabēta secībā. Mēs redzam daudz lielu datu avotu un šāda veida lietas. Mēs redzam arī daudz tradicionālu vai vecāku modelēšanas vides, kuras mēs faktiski varam ieviest, izmantojot šos metadatus. Ja man šeit iet cauri - un es negaidīšu laiku katram no tiem -, mēs redzam daudz dažādu lietu, no kurām mēs to varam ievest, piemēram, modelēšanas platformu un datu platformu jomā. Un tas, kas šeit ir ļoti svarīgi saprast, ir vēl viena daļa, ko mēs varam darīt, kad sākam runāt par datu līniju, Enterprise Team Edition mēs varam arī pratināt ETL avotus, neatkarīgi no tā, vai tās ir lietas, piemēram, Talend vai SQL Server Information Services kartēšana, mēs varam patiesībā ievediet to, lai sāktu arī mūsu datu līnijas diagrammas un nofotografētu to, kas notiek šajās pārvērtībās. Kopumā mums ir vairāk nekā 130 šo dažādo tiltu, kas faktiski ir daļa no Enterprise Team Edition produkta, tāpēc tas patiešām palīdz mums ļoti ātri visus artefaktus apkopot vienā modelēšanas vidē.
Visbeidzot, es vēlos runāt arī par to, ka mēs nevaram aizmirst par faktu, ka mums ir vajadzīgi cita veida konstrukcijas, ja mēs nodarbojamies ar datu glabāšanu vai jebkāda veida analītiku. Mēs joprojām vēlamies, lai būtu iespēja darīt tādas lietas kā dimensiju modeļi, kur mums ir faktu tabulas un mums ir dimensijas un šāda veida lietas. Viena lieta, ko es arī gribu jums parādīt, ir tā, ka mums var būt arī mūsu metadatu paplašinājumi, kas palīdz mums klasificēt kategoriju tipus un visu pārējo. Tātad, ja, piemēram, apskatot šeit dimensijas datu cilni, viena no tām, tā faktiski tiks automātiski noteikta, pamatojoties uz redzamo modeļa modeli, un sniegs jums sākumpunktu, domājot, vai tā ir dimensija vai faktu tabula. Bet ne tikai tas, ko mēs varam darīt, ietilpst dimensijās, un šāda veida lietām mums pat ir dažāda veida dimensijas, kuras mēs varam izmantot, lai klasificētu datus arī datu glabāšanas vidē. Tik ļoti spēcīgas iespējas, ar kurām mēs to visu sašujam.
Es pārdomāšu šo, jo šobrīd atrodos demonstrācijas vidē un parādīšu vēl dažas lietas, pirms atgriezīšos slaidos. Viena no lietām, ko nesen pievienojām ER / Studio Data Architect, ir tā, ka mēs esam nonākuši situācijās - un tas ir ļoti izplatīts lietošanas gadījums, kad strādājat pie projektiem - izstrādātāji domā par objektiem, savukārt mūsu dati modelētāji mēdz domāt tabulas un entītijas un šāda veida lietas. Šis ir ļoti vienkāršots datu modelis, taču tas pārstāv dažus pamatjēdzienus, kur izstrādātāji vai pat biznesa analītiķi vai biznesa lietotāji varētu tos domāt par dažādiem objektiem vai biznesa koncepcijām. Līdz šim ir bijis ļoti grūti tos klasificēt, bet tas, ko mēs faktiski esam paveikuši ER / Studio Enterprise Team Edition 2016. gada laidienā, ir tas, ka mums tagad ir koncepcija ar nosaukumu Biznesa datu objekti. Un tas, kas mums ļauj to darīt, tas ļauj mums iekapsulēt entītiju grupas vai tabulas patiesos biznesa objektos.
Piemēram, tas, kas mums parādījās šajā jaunajā skatā, ir tas, ka iepirkuma pasūtījuma galvene un pasūtījuma rinda tagad ir salikti kopā, tie ir iekapsulēti kā objekts, mēs tos uzskatītu par darba vienību, saglabājot datus , un mēs tos apvienojam, tāpēc tagad to ir ļoti viegli saistīt ar dažādām auditorijām. Tie ir atkārtoti izmantojami visā modelēšanas vidē. Tie ir patiess objekts, ne tikai zīmēšanas konstrukcija, bet mums ir arī papildu ieguvums, ka, kad mēs faktiski sazināmies no modelēšanas viedokļa, mēs tos varam selektīvi sabrukt vai paplašināt, lai mēs varētu izveidot apkopotu skatu dialogiem ar noteiktām ieinteresēto personu auditorijām, un mēs, protams, varam saglabāt arī detalizētāku skatu, kādu mēs šeit redzam, lai vairāk tehnisko auditoriju. Tas tiešām sniedz mums ļoti labu saziņas līdzekli. Tas, ko mēs redzam tagad, ir vairāku dažādu modeļu veidu apvienošana, papildinot tos ar biznesa datu objektu jēdzienu, un tagad es runāšu par to, kā mēs šiem lietu veidiem patiesībā piešķiram vēl kādu nozīmi un kā mēs tos saistam savā vispārējā vide.
Es tikai cenšos šeit atrast savu WebEx, lai es to varētu izdarīt. Un tur mēs dodamies atpakaļ uz Hot Tech slaidiem. Es tikai šeit ātri pārlaidīšu dažus slaidus, jo tos jau esat redzējis modeļa demonstrācijā. Es ļoti ātri gribu runāt par standartu nosaukšanu. Mēs vēlamies piemērot un ieviest dažādus nosaukšanas standartus. Tas, ko mēs vēlamies darīt, ir tas, ka mums ir iespēja repozitorijos glabāt nosaukšanas standartu veidnes, lai pamatā izveidotu šo nozīmi, izmantojot vārdus vai frāzes vai pat saīsinājumus, un saistīt tos ar jēgpilnu angļu valodas vārdu. Mēs izmantosim biznesa terminus, to saīsinājumus un varēsim norādīt pasūtījumu, gadījumus un pievienot prefiksus un piedēkļus. Parasti to izmanto, ja cilvēki ir izveidojuši loģisku modeli un pēc tam faktiski gatavojas izveidot fizisku modeli, kur viņi, iespējams, ir izmantojuši saīsinājumus un visu pārējo.
Skaista lieta ir tā, ka tas ir tikpat jaudīgs, vēl spēcīgāks apgrieztā secībā, ja mēs varam vienkārši pateikt, kādi bija daži no nosaukšanas standartiem dažās no tām fiziskajām datu bāzēm, kuras mēs esam izstrādājuši, mēs varam ņemt šos saīsinājumus, pārvērst tos ilgākos vārdus, un atgrieziet tos atpakaļ angļu frāzēs. Mēs faktiski tagad varam iegūt vārdus, kā izskatās mūsu dati. Kā es saku, tipisks lietošanas gadījums ir tas, ka mēs virzītos uz priekšu, loģiski fiziski, un kartētu datu krājumus un šāda veida lietas. Ja paskatās ekrānuzņēmumu labajā pusē, jūs redzēsit, ka no avota nosaukumiem ir saīsināti vārdi, un, kad mēs esam piemērojuši nosaukumu piešķiršanas standartu veidni, mēs faktiski esam ieguvuši pilnīgākus nosaukumus. Un mēs varētu ievietot atstarpes un visu tamlīdzīgu, ja mēs vēlamies, atkarībā no nosaukšanas standartu veidnes, kuru mēs izmantojām. Mēs varam likt tam izskatīties, tomēr vēlamies, lai tas izskatās mūsu modeļos. Tikai tad, kad mēs zinām, ko kaut kas sauc, mēs patiesībā varam sākt tam pievienot definīcijas, jo, ja mēs nezinām, kas tas ir, kā mēs tam varam piemērot nozīmi?
Patīkami ir tas, ka mēs tiešām varam uz to atsaukties, kad darām visu veidu lietas. Es runāju par reverso inženieriju. Mēs faktiski varam vienlaikus atsaukties uz nosaukšanas standartu veidnēm, kad mēs veicam reverso inženieriju. Tātad, veicot vienu vedņa darbību kopumu, mēs varam darīt, ja mēs zinām, kādas ir konvencijas, mēs varam pārveidot fiziskās datu bāzes inženieriju, un tā to atgriezīs kā fiziskus modeļus modelēšanas vidē, un tas ir piemērosim arī šīs nosaukšanas konvencijas. Tātad mēs redzēsim, kādi vārdi ir angļu valodā līdzīgi attēlojumi attiecīgajā loģiskajā modelī vidē. Mēs to varam arī izdarīt, apvienojot to ar XML shēmas ģenerēšanu, lai mēs varētu ņemt modeli un pat izstumt to ar saīsinājumiem neatkarīgi no tā, vai mēs darām SOA ietvarus vai šāda veida lietas, tāpēc mēs varam arī izstumt dažādas nosaukšanas konvencijas ko mēs faktiski esam saglabājuši pašā modelī. Tas mums dod daudz ļoti spēcīgu iespēju.
Šeit atkal ir piemērs tam, kā varētu izskatīties, ja man būtu veidne. Šis faktiski parāda, ka man bija EMP par “darbinieku”, SAL par “algu”, PLN par “plānu” nosaukšanas standartu konvencijā. Es arī varu tos izmantot, lai tie darbotos interaktīvi, jo es veidoju modeļus un ievietoju lietas. Ja es lietotu šo saīsinājumu un uzņēmuma nosaukumā ierakstītu “Darbinieku algu plāns”, tas darbotos ar nosaukšanas standartu veidni. Es šeit esmu definējis, ka, veidojot entītijas, man uzreiz būtu doti EMP_SAL_PLN.
Atkal ļoti labi, kad mēs arī projektējam un virzījam inženierzinātnes. Mums ir ļoti unikāla koncepcija, un tieši šeit mēs sākam apvienot šo vidi.Un to sauc par universālo kartēšanu. Kad visi šie modeļi mūsu vidē ir ienesti, ko mēs spējam izdarīt, pieņemot, ka mēs tagad esam piemērojuši šīs nosaukšanas konvencijas un tās ir viegli atrodamas, tagad ER var izmantot konstrukciju ar nosaukumu Universal Mappings. / Studija. Mēs varam sasaistīt entītijas visos modeļos. Lai kur mēs redzētu “klientu” - mums, iespējams, būs “klients” daudzās dažādās sistēmās un daudz dažādās datu bāzēs, mēs varam sākt sasaistīt visus tos kopā tā, ka, strādājot ar to vienā modelī, es var redzēt, kur ir klientu izpausmes citos modeļos. Tā kā mums ir modeļa slānis, kas to reprezentē, mēs to pat varam saistīt ar datu avotiem un nodot mūsu pieprasītajos pieprasījumos, kurās datu bāzēs tie arī atrodas. Tas patiešām dod mums iespēju to visu sasaistīt ļoti saskaņoti.
Es jums parādīju biznesa datu objektus. Es ļoti ātri gribu runāt arī par metadatu paplašinājumiem, kurus mēs saucam par pielikumiem. Tas, kas tas notiek, dod mums iespēju izveidot papildu metadatus mūsu modeļa objektiem. Diezgan bieži es izveidoju šāda veida īpašumus, lai no datu pārvaldības un datu kvalitātes viedokļa izdalītu daudz dažādu lietu, kā arī palīdzētu mums ar galveno datu pārvaldību un datu saglabāšanas politiku. Pamatideja ir tāda, ka jūs izveidojat šīs klasifikācijas un varat tos pievienot visur, kur vēlaties, tabulas līmenī, kolonnu līmenī - šāda veida lietas. Visizplatītākais lietošanas gadījums, protams, ir tas, ka entītijas ir tabulas, un tad es varu definēt: kas ir mani galvenie datu objekti, kādas ir manas atsauces tabulas, kādas ir manas darījumu tabulas? Raugoties no datu kvalitātes viedokļa, es varu veikt klasifikāciju, ņemot vērā to nozīmi biznesā, lai mēs varētu noteikt datu apstrādes un šāda veida lietu prioritāti.
Kaut kas bieži tiek aizmirsts, kāda ir dažāda veida datu saglabāšanas politika mūsu organizācijā? Mēs varam tos iestatīt, un mēs tos faktiski varam pievienot dažādiem informācijas artefaktu veidiem mūsu modelēšanas vidē un, protams, arī mūsu krātuvei. Lieliski, vai šie pielikumi atrodas mūsu datu vārdnīcā, tāpēc, kad vidē izmantojam uzņēmuma datu vārdnīcas, mēs tos varam pievienot vairākiem modeļiem. Mums tie ir jādefinē tikai vienreiz, un mēs tos atkal un atkal varam izmantot dažādos mūsu vides modeļos. Šis ir tikai ātrs ekrānuzņēmums, lai parādītu, ka jūs faktiski varat norādīt, kad darāt pielikumu, kādi ir visi gabali, kuriem vēlaties to pievienot. Un šis piemērs šeit faktiski ir vērtību saraksts, tāpēc, kad tie nonāk, jūs varat izvēlēties kādu no vērtību saraksta, modelēšanas vidē jums ir daudz iespēju kontrolēt to, kas tiek atlasīts, un jūs pat varat iestatīt, kāds ir noklusējuma iestatījums. vērtība ir, ja vērtība nav izvēlēta. Tik daudz spēka tur. Viņi dzīvo datu vārdnīcā.
Kaut ko es vēlos jums parādīt mazliet tālāk šajā ekrānā, turklāt augšējā daļā ir redzami pielikumu veidi, zem kuriem redzama datu drošības informācija. Datu drošības politikas mēs faktiski varam piemērot arī dažādajai vidē esošajai informācijai. Dažādām atbilstības kartēm, datu drošības klasifikācijām mēs vairākus no tiem piegādājam ārpus kastes, kurus varat vienkārši ģenerēt un sākt lietot, taču jūs varat arī definēt savus atbilstības kartēšanu un standartus. Neatkarīgi no tā, vai jūs veicat HIPAA vai kādu citu no šeit esošajām iniciatīvām. Un jūs patiešām varat sākt veidot šo ļoti bagātīgo metadatu kopumu savā vidē.
Pēc tam - vārdnīca un termini - šeit tiek sasaistīta biznesa nozīme. Mums diezgan bieži ir datu vārdnīcas, kuras organizācija diezgan bieži izmanto kā sākumpunktu, lai sāktu dzēst vārdnīcas, bet terminoloģija un vārdnīca ir bieži vien ļoti tehniski. Tātad, ko mēs varam darīt, mēs varam, ja vēlamies, izmantot tos kā sākumpunktu, lai izkoptu glosārijus, bet mēs patiešām vēlamies, lai uzņēmumam tie pieder. Tas, ko mēs esam paveikuši komandas servera vidē, ir tas, ka mēs esam devuši cilvēkiem iespēju izveidot biznesa definīcijas, un tad mēs varēsim tos sasaistīt ar dažādiem modeļa artefaktiem, kuriem tie atbilst arī modelēšanas vidē. Mēs atzīstam arī jautājumu, kas tika apspriests iepriekš, proti, jo vairāk cilvēku rakstāt, jo lielāks ir cilvēku kļūdu potenciāls. Tas, ko mēs darām arī mūsu glosārija struktūrā, ir tas, ka mēs atbalstām glosārija hierarhiju, tāpēc organizācijā var būt dažādi glosāriju tipi vai dažāda veida lietas, bet tikpat svarīgi ir tas, ja jums jau ir daži no šiem avotiem Mēs varam veikt CSV importēšanu, izmantojot tur iekļautos terminus un visu definēto, lai tos ievietotu modelēšanas vidē, kā arī komandas serverī vai mūsu vārdnīcā, un pēc tam sāktu saites. Un katru reizi, kad kaut kas tiek mainīts, ir pilnīga audita izsekojamība par to, kas bija iepriekšējie un pēc attēli, ņemot vērā definīcijas un visu pārējo, un tas, ko jūs redzēsit nākam tuvākajā nākotnē, ir vairāk arī autorizācijas darbplūsma. tāpēc mēs patiešām varam kontrolēt, kas par to atbild, komiteju vai personu apstiprinājumus un šāda veida lietas, lai turpinātu pārvaldības procesu vēl spēcīgāku.
Tas arī attiecas uz mums, ja mūsu komandas servera vārdnīcā ir šie vārdnīcas termini. Tas ir rediģēšanas piemērs paša modeļa entītijā, kuru esmu šeit audzinājis. Iespējams, ka tas ir savienojis terminus, bet mēs arī darām, ja šajā glosārijā ir vārdi, kas parādās piezīmēs vai aprakstos par to, kas mums šeit ir mūsu entītijās, tie automātiski tiek parādīti gaišākā hipersaites krāsā, un, ja mēs Ja peles kursors ir virs tām, mēs faktiski varam redzēt definīciju arī biznesa glosārijā. Tas pat sniedz mums bagātāku informāciju, kad patērējam pašu informāciju ar visiem šeit esošajiem vārdnīcu vārdiem. Tas patiešām palīdz bagātināt pieredzi un nozīmi pielietot visam, ar ko mēs strādājam.
Tātad atkal tas bija ļoti ātrs lidojums. Acīmredzot mēs tam varētu pavadīt dienas, iedziļinoties dažādās daļās, taču tas ir ļoti ātrs lidojums virs virsmas. Mēs patiesībā cenšamies saprast, kā izskatās šī sarežģītā datu vide. Mēs vēlamies uzlabot visu šo datu artefaktu redzamību un sadarboties, lai tos izdzenu kopā ar ER / Studio. Mēs vēlamies iespējot efektīvāku un automatizētu datu modelēšanu. Un tas ir visu veidu dati, par kuriem mēs runājam, neatkarīgi no tā, vai tie ir lielie dati, tradicionālie relāciju dati, dokumentu krātuves vai kas cits. Un atkal mēs to paveicām, jo mums ir jaudīgas priekšu un atpakaļgaitas inženierijas iespējas dažādām platformām un citiem rīkiem, kas jums var būt tur. Tas viss attiecas uz dalīšanos un saziņu visā organizācijā ar visām iesaistītajām pusēm. Šeit mēs pielietojam nozīmi, nosaucot standartus. Pēc tam mēs izmantojam definīcijas, izmantojot mūsu biznesa glosārijus. Un tad mēs varam veikt turpmāku klasifikāciju attiecībā uz visām citām mūsu pārvaldības iespējām ar metadatu paplašinājumiem, piemēram, datu kvalitātes paplašinājumiem, klasifikācijām galveno datu pārvaldībai vai jebkura cita veida klasifikācijām, kuras vēlaties izmantot šiem datiem. Tad mēs varam apkopot vēl vairāk un vēl vairāk uzlabot saziņu ar biznesa datu objektiem ar dažādām ieinteresēto personu auditorijām, it īpaši starp modelētājiem un izstrādātājiem.
Un atkal tas, kas ir ļoti svarīgi, aiz tā visa ir integrēts repozitorijs ar ļoti stabilām izmaiņu pārvaldības iespējām. Man šodien nebija laika to parādīt, jo tas kļūst diezgan sarežģīts, bet repozitorijam ir ļoti stabilas izmaiņu pārvaldības iespējas un revīzijas liecības. Jūs varat veikt nosauktas izlaišanas, jūs varat darīt nosauktas versijas, un mums ir arī iespējas tiem, kas veic izmaiņu vadību, mēs varam tos piesaistīt jūsu uzdevumiem. Mūsdienās mēs varam ievietot uzdevumus un saistīt jūsu modeļa izmaiņas ar uzdevumiem, tāpat kā izstrādātāji savas koda izmaiņas saistītu ar uzdevumiem vai lietotāju stāstiem, ar kuriem viņi arī strādā.
Atkal tas bija ļoti ātrs pārskats. Es ceru, ka pietika ar apetītes sašūpošanu, lai turpmāk mēs varētu iesaistīties daudz dziļākās sarunās, sadalot dažas no šīm tēmām. Paldies par jūsu veltīto laiku, un jums ar prieku, Rebeka.
Rebeka Jozwiak: Paldies, Ron, tas bija fantastiski, un man ir diezgan daudz jautājumu no auditorijas, bet es tomēr gribu dot mūsu analītiķiem iespēju iekost zobus tajā, kas jums bija jāsaka. Ēriks, es došos uz priekšu, un varbūt, ja jūs vēlaties pievērsties šim vai citam slaidam, kāpēc gan jums vispirms neiet uz priekšu? Vai kāds cits jautājums.
Ēriks Mazais: Protams. Atvainojiet, kāds bija jautājums, Rebeka? Jūs vēlaties, lai es pajautāju kaut ko konkrētu vai…?
Rebeka Jozwiak: Es zinu, ka jums sākotnēji bija daži jautājumi Ronam. Ja vēlaties tagad lūgt, lai viņš uzrunā kādu no tiem, vai dažus no tiem, kas atrodas pie jūsu slaida, vai kaut ko citu, kas izraisīja jūsu interesi, par kuru vēlaties jautāt? Par IDERA modelēšanas funkcijām.
Ēriks Mazais: Jā, tā ir viena no lietām, Ron, kā jūs, puiši, izskatās, ka diagrammas, kuras jūs parādījāt, ir vispārīgas entītiju attiecību diagrammas, kuras jūs parasti izmantotu datu bāzes veidošanā, vai ne?
Rons Huizenga: Jā, vispārīgi runājot, bet, protams, mums ir paplašināti tipi dokumentu krātuvēm un arī šāda veida lietām. Mēs faktiski esam atšķīrušies no vienkārša relāciju apzīmējuma, un arī šiem citiem veikaliem esam pievienojuši papildu apzīmējumus.
Ēriks Mazais: Vai ir kāds veids, kā jūs, puiši, varat izmantot uz grafikiem balstītus modelēšanas veidus, tātad, vai ir arī veids, kā integrēt, pieņemsim, ka, manuprāt, man ir kaut kas līdzīgs augšējam kvadrantam, komponista rīks TopBraid vai arī esmu kaut ko izdarījis Protégé vai , jūs zināt, tāpat kā FIBO finanšu puiši, viņi daudz strādā semantikā, RDF lietās - vai ir kāds veids, kā šajā rīkā ievietot šāda veida entītiju un attiecību grafika modeļa modeli un to izmantot?
Rons Huizenga: Faktiski mēs skatāmies, kā mēs varam rīkoties ar grafikiem. Mūsdienās mēs tieši nenodarbojamies ar grafiku datu bāzēm un šāda veida lietām, bet mēs meklējam veidus, kā to izdarīt, lai paplašinātu metadatus. Es domāju, ka šobrīd mēs varam ieviest lietas caur XML un šāda veida lietām, ja mēs vismaz varam kaut kādu XML pārsūtīšanu veikt, lai to ieviestu kā sākumpunktu. Bet mēs meklējam elegantākus veidus, kā to ieviest.
Un es jums parādīju arī to reversās inženierijas tiltu sarakstu, kas mums arī ir, tāpēc mēs vienmēr meklējam iespēju paplašināt šos tiltus arī konkrētām platformām. Ja tas ir jēga, tas ir nepārtraukts un nepārtraukts darbs, lai sāktu apgūt daudz šo jauno konstrukciju un dažādās platformas. Bet es varu teikt, ka mēs noteikti to darām. Tās lietas, kuras es parādīju, piemēram, MongoDB, un šāda veida lietām, mēs esam pirmie datu modelēšanas pakalpojumu sniedzēji, kas faktiski to dara savās ierīcēs.
Ēriks Mazais: Labi, jā. Tātad otrs jautājums, kas man jums bija, bija par pārvaldību un saglabāšanu - piemēram, kad jūs izmantojāt piemēru, kad parādījāt personas, kas ir “darbinieks”, es uzskatu, ka tas bija “ alga, un tad jums ir “plāns”, vai ir veids, kā jūs vadāt, piemēram, dažādus cilvēkus, piemēram, pieņemsim, ka jums ir liela arhitektūra, pareizi, pieņemsim, ka jums ir liels uzņēmums un cilvēki sāk apkopot lietas šajā rīkā, un šeit jums ir viena grupa, kurai ir vārds “darbinieks”, un šeit ir viena grupa, kurai ir vārds “darbinieks”. Un šeit viens cilvēks saka “alga”, bet cits saka “Alga”.
Kā jūs, puiši, saskaņojat un pārvaldāt un pārvaldāt šāda veida atšķirības? Tā kā es zinu, kā mēs to darītu grafu pasaulē, jūs zināt, ka jūs izmantotu sinonīmu sarakstus vai jūs teiktu, ka ir viena koncepcija un tai ir vairāki atribūti, vai arī jūs varētu teikt, ka SKOS modelī man ir ieteicama etiķete un man ir daudzas alternatīvas etiķetes, kuras es varu izmantot. Kā jūs, puiši, to darāt?
Rons Huizenga: Mēs to darām pāris dažādos veidos, un vispirms runāsim par terminoloģiju. Viena no lietām, ko mēs, protams, darām, ir tas, ka mēs vēlamies, lai būtu definēti vai sankcionēti termini, un biznesa glosārijā acīmredzami ir tas, kur mēs vēlamies. Uzņēmējdarbības glosārijā mēs atļaujam arī saites uz sinonīmiem, tāpēc jūs varat pateikt, šeit ir mans termins, bet jūs varat arī definēt, kādi ir visi šo sinonīmi.
Tagad, protams, ir interesanta lieta, kad jūs sākat aplūkot šo plašo datu ainavu ar visām šīm dažādajām sistēmām, kuras jūs tur esat ieguvis, jūs nevarat vienkārši tur iziet un mainīt atbilstošās tabulas un šāda veida lietas uz atbilst šim nosaukšanas standartam, jo tā var būt iegādātā pakete, tāpēc jums nav nekādas iespējas kontrolēt datu bāzes maiņu vai kaut ko citu.
Tas, ko mēs tur varētu darīt, papildus spējai saistīt glosāriju definīcijas, ir caur tiem universālajiem kartējumiem, par kuriem es runāju, ko mēs darītu, un šāda veida ieteiktā pieeja ir vispārējs loģisks modelis, kas nosaka to, kas šie dažādie biznesa jēdzieni ir tie, par kuriem jūs runājat. Saistiet biznesa vārdnīcas terminus ar tiem, un jauki ir tas, ka tagad, kad esat ieguvis šo konstrukciju, kas reprezentē loģisku entītiju, varat sākt saistīt šo loģisko entītiju ar visām šīs loģiskās entītijas implementācijām dažādās sistēmas.
Tad, kur jums tas jādara, jūs varat redzēt, ak, “persona” šajā sistēmā tiek saukta par “darbinieku”. “Alga” šeit tiek saukta par “algu” šajā citā sistēmā. Tā kā jūs to redzēsit, redzēsit visas atšķirīgās izpausmes, jo esat tos saistījis.
Ēriks Mazais: Labi, lieliski, jā, es to ieguvu. Šajā ziņā, vai ir droši apgalvot, ka tas ir līdzīgs dažiem no objektorientētajiem paņēmieniem?
Rons Huizenga: Kaut nedaudz. Tas ir nedaudz intensīvāk nekā, es domāju, jūs varētu teikt. Es domāju, ka jūs varētu izvēlēties arī manuālu sasaisti un iziešanu, kā arī inspekciju un darbību. Viena lieta, par kuru man īsti nebija iespējas runāt, jo mums atkal ir daudz iespēju - arī pašā Data Architect rīkā ir pilna automatizācijas saskarne. Un makro iespējas, kas šajā rīkā patiešām ir programmēšanas valoda. Tātad mēs faktiski varam darīt tādas lietas kā rakstīt makro, likt tai iziet un pratināt lietas un izveidot saites jums. Mēs to izmantojam informācijas importēšanai un eksportēšanai, mēs to varam izmantot lietu maiņai vai atribūtu pievienošanai, notikumam, kas balstīts uz pašu modeli, vai arī mēs to varam izmantot, lai palaistu partijās, lai faktiski izietu un pratinātu lietas un faktiski aizpildītu dažādas konstrukcijas modeli. Tātad ir pilna automatizācijas saskarne, kuru var izmantot arī cilvēki. Un universālo kartējumu izmantošana ar tiem būtu ļoti spēcīgs veids, kā to izdarīt.
Rebeka Jozwiak: Labi, paldies Ronam un paldies Ērikam. Tie bija lieliski jautājumi. Es zinu, ka mēs mazliet skrienam garām stundas augšdaļai, bet es gribētu dot iespēju Malcolm mest dažus jautājumus Rona ceļā. Malkolms?
Malkolms Šišolms: Paldies, Rebeka. Tātad, Ron, tas ir ļoti interesanti, es redzu, ka šeit ir daudz iespēju. Viena no jomām, kas mani ļoti interesē, ir, teiksim, ja mums ir attīstības projekts, kā jūs redzat, kā datu modelētājs izmanto šīs iespējas un, iespējams, vairāk sadarbojas ar biznesa analītiķiem, ar datu profilētāju, ar datu kvalitātes analītiķi , un kopā ar biznesa sponsoriem, kuri galu galā būs atbildīgi par faktiskajām informācijas prasībām projektā. Kā datu modelētājs patiesībā, izmantojot mūsu piedāvātās iespējas, padara projektu efektīvāku un lietderīgāku?
Rons Huizenga: Es domāju, ka viena no pirmajām lietām, kas jums tur jādara, ir datu modelētājs - un es nedomāju izvēlēties dažus no modelētājiem, bet es tik un tā darīšu - vai dažiem cilvēkiem joprojām ir iespaids, ka datu modelētājs ir patiešām vārtsarga veida loma, piemēram, mēs definējam, kā tā darbojas, mēs esam sargi, kas rūpējas, lai viss būtu pareizi.
Tagad ir kāds aspekts, ka jums jāpārliecinās, ka definējat pareizu datu arhitektūru un visu pārējo. Bet svarīgāka lieta ir datu modelētājam - un tas, acīmredzot, es to acīmredzami atklāju, kad konsultējos - vai jums ir jākļūst par starpnieku, tāpēc šie cilvēki ir jāapvieno.
Tas vairs nebūs sākotnējs projektēšana, ģenerēšana, datu bāzu izveidošana - tas, kas jums jādara, jums ir jāspēj strādāt ar visām šīm dažādajām ieinteresēto personu grupām, veicot tādas darbības kā reversā inženierija, informācijas importēšana, citi cilvēki sadarbojas neatkarīgi no tā, vai tas atrodas vārdnīcās vai dokumentācijā, viss līdzīgais - un ir palīglīdzeklis, lai ievilktu to krātuvē un sasaistītu koncepcijas krātuvē un strādātu ar šiem cilvēkiem.
Tas tiešām ir daudz līdzīgāks sadarbības veids videi, kurā, pat definējot uzdevumus vai pat diskusiju pavedienus, vai tāda veida lieta, kāda mums ir komandas serverī, cilvēki faktiski var sadarboties, uzdot jautājumus un nonākt pie gala gala produktiem, kurus viņi vajadzība pēc viņu datu arhitektūras un organizācijas. Vai šāda veida atbilde bija?
Malkolms Šišolms: Jā, es piekrītu. Jūs zināt, es domāju, ka atvieglošanas prasme ir tāda, kas ir ļoti vēlama datu modelētājiem. Es piekrītu, ka mēs ne vienmēr to redzam, bet es domāju, ka tas ir nepieciešams, un es ierosinātu, ka dažreiz ir tendence palikt jūsu stūrī, veicot datu modelēšanu, bet jums tiešām ir jābūt tur, strādājot kopā ar citām ieinteresētajām grupām. vai arī jūs vienkārši nesaprotat datu vidi, ar kuru jūs nodarbojaties, un es domāju, ka rezultātā modelis cieš. Bet tas ir tikai mans viedoklis.
Rons Huizenga: Un tas ir interesanti, jo jūs jau pieminējāt kaut ko savā slaidā par vēsturi par to, kā uzņēmumi ir atrauti no IT, jo tie savlaicīgi nepiegādāja risinājumus un šāda veida lietas.
Tas ir ļoti interesanti, ka manās vēlākajās konsultācijās pirms kļūšanas par produktu vadītāju vairums projektu, kurus es realizēju pēdējos divos gados pirms tam, tika sponsorēti ar biznesu, kur to vadīja patiešām bizness un datu arhitekti. un modelētāji nebija IT sastāvdaļa. Mēs bijām daļa no biznesa sponsorētas grupas, un mēs tur darbojāmies kā koordinatori, kas strādāja ar pārējām projekta komandām.
Malkolms Šišolms: Tāpēc es domāju, ka tas ir ļoti interesants jautājums.Es domāju, ka mēs sākam redzēt pārmaiņas biznesa pasaulē, kur bizness jautā vai domā varbūt ne tik daudz kā tas, ko es daru, jo notiek process, bet viņi arī sāk domāt par to, kas ir dati ar ko es strādāju, kādas ir manas datu vajadzības, kādi ir dati, kurus apstrādāju kā datus, un cik lielā mērā mēs varam iegūt IDERA produktus un iespējas šī viedokļa atbalstam, un es domāju, ka biznesa vajadzības, pat lai gan tas ir mazliet joprojām topošs.
Rons Huizenga: Es jums piekrītu un domāju, ka mēs redzam, ka tas notiek arvien vairāk un vairāk. Mēs esam redzējuši pamošanos, un jūs jau iepriekš pieskārāties tam attiecībā uz datu svarīgumu. Mēs redzējām datu nozīmi jau IT vai datu bāzu evolūcijā, tad, kā jūs sakāt, mēs sava veida esam iekļuvuši visā šī procesa pārvaldības ciklā - un process ir ārkārtīgi svarīgs, neļaujiet man tur kļūdīties -, bet tagad, kas notika ir tas, kad tas notika, datu pazaudēts fokuss.
Tagad organizācijas saprot, ka uzmanības centrā ir dati. Dati atspoguļo visu, ko mēs darām mūsu biznesā, tāpēc mums jāpārliecinās, ka mums ir precīzi dati, ka mēs varam atrast pareizo informāciju, kas mums nepieciešama lēmumu pieņemšanai. Jo ne viss nāk no noteikta procesa. Daļa informācijas ir citu lietu blakusprodukts, un mums joprojām ir jāspēj to atrast, zināt, ko tā nozīmē, un jāspēj tur redzamos datus tulkot galu galā zināšanās, kuras mēs varam izmantot, lai labāk vadītu mūsu uzņēmējdarbību.
Malkolms Šišolms: Pareizi, un tagad cita joma, kurā esmu cīnījusies, ir tā, ko es dēvētu par datu dzīves ciklu, kas ir, jūs zināt, ja mēs aplūkotu datu piegādes ķēdes veidu, kas iet caur uzņēmumu, mēs sāktu ar datu iegūšanu vai datu uztveršana, kas varētu būt datu ievadīšana, bet tas pats varētu būt arī, es datus no ārpuses no uzņēmuma saņemu no kāda datu pārdevēja.
Pēc tam, sākot no datu apkopošanas, mēs pārejam uz datu apkopi, kur es domāju par šo datu standartizēšanu un nosūtīšanu uz vietām, kur tie nepieciešami. Un tad datu izmantošana, faktiskie dati, kur atrodas dati, jūs iegūsit vērtību no datiem.
Un vecajos laikos tas viss tiek darīts vienā individuālā stilā, bet šodien, jūs zināt, tā varētu būt, piemēram, analītiska vide, un pēc tam ārpus tā - arhīvs, veikals, kurā mēs ieliekam datus, kad mēs vairs to nedarām. tas ir vajadzīgs, un, visbeidzot, attīrīšanas veida process. Kā, jūsuprāt, datu modelēšana ir piemērota visa šī datu dzīves cikla pārvaldībai?
Rons Huizenga: Tas ir ļoti labs jautājums, un viena lieta, kurai man šodien vispār nebija laika iedziļināties sīkumos, ir tas, par ko mēs patiesībā sākam runāt, ir datu līnija. Tātad, ko mēs patiesībā spējam darīt, ir tas, ka mūsu rīkos ir datu cilmes iespējas, un, kā es saku, mēs faktiski to varam iegūt no ETL rīkiem, bet jūs to varat arī kartēt, tikai zīmējot arī ciltsrakstu. Jebkurā no šiem datu modeļiem vai datu bāzēm, ko esam tverti un ielikuši modeļos, mēs varētu atsaukties uz konstrukcijām, kas parādītas mūsu datu cilmes diagrammā.
Tas, ko mēs varam darīt, ir piesaistīt datu plūsmu, kā jūs sakāt, no avota uz mērķi un visā dzīves ciklā, kā šie dati tiek cauri caur dažādām sistēmām un ko jūs atradīsit, ņemsim darbiniekus 'dati - tas ir viens no maniem favorītiem, kura pamatā ir projekts, kuru darīju pirms gadiem. Es strādāju ar organizāciju, kurā bija darbinieku dati 30 dažādās sistēmās. Tas, ko mēs tur beidzām darīt - un Rebekas izleca datu cilmes slaids - šeit ir diezgan vienkāršots datu cilmes slaids, taču mēs to varējām panākt, lai ieviestu visas datu struktūras, atsauktu tās uz diagrammu, un tad mēs faktiski var sākt aplūkot, kādas ir plūsmas starp, un kā šīs dažādās datu vienības ir savstarpēji saistītas plūsmā? Un mēs arī varam to pārsniegt. Šī ir daļa no šeit redzamās datu plūsmas vai cilmes diagrammas. Ja vēlaties pārsniegt to, mums ir arī šī komplekta biznesa arhitektu daļa, un tur attiecas arī tas pats.
Jebkurai no datu struktūrām, ko esam iemūžinājuši datu modelēšanas vidē, uz tām var atsaukties biznesa modelēšanas rīkā, lai pat biznesa modeļa diagrammās vai biznesa procesa diagrammās jūs varētu atsaukties uz atsevišķiem datu krājumiem, ja vēlaties iziet no datu modelēšanas vide, un, kamēr jūs tos izmantojat biznesa procesa modeļa mapēs, jūs pat varat norādīt arī CRUD tajos, kā šī informācija tiek patērēta vai ražota, un tad mēs varam sākt ģenerēt tādas lietas kā ietekmes un analīzes ziņojumi un diagrammas.
Tas, ko mēs vēlamies sasniegt, un mums jau ir daudz iespēju, taču viena no lietām, kāda mums ir, ir kā sava veida vārtu stabs, uz kuru mēs skatāmies, turpinot attīstīt savus instrumentus, kas iet uz priekšu, ir spējīgs izplānot šo visaptverošo, organizācijas datu līniju un pilnu dzīves ciklu.
Malkolms Šišolms: Labi. Rebeka, vai man atļauj vēl vienu?
Rebeka Jozwiak: Es atļaušos tev vēl vienu, Malkolm, iet uz priekšu.
Malkolms Šišolms: Liels tev paldies. Domājot par datu pārvaldību un domājot par datu modelēšanu, kā panākt, lai šīs divas grupas efektīvi darbotos kopā un saprastu viena otru?
Ēriks Mazais: Nu, tas ir interesanti, es domāju, ka tas tiešām ir atkarīgs no organizācijas, un tas atgriežas pie manas iepriekšējās idejas, ka tajās organizācijās, kurās iniciatīvas tika virzītas uz biznesu, mēs tikām piesaistīti. Piemēram, es vadīju datu arhitektūras komandu, bet mēs mēs bijām sasaistīti tieši ar biznesa lietotājiem, un mēs faktiski palīdzējām viņiem aizstāvēt savu datu pārvaldības programmu. Atkal vairāk konsultējoša pieeja, bet tā patiešām ir uzņēmējdarbības funkcija.
Tas, kas jums patiešām nepieciešams, lai to izdarītu, jums ir nepieciešami datu modelētāji un arhitekti, kas patiešām saprot uzņēmējdarbību, var būt saistīti ar biznesa lietotājiem un pēc tam viņiem ir palīdzējuši piecelties pārvaldības procesiem ap to. Uzņēmums vēlas to darīt, bet vispārīgi runājot, mums ir zināšanas par tehnoloģijām, lai palīdzētu viņiem izcelties no šāda veida programmām. Tam patiešām ir jābūt sadarbībai, bet tai jābūt arī uzņēmuma īpašumā.
Malkolms Šišolms: Labi, tas ir lieliski. Paldies.
Dr. Ēriks Mazais: Labi.
Rebeka Jozwiak: Labi, liels paldies. Mērķauditorijas locekļi, es baidos, ka mēs neuzskatījāmies par jūsu jautājumiem, taču es pārliecināšos, ka viņi tiks pārsūtīti attiecīgajam viesim, kurš šodien bija mūsu rindā. Es gribu pateikt lielu paldies Ērikam, Malcolm un Ronam par to, ka viņi šodien bija mūsu viesi. Tie bija lieliski priekšmeti, ļaudis. Un, ja jums patika šodienas IDERA tīmekļa apraide, IDERA nākamajā trešdienā arī apmeklēs Hot Technologies, ja vēlaties pievienoties, apspriežot indeksēšanas un Oracles izaicinājumus, kas ir vēl viena aizraujoša tēma.
Liels paldies, ļaudis, rūpējieties, un mēs tiksimies nākamreiz. Labdien!