Autors: Techopedia Staff, 2016. gada 28. septembris
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.
Rebecca Jozwiak: dāmas un kungi, sveicināti un laipni gaidīti 2016. gada karstajā tehnoloģijā. Šodien mēs diskutējam par “uz uzņēmējdarbību balstītas datu arhitektūras veidošanu”, kas noteikti ir karsta tēma. Mans vārds ir Rebeka Jozwiaka, es būšu jūsu šodienas tīmekļa pārraides vietne. Mēs tweet ar # HotTech16 ar atsauci, tāpēc, ja jūs jau esat čivināt, lūdzu, jūtieties brīvi pievienoties arī šajā. Ja jums ir jautājumi jebkurā laikā, lūdzu, nosūtiet tos uz jautājumu un atbilžu rūti ekrāna apakšējā labajā stūrī, un mēs pārliecināsimies, ka uz viņiem tiks atbildēts. Ja nē, mēs parūpēsimies, lai viesi tos saņemtu 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 to, kā darbojas viņa risinājums. 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 runu un, cerams, arī noteiktu daļu no šīm tēmām, dažas 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 atrisināts un salīdzinoši ātri apstrādāts ar daudzām 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 tekstu, NLP, entītijas iegūšanu, jums ir grafika informācija, kas nāk no vai nu no statistiskajiem modeļiem, vai arī no semantiskās. 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 to redzēsit 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 sava veida informāciju ap to, ko jūs varētu zināt, vai izmantot kādu kontekstu. 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āpēc 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, piemēram, jau esošajām iespējām Runājot par šo lietu, to integrēt, integrēt 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 tiešām ir jākļūst par obligātu. 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, jums ir milzīgs daudzums zinātnisku 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ādus rezultātus un ieguvumus 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 varēsit 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 izsauks kaut ko X un viena 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 dot viņiem tikai daļu no datiem, vēlaties viņiem dot 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, entītiju-attiecību modeļus, kā izmantot varbūt grafu 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 lietot 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 viņiem ir jāiet un pastāvīgi jālabo datu vārdnīcas un atkārtoti jāatjaunina definīcijas un tā tālāk, 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 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, es esmu ieinteresēts redzē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 veikt salīdzinājumu ar dažiem semantiskajiem dzinējiem, kurus redzu šajā nozarē, un lūgt Ronu 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 Jozvejaka: Liels paldies, Ērikai, 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 nedara kļūdas”, bet, kad runa ir par praktisku pielietojumu, pārāk daudz rokas sīkdatņu burkā mēdz atstāt jūs ar daudz salauztu sīkfailu, vai ne?
Ēriks Mazais: Jā, un dīgļi.
Rebeka Jozwiak: Jā. Ar to es došos uz priekšu un nodošu to Malcolm Chisholm. Malkolm, grīda ir tava.
Malcolm Chisholm: 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 patiešām kļuva pieejami uzņēmumiem - teiksim, ap 1964. gadu - šodien, 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. Tas ir tas, kas padara biznesa virzītu datu arhitektūru tik nozīmīgu un mūsdienās tik būtisku. 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 sašutuši lietotāji, 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 v ir paši.
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ēja iegādāties kaut ko, 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, Twitter, Facebook būtu daļa no tā, bet jūs varētu arī apgalvot, ka Walmart ir.
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, ņemot vērā to, 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 neatbilst sistēmu izstrādei, jūs zināt - ūdenskritums, SDLC dzīves cikls - kuras Agile, es vēlētos apgalvot, 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ē, tā parasti būs, vai mana funkcionalitāte darbojas, 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, būdams kāds, kurš ir veicis datu noliktavu projektus un cietis no augšupvērstā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 šeit ir daudz attieksmes, kad ir grūti sasniegt uz uzņēmējdarbību balstītu datu arhitektūru, jo mūs ietekmē procesu orientētības 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, izmantojot IT un operācijas, tāpēc mums tas būtu jāzina, bet patiesībā tas 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 datiem, 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 lejup pa to, 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 pieņēmām. 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ādē, 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ītā 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 nosaka datu bāzes projektu mūsu datu bāzei, 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 uzglabāšanas modeli pārvērš 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ā tāds datu modelētājs 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 datus apvienot 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ādā tradicionālais klients MDM nav. 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 Jozwiaka: 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 jūs sakāt, kur IT tik ilgi turēja grožus un tas vairs nav tikai šis gadījums, un ka kultūrai ir jāmainās. Un esmu diezgan pārliecināts, ka fonā bija suns, kurš tev 100% piekrita. Un ar to es nodošu bumbu Ronam. Esmu ļoti priecīgs 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ā norādīja Ēriks un Malkolms, šī ir ļoti plaša un dziļa tēma, un ar to, par ko mēs šodien runājam, 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 veidojat uz pakalpojumiem orientētu arhitektūru vai citas lietas, modelis patiešām kļūst par notiekošā dzīvības elementu ar visiem metadatiem ap to un ar jūsu biznesu saistītajiem datiem.
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 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ē, jums nav tikai datu bāzes. Jums būs vairākas datu bāzes, datu krātuves, jums būs arī daudz mantojošu 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 viņi ir tikai ceļā. Un mums ir jāizdomā, no kā mēs patiesībā varam atbrīvoties savā vidē, kā arī tas, kas ir noderīgs turpmākajai darbībai. Un tas ir saistīts ar slikto demontāžas stratēģiju. Tā ir šīs pašas lietas neatņemama 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 izmantošana, uzņēmuma pakalpojumu kopnes un šāda veida lietas, 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, vai tie ir tradicionālie dati relāciju datu bāzēs, mums visi šie dati ir jāsaliek kopā, 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 vairāki soļi, kurus mēs vēlamies darīt. Pirmkārt, jūs ejat iekšā, un jums, iespējams, nav šo plānu, 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ēlreiz dokumentētu un definētu, un tur mēs savus datus varam klasificēt sīkāk ar pielikumiem, 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 esmu runājis 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. Diezgan ātri runāšu par reverso inženieriju. Es jau esmu devis jums to ļoti ātru uzsvaru. 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 no jaunajiem datu avotiem, 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 procesu modelī, par ko mēs runāsim nākamreiz.
Š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 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, jo 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 piemērs, varbūt cits ir Oracle piemērs. Mums ir visas iespējas to visu sasaistīt vienā un tajā pašā modelēšanas vidē. Un šeit es atkal esmu ieguvis faktisko datu noliktavas modeli, kas atkal var atrasties tajā pašā modelēšanas vidē vai arī mums tas var būt krātuvē un sasaistīt arī dažādās lietās.
Tas, ko es patiešām gribēju jums parādīt šajā sakarā, ir dažas citas lietas un citi to 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.
Tagad pieņemsim, ka mēs esam arī stropu savā vidē. Ja mēs atgriežam inženieri no stropa vides - un mēs varam virzīt uz priekšu un atpakaļ inženierus no stropu ar šo tieši 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 ir atšķirīgi. 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 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ā. .
Ņemsim vēl vienu, kas mazliet atšķiras. 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 neeksistē tradicionālajā relāciju apzīmējumā. Tas, ko mēs šeit izdarījām, 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 kardinālisms nozīmē, ka izdevējā, ja mēs sekojam šīm attiecībām, mums ir iegultas adreses objekts. Jautājot JSON, mēs esam noskaidrojuši, ka tā ir tieši tāda pati objektu struktūra, kas iegulta patronim, bet faktiski tā ir iegulta kā objektu masīvs. Mēs to redzam ne tikai caur savienotājiem, bet arī, aplūkojot faktiskās entītijas, jūs redzēsit, ka jūs redzat adreses patronim, kas to arī klasificē 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 ievedu to 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 vidi, kuras mēs faktiski varam ieviest, izmantojot šos metadatus. Ja man šeit iet cauri un es negrasos veltīt laiku nevienam no viņiem, 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, bet ne mazāk svarīgi, es arī gribu runāt par to, ka mēs nevaram aizmirst par faktu, ka mums ir vajadzīgi citi konstrukciju veidi, 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 jaudīgas spējas, ar kurām mēs to visu sašujam.
Es sākšu pāriet uz šo vienu, jo šobrīd esmu 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 došos ātri pārspēt dažus slaidus šeit, 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, saīsinājumus katram, un mēs varam 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. Apskatot ekrānuzņēmumu labajā pusē, jūs redzēsit, ka no avota nosaukumiem ir saīsināti nosaukumi, un, kad mēs esam piemērojuši nosaukš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, vai mēs tiešām to varam atsaukties, darot visādas 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.
Atkal šeit ir piemērs tam, kā tas izskatās, 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, ja 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 Universal Mappings. 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 saistī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ā, lai, 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 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. Skaistums ir tas, 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 darāt HIPAA vai kādu citu no turienes 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, kas attiecas arī uz mums, ir tas, kad mūsu komandas servera vārdnīcā ir šie vārdnīcas termini. Šis 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, ja patērējam pašu informāciju ar visiem vārdnīcas vārdiem, kas tur ir. 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 lieli dati, tradicionālie relāciju dati, dokumentu krājumi 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. Un tas viss ir saistīts ar 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. Mums šodien ir iespēja 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 ar to ir pietiekami, lai apetīti uzkurinātu, lai mēs varētu iesaistīties daudz dziļākās sarunās, sadalot dažas no šīm tēmām, virzoties nākotnē. Paldies par jūsu veltīto laiku, un jums ar prieku, Rebeka.
Rebecca Jozwiak: Paldies, Ron, tas bija fantastiski, un man ir diezgan daudz jautājumu no auditorijas, bet es vēlos dot mūsu analītiķiem iespēju iedziļināties zobos 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 slidkalniņam, kāpēc jūs vispirms nedrīkstat iet 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 Jozvejaka: 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 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ā jums, puišiem, 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ātie tipi dokumentu glabātavām un arī šāda veida lietām. Mēs faktiski esam atšķīrušies no tikai tīra relāciju apzīmējuma, mēs faktiski esam pievienojuši papildu apzīmējumus arī šiem citiem veikaliem.
Ē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 TopBraid rīks vai esmu kaut ko izdarījis Protēžā vai, kā jūs zināt, piemēram, 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 veidošanu un izmantot tas?
Rons Huizenga: Mēs faktiski skatāmies, kā mēs varam rīkoties ar grafikiem. Mūsdienās mēs tieši nedarbojamies ar grafiku datu bāzēm un šāda veida lietām, bet mēs meklējam veidus, kā mēs to varam izdarīt, lai paplašinātu mūsu 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 paplašinājumus šiem tiltiem arī konkrētām platformām. Ja tas ir jēga, tas ir nepārtraukts un nepārtraukts darbs, lai sāktu aptvert daudz šo jauno konstrukciju un dažādās platformas. Bet es varu teikt, ka mēs noteikti to darām. Tie sīkumi, kurus es parādīju, piemēram, MongoDB, un šāda veida lietas, mēs esam pirmie datu modelēšanas pārdevē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 teikt, ka š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 redzēsit, redzēsit visas atšķirīgās izpausmes, jo jūs tos esat savienojis.
Ēriks Mazais: Labi, lieliski, jā, sapratu. Šajā ziņā, vai ir droši apgalvot, ka tas ir tāds pats kā daži 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 parunā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, ko cilvēki var izmantot arī. Un universālo kartējumu izmantošana ar tiem būtu ļoti spēcīgs veids, kā to izdarīt.
Rebeka Jozviaka: 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?
Malcolm Chisholm: 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ēšana - un es nedomāju izvēlēties dažus no modelētājiem, bet es tik un tā darīšu - vai dažiem ļaudīm joprojām ir iespaids, ka datu modelētājs patiešām ir vārtsarga veida loma, piemēram, mēs definējam, kā tā darbojas, mēs esam sargi, kas pārliecinās, ka viss ir pareizi.
Tagad tam ir kāds aspekts, kas jums jāpārliecinās, vai 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 diezgan acīmredzami to atklāju, konsultējoties - vai jums ir jākļūst par starpnieku, tāpēc šie cilvēki ir jāapvieno.
Tas vairs nebūs 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 var reāli 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?
Malcolm Chisholm: Jā, es tam piekrītu. Jūs zināt, es domāju, ka atvieglošanas prasmes ir kaut kas ļoti ieteicams 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 patiešā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 it kā novērsušies 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.
Malcolm Chisholm: Tāpēc es domāju, ka tas ir ļoti interesants punkts. 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 savā 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.
Malcolm Chisholm: Pareizi, un tagad vēl viena joma, kurā esmu cīnījusies, ir tā, ko es saucu 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ūšana vai datu uztveršana, kas varētu būt datu ievadīšana, bet tas pats varētu būt arī, es datus no cita uzņēmuma iegūstu no uzņēmuma.
Pēc tam, sākot ar datu apkopošanu, 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 punkti, 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 notverti un ielikuši modeļos, mēs varētu atsaukties uz konstrukcijām, kas ir redzamas 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 arī norādīt 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 uz priekšu, ir spējīgs izplānot šo visaptverošo, organizācijas datu līniju un pilnu dzīves ciklu.
Malcolm Chisholm: Labi. Rebeka, vai man atļauj vēl vienu?
Rebeka Jozwiak: Es atļaušos jums vēl vienu, Malcolm, iet uz priekšu.
Malcolm Chisholm: Liels 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ūru komanda, bet mēs bijām sasaistīti tieši ar biznesa lietotājiem, un mēs patiesībā palīdzējām viņiem izveidot 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 biznesu, var būt saistīti ar biznesa lietotājiem un pēc tam ir palīdzējuši viņiem aizstāvēt pārvaldības procesus 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ā.
Malcolm Chisholm: Labi, tas ir lieliski. Paldies.
Dr Eric Eric: Labi.
Rebeka Jozwiaka: Labi, liels paldies. Auditorijas locekļi, es baidos, ka mēs neuzskatījāmies par jūsu jautājumiem, bet 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!
