A Techopedia munkatársai, 2016. szeptember 28
Elvihető: Rebecca Jozwiak a házigazda adatrögzítési megoldásait tárgyalja Eric Little-ről az OSTHUS-ról, Malcolm Chisholm-nak, az első San Francisco-i partnernek és Ron Huizenga-nak az IDERA-ról.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Rebecca Jozwiak: Hölgyeim és uraim, üdvözlet és üdvözlet a 2016-os Hot Technologies-ben. Ma az „Üzleti alapú adat-architektúra felépítése” témát tárgyaljuk, amely feltétlenül egy forró téma. A nevem Rebecca Jozwiak, a házigazda lennék a mai internetes közvetítésben. Tweetelünk a # HotTech16 hashtaggal, tehát ha már a Twitteren vagy, kérjük, bátran csatlakozzon ehhez is. Ha bármikor kérdése van, kérjük, küldje el őket a képernyő jobb alsó sarkában található Kérdések és válaszok ablaktáblába, és mi gondoskodunk arról, hogy válaszokat kapjanak. Ha nem, akkor gondoskodunk arról, hogy vendégeink megkapják az Ön számára.
Tehát ma van egy igazán izgalmas felállás. Nagyon sok nehéz ütõ van ma velünk. Van Eric Little, az OSTHUS adattudományi alelnöke. Van Malcolm Chisholm, az innovációs vezérigazgató-helyettes, ez egy igazán nagyszerű cím a First San Francisco Partners számára. És van Ron Huizenga, az IDERA vezető termékmenedzsere. És tudod, az IDERA valóban teljes adatkezelési és modellezési megoldásokkal rendelkezik. És ma bemutat egy bemutatót arról, hogyan működik a megoldása. De mielőtt odajutunk, Eric Little, átadom a labdát neked.
Eric Little: Oké, nagyon köszönöm. Tehát átmegyek itt néhány olyan témát, amelyek szerintem egy kicsit kapcsolódnak Ron beszédéhez, és remélhetőleg ezen témák némelyikére is készítik a színpadot, néhány kérdésre és válaszra.
Tehát az, ami érdekel az IDERA dolgában, az, hogy szerintem helyesen rámutatnak arra, hogy manapság az összetett környezet valóban sok üzleti értéket vezet. És összetett környezetek alatt összetett adatkörnyezetekre gondolunk. És a technológia valóban gyorsan halad, és nehéz lépést tartani a mai üzleti környezettel. Tehát azok az emberek, akik a technológiai terekben dolgoznak, gyakran látják, hogy vannak olyan ügyfelek, akiknél problémák merülnek fel: „Hogyan használhatom a nagy adatokat? Hogyan beépíthetem a szemantikát? Hogyan kapcsolhatom össze az új dolgok némelyikét a régebbi adatokkal? ”És így tovább, és ez a fajta vezet bennünket manapság ebbe a négy nagy adatforrásba, amelyek sokan nagyon ismerkednek meg, és megértem, hogy négynél több is lehet. néha - akár nyolc vagy kilenc is láttam -, de általában, amikor az emberek olyan dolgokról beszélnek, mint nagy adatok, vagy ha nagy adatokról beszélnek, akkor általában valami olyanra néznek, ami valamilyen vállalati méretű. És így az emberek azt fogják mondani: oké, nos, gondolkodjon az adatainak mennyiségén, amely általában a középpontban áll - éppen ennyit kell megtenni. Az adatok sebességének attól függ, hogy milyen gyorsan tudok mozogni, vagy milyen gyorsan tudok lekérdezni, vagy megkapni a válaszokat, és így tovább. És személy szerint úgy gondolom, hogy ennek bal oldala valami olyasmit old meg, amelyet viszonylag gyorsan kezelnek sokféle megközelítés. De a jobb oldalon nagyon sok fejlesztési képességet és sok új technológiát látok, amelyek valóban előtérbe kerülnek. És ez valójában köze van a harmadik oszlophoz, az adatfajtához.
Tehát más szavakkal manapság a legtöbb vállalat strukturált, félig strukturált és strukturálatlan adatokat keres. A képadatok forró témagé válnak, így a számítógépes látásmód használata, a képpontok megnézése, a szöveg lekaparása, az NLP, az entitás kibontás, grafikon információkkal rendelkeznek, amelyek akár statisztikai modellekből származnak, akár szemantikusból származnak. modellek, rendelkeznek relációs adatokkal, amelyek léteznek a táblákban, és így tovább. És tehát az összes ilyen adat összevonása és az összes különféle típus valóban nagy kihívást jelent, és ezt láthatja, tudod, a Gartnerben és más emberekben, akik valamilyen módon követik az iparág trendeit.
És akkor a végső dolog, amiről az emberek nagy adatokban beszélnek, gyakran a szóhasználat fogalma, amely valójában az Ön adatainak bizonytalansága, azok homályossága. Mennyire tudja, mi az adatai, mennyire tudja megérteni, mi van benne, és tudja? Hasznos lehet a statisztikák felhasználásának képessége és az a képesség, hogy valamilyen típusú információt felhasználjon annak körül, amit tudhat, vagy valamilyen összefüggést használjon. És tehát az a képesség, hogy így nézzük meg az adatokat, figyelembe véve azt, hogy mekkora van, milyen gyorsan kell áthelyezni vagy megszerezni, az összes típusú adatot, amely a vállalkozásában rendelkezhet, és mennyire biztos benne, hogy hol van, mi az, milyen minőségű, és így tovább. Ez valóban nagy, összehangolt erőfeszítéseket igényel sok ember között az adatok hatékony kezelése érdekében. Az adatok modellezése ezért egyre fontosabb a mai világban. Tehát a jó adatmodellek valóban nagyon sok sikert eredményeznek a vállalati alkalmazásokban.
Adatforrások különböző forrásokból származnak, például amint mondtuk, ami valóban sokféle integrációt igényel. Tehát mindezt összehúzva nagyon hasznos lehet a lekérdezések futtatása, például számos típusú adatforrás között, és az információk visszahúzása. De ahhoz, hogy ezt megtegye, jó leképezési stratégiákra van szüksége, így valódi kihívás lehet az ilyen adatok feltérképezése és az ezekkel való leképezés. És akkor megvan ez a kérdés, hogy hogyan kapcsolhatom össze örökölt adataimat az összes új adatforrással? Tehát tegyük fel, hogy van grafikonom, elviszem az összes relációs adatamat és beillesztem grafikonba? Általában ez nem jó ötlet. Szóval hogyan lehet az emberek kezelni a folyamatban lévő összes ilyen adatmodellet? Az elemzést valóban sok ilyen típusú adatforráson és kombináción kell elvégezni. Tehát a válaszok, amelyek ebből adódnak, azokra a válaszokra, amelyekre az embereknek szükségük van a jó üzleti döntések meghozatalához, kritikus fontosságúak.
Tehát ez nem csak az épületgépészetről szól a technológia kedvéért, ez tényleg az, mit fogok csinálni, mit tudok csinálni vele, milyen elemzést tudok futtatni, és tehát a képességet, ahogy már tényleg nagyon fontos, hogy ezeket a dolgokat összevonjam, integráljuk. És az ilyen típusú elemzések egyike például olyan egyesített keresésekre és lekérdezésekre fut. Ez valóban kötelezővé válik. A lekérdezéseit általában többféle forrásba kell foglalni, és az információkat megbízhatóan kell visszavonni.
Az egyik kulcsfontosságú elem, amely gyakran, különösen az emberek, olyan kulcsfontosságú dolgokat fog megvizsgálni, mint például a szemantikai technológiák - és remélem, hogy Ron az IDERA megközelítésben egy kicsit beszélni fog az - hogyan választja el vagy kezeli a az adatok modellrétege magából az adatrétegből, abból a nyers adatból? Tehát az adatrétegnél lehet, hogy vannak adatbázisai, lehet, hogy vannak dokumentumadatai, munkalap-adatai, képadatai is. Ha olyan területeken tartózkodsz, mint a gyógyszeripar, hatalmas mennyiségű tudományos adatot kapsz. És ezután az emberek általában keresnek egy módszert egy olyan modell felépítésére, amely lehetővé teszi számukra az adatok gyors integrálását, és amikor ténylegesen adatokat keres, akkor nem akarja, hogy az összes adat felkerüljön a modellrétegbe., amit a modellrétegre keres, az az, hogy szép logikai ábrázolást adjon a dolgokról, a közös szótárakról, az entitások és kapcsolatok közös típusairól, valamint arról a képességről, hogy valóban eljuthasson az adatokhoz, ahol van. Tehát el kell mondania, mi az, és meg kell mondania, hogy hol van, és el kell mondania, hogyan kell letölteni és visszahozni.
Tehát ez egy olyan megközelítés, amely meglehetősen sikeres volt a szemantikai technológiák előremozdításában, amely olyan terület, ahol nagyon sokat dolgozom. Tehát egy kérdés, amelyet Ronnak akartam felvetni, és amely szerintem hasznos lesz a Kérdések és válaszok részben, az, hogy hogyan hajtja végre ezt az IDERA platform? Tehát a modellréteg valóban külön van-e az adatrétegtől? Integráltabbak? Hogyan működik ez, és milyen eredmények és előnyök vannak néhány megközelítésükből? Ezért a referenciaadatok valóban kritikusak is. Tehát ha ilyen típusú adatmodellekre lesz szükséged, ha összevág, és kereshet a dolgok között, akkor valóban jó referenciaadatokkal kell rendelkeznie. De a probléma az, hogy a referenciaadatokat nagyon nehéz fenntartani. Tehát gyakran a standardok önmagában történő megnevezése nehéz kihívás. Az egyik csoport valamit X-nek hív, az egyik csoport valamit Y-nek hív, és most felmerül a problémád, hogyan talál valaki X-et és Y-t, amikor ilyen típusú információkat keresnek? Mivel nem akarja, hogy csak az adatok egy részét adja meg nekik, mindent meg szeretne adni nekik. Ugyanakkor a feltételek megváltoznak, a szoftver elavulttá válik, és így tovább: hogyan tudod fenntartani és fenntartani ezeket a referenciaadatokat idővel?
És ismét, a szemantikai technológiák, amelyek kifejezetten taxonómiákat és szótárakat, adat-szótárakat használnak, biztosítottak egy szokásos térbeli módot ennek végrehajtására, amely valóban nagyon robusztus, bizonyos típusú szabványokat alkalmaz, de az adatbázis-közösség ezt egy hosszú ideje is, csak különböző módon. Úgy gondolom, hogy itt az egyik kulcsfontosságú az, hogy gondolkozzunk, hogyan lehet esetleg entitás-relációs modelleket használni, hogyan lehet grafikonmodelleket használni, vagy valamilyen típusú megközelítést, amely valóban remélhetőleg egy szabványos távolságot biztosít a referenciaadatok kezelésére. És akkor természetesen, ha megvan a referenciaadatok, a leképezési stratégiáknak sokféle nevet és entitást kell kezelniük. Tehát a téma szakértői gyakran szeretik használni a saját kifejezéseiket.
Tehát ebben a kihívás mindig az, hogy hogyan adsz információt valakinek, de mennyire releváns annak, ahogy beszélnek róla? Tehát egy csoportnak lehet egy módja annak, hogy valamit megvizsgáljon, például lehet, hogy egy gyógyszer mellett dolgozó gyógyszerész, és ugyanabban a gyógyszeren dolgozó szerkezeti biológus lehet, és ugyanazon típusú entitásoknak különböző nevei lehetnek amelyek a te meződdel kapcsolatosak. Ki kell találnia a személyre szabott terminológiák összeillesztésének módjait, mert a másik megközelítés az, hogy az embereket arra kell kényszeríteni, hogy hagyják el a kifejezésüket, és használják valakinek másikat, ami gyakran nem tetszik. Egy másik szempont itt a nagyszámú szinonimák kezelése megnehezedése, tehát sok ember adataiban sok különféle szó található, amelyek ugyanazra a dologra utalhatnak. Van egy referencia-problémája ott, a sok-sok kapcsolat használatával. A speciális kifejezések iparonként különböznek, tehát ha ilyen átfogó megoldást kínál az ilyen típusú adatkezelésre, mennyire könnyen hordozható az egyik projektből vagy az egyik alkalmazásból a másikba? Ez újabb kihívás lehet.
Az automatizálás fontos, és ez szintén kihívás. A referencia adatok kézi kezelése drága. Drága, ha manuálisan kell feltérképezni, és drága, ha a téma szakértői abbahagyják a napi munkájukat, és be kell lépniük, és folyamatosan javítaniuk kell az adat-szótárakat, újra kell frissíteni a definíciókat és így tovább, és így tovább. A megismételhető szótárak valóban sok értéket mutatnak. Tehát ezek gyakran olyan szavak, amelyek a szervezeten kívül találhatók. Például, ha nyersolajjal dolgozik, akkor lesznek bizonyosfajta szótárak, amelyeket kölcsönözhet nyílt forrású helyekről, ugyanaz a gyógyszerkészítmény, ugyanaz a bankipar és a pénzügyi, ugyanaz a sok ilyen típusú terület. Az emberek újrahasznosítható, általános, megismételhető szókincseket hoznak oda az emberek számára.
És ismét, az IDERA eszközt nézve, kíváncsi vagyok, hogyan látják, hogyan kezelik ezt a fajta szabványok felhasználása szempontjából. A szemantika világában gyakran lát olyan dolgokat, mint a SKOS modellek, amelyek legalább a kapcsolatok szélesebb körű / szűkebb szabványait nyújtják, és ezeket a dolgokat nehéz lehet elvégezni az ER modellekben, de tudod, nem lehetetlen, ez csak attól függ, hogy ennek gépek és az összeköttetés, amelyet az ilyen típusú rendszerekben kezelni lehet.
Tehát végül csak szerettem volna összehasonlítani néhány olyan szemantikai motorral, amelyet az iparban látok, és kérdezem meg Ronot, hogy egy kicsit tedd rá, hogy beszéljen arról, hogy az IDERA rendszerét hogyan használják bármilyen szemantikai technológiával összefüggésben. Integrálható-e hármas üzletekkel, gráf-adatbázisokkal? Mennyire könnyű használni a külső forrásokat, mert a szemantikai világban az ilyen dolgok gyakran kölcsönözhetők a SPARQL végpontok használatával? Az RDF vagy OWL modelleket közvetlenül a modelljébe importálhatja - utalhat rájuk - így például a gén-ontológia vagy a protein-ontológia, amelyek valahol a saját térben élhetnek, saját irányítási struktúrájukkal, és egyszerűen mindet vagy ennek egy része, amire szükségem van a saját modelleimbe. És kíváncsi vagyok arra, hogy az IDERA hogyan közelíti meg ezt a kérdést. Mindent kell karbantartania belsőleg, vagy vannak módok más típusú szabványos modellek használatához, és behúzásukhoz, és hogyan működik ez? És az utolsó dolog, amelyet itt említettem, az, hogy ténylegesen mekkora kézi munka folyik a szószedetek és a metaadat-tárhelyek készítésében?
Tehát tudom, hogy Ron megmutatja nekünk néhány ilyen demó dolgot, amelyek igazán érdekesek lesznek. De az ügyfelekkel való konzultációt gyakran tapasztalom, hogy sok hiba történik, ha az emberek saját definíciójukat vagy saját metaadataikat írják. Így hibásan ír el szöveget, kövér ujjhibákat kap, ez egy dolog. Olyan embereket is kap, akik, tudod, csak a Wikipediaból vagy egy olyan forrásból származnak, amely nem feltétlenül olyan minőségi forrást jelent, amelyet a definíciójában megkívánhat, vagy a definíció csak egy személy szempontjából áll, tehát nem teljes, és akkor sem világos hogyan működik az irányítási folyamat. A kormányzás, természetesen, nagyon-nagyon nagy kérdés, bármikor, amikor referenciaadatokról beszélünk, és bármikor arról beszélünk, hogy ez hogyan illeszkedik valaki törzsadatához, hogyan fogják használni a metaadataikat, és hamar.
Szóval csak ki akartam húzni ezeket a témákat. Ezeket az elemeket látom az üzleti térben sokféle típusú tanácsadói megbízással és sok különböző területtel, és nagyon érdekel, hogy Ron mit fog mutatni nekünk az IDERA-val, hogy rámutasson ezekre a témákra . Szóval nagyon köszönöm.
Rebecca Jozwiak: Nagyon köszönöm, Eric, és nagyon szeretem a megjegyzését, hogy sok hiba fordulhat elő, ha az emberek saját definíciókat vagy metaadatokat írnak. Tudom, hogy az újságíró világban van egy mantra, miszerint „sok szem elhárítja a hibákat”, de amikor a gyakorlati alkalmazásokra gondolunk, akkor a sütőedény túl sok keze általában sok törött sütit hagy maga után, igaz?
Eric Little: Igen, és baktériumok.
Rebecca Jozwiak: Igen. Ezzel megyek előre, és továbbadom Malcolm Chisholmnak. Malcolm, a padló a tied.
Malcolm Chisholm: Nagyon köszönöm, Rebecca. Szeretnék egy kicsit átnézni azt, amit Eric beszélt, és hozzá néhány olyan megfigyelést, amelyekre, tudod, Ron valószínűleg reagál, még akkor is, amikor „Az üzleti vezetésű adat-architektúra felé ”- mit jelent az, hogy vállalkozást vezessenek, és miért olyan fontos? Vagy csak a hype valamilyen formája? Nem hiszem, hogy az.
Ha megnézzük, mi történik azóta, akkor tudod, hogy a nagygépes számítógépek valóban a vállalatok számára elérhetők voltak - mondjuk, 1964 körül - a mai napig, láthatjuk, hogy sok változás történt. Ezeket a változásokat összefoglalva úgy fogalmazom meg, mint az áttérést a folyamatközpontúságról az adatközpontútra. És ez teszi az üzleti alapú adat-architektúrákat olyan fontosak és relevánsak manapság. És azt hiszem, tudod, hogy ez nem csak egy szószó, hanem valami teljesen valóságos is.
De egy kicsit jobban értékelhetjük, ha belemerülünk a történelembe, tehát az idővel visszamenőleg, az 1960-as évekre visszatekintve, majd egy ideig ezt követően a mainframek domináltak. Ezek aztán helyet adtak a PC-knek, ahol valójában lázadtak a felhasználók, amikor a PC-k bejöttek. A centralizált IT elleni lázadás, akik szerintük nem feleltek meg igényeiknek, nem voltak elég agilisak. Ez gyorsan hozta létre az elosztott számítástechnikát, amikor a PC-ket összekapcsolták. És akkor kezdődött az internet, amely elmosta a vállalkozás határait - az adatcsere terén most már kapcsolatba léphet a magán kívüli felekkel, ami még nem történt. És most belépettünk a felhő és a nagy adatok korszakába, ahol a felhő olyan platformokat jelent, amelyek valóban árucikké teszik az infrastruktúrát, és így IT-ről elhagyjuk a nagy adatközpontok működtetésének szükségességét, mert tudod, mi A felhőkapacitást rendelkezésére bocsátottuk, és egyidejűleg azokkal a nagy adatokkal, amelyekről Eric, tudod, annyira ékesszólóan beszélt. És általánosságban, amint látjuk, ahogy a technológiaváltás bekövetkezett, adatközpontúbbá vált, mi jobban törődünk az adatokkal. Az internethez hasonlóan az adatok cseréjének módja is. Nagy adat esetén maga az adat négy vagy több v-je.
Ugyanakkor, és ami talán még ennél is fontosabb, az üzleti felhasználási esetek eltolódtak. A számítógépek első bevezetésekor ezeket automatizálták például a könyvek és az iratok számára. És bármi, ami kézi folyamat volt, amely magában foglalta a főkönyveket vagy hasonló dolgokat, lényegében házon belül volt programozva. Ez a 80-as években eltolódott az operációs csomagok elérhetősége felé. Nem kellett többé megírnia a saját bérszámfejtését, vásárolhatott valamit, ami megcsinálta. Ez sok IT-osztályban akkoriban jelentős leépítést vagy szerkezetátalakítást eredményezett. De akkor az üzleti intelligencia, többek között az adattárházak, többnyire a 90-es években jelent meg. A dotcom üzleti modellek követték, amelyek természetesen nagy őrület voltak. Aztán MDM. Az MDM használatával láthatja, hogy nem az automatizálásra gondolunk; csak arra koncentrálunk, hogy az adatokat mint adatokat kurázzuk. És akkor az elemzés, amely azt az értéket képviseli, amelyet ki lehet szerezni az adatokból. Az elemzésen belül olyan sikeres vállalkozásokat látsz, amelyek fő üzleti modellje az adatok körül forog. A Google, a Twitter, a Facebook része lenne ennek, de azt is érvelheti, hogy a Walmart az.
Tehát a vállalkozás most valóban az adatokra gondol. Hogyan lehet kiértékelni az adatokat? Hogyan vezethetik az adatok az üzletet, a stratégiát, és mi vagyunk az adatok aranykorában? Tehát, figyelembe véve, hogy mi történik adat-architektúránkban, ha az adatokat már nem csupán az alkalmazások hátsó részéből fakadó kipufogógáznak tekintjük, hanem ténylegesen központi üzleti modellekben? Nos, a probléma egy része, amely az IT elérésével szembesül, valóban megragadt a múltban a rendszerfejlesztés életciklusával kapcsolatban, amely annak következménye volt, hogy gyorsan meg kellett kezelni ezt a folyamat-automatizálási szakaszt az informatika korai korában, és a projektek hasonló dolog. Az IT-hez - és ez egy kicsit karikatúra -, de azt akarom mondani, hogy az üzleti-orientált adat-architektúra megszerzésének néhány akadálya az, hogy valamiféle kritikát nélkül elfogadtunk egy informatikai kultúrát. amely egy eltelt korból származik.
Tehát minden egy projekt. Mondja el részletesen az igényeit. Ha a dolgok nem működnek, az azért van, mert nem mondtad el a követelményeidet. Nos, ez ma nem működik az adatokkal, mert nem automatizált kézi folyamatokkal, vagy, tudjuk, az üzleti folyamatok műszaki átalakításával kezdjük, nagyon gyakran már meglévő termelési adatokkal kezdjük, amelyeket megpróbálunk kiértékelni az értéket. De senki, aki szponzorál egy adatközpontú projektet, valóban nem érti meg az adatokat alaposan. Meg kell tennünk az adatok felfedezését, a forrás adatok elemzését. És ez nem igazán felel meg a rendszerfejlesztésnek, tudod - vízesés, SDLC életciklus - amelynek az Agile, azt állítanám, egyfajta jobb verziója.
És a középpontban a technológia és a funkcionalitás áll, nem az adatok. Például, amikor tesztelést tesztelési szakaszban végezzünk, akkor általában ez lesz, működik-e a funkcionalitásom, mondjuk az ETL-én, de nem teszteljük az adatokat. Nem teszteljük a forrás adatok beérkezésére vonatkozó feltételezéseinket. Ha igen, akkor talán jobb formában lennénk, és mint valaki, aki adatraktári projekteket hajtott végre, és szenvedett az előző szakaszban bekövetkező változásoknak köszönhetően az ETL-ek felrobbantására, ezt nagyra értékelném. És valójában, amit látni akarunk, az a folyamatos termelési adatminőség-ellenőrzés előzetes lépéseként történő tesztelés. Tehát nagyon sok olyan hozzáállás van, ahol nehéz elérni az üzleti alapú adat architektúrát, mivel a folyamat-központúság korszakától függünk. Át kell állnunk az adatközpontúság felé. És ez nem egy teljes átmenet, tudod, még mindig sok a folyamat elvégzése, de valójában nem adatközpontúan gondolkodunk, amikor szükségünk van rá, és a körülményekre, amelyek valóban valóban mi vagyunk erre kötelezett.
Most a vállalkozás felismeri az adatok értékét, fel akarják oldani az adatokat, szóval hogyan fogjuk ezt csinálni? Szóval hogyan kell végrehajtani az átmenetet? Nos, az adatokat helyezzük a fejlesztési folyamatok középpontjába. És hagyjuk, hogy az üzleti vállalkozás információs követelményekkel vezesse. És megértjük, hogy senki sem érti a meglévő forrásadatokat a projekt kezdetén. Azt állíthatják, hogy az adatszerkezet és az adatok IT-n keresztül, illetve a műveletek révén jutottak el oda, tehát ezt tudnunk kell, de valójában nem. Ez adatközpontú fejlesztés. Tehát, gondolkodva arról, hogy hol állunk, és hogyan kell adatmodellezést készíteni egy adatközpontú világban, visszajelzési hurkokkal kell rendelkeznünk a felhasználók számára az információszükségletük finomítása szempontjából, mivel adatfelderítést és adatprofilálást végezzünk., előre látja a forrásadatok elemzését, és mivel fokozatosan egyre nagyobb bizonyosságot szerezünk az adatainkkal. És most egy tradicionálisabb projektről beszélek, mint például az MDM hub vagy az adattárház, nem feltétlenül a nagy adatprojektekről, bár ez még mindig áll, azt állítom, elég közel ehhez. Tehát ezek a visszacsatolási körök tartalmazzák az adatmodellezőket, tudod, fokozatosan továbbfejlesztve adatmodellüket és együttműködve a felhasználókkal, hogy megbizonyosodjanak arról, hogy az információigények finomítása annak alapján történik, hogy mi lehetséges, mi elérhető, a forrásadatok alapján, ahogy jobban megértik őket, tehát ez már nem az az eset, amikor az adatmodell olyan állapotban van, amelyben nincs ilyen vagy teljesen megtörtént, fokozatosan kerül a hangsúlyba.
Hasonlóképpen, későbbi szakaszban minőségbiztosításunk van, ahol kidolgozzuk az adatminőség-tesztelés szabályait, hogy megbizonyosodjunk arról, hogy az adatok azokon a paramétereken belül vannak, amelyekre feltételezünk. Bement, Eric a referenciaadatok változására utalt, amelyek történhetnek. Nem akarja, hogy valaha is egyfajta, irányítatlan változás áldozata lehessen ezen a területen, tehát a minőségbiztosítási szabályok beépülhetnek a gyártás utáni folyamatos adatminőség-ellenőrzésbe. Tehát megnézheti, hogy adatközpontúak leszünk-e, és hogy az adatközpontú fejlesztés hogyan különbözik a funkcionalitáson alapuló SDLC-től és az Agile-től. És akkor oda kell figyelnünk az üzleti nézetekre is. Megvan - és ez ismétlődik az, amit Eric mondott - van olyan adatmodell, amely meghatározza az adatbázis történetének tervét, de ugyanakkor szükségünk van azoknak a fogalmi modelleknek, az adatok üzleti nézeteinek, amelyeket hagyományosan nem végeztek el a múlt. Úgy gondolom, néha azt gondoltuk, hogy az adatmodell képes mindent megtenni, de szükségünk van a fogalmi nézetre, a szemantikára, és át kell vizsgálnunk az adatokat, és absztrakciós rétegen keresztül kell azokat átadniuk, amely a tárolási modellt átadja az üzleti vállalkozásnak. Kilátás. És ismét, mindazokról a dolgokról, amelyekről Eric beszélt a szemantika szempontjából, fontos szerepet játszik ez, tehát valójában további modellezési feladatok vannak. Azt hiszem, ez érdekes, ha olyan adatmodellezőként lépett fel a rangsorban, mint én, és ismét valami új.
És végül azt szeretném mondani, hogy a nagyobb építészetnek tükröznie kell ezt az új valóságot. Például a hagyományos ügyfél MDM olyan, rendben van, tegyük ügyfél-adatainkat egy olyan központba, ahol tudjuk, hogy értelmezhetjük azt a back office alkalmazások valóban igazságos adatminősége szempontjából. Ami üzleti stratégiai szempontból ásítás. Ma azonban azon ügyfél-MDM-hubokat vizsgáljuk, amelyekben további ügyfélprofil-adatok vannak benne, nem csak a statikus adatok, amelyeknek valójában kétirányú felületük van az ügyfél tranzakciós alkalmazásaival. Igen, továbbra is támogatják a hátsó irodát, de most már tudunk ügyfeleink ilyen viselkedéséről is. Ez drágább építeni. Ezt bonyolultabb építeni. De üzleti szempontból irányítja, ahogyan a hagyományos ügyfél MDM nem. Ön az üzleti vállalkozás felé orientál, egyszerűbb tervekkel szemben, amelyeket könnyebb megvalósítani, ám az üzleti vállalkozások számára ezt akarják látni. Valóban egy új korszakban vagyunk, és azt hiszem, hogy számos szintre kell reagálnunk az üzleti vezetésű adat-architektúrára, és azt hiszem, hogy nagyon izgalmas idő a dolgok elvégzése.
Szóval köszönöm, vissza neked Rebecca.
Rebecca Jozwiak: Köszönöm Malcolm-nak, és nagyon élveztem az adatmodellekről mondottaikat, hogy táplálják az üzleti nézetet, mert - ellentétben azzal, amit mondtál, ahol az IT olyan sokáig tartotta a kormányt, és ez már nem így van, és hogy a kultúrának meg kell változnia. És biztos vagyok benne, hogy volt egy kutya a háttérben, aki teljes mértékben egyetértett veled. És ezzel átadom a labdát Ronnak. Nagyon izgatott vagyok, hogy látom a bemutatódat. Ron, a padló a tied.
Ron Huizenga: Nagyon köszönöm, és mielőtt belemegyünk ebbe, átmegyek néhány diát, majd egy kicsit egy demót, mert amint Eric és Malcolm rámutattak, ez egy nagyon széles és mély téma, és azzal a kérdéssel, amellyel ma beszélünk, csak lekaparjuk annak felületét, mert oly sok szempont és oly sok dolog van, amelyeket tényleg meg kell vizsgálnunk és meg kell vizsgálnunk egy üzleti vezérelt építészet alapján. És megközelítésünk az, hogy valóban ezt a modell-alapúvá tegyük és valódi értéket nyerjünk ki a modellekből, mivel kommunikációs eszközként és rétegként használhatják őket más rendszerek engedélyezésére. Függetlenül attól, hogy szolgáltatás-orientált architektúrát végez, vagy más dolgot végez, a modell valóban a folyó életévé válik, a körülötte lévő metaadatokkal és az üzleti vállalkozásában található adatokkal.
Amit arról szeretnék beszélni, hogy szinte egy lépést hátrafelé haladok, mert Malcolm megismerte a megoldások fejlődésének történetét és az ilyen típusú dolgokat. Az egyik módja annak, hogy valóban rámutassunk arra, hogy mennyire fontos a megbízható adat-architektúra, egy olyan használati eset, amelybe nagyon gyakran jutottam, amikor konzultációt folytattam, mielőtt termékmenedzsment szerepet vállaltam, vagyis szervezetekbe léptem. akár üzleti átalakítást hajtottak végre, akár csak meglévő rendszerek és ilyen típusú dolgok cseréjét végezték el, és nagyon gyorsan nyilvánvalóvá vált, hogy a szervezetek milyen rosszul értik meg saját adataikat. Ha egy adott felhasználási esethez hasonlót vesz igénybe, függetlenül attól, hogy tanácsadóként lép be, vagy esetleg olyan személy, aki éppen egy szervezettel kezdte meg, vagy a szervezetét az évek során felépítették különböző társaságok felvásárlásával, akkor mit végez up up egy nagyon összetett környezet, nagyon gyorsan, számos új, különféle technológiával, valamint a régi technológiával, az ERP megoldásokkal és minden egyébvel.
Tehát az egyik dolog, amelyet ténylegesen megtehetünk a modellező megközelítésünk során, az, hogy megválaszoljuk a kérdést: hogyan tudom érteni mindezt? Valójában elkezdhetjük az információk összegyűjtését, így a vállalkozás felhasználhatja a megfelelő információk felhasználását. Kiderül, hogy mi van odakint ezekben a környezetekben? Hogyan használhatom a modelleket a szükséges információk kiszámításához és az információk jobb megértéséhez? És akkor megvannak a metaadatok hagyományos típusai az összes különféle dologhoz, például a relációs adatmodellekhez, és szoktuk, hogy olyan dolgokat látunk, mint például a definíciók és az adat-szótárak, tudod, az adattípusok és az ilyen típusú dolgok. De mi lenne azokkal a metaadatokkal, amelyeket rögzíteni szeretne, hogy valóban még több jelentést adjon nekik? Mint például, hogy mely entitások valóban a jelöltek, amelyeknek referenciaadat-objektumoknak kell lenniük, amelyeknek törzsadat-kezelési objektumoknak és az ilyen típusú dolgoknak kell lenniük, és össze kell őket kapcsolniuk. És hogyan folyik az információ a szervezeten keresztül? Az adatok folynak attól, hogy miként fogyasztják őket, mind a folyamat szempontjából, mind az adatok vonalát tekintve az információk üzleti vállalkozásokon keresztüli utazása szempontjából, valamint az, hogy hogyan jutnak el a különféle rendszereken vagy az adattárolókon keresztül, tehát tudjuk amikor az I-megoldásokat vagy az ilyen típusú dolgokat építjük fel, valójában a helyes információkat fogyasztjuk a feladathoz.
És akkor nagyon fontos az a kérdés, hogyan lehet az összes érdekelt felet együttműködni, és különösen az üzleti érdekelteket, mert ezek adják nekünk az adatok valódi jelentését. A vállalkozás a nap végén birtokolja az adatokat. Ők megadják a szókincsek és dolgok meghatározásait, amiről Eric beszélt, tehát szükségünk van egy helyre, hogy mindezt összekapcsoljuk. És úgy csináljuk, mint az adatmodellezés és az adattár-architektúránk.
Érdekel néhány dolgot. Az ER / Studio Enterprise Team Editionről fogok beszélni. Elsődlegesen az adat-architektúra termékről fogok beszélni, ahol az adatmodellezést és az ilyen típusú dolgokat végezzük, de a csomagnak sok más összetevője is van, amelyeket csak nagyon röviden érintek. Látni fogja egy kivonatot az Business Architect-ből, amelyben elkészíthetjük a koncepcionális modelleket, de üzleti folyamatok modelleit is készíthetjük, és ezeket a folyamatmodelleket összekapcsolhatjuk az adatmodellekben lévő aktuális adatok összekapcsolása céljából. Ez tényleg segít abban, hogy összekapcsoljuk ezt a nyakkendőt. A Software Architect lehetővé teszi további konstrukciók készítését, például néhány UML modellezést és az ilyen típusú dolgokat, hogy támogató logikát biztosítsunk azoknak a rendszereknek és folyamatoknak, amelyekről beszélünk. De nagyon fontos, hogy ha lefelé haladunk, megvan a lerakat és a csapatkiszolgáló, és erről mint ugyanazon dolog két felének fogok beszélni. A tárolóban tároljuk az összes modellezett metaadatot, valamint az üzleti metaadatokat az üzleti szószedetek és kifejezések szempontjából. És mivel van ez a lerakat-alapú környezet, akkor ezeket a különféle dolgokat összekapcsolhatjuk ugyanabban a környezetben, és ezeket ténylegesen fogyasztási célokra is felhasználhatjuk, nemcsak a műszaki emberek, hanem az üzletemberek számára is. És így kezdjük el valóban az együttműködést.
És akkor az utolsó darab, amiről röviden beszélek, az, hogy amikor bemegyek ebbe a környezetbe, nem csak az adatbázisok állnak rendelkezésre. Számos adatbázissal, adattárolóval rendelkezel, és rengeteg műtermékkel is fogok rendelkezni, amit én neveznék. Lehet, hogy az emberek Visio-t vagy más ábrákat használtak egyes dolgok feltérképezésére. Lehet, hogy vannak más modellező eszközeik és ilyen típusú dolgok. Tehát, amit megtehetünk a MetaWizard segítségével, az az információ részleges kinyerése és beillesztése a modellbe, aktualizálása és felhasználása, fogyasztása, a jelenlegi módon újrafelhasználása, ahelyett, hogy odakinn ülnénk. Most működő modelljeink aktív részévé válik, ami nagyon fontos.
Amikor belépsz egy szervezetbe, amint mondtam, nagyon sok eltérő rendszer van odakinn, rengeteg ERP-megoldás, eltérő osztályos megoldás. Számos szervezet használ SaaS megoldásokat is, amelyek szintén külső ellenőrzés alatt állnak, így nem tudjuk ellenőrizni az adatbázisokat és az ilyen típusú dolgokat a gazdagépeken, de még mindig tudnunk kell, hogy hogyan néznek ki ezek az adatok, és természetesen a metaadatok körül. Azt is találjuk, hogy sok elavult hagyományrendszer létezik, amelyeket még nem tisztítottak ki annak a projekt-alapú megközelítésnek a miatt, amelyről Malcolm beszélt. Bámulatos, hogy az elmúlt években a szervezetek kiépítik a projekteket, helyettesítik a rendszert vagy a megoldást, de gyakran nincs elegendő projektköltség az elavult megoldások leszereléséhez, tehát most már csak úton vannak. Ki kell találnunk, hogy miben tudunk valóban megszabadulni a környezetünkben, és mi is hasznos a jövőben. És ez kapcsolódik a rossz leszerelési stratégiához. Ez ugyanazon dolog része.
Amit mi is találunk, mivel sok szervezet felépült ebből a különféle megoldásból, az az, hogy sok pont-pont interfészt látunk, sok helyen mozogva sok adatot. Képesek vagyunk ezt ésszerűsíteni, és kitalálni azt az adatvonalat, amelyet röviden említettem korábban, így koherensebb stratégiánkkal rendelkezhetünk, például a szolgáltatásorientált architektúra, a vállalati szolgáltató buszok és az ilyen típusú dolgok felhasználása a helyes információk továbbítása érdekében. egy olyan közzétételi és feliratkozási típusú modellre, amelyet helyesen használunk az üzleti életünk során. És akkor természetesen még valamilyen elemzést kell végeznünk, függetlenül attól, hogy adattárakat, adatkártyákat használunk a hagyományos ETL-sel, vagy néhány új adatlakot használunk. Mindez ugyanahhoz a dologhoz vezet. Az összes adat, függetlenül attól, hogy nagy adat, függetlenül attól, hogy hagyományos adatok-e a relációs adatbázisokban, össze kell vonnunk ezeket az adatokat, hogy kezelni tudjuk őket, és tudjuk, hogy mi a modelljeinkkel foglalkozik.
Megint az a bonyolultság, amelyet megteszünk, az, hogy számos lépést megteszünk, amelyeket meg akarunk tenni. Először is sétálsz be, és előfordulhat, hogy nincsenek azok a tervrajzok, amilyene az információs táj néz. Egy olyan adatmodellező eszközben, mint az ER / Studio Data Architect, először sok fordított mérnöki munkát fog végezni azzal kapcsolatban, hogy mutassuk a kimenő adatforrásokra, hozzuk be őket, majd ténylegesen összekapcsoljuk reprezentatívabbá. modellek, amelyek az egész üzletet képviselik. Fontos az, hogy meg akarjuk-e bontani ezeket a modelleket az üzleti vonalak mentén, hogy kisebb méretű darabokat képezzünk rájuk, amelyekkel üzletembereink is kapcsolatba léphetnek, valamint üzleti elemzőinkkel és más érdekelt felekkel, akik dolgoznak Rajta.
Az elnevezési szabványok rendkívül fontosak, és itt néhány különféle módon beszélek. A szabványok elnevezése abban, hogy hogyan nevezzük a dolgokat modelleinkben. Meglehetősen könnyű ezt megtenni a logikai modellekben, ahol van egy jó elnevezési konvenciónk és jó adatszótárunk a modelleink számára, de emellett sokféle fizikai modellben különféle elnevezési konvenciókat is látunk, amelyeket bevezetünk. fordított mérnök, elég gyakran rövidített neveket és olyan típusú dolgokat látunk, amelyekről beszélni fogok. És ezeket vissza kell fordítanunk olyan értelmes angol nevekre, amelyek az üzleti élet szempontjából értelmesek, hogy megértsük, hogy ezek az adatok melyek a környezetünkben. És akkor az univerzális leképezés az, ahogyan összefűzzük őket.
Ezen felül dokumentálnánk és tovább definiálnánk, és itt az adatokat tovább osztályozhatjuk úgynevezett Mellékletek néven, amelyeken megmutatom neked néhány diát. És akkor bezárva a ciklust, azt az üzleti jelentést akarjuk alkalmazni, amellyel összekapcsoljuk üzleti szótárainkat, és összekapcsolhatjuk azokat a különféle modell-műtermékeinkkel, tehát tudjuk, hogy amikor egy bizonyos üzleti kifejezésről beszélünk, adatunkban a szervezet egészében megvalósult. És végül, már beszéltünk arról a tényről, hogy mindezeknek sok-sok együttműködési és közzétételi képességgel rendelkező adattárra van szükségük, hogy érdekelt feleink ki tudják használni azt. Meglehetősen gyorsan beszélek a fordított tervezésről. Már nagyon gyorsan felhívtam a figyelmet erre. Megmutatom neked egy tényleges bemutatóban, csak hogy megmutassam néhány dolgot, amit be tudunk hozni oda.
És szeretnék beszélni néhány különféle modelltípustól és ábráról, amelyeket az ilyen típusú forgatókönyvek készítenek. Nyilvánvaló, hogy a koncepcionális modelleket sok esetben elkészítjük; Nem fogok sok időt erre költeni. Nagyon szeretnék beszélni logikai modellekről, fizikai modellekről és a modellek speciális típusairól, amelyeket létrehozhatunk. És fontos, hogy ezeket mind ugyanazon a modellező platformon hozzuk létre, hogy összekapcsoljuk őket. Ez magában foglalja a dimenziós modelleket és azokat a modelleket, amelyek felhasználják néhány új adatforrást, például a NoSQL-t, amelyet megmutatok. És akkor hogyan néz ki az adatvonal modell? És hogyan tudjuk ezeket az adatokat egy üzleti folyamatmodellbe illeszteni, erről beszélünk a következőkben.
Itt fogok átváltani egy modellező környezetre, csak hogy nagyon magas és gyors áttekintést kapjak. És azt hiszem, most már látnia kell a képernyőmet. Mindenekelőtt csak egy hagyományos típusú adatmodellről akarok beszélni. És ahogyan azt szeretnénk megszervezni a modelleket, amikor behozzuk őket, azt akarjuk képezni, hogy képesek lebontani őket. Tehát amit a bal oldali oldalon látsz, az ebben a modell fájlban logikai és fizikai modellekkel rendelkezik. A következő dolog az, hogy fel tudjuk-e bontani az üzleti bomlás mentén, tehát ezért látja a mappákat. A világoskék logikai modellek és a zöld fizikai modellek. És le is fúrhatunk, tehát az ER / Stúdión belül, ha üzleti bomlásról van szó, akkor menjen annyi szintet mélyre vagy almodellre, amennyit csak akar, és az alsóbb szinteken végrehajtott változtatások automatikusan tükrözik a magasabb szinteket. Így nagyon gyorsan modellező környezetré válik.
Valamit, amit rámutatni szeretnék, nagyon fontos az információk összegyűjtése, mivel több olyan fizikai modellünk is lehet, amely egy logikai modellnek is megfelel. Gyakran előfordulhat, hogy logikus modellje van, de lehet, hogy fizikai modellek vannak különböző platformon és az ilyen típusú dolgokon. Lehet, hogy az egyik SQL Server példánya, a másik pedig az Oracle példánya. Képesek vagyunk mindezt összekapcsolni ugyanabban a modellező környezetben. És itt megint itt van egy tényleges adattárház-modell, amely ismét ugyanabban a modellező környezetben lehet, vagy akár a tárházban is lehet, és különféle dolgokhoz is összekapcsolható.
Amit igazán meg akartam mutatni neked, ez a modellek néhány más dolga és más változata, amelyekbe bejutunk. Tehát, amikor egy ilyen hagyományos adatmodellbe kerülünk, szoktuk megnézni a tipikus entitásokat az oszlopokkal, a metaadatokkal és az ilyen típusú dolgokkal, de ez a nézőpont nagyon gyorsan változik, amikor elkezdjük foglalkozni ezekkel az újabb NoSQL technológiákkal, vagy amint egyesek még mindig szeretik őket hívni, a nagy adatátviteli technológiákat.
Tegyük fel most, hogy a környezetünkben is van Kaptár. Ha hátrányos mérnököket kaptunk a kaptár környezetéből - és a kaptár előre és hátra tervezhetjük ugyanazzal a modellező eszközzel -, látunk valamit, ami kissé más. Az összes adatot továbbra is konstrukcióknak tekintjük, de a TDL-ek eltérőek. Azok, akik már szoktak látni az SQL-t, amit most látnának, a Hive QL, amely nagyon SQL-szerű, de ugyanabból az eszközből éppen mostantól kezdheti el a különbözõ szkriptnyelvek használatát. Tehát modellezhet ebben a környezetben, generálhatja azt a Hive környezetbe, de ugyanilyen fontos, hogy a fent leírt forgatókönyvben visszafordíthatod az egészet, megértheted azt, és elkezdhetsz összefűzni. .
Vegyünk egy újat, amely egy kicsit más. A MongoDB egy másik platform, amelyet natív módon támogatunk. És amikor elkezdi bejutni a JSON típusú környezetekbe, ahol dokumentumtároló van, a JSON más állat, és vannak olyan konstrukciók, amelyek nem felelnek meg a relációs modelleknek. Hamarosan elkezdi foglalkozni olyan fogalmakkal, mint a beágyazott objektumok és a beágyazott objektummátrixok, amikor elkezdi kihallgatni a JSON-t, és ezek a fogalmak nem léteznek a hagyományos relációs jelölésben. Amit itt tettünk, valójában kibővítettük a jelölést és a katalógusunkat, hogy ugyanabban a környezetben tudjuk kezelni.
Ha itt átnézi a bal oldalt, az elemek és táblázatok látása helyett objektumoknak nevezzük őket. És különböző jelöléseket látsz. Még mindig itt látja a referencia-jelölések tipikus típusait, de ezek a kék entitások, amelyeket ebben az adott ábraben mutatok, valójában beágyazott objektumok. És különböző bíborosságokat mutatunk be. A gyémánt kardinalitás azt jelenti, hogy az egyik oldalán tárgy, de az egyik kardinalitása azt jelenti, hogy a kiadónkon belül, ha ezt a kapcsolatot követjük, van beágyazott címobjektum. A JSON lekérdezése során rájöttünk, hogy pontosan ugyanaz az objektumok szerkezete, mint a pártfogóba ágyazott, de valójában objektum tömbként van beágyazva. Ezt nemcsak a csatlakozókon keresztül látjuk, hanem ha a tényleges entitásokat is megnézjük, akkor látni fogjuk, hogy a védőszemlélet alatt szereplő címeket is objektumok tömbjeként osztályozzák. Nagyon leíró nézetet kap arról, hogyan lehet ezt bevinni.
És ismét, most, amit néhány másodperc alatt láthattunk, a tradicionális, többszintű relációs modellek, ugyanazt tehetjük Hive-vel, ugyanazt tehetjük a MongoDB-vel és más nagy adatforrásokkal, mint például jól. Mit tehetünk, és ezt csak nagyon gyorsan megmutatom nektek, arról beszélték, hogy más dolgokról más területeket hoznak be. Feltételezem, hogy modellt importálok egy adatbázisból, vagy visszafordítom, de külső metaadatokból hozom be. Csak azért, hogy nagyon gyors nézetet nyújtsunk az összes különféle dologról, amelyeket be tudunk hozni.
Mint látja, rengeteg olyan dolog van, amelyekkel ténylegesen behozhatjuk a metaadatokat a modellező környezetünkbe. Olyan dolgokkal kezdve, mint például az Amazon Redshift, a Cassandra, a sok más nagy adatplatform, tehát ezek közül sokat láthat. Ez ábécé sorrendben van. Sok nagy adatforrást és ilyen típusú dolgokat látunk. Sok olyan hagyományos vagy régebbi modellező környezetet is látunk, amelyeken keresztül ténylegesen átadhatjuk ezeket a metaadatokat. Ha átmegyek itt - és nem fogok mindegyikre időt költeni -, sokféle dolgot látunk, amelyekből behozhatjuk a modellező platformokat és az adatplatformokat. És nagyon fontos, hogy itt felismerjük, egy másik rész, amit megtehetünk, amikor az adatforgalomról beszélünk, az Enterprise Team Edition-en megkérdezhetjük az ETL-forrásokat is, például Talend vagy SQL Server Information Services leképezésekkel, Valójában hozza ezt be, hogy elindítsa az adatvonalas diagramjainkat is, és rajzoljon képet arról, hogy mi történik ezekben az átalakulásokban. Összességében a dobozból több mint 130 ilyen hidat találunk, amelyek valójában az Enterprise Team Edition termék részét képezik, tehát ez valóban segít abban, hogy minden tárgyat nagyon gyorsan összegyűjtsünk egy modellező környezetbe.
Végül, de nem utolsósorban, arról is beszélek, hogy nem szabad szem elől tévesztenünk azt a tényt, hogy szükségünk van más típusú konstrukciókra is, ha adatraktározást vagy bármilyen típusú elemzést végezünk. Még mindig azt akarjuk képessé tenni, hogy olyan dolgokat csináljon, mint a dimenziós modellek, ahol ténytáblák vannak, és vannak méretek és ilyen típusú dolgok. Az egyik dolog, amit meg akarok mutatni neked, az is, hogy metaadatunk kiterjesztésével is rendelkezhetünk, amelyek segítenek kategorizálni a dimenziók típusait és mindent. Tehát ha itt megnézzük például a dimenziós adatok fület, ezek egyikét, akkor az automatikusan felismeri az általa látott modellmintázat alapján, és megad egy kiindulási pontot arra vonatkozóan, hogy véleménye szerint dimenzió vagy egy ténytáblázat. De ezen túlmenően, amit megtehetünk, az a dimenziókon belül van, és ennek a fajta dolognak különféle típusú dimenziói is vannak, amelyeket felhasználhatunk az adatok osztályozására egy adattárolási típusú környezetben is. Olyan nagyon nagy képességekkel, amelyekkel ezt teljesen összevarrjuk.
Megismerem ezt, mivel jelenleg a demo környezetben vagyok, és még néhány dolgot megmutatok, mielőtt visszamegyek a diákhoz. Az egyik dolog, amelyet a közelmúltban hozzáadtunk az ER / Studio Data Architect-hez, az, hogy helyzetbe kerülünk - és ez egy nagyon gyakori használati eset, amikor projekten dolgozunk -, a fejlesztők objektumok szempontjából gondolkodnak, míg az adataink A modellezők hajlamosak táblázatokra és entitásokra, valamint az ilyen típusú dolgokra gondolkodni. Ez egy nagyon egyszerű adatmodell, de néhány alapvető fogalmat képvisel, amelyekben a fejlesztők vagy akár üzleti elemzők vagy üzleti felhasználók különféle objektumoknak vagy üzleti koncepcióknak gondolhatnak rájuk. Mostanáig nagyon nehéz ezeket besorolni, de amit ténylegesen elvégeztünk az ER / Studio Enterprise Team Edition kiadásban, a 2016-os kiadásban, az az, hogy most van egy üzleti adatobjektumok nevű koncepció. És amit ez lehetővé tesz, az lehetővé teszi számunkra, hogy az entitáscsoportokat vagy táblázatokat valódi üzleti objektumokká kapjuk be.
Például, amit itt találtunk erről az új nézetről, az a megrendelés fejléc és a megrendelési sor össze vannak húzva, objektumba vannak beágyazva, úgy gondolnánk őket, mint egy munkaegységre, ha megmaradnak az adatok, és összehozzuk őket, így nagyon könnyű ezt a különféle közönséghez kapcsolni. A modellezési környezetben újrafelhasználhatók. Valódi tárgyak, nem csupán rajzkonstrukciók, de további előnyeinknek is van, hogy amikor ténylegesen modellezési szempontból kommunikálunk, szelektíven összeomolhatjuk vagy kibővíthetjük őket, így összeállított nézetet állíthatunk elő az egyes érdekelt felekkel folytatott párbeszédekhez, és természetesen megtarthatjuk a részletesebb nézetet, mint amilyent itt látunk a technikai közönség számára. Ez valóban egy nagyon jó kommunikációs eszközt jelent nekünk. Amit most látunk, több különböző modelltípust ötvözünk, kiegészítve őket az üzleti adatobjektumok fogalmával, és most arról fogok beszélni, hogy hogyan alkalmazunk valamilyen további jelentést az ilyen típusú dolgokra, és hogyan öleljük össze őket a általános környezet.
Csak itt próbálom megtalálni a WebEx-et, hogy képes vagyok erre. És ott megyünk vissza a Hot Tech diákhoz. Csak előrehaladok itt néhány diával, mert ezeket már látta a modell demonstrációjában. Nagyon gyorsan szeretnék beszélni a szabványok elnevezéséről. Különböző elnevezési szabványokat akarunk alkalmazni és érvényesíteni. Azt akarjuk csinálni, hogy képesek vagyunk ténylegesen tárolni az elnevezési szabványsablonokat az adattárainkban, hogy ezt a jelentést alapvetően szavakkal vagy kifejezésekkel, vagy akár rövidítésekkel építjük fel, és összekapcsoljuk őket egy értelmes angol típusú szóval. Az üzleti kifejezéseket, azok rövidítéseit használjuk, meghatározhatjuk a megrendelést, az eseteket, és hozzáadhatunk előtagokat és utótagokat. A tipikus felhasználási eset ehhez általában az, amikor az emberek logikai modellt készítenek, majd ténylegesen egy fizikai modellt készítenek, ahol esetleg rövidítéseket és minden mást használtak.
A gyönyörű dolog az, hogy éppen olyan erős, fordítva még hatalmasabb, ha elmondhatjuk, hogy ezek az elnevezési szabványok közül melyek voltak azokon a fizikai adatbázisokon, amelyeket fordítottan készítettünk, akkor ezeket a rövidítéseket átvehetjük, hosszabbá alakíthatjuk őket. szavakat, és hozza vissza őket angol kifejezésekbe. Valójában most már megfelelő neveket származtathatunk az adatok kinézetéhez. Mint mondtam, a tipikus felhasználási eset az, ha előre lépünk, logikailag fizikai szempontból, és feltérképezzük az adattárakat és az ilyen típusú dolgokat. Ha megnézi a képernyőképet a jobb oldalon, látni fogja, hogy a forrásnevekben rövidítések vannak, és amikor elnevezési szabványsablont alkalmaztunk, valójában több teljes névvel rendelkezik. És tetszőleges helyet és minden hasonlót behelyezhetünk, ha akarjuk, attól függően, hogy milyen névnevezési szabványokat használunk. Tehát úgy nézhet ki, hogy azt szeretnénk, ha megjelenik a modelljeinkbe. Csak akkor, ha tudjuk, hogy mit hívnak, ténylegesen megkezdhetjük a definíciók hozzáfűzését, mert ha nem tudjuk, mi az, hogyan lehet azt értelmezni?
A jó dolog az, hogy tényleg hivatkozhatunk erre, amikor mindenféle dolgot csinálunk. A fordított tervezésről beszéltünk, valójában egyidejűleg hivatkozhatunk az elnevezési szabványok sablonjaira, amikor fordított mérnököket végezünk. Tehát egy varázslón belüli lépéscsomagban azt tudjuk csinálni, ha tudjuk, hogy mi az egyezmény, visszafordíthatunk egy fizikai adatbázist, ez visszaadja azt fizikai modellekként egy modellező környezetben, és ez alkalmazni fogjuk ezeket az elnevezési konvenciókat is. Tehát meglátjuk, hogy a nevek angolszerű ábrázolása a megfelelő logikai modellben van a környezetben. Meg tudjuk csinálni, és kombinálhatjuk az XML Séma generációval, így elkészíthetünk egy modellt, sőt ki is húzhatjuk rövidítéseinket, függetlenül attól, hogy SOA keretrendszert készítünk, vagy ilyesfajta dolgot, tehát különféle elnevezési konvenciókat is ki tudunk állítani. amit valójában magában a modellben tároltunk. Nagyon sok nagyon erős képességet ad nekünk.
Itt ismét egy példa arra, hogyan nézne ki, ha lenne sablonom. Ez valójában azt mutatja, hogy az elnevezési szabványok egyezményében EMP volt a „munkavállaló”, a SAL a „fizetés”, a PLN a „terv”. Azt is alkalmazhatom, hogy interaktív módon futtassam őket, miközben modelleket készítek és elhelyezem a dolgokat. Ha ezt a rövidítést használom, és az entitás nevére beírom a „Munkavállalói fizetési terv” elemet, akkor az az elnevezési szabványok sablonjával működne. Itt határoztam meg, az EMP_SAL_PLN-t adhatott volna, amikor az entitásokat létrehoztam, és azonnal megadtam a megfelelő fizikai neveket.
Nagyon jó, ha a mérnököket is tervezzük és továbbfejlesztjük. Nagyon egyedi koncepciónk van, és itt kezdjük el valóban összehozni ezeket a környezeteket. És úgy hívják, hogy Universal Mappings. Miután ezeket a modelleket a környezetünkbe behoztuk, amit képesek vagyunk tenni, ha feltételezzük, hogy ezeket az elnevezési konvenciókat már alkalmaztuk és könnyen megtalálhatók, akkor az Universal Mappings nevű konstrukciót használhatjuk az ER-ben /Stúdió. Összekapcsolhatjuk az entitásokat a modellek között. Bárhol is látjuk az „ügyfelet” - valószínűleg „ügyfelet” fogunk találni sok különböző rendszerben és sok különböző adatbázisban - elkezdhetjük mindegyik összekapcsolását, hogy amikor egy modellben dolgozom láthatja, hogy hol vannak a vásárlók más modellekben. És mivel megvan a modellréteg, amely ezt képviseli, akkor azt még az adatforrásokhoz is hozzákapcsolhatjuk, és levisszük a felhasznált vizsgálatainkba, mely adatbázisokban ezek szintén találhatók. Ez valóban lehetőséget ad nekünk, hogy mindezt nagyon koherens módon összekapcsoljuk.
Megmutattam az üzleti adat objektumokat. Nagyon gyorsan szeretnék beszélni a metaadat-kiterjesztésekről, amelyeket Mellékleteknek hívunk. Amit ez ad, lehetőséget ad arra, hogy további metaadatokat hozzunk létre a modellobjektumainkhoz. Elég gyakran állítottam fel ilyen típusú tulajdonságokat, hogy sok különféle dolgot ki lehessen vezetni az adatkezelés és az adatminőség szempontjából, valamint hogy segítsünk nekünk a törzsadat-kezelés és az adatmegőrzési politikák kidolgozásában. Az alapötlet az, hogy ezeket az osztályozásokat létrehozza, és bárhová csatolhatja őket, az asztalfajok, oszlopok szintjén az ilyen típusú dolgokat. A leggyakoribb használati eset természetesen az, hogy az entitások táblák, és akkor meg tudom határozni: mi a törzsadataim, mi a referencia tábláim, mi a tranzakciós tábláim? Adatminőség szempontjából osztályozásokat végezhetek az üzleti jelentőség szempontjából, hogy az adattisztítási erőfeszítéseket és az ilyen típusú dolgokat prioritássá tegyük.
Valami, amelyet gyakran figyelmen kívül hagynak, mi a különféle típusú adatok megőrzési politikája szervezetünkben? Felállíthatjuk ezeket, és ténylegesen hozzákapcsolhatjuk őket a modellező környezetünkben található természetesen különféle típusú információhoz és természetesen a tárolóinkhoz is. A szépség az, hogy ezek a mellékletek élnek-e az adat-szótárban, tehát amikor vállalati adatszótárakat használunk a környezetben, akkor több modellhez csatolhatjuk őket. Csak egyszer kell meghatároznunk őket, és újra és újra felhasználhatjuk őket a környezetünk különböző modelljein. Ez csak egy gyors képernyőképernyő, amely megmutatja, hogy valóban megadhatja-e a mellékletet, amikor az összes darabot csatolja. És ez a példa valójában egy értékek listáját foglalja magában, tehát amikor bemennek, kiválaszthat az értékek listájából, a modellezési környezetben sok ellenőrzést végezhet azzal, amit kiválasztanak, és beállíthatja, hogy mi legyen az alapértelmezett érték, ha egy értéket nem választanak ki. Tehát rengeteg erő van ott. Az adat-szótárban élnek.
Valami, amit kissé tovább szeretnék mutatni neked ezen a képernyőn, ráadásul a mellékleteknek a felső részén is megjelenik, mögötte az adatbiztonsági információk. Az adatbiztonsági politikákat valóban alkalmazhatjuk a környezetben található különféle információkra is. Különböző megfelelőségi leképezésekhez, adatbiztonsági osztályozásokhoz néhányat szállítunk a dobozból, amelyet Ön előállíthat és felhasználhat, de meghatározhatja saját megfelelőségi leképezéseit és szabványait is. Függetlenül attól, hogy HIPAA-t csinálsz, vagy bármilyen más kezdeményezést odakint. És valóban elkezdheti felépíteni ezt a nagyon gazdag metaadat-készletet a környezetében.
És akkor a Szószedet és a kifejezések - ez az, ahol az üzleti jelentés össze van kötve. Gyakran vannak olyan adatszótárak, amelyeket egy szervezet gyakran kiindulási pontként használ a szószedetek elkészítéséhez, de a terminológia és a szóbeszéd gyakran nagyon technikai. Tehát amit tehetünk, ha felhasználunk kiindulópontként ezeket a szószedetek kiállításához, akkor valóban azt akarjuk, hogy a vállalkozás birtokolja ezeket. Amit a csapatkiszolgálói környezetben tettünk, az az a képesség, hogy az emberek üzleti definíciókat készítsenek, majd összekapcsolhatjuk őket a különböző modell-műtermékekkel, amelyek megfelelnek a modellező környezetben is. Elismerjük azt a pontot, amelyet korábban megvitattunk: minél több ember gépel, annál nagyobb az esély az emberi tévedésre. A szótár szerkezetünkben az is egy, hogy támogatjuk a szótár hierarchiáját, tehát a szervezetben különböző szótár típusok vagy különféle típusú dolgok lehetnek, de ugyanolyan fontos, hogy ha már van ezek közül a forrásokból odakint a megadott kifejezésekkel és mindent megtehetünk, valójában CSV-importálást készíthetünk a modellező környezetünkbe, a csapat szerverünkbe vagy a szószedetbe is, és onnan kezdhetjük a linkeket. És minden alkalommal, amikor valamit megváltoztatnak, teljes ellenőrzési nyomvonal van arról, hogy mi volt az előző és utáni képek, a definíciók és minden más szempontjából, és amit a közeljövőben látni fog, az inkább az engedélyezési munkafolyamat. így ténylegesen ellenőrizhetjük, ki felelős azért, a bizottságok vagy az egyének jóváhagyásai és az ilyen típusú dolgok, hogy tovább mozdítsuk az irányítási folyamatot.
Ez nekünk is azt okozza, ha ezek a szószedet-kifejezések szerepelnek a csapatkiszolgálói szótárban. Ez egy példa a szerkesztésre egy modell entitásában maga a modell, amelyet itt vettem fel. Lehetséges, hogy összekapcsolta a kifejezéseket, de mi is teszünk, ha vannak olyan szavak, amelyek abban a szószedetben szerepelnek az itt található entitásaink megjegyzésében vagy leírásában, akkor ezek automatikusan világosabb, hiperhivatkozással jelennek meg, és ha Az egérrel rájuk valójában a meghatározást az üzleti szótárból is láthatjuk. Még gazdagabb információkat is ad nekünk, amikor magát az információt fogyasztjuk, az összes ott található szószedettel. Ez valóban segít gazdagítani a tapasztalatokat, és a jelentést alkalmazni mindazokra, amelyekkel dolgozunk.
Tehát megint nagyon gyors repülés volt. Nyilvánvalóan napokat is eltölthetünk erre, amikor belemerülünk a különböző részekbe, de ez egy nagyon gyors repülés a felszínen. Arra törekszünk, hogy megértsük, hogy néznek ki az összetett adatkörnyezetek. Javítani szeretnénk az összes ilyen műtárgy láthatóságát, és együttműködni szeretnénk az ER / Studio segítségével. Szeretnénk lehetővé tenni a hatékonyabb és automatizált adatmodellezést. És ez az összes típusú adat, amelyről beszélünk, legyen az nagy adat, hagyományos relációs adat, dokumentumtár vagy bármi más. És megismételjük ezt is, mert hatalmas előre és hátra tervezési képességeink vannak a különböző platformokhoz és az egyéb eszközökhöz, amelyek ott vannak. És arról szól, hogy megosszák és kommunikálják a szervezetet az összes érintett szereplővel. Itt alkalmazzuk a jelentést a szabványok elnevezésén keresztül. Ezután az üzleti szótárakban alkalmazzuk a meghatározásokat. És akkor tovább osztályozhatjuk az összes többi irányítási képességünket a metaadat-kiterjesztésekkel, például az adatminőség-kiterjesztésekkel, az alapadatok kezelésére szolgáló osztályozásokkal vagy bármilyen más típusú osztályozással, amelyet az adatokra alkalmazni kívánunk. Aztán tovább foglalhatjuk össze, és tovább fejleszthetjük a kommunikációt az üzleti adatobjektumokkal, a különböző érdekelt felek közönségével, különösen a modellezők és a fejlesztők között.
És ismét, ami ebben a tekintetben nagyon fontos, mögötte egy integrált adattár található, amely rendkívül robusztus változáskezelési képességekkel rendelkezik. Nem volt ideje megmutatni ma, mert meglehetősen bonyolult, de a lerakat nagyon robusztus változáskezelési képességekkel és ellenőrzési nyomvonalakkal rendelkezik. Meghatározott kiadásokat is megtehet, megnevezett verziókat is készíthet, és mi is képesek vagyunk azoknak, akik változáskezelést végeznek, ezt közvetlenül hozzá tudjuk kapcsolni a feladatainkhoz. Ma képesek vagyunk feladatokat beilleszteni és a modellváltoztatásokat a feladatokhoz társítani, akárcsak a fejlesztők a kódváltásokat a feladatokhoz vagy a felhasználói történetekhez társítják, amelyekkel együtt dolgoznak.
Ismét nagyon gyors áttekintés volt. Remélem, elegendő volt az étvágya, hogy a jövőben sokkal mélyebb beszélgetésekbe kezdhessünk ezeknek a témáknak a felosztásával. Köszönöm az időt, és viszonozva, Rebecca.
Rebecca Jozwiak: Köszönöm, Ron, ez fantasztikus volt, és nagyon sok kérdésem merül fel a közönség részéről, de szeretnék lehetőséget adni elemzőinknek, hogy belemerítsék a fogaikat ahhoz, amit mondani kellett. Eric, megyek előre, és talán ha ezt a diát, vagy másikat szeretné megcélozni, miért nem megy előre? Vagy bármilyen más kérdés.
Eric Little: Persze. Sajnálom, mi volt a kérdés, Rebecca? Azt akarja, hogy kérdezzek valami konkrét, vagy…?
Rebecca Jozwiak: Tudom, hogy kezdetben volt néhány kérdés Ronnak. Ha most fel akarsz kérni tőle, hogy keressen mindegyiket, vagy néhányat a diáról, vagy bármi mást, amely felkeltette érdeklődését? Az IDERA modellezési funkcióiról.
Eric Little: Igen, az egyik dolog, Ron, hogy szóltok, úgy néz ki, hogy az Ön által ábrázolt diagramok általában olyan entitás-kapcsolati diagramok, mint amelyeket általában az adatbázis-felépítésben használnának, igaz?
Ron Huizenga: Igen, általában véve, de természetesen megvannak a kibővített típusai a dokumentumtárolókhoz és az ilyen típusú dolgokhoz is. Valójában különbözöttünk a pusztán relációs jelölésektől, valójában további jelöléseket adtunk hozzá ehhez a többi üzlethez is.
Eric Little: Van-e módja annak, hogy srácok felhasználhassák a gráf alapú modellezés típusokat, tehát létezik-e olyan módszer, amellyel integrálhatjuk, tegyük fel például, hogy van valami hasonlóm a felső kvadránshoz, a TopBraid zeneszerző eszközhöz, vagy csináltam valamit a Protégé-ben, vagy, tudod, mint például a FIBO pénzügyi srácai, sok munkát végeznek a szemantikában, az RDF dolgokban - van mód arra, hogy beépítsék az ilyen entitás-kapcsolati gráf típusú modellezést ebbe az eszközbe, és felhasználják azt azt?
Ron Huizenga: Valójában azt vizsgáljuk, hogyan tudjuk kezelni a grafikonokat. Ma nem foglalkozunk kifejezetten grafikon-adatbázisokkal és az ilyen típusú dolgokkal, de megvizsgáljuk a módszereit, amelyek segítségével megnövelhetjük a metaadatunkat. Úgy értem, most behozhatunk dolgokat az XML-en keresztül és az ilyen típusú dolgokat, ha legalább meg tudjuk csinálni valami XML-átruházást, hogy kiindulási pontként behozhassuk. De elegánsabb módszereket keresünk ennek bevezetésére.
Megmutattam neked azt a fordított mérnöki hidak listáját is, amelyek ott is vannak, tehát mindig arra törekszünk, hogy kiterjesszük ezeket a hidakat az egyes platformokra is. Folyamatos, folyamatos erőfeszítés, ha ennek értelme van, ezen új konstrukciók és a különféle platformok sok részletének megkezdésére. De elmondhatom, hogy határozottan élen járunk ennek megvalósításában. Azok a dolgok, amiket például a MongoDB-en mutattam, és az ilyen típusú dolgokat, mi vagyunk az első adatmodell-gyártók, akik ezt ténylegesen saját termékünkben csinálták.
Eric Little: Oké, igen. Tehát a másik kérdés, amelyet akkor vettem fel neked, az irányítás és a fenntartás szempontjából volt - például amikor a példát használta, amikor megmutatta annak a személynek a példáját, aki „alkalmazott”, azt hiszem, hogy „ fizetés ”, és akkor van egy„ terv ”, hogyan lehet kezelni például különféle embereket, akiknek lehetnek - tegyük fel, hogy van egy nagy építészeted, igaz, tegyük fel, hogy van egy nagy vállalkozása, és az emberek elkezdenek összerakni a dolgokat ebben az eszközben, és itt van egy csoport, amelyen szerepel a „munkavállaló” szó, és itt van egy csoport, amelyben szerepel a „munkavállaló”. És itt egy ember mondja „fizetés”, a másik pedig azt mondja "bér."
Hogyan, srácok, összeegyezteted, irányítod és irányítod az ilyen különbségeket? Mivel tudom, hogyan csinálnánk a gráf világban, tudod, hogy szinonim listákat használna, vagy azt mondaná, hogy van egy fogalom és több attribútummal rendelkezik, vagy mondhatná a SKOS modellben, hogy van egy preferált címkém, és van számos alternatív címke, amelyeket tudok használni. Hogy csináljátok ezt?
Ron Huizenga: Néhány különféle módon csináljuk, és elsősorban a terminológiáról beszélünk. Az egyik dolog, amit megteszünk, természetesen azt akarjuk, hogy a meghatározott vagy szankcionált kifejezések szerepeljenek, és az üzleti szószedetben nyilvánvalóan ott van, ahol szeretnénk. És engedélyezzük a szinonimákra mutató hivatkozásokat az üzleti szótárban is, így tehát azt mondhatja, hogy itt van a kifejezésem, de meghatározhatja azt is, hogy mi az összes szinonimája ezeknek.
Most természetesen az érdekes dolog, amikor elkezdi átnézni ezt a hatalmas adattáblát az összes különféle rendszerrel, amelyek ki vannak téve, akkor nem egyszerűen odamenhet, és megváltoztathatja a megfelelő táblákat és az ilyen típusú dolgokat megfelelnek az említett elnevezési szabványnak, mert lehet, hogy egy csomagot vásárolt, tehát nem tudja befolyásolni az adatbázis megváltoztatását, vagy bármi mást.
Amit a szószedet-definíciók összekapcsolása mellett tehetünk, az az egyetemes leképezésen keresztül történik, amelyről beszéltem, amit tennénk, és egyfajta ajánlott megközelítés, hogy egy átfogó logikai modell legyen, amely meghatározza, hogy mi ezek a különböző üzleti koncepciók, amiről beszél. Az üzleti szótár fogalmait ezekre kell kötni, és az a jó dolog, hogy megkapta ezt a konstrukciót, amely egy logikai entitásot ábrázol, mint ahogy van, akkor elkezdheti a logikai entitás összeköttetését a logikai entitás összes implementációjával a a különböző rendszerek.
Akkor, ahol erre szükséged van, láthatja, ó, itt a „személyt” ebben a rendszerben „alkalmazottnak” hívják. Ebben a másik rendszerben a „fizetést” itt „béreknek” nevezzük. Mert látni fogja, látni fogja az összes különféle megnyilvánulást, mert összekapcsolta őket.
Eric Little: Oké, nagyszerű, igen, megvan. Ebben az értelemben biztonságos azt mondani, hogy ez olyan, mint a tárgy-orientált megközelítések?
Ron Huizenga: Némileg. Kicsit intenzívebb, mint azt hiszem, mondhatnád. Úgy értem, megválaszthatja azt a megközelítést, hogy manuálisan összekapcsolja és átjárja, megvizsgálja és elvégzi mindet is. Az egyik dolog, amiről nem volt való esélyem beszélni - mivel ismét nagyon sok képességünk van -, akkor is teljes automatizálási felületünk van magában az Data Architect eszközben. És egy makró képesség, amely valóban programozási nyelv az eszközben. Tehát valójában olyan dolgokat is végezhetünk, mint például a makrók írása, kivitele, kihallgatása és linkek létrehozása az Ön számára. Információk importálására és exportálására használjuk, dolgok megváltoztatására vagy attribútumok hozzáadására, eseményekre, vagy a modellre alapozva, vagy felhasználhatjuk részekben való futtatáshoz, hogy ténylegesen kimenjenek és kihallgassunk dolgokat, és ténylegesen kitöltsük a különböző konstrukciókat a modell. Tehát van egy teljes automatizálási felület, amelyet az emberek is kihasználhatnak. És az univerzális leképezések felhasználása ezekkel egy nagyon hatékony módszer erre.
Rebecca Jozwiak: Oké, köszönöm Ronnak és Ericnak. Nagyszerű kérdések voltak. Tudom, hogy kissé elindulunk az óra tetején, de szeretnék megengedni Malcolmnak, hogy felvegyen néhány kérdést Ron útjába. Malcolm?
Malcolm Chisholm: Köszönöm, Rebecca. Szóval, Ron, nagyon érdekes, látom, hogy nagyon sok képesség van itt. Az egyik olyan terület, amelyben nagyon érdekel, mondjuk, ha van fejlesztési projektünk, hogyan látja az adatmodellező ezeket a képességeket használva, és talán inkább együttműködve üzleti elemzőkkel, adat profilozóval, adatminőség elemzővel, és azokkal az üzleti szponzorokkal, akik végső soron felelnek a projektben rejlő információs követelményekért. Tudja, hogy az adatmodellező valójában miként teszi a projektet hatékonyabbá és eredményesebbé az általunk vizsgált képességekkel?
Ron Huizenga: Úgy gondolom, hogy az egyik első dolgom, amelyet itt kell tennem, mint adatmodellező - és nem azt akarom, hogy néhány modellezőt válasszak, de egyébként is -, hogy néhány embernek továbbra is az a benyomása, hogy az adatmodellező valóban a kapufajta szerepkör, meghatározzuk annak működését, őrök vagyunk, akik gondoskodnak arról, hogy minden rendben legyen.
Most van egy aspektusa ennek, hogy meg kell győződnie arról, hogy meghatározza a megbízható adat-architektúrát és minden mást. De az a fontosabb, mint egy adatmodellező - és ezt egy kicsit nyilvánvalóan rájöttem, amikor konzultációt folytattam -, hogy segítővé kell válnod, tehát össze kell vonnod ezeket az embereket.
Ez nem lesz az előzetes tervezés, az adatbázisok létrehozása, létrehozása és létrehozása - csak annyit kell tennie, hogy képesnek kell lennie arra, hogy együtt dolgozzon ezekkel a különféle érdekelt csoportokkal, például olyan tevékenységeket végezzen, mint például a fordított tervezés, az információk importálása, a mások együtt dolgoznak, akár a szószedetekben, akár a dokumentációban vannak, mindent hasonló - és segítséget nyújtanak, ha behúzza ezt a lerakatba, összekapcsolja a fogalmakat a lerakatban, és együttműködik ezekkel az emberekkel.
Valójában sokkal inkább egy olyan típusú együttműködési környezet, ahol akár a feladatok meghatározása, akár a beszélgetési szálak meghatározása vagy az a fajta dolog, amely a csapat szerverén található, az emberek valóban együttműködhetnek, kérdéseket tehetnek fel és érkezhetnek a végső végtermékekhez, amelyeket adat-architektúrájuk és szervezésük szükségessége. Ilyen válasz volt?
Malcolm Chisholm: Igen, egyetértek. Tudod, azt hiszem, hogy az elősegítő képesség nagyon érdekes az adatmodellezőknél. Egyetértek azzal, hogy nem mindig látjuk ezt, de szerintem erre szükség van, és azt javaslom, hogy néha hajlamosak maradni a sarokban az adatmodellezés során, de valóban ott kell lennie a többi érdekelt csoporttal együttműködve. vagy csak nem érti az adatkörnyezetet, amelyikkel foglalkozik, és azt hiszem, hogy a modell ennek következtében szenved. De ez csak a véleményem.
Ron Huizenga: És érdekes, mert korábban már említette a diajában valamit a történelemről arról, hogy a vállalkozások hogyan fordultak el az informatikától, mert nem szállították meg időben a megoldásokat és az ilyen típusú dolgokat.
Nagyon érdekes, hogy a későbbi tanácsadói megbízásaim során, mielőtt termékmenedzserré váltam, a projektek nagy részét, amelyeket az elmúlt két évben tettem, az üzleti szponzorok támogatták, ahol valójában az üzlet vezette és az adatépítészek és a modellezők nem voltak az informatika részei. Egy üzleti szponzorált csoport részét képeztük, és ott voltunk segítők, akik a projekt többi tagjával együtt dolgoztak.
Malcolm Chisholm: Úgy gondolom, hogy ez egy nagyon érdekes pont. Úgy gondolom, hogy egy olyan változást tapasztalunk meg az üzleti világban, ahol az üzlet azt kérdezi, vagy talán gondolkodik, nem annyira, hogy mit csinálok, mint folyamat, hanem ők is gondolkodni kezdnek azon, hogy mi az adat hogy dolgozom, milyen adataim vannak szükségem, milyen adatokkal foglalkozom adatokkal, és milyen mértékben tudunk IDERA termékeket és képességeket kapni ennek a nézetnek a támogatására, és azt hiszem, hogy az üzleti bár ez még mindig kicsit születő.
Ron Huizenga: Egyetértek veled, és azt hiszem, látjuk, hogy egyre inkább így megy. Láthattunk egy ébredést, és Ön már korábban megérintette azt az adatok fontossága szempontjából. Láttuk az adatok fontosságát az IT-ben vagy az adatbázisok fejlődésének korai szakaszában, akkor amint mondod, belekerültünk ebbe az egész folyamatkezelési ciklusba - és a folyamat rendkívül fontos, ne tégy félre itt -, de most mi történt amikor ez történt, az adat elvesztette a fókuszt.
És most a szervezetek rájönnek, hogy az adatok valóban a középpontban vannak. Az adatok mindent képviselnek, amit vállalkozásunkban csinál, ezért gondoskodnunk kell arról, hogy pontos adatokkal rendelkezzünk, hogy megtaláljuk a helyes információkat, amelyekre szükségünk van döntéseink meghozatalához. Mert nem minden jön egy meghatározott folyamatból. Az információ egy része más dolgok mellékterméke, és továbbra is képesnek kell lennünk megtalálni, tudni, hogy mit jelent, és képesnek kell lennünk arra, hogy az ott látható adatokat végül olyan tudássá alakítsuk át, amelyet vállalkozásunk jobb vezetésére használhatunk.
Malcolm Chisholm: Rendben, és most egy másik terület, mellyel küzdöttem, az, amit az adatok életciklusának neveznék, vagyis tudod, ha egy vállalkozáson átmenő adatszolgáltatási láncot nézzünk meg, akkor azzal kezdjük, adatgyűjtés vagy adatgyűjtés, amely lehet az adatbevitel, de valószínűleg az is, hogy a vállalkozáson kívüli adatokat kapok valamilyen adatszolgáltatótól.
Aztán az adatgyűjtés óta az adatkarbantartásig megyünk, ahol gondolkodom ezen adatok szabványosításával és elküldésével oda, ahol szükséges. És akkor az adathasználat, a tényleges pontok, ahol vannak az adatok, akkor kiértékeljük az adatokat.
És a régi időkben mindez egyetlen stílusban történt, de ma lehet, hogy tudod, például egy analitikai környezet, és azon túl egy archívum, egy áruház, ahol az adatokat tároljuk, amikor már nem vagyunk szüksége van rá, és végül egy tisztító típusú folyamat. Hogyan látja, hogy az adatmodellezés illeszkedik-e a teljes adat-életciklus kezeléséhez?
Ron Huizenga: Ez egy nagyon jó kérdés, és egy dolog, amire valójában nem volt ideje mélyebben bemélyedni ma itt a részleteket, az, amiről valójában elkezdünk beszélni, az adat vonal. Tehát valójában képesek vagyunk arra, hogy eszközünkön van adatvonalas képesség, és amint azt mondom, valójában kinyerhetjük annak egy részét az ETL eszközökből, de hozzáfűzhetjük azt is csak a vonal rajzolásával. Az ilyen adatmodellek vagy adatbázisok, amelyeket felfogtunk és beépítettünk modellekbe, hivatkozhatunk a konstrukciókra az adatok vonaldiagramjában.
Amit tudunk csinálni, az adatfolyam felhívása, ahogy mondod, a forrástól a célig, és az átfogó életcikluson keresztül, hogyan továbbadnak az adatok a különböző rendszerekön, és mit fog találni, vegyük az alkalmazottakat 'adatok - ez az egyik kedvencem egy olyan projekt alapján, amelyet évekkel ezelőtt készítettem. Egy olyan szervezettel dolgoztam, amelynek alkalmazottai 30 különböző rendszerben voltak. Amit végül ott csináltunk - és Rebecca felbukkant az adatvonalat tartalmazó dia - ez itt egy meglehetősen egyszerűsített adatvonalat mutató dia, de amit meg tudtunk csinálni, az az összes adatszerkezet behozatala, hivatkozás a diagramra, majd ténylegesen megnézheti, hogy milyen áramlások vannak, és hogyan kapcsolódnak egymáshoz ezek a különféle adatelemek egy folyamatban? És ezen túl is túlléphetünk. Ez az itt látható adatfolyam vagy vonaldiagram része. Ha túl akarunk lépni, akkor is van ennek a csomagnak az üzleti építészmérnöki része, és ugyanez vonatkozik rá.
Az adatmodellezési környezetben rögzített adatstruktúrák bármelyikére hivatkozhatunk az üzleti modellező eszközben úgy, hogy még az üzleti modelldiagramjaiban vagy az üzleti folyamatdiagramjaiban is hivatkozhasson az egyes adattárakra, ha ki szeretne lépni a az adatmodellezési környezet, és miközben üzleti folyamata modellje mappáiban használja őket, akkor a CRUD-ot is megadhatja azokon is, azaz hogy ezeket az információkat akár felhasználják, akár előállítják, majd elkezdhetjük generálni olyan dolgok, mint a hatás- és elemzési jelentések, valamint az azokból ábrák.
Amit elérni szándékozunk, és már nagyon sok képességünk van, de az egyik dolog, amilyennek van egy olyan célpont, amelyet nézünk, miközben tovább fejlesztjük eszközöinket, képes feltérképezni ezt a végponttól a szervezeti adatsort és az adatok teljes életciklusát.
Malcolm Chisholm: Oké. Rebecca, engedélyezhetek még egyet?
Rebecca Jozwiak: Megengedöm, hogy menjen még, Malcolm.
Malcolm Chisholm: Nagyon köszönöm. Az adatkezelésre és az adatmodellezésre gondolkodva hogyan kaphatjuk meg ezt a két csoportot az eredményes együttműködésre és az egymás megértésére?
Eric Little: Érdekes, azt hiszem, ez valóban a szervezettől függ, és visszatér a korábbi koncepciómhoz, amikor azokban a szervezetekben, ahol a kezdeményezéseket üzleti célú voltak, közvetlenül megkötöttük voltunk. Például az adat architektúrát vezettem. csapatot, de szorosan kapcsolatban álltunk az üzleti felhasználókkal, és ténylegesen segítettünk nekik az adatkezelési program kidolgozásában. Ismét inkább egy konzultatív megközelítés, de valójában inkább üzleti funkció.
Amire valójában szükség van, az szükséges: olyan adatmodellezőkre és építészekre, akik valóban megértik az üzletet, kapcsolatba léphetnek az üzleti felhasználókkal, és ezután segítettek nekik felépíteni a körülötte lévő irányítási folyamatokat. A vállalkozás meg akarja tenni, de általában véve technológiai ismeretekkel rendelkezünk, hogy segítsünk nekik az ilyen típusú programok kiemelésében. Valójában együttmûködésnek kell lennie, de üzleti vállalkozásnak kell lennie.
Malcolm Chisholm: Oké, ez nagyszerű. Köszönöm.
Dr. Eric Eric: Oké.
Rebecca Jozwiak: Oké, köszönöm szépen. A közönség tagjai, attól tartok, hogy nem jutottunk el a kérdéseidhez, de gondoskodni fogok arról, hogy azok továbbításra kerüljenek a megfelelő vendégnek, akit ma a sorban voltunk. Nagyon szeretnék köszönetet mondani Ericnek, Malcolmnak és Ronnak, hogy ma vendégeink voltak. Nagyszerű cucc volt, emberek. És ha élvezte a mai IDERA internetes közvetítést, akkor az IDERA jövő szerdán is a Hot Technologies műsorán lesz, ha csatlakozni szeretne, megvitatja az indexelés és az Oracles kihívásait, ez egy újabb érdekes téma.
Nagyon köszönöm, emberek, vigyázzon, és legközelebb találkozunk. Viszlát.
