בניית ארכיטקטורת נתונים מונע עסקים

להסיר: המארחת רבקה יוז'ויאק דנה בפתרונות לארכיטקטורת נתונים עם אריק ליטל מ- OSTHUS, מלקולם קישולם מסן פרנסיסקו פרטנרס ראשונה ורון הויזנגה מ- IDERA.

אינך מחובר כרגע. התחבר או הירשם כדי לראות את הסרטון.

רבקה יוז'ויאק: גבירותיי ורבותיי, שלום, וברוכים הבאים ל- Hot Technologies משנת 2016. היום אנו דנים ב"בניית ארכיטקטורת נתונים מונע עסקים ", בהחלט נושא חם. שמי רבקה יוז'ויאק, אני אהיה המארח שלך לשידור האינטרנט של היום. אנו מבצעים ציוץ באמצעות hashtag של # HotTech16 כך שאם אתה כבר, אנא אל תהסס להצטרף גם לזה. אם יש לך שאלות בכל עת, אנא הכנס אותם לחלונית שאלות ותשובות בפינה השמאלית התחתונה של המסך שלך ואנחנו נדאג שהם יענו. אם לא, אנו נדאג שהאורחים שלנו יקבלו אותם בשבילך.

אז היום יש לנו מערך מרתק באמת. הרבה מפגינים כבדים שנמצאים איתנו היום. יש לנו את אריק ליטל, סמנכ"ל מדעי הנתונים מ- OSTHUS. יש לנו את מלקולם שישולם, קצין חדשנות ראשי, שהוא תואר ממש מגניב, לסן פרנסיסקו פרטנרס פרטנרס. ויש לנו את רון הויזנגה, מנהל מוצר בכיר מ- IDERA. וגם, אתה יודע, IDERA כוללת חבילה מלאה של פתרונות ניהול נתונים ומודלים. והיום הוא הולך לתת לנו הדגמה כיצד פועל הפיתרון שלו. אבל לפני שנגיע לזה, אריק ליטל, אני הולך להעביר לך את הכדור.

אריק ליטל: אוקיי, תודה רבה. אז אני אעבור כאן כמה נושאים שלדעתי הולכים להתייחס קצת לדיבורים של רון ובתקווה להציב את הבמה גם לכמה מהנושאים האלה, חלקם שאלות ותשובות.

אז הדבר שעניין אותי מה עושה IDERA הוא שלדעתי הם מציינים כי נכונה בסביבות מורכבות הרבה ערכים עסקיים בימינו. ועל פי סביבות מורכבות אנו מתכוונים לסביבות נתונים מורכבות. והטכנולוגיה באמת נעה מהר וקשה לעמוד בקצב העסקי של היום. כך שאנשים שעובדים בחללי טכנולוגיה יראו לעיתים קרובות שיש לכם לקוחות שעובדים בעיות עם "איך אוכל להשתמש בנתונים גדולים? כיצד אוכל לשלב סמנטיקה? איך אני מקשר כמה מהדברים החדשים האלה עם הנתונים הישנים שלי? "וכן הלאה, והסוג הזה מוביל אותנו בימינו אל ארבעת ה- V של נתונים גדולים שאנשים רבים מכירים אותם למדי, ואני מבין שיכולים להיות יותר מארבעה לפעמים - ראיתי שמונה או תשע - אבל בדרך כלל, כשאנשים מדברים על דברים כמו נתונים גדולים או אם אתה מדבר על נתונים גדולים, בדרך כלל אתה מסתכל על משהו שהוא סוג של סולם ארגוני. וכך אנשים יגידו, בסדר, ובכן, חשבו על נפח הנתונים שלכם, שבדרך כלל הוא המוקד - זה בדיוק כמה יש לכם. מהירות הנתונים קשורה לאיזו מהירות אני יכול להזיז אותם או כמה מהר אוכל לשאול אותם או לקבל את התשובות, וכן הלאה. ובאופן אישי אני חושב שהצד השמאלי של זה זה דבר שנפתר ומטופל במהירות יחסית על ידי הרבה גישות שונות. אבל בצד ימין אני רואה הרבה יכולות לשיפור והרבה טכנולוגיות חדשות שבאמת עולות לקדמת הבמה. וזה באמת קשור לטור השלישי, מגוון הנתונים.

אז במילים אחרות, רוב החברות בוחנות כיום נתונים מובנים, מובנים למחצה ולא מובנים. נתוני תמונות מתחילים להפוך לנושא חם, לכן היכולת להשתמש בראייה ממוחשבת, להסתכל על פיקסלים, להיות מסוגלת לגרד, NLP, מיצוי ישויות, יש לך מידע גרפי שיוצא משני מודלים סטטיסטיים או שמגיע מדגמים סמנטיים. , יש לך נתונים יחסים הקיימים בטבלאות וכן הלאה. ולכן צירוף כל הנתונים האלה יחד וכל הסוגים השונים האלה באמת מהווה אתגר גדול ותוכלו לראות את זה, אתם יודעים, בגרטנר ובאנשים אחרים שעוקבים אחר המגמות בענף.

ואז הדבר הסופי שאנשים מדברים עליו בנתונים גדולים הוא לרוב הרעיון הזה של רעבנות, שהוא באמת חוסר הוודאות של הנתונים שלך, הערפול שבהם. כמה טוב אתה יודע על מה הנתונים שלך, כמה טוב אתה מבין מה יש שם, ואתה יודע? היכולת להשתמש בסטטיסטיקות והיכולת להשתמש בסוג כלשהו של מידע סביב מה שאתה יודע או להשתמש בכמה קונוסים, יכולות להיות שם ערך. וכך היכולת להסתכל על נתונים בצורה כזו מבחינת כמה יש לך, כמה מהר אתה צריך להעביר אותם או להגיע אליהם, את כל סוגי הנתונים שיש לך בארגון ועד כמה אתה בטוח איפה אתה זה, מה זה, באיזה איכות הוא נמצא וכן הלאה. זה באמת דורש מאמץ גדול ומתואם עכשיו בין הרבה אנשים לנהל את הנתונים שלהם בצורה יעילה. לפיכך, דוגמנות הנתונים חשובה יותר ויותר בעולם של ימינו. אז דגמי נתונים טובים באמת מניבים הצלחה רבה ביישומים ארגוניים.

יש לך מקורות נתונים ממגוון מקורות, כמו שאמרנו, מה שבאמת מצריך הרבה שילובים מסוגים שונים. לכן, כדאי לחבר את הכל יחד כדי להריץ שאילתות, למשל, על פני סוגים רבים של מקורות נתונים, ולמשוך מידע אחורה. אבל כדי לעשות זאת אתה זקוק לאסטרטגיות מיפוי טובות ולכן מיפוי של סוגים אלה של נתונים והתמדה במיפויים אלה יכול להיות אתגר אמיתי. ואז יש לך את הנושא הזה, ובכן, כיצד אוכל לקשר את הנתונים שלי מדור קודם לכל מקורות הנתונים החדשים האלה? אז נניח שיש לי גרף, האם אני לוקח את כל הנתונים היחסים שלי ומכניס אותם לתרשים? בדרך כלל זה לא רעיון טוב. אז איך אנשים מסוגלים לנהל את כל אותם דגמי נתונים שמתרחשים? באמת צריך להפעיל ניתוח על הרבה סוגים שונים אלה של מקורות ושילובי נתונים. אז התשובות שיוצאות מזה, התשובות שאנשים צריכים באמת לקבל החלטות עסקיות טובות הן קריטיות.

אז זה לא קשור רק לבניית טכנולוגיה למען הטכנולוגיה, זה באמת, מה אני הולך לעשות, מה אני יכול לעשות עם זה, איזה סוג של ניתוח אני יכול להריץ, והיכולת, לפיכך, כפי שכבר עשיתי דיברנו, לחבר את הדברים יחד, לשלב אותם זה ממש ממש חשוב. ואחד מסוגי הניתוחים הללו פועל לאחר מכן על דברים כמו חיפוש ושאילתא מאוחדים. זה באמת הופך להיות חובה. השאלות שלך בדרך כלל צריכות להיות מושחלות על פני סוגים רבים של מקורות ולמשוך מידע באופן אמין.

מרכיב המפתח היחיד שלעתים קרובות, במיוחד אנשים מתבוננים בדברים מרכזיים כמו טכנולוגיות סמנטיות - וזה משהו שאני מקווה שרון ידבר עליו קצת בגישה של IDERA - הוא איך אתה מפריד או מנהל את מודל שכבה של הנתונים שלך משכבת ​​הנתונים עצמה, מאותם נתונים גולמיים? אז למטה בשכבת הנתונים יתכן שיש לך מסדי נתונים, יתכן שיהיה לך נתוני מסמך, יתכן ויהיה לך נתוני גיליונות אלקטרוניים, יתכן ויהיה לך נתוני תמונה. אם אתה נמצא בתחומים כמו תעשיות התרופות, יש לך כמויות אדירות של נתונים מדעיים. ואז מעבר לכך האנשים בדרך כלל מחפשים דרך לבנות מודל שמאפשר להם לשלב במהירות את הנתונים האלה ובאמת כשאתה מחפש נתונים עכשיו אתה לא מחפש למשוך את כל הנתונים לשכבת הדגם שלך. , מה שאתה מסתכל על שכבת הדגם לעשות הוא לתת לך ייצוג הגיוני יפה של הדברים, דברים אוצרות נפוצות, סוגים נפוצים של ישויות ומערכות יחסים, והיכולת באמת להיכנס לנתונים היכן שהם נמצאים. אז זה צריך לומר מה זה, וזה צריך לומר איפה הוא נמצא, וזה צריך לומר איך ללכת להביא אותו ולהחזיר אותו.

אז זו הייתה גישה שהצליחה למדי להניע טכנולוגיות סמנטיות קדימה, וזה תחום בו אני עובד הרבה. אז שאלה שרציתי להציב בפני רון, ושאני חושבת שתועיל במקטע שאלות ותשובות, היא לבדוק כיצד זה מושג על ידי פלטפורמת IDERA? אז האם שכבת הדגם אכן נפרדת משכבת ​​הנתונים? האם הם יותר משולבים? איך זה עובד ומהן התוצאות והיתרונות שהם רואים מהגישה שלהם? לכן נתוני הפניה באמת הופכים להיות קריטיים. אז אם יש לך דגמי נתונים מסוג זה, אם אתה מסוגל להתאחד ולחפש דברים, אתה באמת צריך שיהיה לך נתוני עיון טובים. אך הבעיה היא שקשה מאוד לשמור על נתוני הפניה. לעתים קרובות שמות סטנדרטים כשלעצמם הם אתגר קשה. קבוצה אחת תקרא למשהו X וקבוצה אחת תקרא למשהו Y ועכשיו יש לך בעיה איך מישהו מוצא את X ו- Y כשהוא מחפש מידע מסוג זה? מכיוון שאתה לא רוצה לתת להם רק חלק מהנתונים, אתה רוצה לתת להם את כל מה שקשור. במקביל לתנאים משתנים, תוכנה הופכת לבלתי מיושנת וכן הלאה, כיצד אתה ממשיך ומתחזק את נתוני ההתייחסות הללו לאורך זמן?

ושוב, טכנולוגיות סמנטיות, במיוחד באמצעות דברים כמו טקסונומיות ואוצר מילים, מילוני נתונים, סיפקו דרך מרחב סטנדרטית לעשות זאת, שהיא באמת חזקה מאוד, היא משתמשת בסוגים מסוימים של סטנדרטים, אך קהילת בסיס הנתונים עשתה זאת למען זמן רב, רק בדרכים שונות. אני חושב שאחד המפתחות כאן הוא לחשוב כיצד להשתמש אולי במודלים של קשרי ישויות, כיצד להשתמש אולי במודלים של גרפים או סוג כלשהו של גישה כאן שבאמת ייתן לך בתקווה דרך רגילה לטיפול בנתוני ההתייחסות שלך. ואז כמובן, ברגע שיש לך את נתוני ההתייחסות, אסטרטגיות המיפוי צריכות לנהל מגוון רחב של שמות וישויות. כך שמומחי נושא לעתים קרובות אוהבים להשתמש במונחים שלהם.

אז אתגר בזה הוא תמיד, איך אתה נותן למישהו מידע אבל הופך אותו לרלוונטי לאופן בו הם מדברים עליו? אז לקבוצה אחת יכולה להיות דרך אחת להסתכל על משהו, למשל, יתכן שאתה כימאי שעוסק בתרופה, ויכול להיות שאתה ביולוג מבני שעובד על אותה התרופה, וייתכן שיש לך שמות שונים לאותם סוגים של ישויות שקשורים לתחום שלך. אתה צריך להבין דרכים להפגיש בין המינוחים המותאמים אישית, כיוון שהגישה השנייה היא שאתה צריך להכריח אנשים לפטר את הקדנציה ולהשתמש במישהו אחר, שלעתים קרובות הם לא אוהבים. נקודה נוספת כאן היא הטיפול במספרים נרדפים נרדפים מתקשה, כך שיש המון מילים שונות בנתונים של אנשים רבים שיכולים להתייחס לאותו דבר. יש לך בעיית התייחסות שם באמצעות מערכת יחסים מרובה לאחד. מונחים מומחים משתנים מענף לתעשייה, כך שאם אתה מתכוון לפתח סוג של פיתרון עיקרי לניהול נתונים מסוג זה, עד כמה הוא קל לנייד מפרויקט אחד, או יישום אחד לאחר? זה יכול להיות אתגר נוסף.

אוטומציה חשובה וזה גם אתגר. יקר לטפל ידנית בנתוני הפניה. יקר צריך להמשיך במיפוי ידני וכדאי שמומחי נושא יפסיקו לבצע את עבודתם היום-יומית ויצטרכו להיכנס ולתקן כל העת מילוני נתונים ולעדכן מחדש הגדרות וכן הלאה, וכן הלאה. אוצר מילים שניתן לשכפל באמת מציג ערך רב. אז אלה הם אוצר מילים לעתים קרובות שתוכלו למצוא חיצוניים לארגון שלכם. אם אתה עושה עבודה בנפט גולמי, למשל, יהיו סוגים מסוימים של אוצר מילים שאתה יכול לשאול ממקומות פתוחים, זהה לתרופות, כמו לתעשיית הבנקאות ולפיננסים, אותו דבר עם הרבה תחומים מסוג זה. אנשים מכניסים שם מילות מפתח חוזרות לשימוש, גנריות, שניתן לשכפל בהן כדי שאנשים יוכלו להשתמש בהן.

ושוב, כשמסתכלים על הכלי IDERA, אני סקרן לראות איך הם מתמודדים עם זה במונחים של שימוש בסוגים של סטנדרטים. בעולם הסמנטיקה אתה רואה לעתים קרובות דברים כמו דגמי SKOS שמספקים סטנדרטים לפחות רחבים יותר / צרים יותר ממערכות יחסים, והדברים האלה יכולים להיות קשים לביצוע במודלים של ER, אבל אתה יודע, לא בלתי אפשרי, זה פשוט תלוי בכמה מזה מכונות וכי קישור בו תוכלו להתמודד בסוגים אלו של מערכות.

אז לבסוף רק רציתי לעשות השוואה עם כמה מנועים סמנטיים שאני רואה בתעשייה, ובדיוק לשאול את רון ולתכנן אותו קצת כדי לדבר על אולי איך משתמשים במערכת IDERA בשילוב עם כל טכנולוגיות סמנטיות.האם זה יכול להיות משולב עם חנויות משולשות, מסדי נתונים גרפיים? כמה קל להשתמש במקורות חיצוניים מכיוון שלעיתים ניתן לשאול דברים כאלה בעולם הסמנטי באמצעות נקודות קצה של SPARQL? אתה יכול לייבא מודלים של RDF או OWL ישירות למודל שלך - חזור אליהם - כך למשל, אונטולוגיית הגנים או אונטולוגיית החלבון, שיכולים לחיות איפשהו במרחב שלה עם מבנה ממשל משלו ואני יכול פשוט לייבא את כל או חלק מזה שאני זקוק לזה למודלים שלי. ואני סקרן לדעת איך IDERA ניגשת לנושא זה. האם עליכם לתחזק את הכל באופן פנימי, או שיש דרכים להשתמש בסוגים אחרים של דגמים סטנדרטיים ולמשוך אותם פנימה ואיך זה עובד? והדבר האחרון שציינתי כאן הוא כמה עבודה ידנית באמת מעורבת בבניית מילוני המונחים ומאגרי המטא נתונים?

אז אני יודע שרון יראה לנו כמה הדגמות על דברים כאלה שיהיו מעניינים באמת. אבל הבעיות שלעתים קרובות אני רואה בהתייעצות עם לקוחות היא שהרבה טעויות מתרחשות אם אנשים כותבים בהגדרות שלהם או במטא-נתונים שלהם. אז אתה מקבל איות שגוי, אתה מקבל שגיאות אצבעות שומן, זה דבר אחד. אתה מקבל גם אנשים שאולי לוקחים משהו, אתה יודע, רק ויקיפדיה או מקור שהוא לא בהכרח באיכות שאתה רוצה בהגדרה שלך, או שההגדרה שלך היא רק מנקודת מבט של אדם אחד אז היא לא שלמה, וזה לא ברור אז איך עובד תהליך הממשל. ממשל, כמובן, בהיותך נושא מאוד מאוד גדול בכל פעם שאתה מדבר על נתוני עזר ובכל עת שאתה מדבר על איך זה יכול להתאים לנתוני האב של מישהו, איך הם משתמשים במטא-נתונים שלהם, בקרוב.

אז רק רציתי לשים כמה מהנושאים האלה שם בחוץ. אלה פריטים שאני רואה בחלל העסקי על פני המון סוגים שונים של התקשרויות לייעוץ והרבה מאוד חללים שונים, ואני ממש מעוניין לראות מה רון הולך להראות לנו עם IDERA כדי להצביע על כמה מהנושאים האלה . אז תודה רבה.

רבקה יוז'ויאק: תודה רבה, אריק, ואני מאוד אוהבת את התגובה שלך לכך ששגיאות רבות יכולות להתרחש אם אנשים כותבים הגדרות או מטא נתונים. אני יודע שבעיתונות יש מנטרה ש"עיניים רבות עושות מעט את השגיאות ", אבל כשמדובר ביישומים מעשיים, יותר מדי ידיים בצנצנת העוגיות נוטות להשאיר אותך עם הרבה עוגיות שבורות, נכון?

אריק ליטל: כן, חיידקים.

רבקה יוז'ויאק: כן. עם זה אני הולך להמשיך ולהעביר אותו למלקולם שישולם. מלקולם, הרצפה היא שלך.

מלקולם שישולם: תודה רבה, רבקה. הייתי רוצה להסתכל קצת על מה שאריק דיבר עליו ולהוסיף, סוג של, כמה תצפיות, שידוע לך, רון עשוי לדאוג להגיב עליהן גם בדיבור על "לקראת אדריכלות נתונים מונע עסקים". "- מה המשמעות של להיות מונע עסקים ומדוע זה חשוב? או שזה רק סוג כלשהו של הייפ? אני לא חושב שכן.

אם אנו מסתכלים על המתרחש מאז, אתה יודע, מחשבי מיינפריים באמת הפכו לזמינים לחברות - נניח בערך 1964 - עד היום, אנו יכולים לראות שהתרחשו הרבה שינויים. ואת השינויים האלה הייתי מסכם שהם מעבר ממרכזיות תהליכים למרכזיות נתונים. וזה מה שהופך את ארכיטקטורות הנתונים המונעות על ידי עסקים כל כך חשובים וכל כך רלוונטיים להיום. ואני חושב, אתה יודע, זה לא סתם מילת באזז, זה משהו שהוא אמיתי לחלוטין.

אבל אנו יכולים להעריך את זה קצת יותר אם אנו צוללים אל ההיסטוריה, כך שנחזור אחורה בזמן, חזרה לשנות השישים ובמשך זמן מה לאחר מכן, המסגרות הראשיות שלטו. אלה אז פינו את מקומם למחשבים אישיים שבהם מרמתם של המשתמשים בפועל כאשר נכנסו למחשבים אישיים. מרד נגד IT מרכזי, שלדעתם לא ממלא את צרכיהם, לא היו מספיק זריזים. זה הוביל במהירות למחשוב מבוזר, כאשר מחשבים אישיים היו קשורים זה לזה. ואז האינטרנט התחיל לקרות, שהטשטש את גבולות המיזם - כעת הוא יכול היה לקיים אינטראקציה עם גורמים מחוץ לעצמה מבחינת חילופי נתונים, שלא קרה לפני כן. ועכשיו נכנסנו לעידן הענן והביג נתונים שבהם הענן הוא פלטפורמות שבאמת משווקות תשתיות ולכן אנו משאירים, כביכול, את ה- IT של הצורך להפעיל מרכזי נתונים גדולים מכיוון שאתה יודע, יש לנו את יכולת הענן העומדת לרשותנו, ובמקביל לנתונים הגדולים האלה שאריק, אתה יודע, דנו בצורה כה רהוטה. ובסך הכל, כפי שאנו רואים, ככל שהחלפת הטכנולוגיה התרחשה, היא הפכה להיות יותר ממוקדת נתונים, אכפת לנו יותר מהנתונים. כמו באינטרנט, כיצד מחליפים נתונים. עם נתונים גדולים, ארבעת ה- V או יותר של הנתונים עצמם.

במקביל, ואולי חשוב מכך, תיקים של שימוש עסקי עברו. עם הצגת המחשבים לראשונה, הם שימשו לאוטומציה של דברים כמו ספרים ורישומים. וכל מה שהיה תהליך ידני, שהיה כרוך בספרים או דברים כאלה, תוכנתו, בעצם, בבית. זה עבר בשנות ה -80 לזמינות של חבילות תפעול. כבר לא היית צריך לכתוב שכר משלך, אתה יכול לקנות משהו שעשה את זה. זה הביא לצמצום גדול באותה עת, או בארגון מחדש, במחלקות IT רבות. אבל אז הופיע מודיעין עסקי, עם דברים כמו מחסני נתונים, בעיקר בשנות ה -90. אחריהם הגיעו מודלים עסקיים של דוטקום שהיו כמובן תזזית גדולה. ואז MDM. עם MDM אתה מתחיל לראות שאנחנו לא חושבים על אוטומציה; אנו פשוט מתמקדים באוצרת נתונים כנתונים. ואז ניתוחים, המייצגים את הערך שאתה יכול לצאת מהנתונים. ובתוך אנליטיקה רואים חברות שמצליחות מאוד שהמודל העסקי הליבה שלהן נסוב על נתונים. גוגל, יהיה חלק מזה, אבל אתה יכול גם לטעון כי וולמארט כן.

וכך העסק באמת חושב על נתונים. כיצד ניתן להפיק ערך מהנתונים? כיצד נתונים יכולים להניע את העסק, את האסטרטגיה ואנחנו בעידן הזהב של הנתונים. אז בהתחשב בכך, מה קורה מבחינת ארכיטקטורת הנתונים שלנו, אם נתונים כבר לא נחשבים פשוט הפליטה היוצאת מהקצה האחורי של יישומים, אך הם באמת מרכזיים במודלים העסקיים שלנו? ובכן, חלק מהבעיה שיש לנו בהשגתה היא IT הוא באמת תקוע בעבר עם מחזור החיים של פיתוח מערכות שהיה תוצאה של הצורך להתמודד במהירות עם אותו אוטומציה של תהליכים בגיל המוקדם של ה- IT, ועבודה עם פרויקטים זה דבר דומה. מבחינת ה- IT - וזה קצת קריקטורה - אבל מה שאני מנסה לומר הוא שחלק מהחסמים להשגת ארכיטקטורת נתונים מבוססת עסק נובעים מכיוון שקיבלנו תרבות ב- IT באופן לא ביקורתי. שמקורו בעידן עבר.

אז הכל פרויקט. ספר לי את הדרישות שלך בפירוט. אם הדברים לא עובדים, זה בגלל שלא אמרת לי את הדרישות שלך. ובכן זה לא עובד היום עם נתונים מכיוון שאנחנו לא מתחילים בתהליכים ידניים לא אוטומטיים או המרה טכנית של תהליכים עסקיים, אנו מתחילים לעתים קרובות מאוד עם נתוני ייצור קיימים שכבר אנו מנסים. להוציא ערך. אבל אף אחד שלא מממן פרויקט ממוקד נתונים באמת מבין את הנתונים האלה לעומק. עלינו לבצע גילוי נתונים, עלינו לבצע ניתוח נתוני מקור. וזה לא ממש תואם את פיתוח המערכות, אתה יודע - מפל, מחזור החיים של SDLC - שהאחיזה שלו, הייתי אומר, היא סוג של גרסה טובה יותר לזה.

ומה שמתמקד בו זה טכנולוגיה ופונקציונליות, לא נתונים. לדוגמה, כאשר אנו מבצעים בדיקות בשלב בדיקות זה בדרך כלל יהיה, האם הפונקציונליות שלי עובדת, נניח ETL שלי, אך אנו לא בודקים את הנתונים. אנחנו לא בוחנים את ההנחות שלנו לגבי נתוני המקור שנכנסים. אם היינו עושים זאת, היינו במצב טוב יותר וכמישהו שעשה פרויקטים של מחסני נתונים וסבל משינויים במעלה הזרם, כשהוא מקפיץ את תעודות הסל שלי, הייתי מעריך את זה. ולמעשה, מה שאנחנו רוצים לראות זה בדיקה כצעד מקדים לבקרת איכות נתוני ייצור רציפה. אז יש לנו הרבה עמדות בהן קשה להשיג את ארכיטקטורת הנתונים המונעת על ידי העסק מכיוון שאנחנו מותנים בעידן של מרכזיות בתהליך. עלינו לעבור למרכזיות נתונים. וזה לא מעבר מוחלט, אתה יודע, עדיין יש הרבה עבודות תהליכים בחוץ, אבל אנחנו לא באמת חושבים במונחים מרכזיים-נתונים כשאנחנו צריכים, והנסיבות שמתרחשות כשאנחנו באמת מחויב לעשות זאת.

כעת העסק מבין את הערך של הנתונים, הם רוצים לפתוח את הנעילה של הנתונים, אז איך נעשה זאת? אז איך עושים את המעבר? ובכן, שמנו נתונים בלב תהליכי הפיתוח. ואנחנו נותנים לעסק להוביל עם דרישות מידע. ואנחנו מבינים שאיש אינו מבין את נתוני המקור הקיימים בתחילת הפרויקט. אפשר לטעון שמבנה הנתונים והנתונים עצמם הגיעו לשם באמצעות IT ותפעול, בהתאמה, לכן עלינו לדעת זאת, אבל באמת, אנחנו לא. זו פיתוח ממוקד נתונים. לכן עלינו לחשוב איפה אנחנו ואיך עושים דוגמנות נתונים בעולם מרכזי נתונים, עלינו להיות לולאות משוב למשתמשים בכל הקשור לשכלול דרישות המידע שלהם, כמו שאנו מבצעים גילוי נתונים ופרופיל נתונים. , צפה בניתוח נתוני המקור וככל שאנו מקבלים בהדרגה יותר ויותר ודאות לגבי הנתונים שלנו. ועכשיו אני מדבר על פרויקט מסורתי יותר כמו רכזת MDM או מחסן נתונים, לאו דווקא פרויקטים גדולים של נתונים, למרות שזה עדיין, אני חושב, קרוב למדי לזה. וכך לולאות המשוב כוללות את מודלי הנתונים, אתם יודעים, מקדמות בהדרגה את מודל הנתונים שלהם ומתקיימות אינטראקציה עם המשתמשים כדי לוודא שדרישות המידע מעודנות על סמך מה שאפשר, מה זמין, מנתוני המקור כפי שהם מבינים טוב יותר את זה, כך זה כבר לא מקרה של מודל הנתונים, אתה יודע, במצב שהוא לא שם או שהוא לגמרי נעשה, זה הדרגתי שמביא אותו למוקד.

באופן דומה, במורד הזרם שלנו יש לנו הבטחת איכות בה אנו מפתחים כללים לבדיקת איכות נתונים כדי לוודא שהנתונים נמצאים בפרמטרים עליהם אנו מניחים הנחות. כשנכנס, אריק התייחס לשינויים בנתוני ההתייחסות, אשר עשויים לקרות. אינך רוצה להיות, כביכול, קורבן במורד הזרם של שינוי, סוג של לא מנוהל בתחום זה, כך שכללי אבטחת האיכות יכולים להיכנס לפיקוח על הייצור של הנתונים באופן רציף. כך שתוכלו לראות אם אנו עומדים להיות ממוקדים בנתונים, כיצד אנו מבצעים פיתוח ממוקד נתונים שונה בתכלית מה- SDLC המבוסס על פונקציונליות ו Agile. ואז עלינו לשים לב גם לתפיסות העסקיות. יש לנו - ושוב זה מהדהד את מה שאריק אמר - יש לנו מודל נתונים המגדיר סיפור נתונים כחול עבור בסיס הנתונים שלנו, אך יחד עם זאת אנו זקוקים לאותם מודלים רעיוניים, אותם השקפות עסקיות של נתונים שבאופן מסורתי לא נעשו בהם העבר. לפעמים, אני חושב, חשבנו שמודל הנתונים יכול לעשות את כל זה, אבל אנחנו צריכים לקבל את התצוגה הרעיונית, הסמנטיקה, ולהסתכל בנתונים, להעביר אותם דרך שכבת הפשטה שתורגמת את מודל האחסון לעסק. נוף. ושוב, כל הדברים שאריק דיבר עליהם מבחינת הסמנטיקה, הופכים להיות חשובים לעשות זאת, כך שלמעשה יש לנו משימות דוגמנות נוספות. אני חושב שזה, אתה יודע, מעניין אם אתה עולה בשורות כמודל נתונים כמוני, ושוב, משהו חדש.

ולבסוף אני רוצה לומר שהארכיטקטורה הגדולה יותר צריכה לשקף גם את המציאות החדשה הזו. MDM של לקוחות מסורתיים, למשל, הוא די, בסדר, בואו נכניס את נתוני הלקוחות שלנו לרכזת בה אנו יכולים לדעת להבין מהם איכות נתונים עבור יישומי משרד. שמבחינה אסטרטגית עסקית הוא סוג של פיהוק. עם זאת, כיום אנו בוחנים רכזות MDM של לקוחות שיש בהם נתונים נוספים על פרופיל לקוחות, ולא רק על הנתונים הסטטיים, אשר באמת יש להם ממשק דו כיווני עם יישומי עסקה של הלקוח. כן, הם עדיין תומכים במשרד האחורי, אך כעת אנו יודעים על התנהגויות אלה של הלקוחות שלנו. זה יקר יותר לבנייה. זה מורכב יותר לבנות. אבל זה מונע על ידי עסקים באופן שבו הלקוח MDM המסורתי אינו. אתה נסחר בנטייה לעסק מול עיצובים פשוטים יותר שקל יותר ליישם, אך עבור העסק, זה מה שהם רוצים לראות. אנחנו באמת בעידן חדש ואני חושב שיש כמה רמות שעלינו להגיב לארכיטקטורת הנתונים לנהיגה עסקית ואני חושב שזה זמן מרגש מאוד לעשות דברים.

אז תודה לך, חזרה לך רבקה.

רבקה יוז'ויאק: תודה מלקולם, ומאוד נהניתי ממה שאמרת על מודלים של נתונים חייב להאכיל את התצוגה העסקית, כיוון שלא כמו מה שאמרת, שם ה- IT החזיק את המושכות כל כך הרבה זמן וזה פשוט לא מקרה שכזה ושהתרבות צריך לעבור. ואני די בטוח שהיה ברקע כלב שהסכים איתך 100%. ועם זה אני הולך להעביר את הכדור לרון. אני ממש מתרגש לראות את ההדגמה שלך. רון, הרצפה שלך.

רון הויזנגה: תודה רבה ולפני שנקפוץ לזה, אעבור כמה שקופיות ואז קצת הדגמה כי כמו שציינו אריק ומלקולם זה נושא רחב מאוד ועמוק, ועם מה שאנחנו אנו מדברים על היום אנו פשוט מגרדים את פני השטח מכיוון שיש כל כך הרבה היבטים וכל כך הרבה דברים שאנחנו באמת צריכים לקחת בחשבון ולהביט בהם מתוך ארכיטקטורה מונעת עסק. והגישה שלנו היא באמת להפוך את הדגם המבוסס על כך ולגזור את הערך האמיתי מהדגמים מכיוון שאתה יכול להשתמש בהם ככלי תקשורת כמו גם שכבה כדי לאפשר מערכות אחרות. בין אם אתה עושה ארכיטקטורה מוכוונת שירות, או דברים אחרים, המודל באמת הופך לאזור החיים של המתרחש, עם כל המטא נתונים סביבו והנתונים שיש לך בעסק שלך.

עם זאת, אני רוצה לדבר על זה כמעט לקחת את זה צעד אחורה, מכיוון שמלקולם נגע בכמה מההיסטוריה של התפתחות פתרונות וסוג כזה. אחת הדרכים באמת להצביע על כמה חשוב לארכיטקטורת נתונים סאונד היא מקרה שימוש שבעבר נתקלתי בו לעתים קרובות מאוד כאשר התייעצתי לפני שנכנסתי לתפקיד של ניהול מוצר, כלומר הייתי נכנס לארגונים בין אם הם עשו טרנספורמציה עסקית או סתם החליפו כמה מערכות קיימות וסוג כזה של דברים, והתברר מהר מאוד עד כמה ארגונים לא טובים מבינים את הנתונים שלהם. אם אתה לוקח מקרה שימוש מסוים כמו זה, בין אם אתה יועץ שנכנס או שאולי מדובר באדם שרק התחיל בארגון, או שהארגון שלך נבנה במהלך השנים עם רכישת חברות שונות, מה אתה מסיים למעלה עם היא סביבה מורכבת מאוד מהר מאוד, עם מספר טכנולוגיות שונות ומשונות, כמו גם טכנולוגיות מדור קודם, פתרונות ERP וכל השאר.

אז אחד הדברים שאנחנו באמת יכולים לעשות עם גישת הדוגמנות שלנו הוא לענות על השאלה, איך אני הגיוני מכל זה? אנחנו באמת יכולים להתחיל לחבר את המידע יחד, כך שהעסק יכול למנף את המידע שיש לנו כמו שצריך. וזה מסתבר, מה יש לנו שם בסביבות האלה? כיצד אוכל להשתמש במודלים כדי להוציא את המידע הדרוש לי ולהבין טוב יותר את המידע הזה? ואז יש לנו את סוגי המטא נתונים המסורתיים עבור כל הדברים השונים כמו מודלים של נתונים יחסיים, ואנחנו רגילים לראות דברים כמו הגדרות ומילוני נתונים, אתה יודע, סוגי נתונים וסוג כזה. אבל מה עם מטא נתונים נוספים שברצונך ללכוד כדי באמת לתת לה משמעות עוד יותר? למשל, אילו ישויות הם באמת המועמדים שצריכים להיות אובייקטים של נתוני התייחסות, שאמורים להיות אובייקטים לניהול נתונים ראשיים וסוגי אותם דברים ולקשור אותם זה בזה. ואיך המידע זורם בארגון? נתונים נובעים מאיך שהם נצרכים הן מבחינת תהליכים, אך גם משושלת נתונים מבחינת מסע המידע דרך העסקים שלנו וכיצד היא עושה את דרכה במערכות השונות, או דרך חנויות הנתונים, כך שאנו יודעים כאשר אנו בונים את פתרונות ה- I, או את אותם סוגים של דברים, שאנו למעשה צורכים את המידע הנכון למשימה העומדת בפניך.

ואז חשוב מאוד, כיצד נוכל לגרום לכל אותם בעלי עניין לשתף פעולה, ובמיוחד לבעלי העניין העסקי מכיוון שהם אכן נותנים לנו את המשמעות האמיתית של הנתונים האלה. העסק, בסופו של יום, הבעלים של הנתונים. הם מספקים את ההגדרות לאוצר המילים ולדברים שאריק דיבר עליהם, ולכן אנו צריכים מקום לקשור את כל זה יחד. והדרך בה אנו עושים זאת היא באמצעות דוגמנות הנתונים והארכיטקטורות של מאגר הנתונים שלנו.

אני הולך לגעת בכמה דברים. אני הולך לדבר על ER / Studio Enterprise Team Edition. בעיקר אני אדבר על מוצר ארכיטקטורת הנתונים בו אנו מבצעים את דוגמנות הנתונים וסוג כזה של דברים, אבל ישנם המון רכיבים אחרים בסוויטה שאני רק אגע בהם בקצרה. תראה קטע אחד של האדריכל העסקי, בו אנו יכולים לבצע מודלים רעיוניים, אך אנו יכולים גם לבצע מודלים של תהליכים עסקיים ונוכל לקשור את מודלי התהליכים האלה כדי לקשר את הנתונים בפועל שיש לנו במודלי הנתונים שלנו. זה באמת עוזר לנו לקשר את הקשר הזה. אדריכל התוכנה מאפשר לנו לבצע קונסטרוקציות נוספות כמו דוגמנות מסוימות של UML וסוגי אותם דברים לתת לוגיקה תומכת לכמה מאותן מערכות ותהליכים אחרים עליהם אנו מדברים. אבל חשוב מאוד כשאנחנו יורדים למטה יש לנו את המאגר ואת שרת הצוות, ואני אדבר על זה כסוג של שני חצאים של אותו הדבר. המאגר הוא המקום בו אנו מאחסנים את כל המטא-נתונים המוצבים כמו גם את כל המטא-נתונים העסקיים מבחינת מילוני מונחים ומונחים עסקיים. ומכיוון שיש לנו את הסביבה המבוססת על מאגר, אנו יכולים לתפור את כל הדברים השונים האלה באותה סביבה ואז אנו יכולים למעשה להפוך אותם לזמינים לצריכה, לא רק לאנשים הטכניים אלא גם לאנשי העסקים. וככה אנחנו באמת מתחילים לעודד שיתוף פעולה.

ואז היצירה האחרונה עליה אדבר בקצרה היא שכשאתה נכנס לסביבות האלה, זה לא רק בסיסי נתונים שיש לך שם בחוץ. יהיה לך מספר מסדי נתונים, חנויות נתונים, יהיה לך הרבה דברים, מה שהייתי קורא, חפצים מדור קודם. אולי אנשים השתמשו ב- Visio או בתרשימים אחרים כדי למפות כמה דברים. אולי היו להם כלי דוגמנות אחרים וסוג כזה של דברים.אז מה שאנחנו יכולים לעשות עם ה- MetaWizard הוא למעשה לחלץ חלק מהמידע הזה ולהכניס אותו לדגמים שלנו, להפוך אותו עדכני ולהיות מסוגל להשתמש בו, לצרוך אותו, בצורה עדכנית שוב, במקום רק לשבת שם בחוץ. זה הופך כעת לחלק פעיל במודלים העובדים שלנו, וזה מאוד חשוב.

כשאתה נכנס לארגון, כמו שאמרתי, יש הרבה מערכות שונות זה מזה, הרבה פתרונות ERP, פתרונות מחלקתיים שאינם תואמים. ארגונים רבים משתמשים גם בפתרונות SaaS, שגם הם נשלטים ומנוהלים חיצונית, כך שאיננו שולטים על בסיסי הנתונים ועל אותם סוגים של דברים המארחים על אלה, אך אנו עדיין צריכים לדעת כיצד נראים נתונים אלה וכמובן, המטא נתונים סביב זה. מה שאנחנו גם מוצאים זה הרבה מערכות מורשת מיושנות שלא נוקו בגלל אותה גישה מבוססת פרוייקט עליה דיבר מלקולם. מדהים איך בשנים האחרונות ארגונים יפתחו פרוייקטים, הם יחליפו מערכת או פיתרון, אבל לעתים קרובות לא נותר מספיק תקציב לפרויקט כדי לבטל את הפתרונות המיושנים, אז עכשיו הם פשוט בדרך. ועלינו להבין ממה אנו יכולים באמת להיפטר בסביבתנו, כמו גם מה מועיל בעתיד. וזה קשור לאסטרטגיית הפירוק הגרועה. זה החלק של אותו הדבר.

מה שאנו מוצאים גם מכיוון שהרבה ארגונים בנויים מכל הפתרונות השונים הללו, האם אנו רואים הרבה ממשקים נקודתיים לנקודה עם הרבה נתונים מסתובבים במספר מקומות. עלינו להיות מסוגלים לתרץ את זה ולברר את שושלת הנתונים שציינתי בקצרה לפני כן, כדי שנוכל לקבל אסטרטגיה מגובשת יותר כמו שימוש בארכיטקטורה מוכוונת שירות, אוטובוסים של שירות ארגוני וסוגי אותם דברים, כדי לספק את המידע הנכון לסוג מודל של פרסום ורישום שאנו משתמשים בו נכון בכל עסקנו. ואז, כמובן, אנו עדיין צריכים לבצע ניתוחים כלשהם, בין אם אנו משתמשים במחסני נתונים, מצעדי נתונים עם ETL מסורתיים ובין אם אנו משתמשים בכמה מאגמי הנתונים החדשים. הכל מסתכם באותו דבר. כל הנתונים, בין אם מדובר בנתונים גדולים, בין אם מדובר בנתונים מסורתיים במאגרי מידע יחסים, עלינו לקבץ את כל הנתונים האלה כדי שנוכל לנהל אותם ולדעת עם מה יש לנו עסק בכל הדגמים שלנו.

שוב, המורכבות שאנו הולכים לעשות היא שיש לנו מספר צעדים שאנחנו רוצים שנוכל לעשות. ראשית, אתה נכנס פנימה וייתכן שאין לך את הכחולים שבהם נראית נוף המידע הזה. בכלי דוגמנות נתונים כמו ER / Studio Data Architect אתה קודם תעשה הרבה הנדסת רוורס מבחינת הבה נצביע על מקורות הנתונים שנמצאים שם, נכניס אותם ואז בעצם תפור אותם יחד לייצוג יותר מודלים המייצגים את העסק כולו. הדבר החשוב הוא האם אנו רוצים שנוכל לפרק את המודלים הללו גם לאורך קווי עסקים, כך שנוכל להתייחס אליהם בגושים קטנים יותר, שאנשי העסקים שלנו יכולים להתייחס אליהם, ואנליסטים העסקיים שלנו ובעלי עניין אחרים העובדים. על זה.

תקני שמות הם חשובים ביותר ואני מדבר על זה בכמה אופנים שונים כאן. שמות סטנדרטים מבחינת האופן בו אנו קוראים דברים במודלים שלנו. זה די קל לעשות במודלים לוגיים, שבהם יש לנו אמנת שמות טובה ומילון נתונים טוב עבור המודלים שלנו, אבל גם אז, אנו רואים מוסכמות שמות שונות להרבה מהמודלים הפיזיים האלה שאנו מכניסים אליהם. כאשר אנו מהנדס רוורס, לעתים קרובות אנו רואים שמות מקוצרים ואת סוג הדברים האלה עליהם אדבר. ואנחנו צריכים לתרגם את אלה בחזרה לשמות אנגלים משמעותיים בעלי משמעות לעסק כדי שנוכל להבין מהם כל חלקי הנתונים האלה שיש לנו בסביבה. ואז מיפויים אוניברסליים הם איך אנחנו תופרים אותם זה לזה.

נוסף על כך היינו מתעדים ומגדירים עוד יותר וכאן נוכל לסווג את הנתונים שלנו עוד יותר עם משהו שנקרא קבצים מצורפים, שאציג לכם כמה שקופיות עליהן. ואז סוגרים את הלולאה, אנו רוצים ליישם את המשמעות העסקית הזו, וכאן נקשר את מילוני המונחים העסקיים שלנו ויכולים לקשר אותם למוצרי המודל השונים שלנו, כך שאנחנו יודעים, כשאנחנו מדברים על מונח עסקי מסוים, איפה זה מיושם בנתונים שלנו ברחבי הארגון. ואז לבסוף, כבר דיברתי על העובדה שאנחנו צריכים שכל זה יהיה מאגר מבוסס הרבה יכולות שיתוף פעולה ופרסום, כך שבעלי העניין שלנו יוכלו להשתמש בו. אני הולך לדבר על הנדסת רוורס די מהר. כבר נתתי לך הדגשה מהירה מאוד של זה. אני אראה לך זאת בהדגמה בפועל רק כדי להראות לכם כמה מהדברים שאנחנו יכולים להביא לשם.

ואני רוצה לדבר על כמה מסוגי הדגם והתרשימים השונים שהיינו מייצרים בסוג זה של תרחיש. ברור שנעשה את המודלים הרעיוניים בהרבה מקרים; אני לא מתכוון לבזבז הרבה זמן על זה. אני באמת רוצה לדבר על מודלים לוגיים, דגמים פיזיים וסוגים מודלים מיוחדים שנוכל ליצור. וחשוב שנוכל ליצור את כולם באותה פלטפורמת דוגמנות, כך שנוכל לתפור אותם יחד. זה כולל מודלים ממדיים וגם דגמים המשתמשים בכמה ממקורות הנתונים החדשים, כגון NoSQL שאציג לך. ואז, איך נראה מודל שושלת הנתונים? וכיצד ניתן לתפור נתונים אלה למודל תהליכים עסקיים, על זה נדבר בהמשך.

אני הולך לעבור לסביבת דוגמנות כאן רק כדי לתת לך סקירה גבוהה מאוד ומהירה. ואני מאמין שאתה אמור להיות מסוגל לראות את המסך שלי עכשיו. קודם כל אני רוצה לדבר על רק סוג מסורתי של מודל נתונים. והדרך בה אנו רוצים לארגן את הדגמים כאשר אנו מכניסים אותם, היא שאנו רוצים להיות מסוגלים לפרק אותם. אז מה שאתה רואה כאן בצד שמאל הוא שיש לנו מודלים הגיוניים ופיזיים בקובץ המודל הספציפי הזה. הדבר הבא הוא שנוכל לפרק את זה לאורך הפירוק העסקי, לכן זו הסיבה שאתה רואה את התיקיות. הכחולים בהירים הם מודלים הגיוניים והירוקים הם מודלים פיזיים. ואנחנו יכולים גם להתעמק, כך שב- ER / Studio, אם יש לך פירוק עסקי, אתה יכול ללכת כמה שיותר דרגות עומק או תת-מודלים שתרצה, ושינויים שאתה מבצע ברמות הנמוכות משתקפים אוטומטית בגובה הגבוה יותר רמות. כך שהיא הופכת לסביבת דוגמנות חזקה מאוד מהר.

משהו שאני גם רוצה לציין שחשוב מאוד להתחיל לצרף את המידע הזה זה שאנחנו יכולים להיות מודלים פיזיים מרובים שתואמים גם למודל לוגי אחד. לעתים קרובות למדי יתכן שיש לך מודל הגיוני אבל יתכן שיש לך מודלים פיזיים בפלטפורמות שונות וסוג כזה של דבר. אולי זה מופע של SQL Server, ואולי אחר מופע של Oracle. יש לנו את היכולת לקשור את כל אלה יחד באותה סביבת דוגמנות. ושוב, מה שיש לי כאן הוא מודל מחסן נתונים בפועל שיכול להיות, שוב, באותה סביבת דוגמנות, או שנוכל להחזיק אותו במאגר ולקשר אותו גם בין דברים שונים.

מה שבאמת רציתי להראות לכם בנושא זה כמה מהדברים האחרים וגרסאות אחרות של הדגמים שאנחנו נכנסים אליהם. אז כשאנחנו נכנסים למודל נתונים מסורתי כזה אנחנו רגילים לראות את הישויות האופייניות עם העמודות והמטא נתונים וסוג כזה, אבל נקודת המבט הזו משתנה מהר מאוד כשאנחנו מתחילים להתמודד עם כמה מהטכנולוגיות החדשות האלה של NoSQL. , או כמו שאנשים מסוימים עדיין אוהבים לקרוא להם, טכנולוגיות הנתונים הגדולות.

אז בואו נגיד שיש לנו גם כוורת בסביבה שלנו. אם אנו מהנדסים אחוריים מסביבת כוורת - ואנחנו יכולים לבצע מהנדס אחורנית מ- Hive עם אותו כלי דוגמנות בדיוק - אנו רואים משהו שהוא קצת שונה. אנו עדיין רואים את כל הנתונים כמבנים שם, אך ה- TDL שלנו שונה. אלה מכם שרגילים לראות SQL, מה שהייתם רואים עכשיו הוא Hive QL, שהוא מאוד SQL אך מתוך אותו הכלי אתם יכולים להתחיל לעבוד עם שפות הסקריפט השונות. כך שתוכלו ליצור מודל בסביבה הזו, לייצר אותה לסביבת הכוורת, אך לא פחות חשוב, בתרחיש שתיארתי, תוכלו לבצע מהנדס הפוך את כל זה ולהרגיש בו ולהתחיל לתפור אותו גם יחד. .

ניקח עוד אחד שקצת שונה. MongoDB היא פלטפורמה נוספת בה אנו תומכים באופן טבעי. וכשאתה מתחיל להיכנס לסוגי JSON של סביבות בהן יש לך חנויות מסמכים, JSON הוא חיה אחרת ויש בו מבנים שלא תואמים מודלים יחסיים. בקרוב אתה מתחיל להתמודד עם מושגים כמו אובייקטים משובצים ומערכים מוטבעים של אובייקטים כשאתה מתחיל לחקור את JSON ומושגים אלה אינם קיימים בסימן היחסים המסורתי. מה שעשינו כאן הוא שבאמת הרחבנו את הסימון והקטלוג שלנו בכדי שנוכל לטפל בזה באותה סביבה.

אם אתה מסתכל שמאלה כאן, במקום לראות דברים כמו ישויות וטבלאות, אנו קוראים להם חפצים. ואתה רואה סימנים שונים. כאן אתה עדיין רואה את הסוגים הטיפוסיים של רישומי הפניה, אך הישויות הכחולות האלה שאני מציג בתרשים הספציפי הזה הם למעשה אובייקטים משובצים. ואנחנו מראים קרדינליות שונות. קרדינליות היהלום פירושה שהיא אובייקט מצד אחד, אבל הקרדינליות של זה פירושה שיש לנו בתוך המו"ל אם אנו עוקבים אחר מערכת יחסים זו, יש לנו אובייקט כתובת משובץ. בחקירת ה- JSON מצאנו שזה בדיוק אותו מבנה של חפצים המוטמעים בפטרון, אבל זה בעצם מוטמע כמו מערך של חפצים. אנו רואים זאת, לא רק דרך המחברים עצמם, אלא אם אתה מסתכל על הישויות בפועל תראה שאתה רואה כתובות תחת פטרון שגם מסווגות את זה כמערך של חפצים. אתה מקבל נקודת מבט מאוד תיאורית של איך אתה יכול להכניס את זה.

ושוב, עכשיו מה שראינו עד כה בכמה שניות זה מודלים יחסיים מסורתיים שהם רב ברמה, אנחנו יכולים לעשות את אותו הדבר עם כוורת, אנחנו יכולים לעשות את אותו הדבר עם MongoDB, ומקורות נתונים גדולים אחרים כמו ובכן. מה שאנחנו יכולים לעשות, ואני רק אראה לך את זה מהר מאוד, דיברתי על העובדה להכניס דברים מתחומים אחרים. אני מתכוון להניח שאני הולך לייבא מודל ממסד נתונים או להנדס הפוך, אבל אני הולך להביא אותו מתוך מטא נתונים חיצוניים. רק כדי לתת לך מבט מהיר מאוד על כל סוגי הדברים השונים שנוכל להתחיל להביא.

כפי שאתה רואה, יש לנו מספר רב של דברים שאנחנו יכולים למעשה להביא את המטא נתונים לסביבת הדוגמנות שלנו. החל מדברים כמו אפילו Amazon Redshift, קסנדרה, הרבה פלטפורמות ה- Big Data האחרות, כך שרואים הרבה כאלה הרשומים. זה בסדר אלפביתי. אנו רואים הרבה מקורות נתונים גדולים וסוג כזה. אנו רואים גם הרבה סביבות דוגמנות מסורתיות או ישנות שאנו באמת יכולים להביא את המטא נתונים הללו. אם אעבור לכאן - ואני לא מתכוון לבזבז זמן על כל אחד מהם - אנו רואים הרבה דברים שונים שנוכל להכניס אליהם, מבחינת פלטפורמות דוגמנות ופלטפורמות נתונים. ומשהו שחשוב מאוד להבין כאן הוא חלק אחר שאנחנו יכולים לעשות כשאנחנו מתחילים לדבר על שושלת נתונים, במהדורת Enterprise Team אנחנו יכולים לחקור גם מקורות ETL, בין אם זה דברים כמו מיפוי של שירותי Talend או SQL Server Information, אנחנו יכולים למעשה הכניסו את זה כדי להתחיל גם את דיאגרמות שושלת הנתונים שלנו ולצייר תמונה של מה שקורה בתמורות הללו. בסך הכל יש לנו מעל 130 גשרים שונים אלה שהם למעשה חלק ממוצר Enterprise Team Edition, כך שזה באמת עוזר לנו לחבר את כל הממצאים לסביבת דוגמנות אחת במהירות רבה.

ואחרון חביב, אני גם רוצה לדבר על העובדה שאנחנו לא יכולים לאבד את העין מהעובדה שאנו זקוקים לסוגים אחרים של מבנים אם אנו מבצעים אחסון נתונים או סוגים אחרים של ניתוחים. אנו עדיין רוצים להיות מסוגלים לעשות דברים כמו מודלים ממדים שבהם יש לנו טבלאות עובדות ויש לנו ממדים וסוגי הדברים האלה. דבר אחד אני רוצה להראות לכם גם הוא שנוכל לקבל הרחבות למטא נתונים שלנו שיעזרו לנו לקטלג את סוגי הממדים וכל השאר. אז אם אני מסתכל על לשונית הנתונים הממדיות כאן, למשל, על אחת מאלה, היא למעשה תאתר אוטומטית, בהתבסס על תבנית המודל שהיא רואה, ותיתן לך נקודת התחלה אם היא חושבת שזה ממד או טבלת עובדות. אך מעבר לכך, מה שאנו יכולים לעשות הוא בממדים ובסוג הדברים האלה אפילו יש לנו סוגים שונים של ממדים בהם אנו יכולים להשתמש כדי לסווג את הנתונים גם בסביבת אחסון נתונים. כל כך יכולות עוצמתיות מאוד שאנחנו תופרים את זה לגמרי.

אני הולך לקפוץ לסביבה הזו מכיוון שאני בסביבת ההדגמה ברגע זה ולהראות לכם עוד כמה דברים לפני שאקפוץ לשקופיות. אחד הדברים שהוספנו לאחרונה ל- ER / Studio Data Architect הוא שנתקלנו במצבים - וזה מקרה נפוץ מאוד כשאתם עובדים על פרויקטים - מפתחים חושבים מבחינת אובייקטים, ואילו הנתונים שלנו דוגמניות נוטות לחשוב במונחים של טבלאות וישויות וסוג כזה של דברים. זהו מודל נתונים פשטני מאוד, אך הוא מייצג כמה מושגי יסוד, שבהם המפתחים או אפילו אנליסטים עסקיים או משתמשים עסקיים, עשויים לחשוב עליהם כעל אובייקטים או מושגים עסקיים שונים. היה קשה מאוד לסווג את אלה עד כה, אך מה שעשינו בפועל במהדורת ER / Studio Enterprise Team Edition, במהדורת המהדורה לשנת 2016, הוא שעכשיו יש לנו מושג שנקרא Business Data Objects. ומה שמאפשר לנו לעשות זה שזה מאפשר לנו להכיל קבוצות של ישויות או טבלאות לאובייקטים עסקיים אמיתיים.

למשל, מה שיש לנו כאן בתצוגה החדשה הזו זה כותרת הזמנת הרכש ושורת ההזמנה נשלבו זה לזה עכשיו, הם מכוסים כאובייקט, היינו חושבים עליהם כיחידת עבודה כשאנחנו ממשיכים את הנתונים ואנחנו מפגישים אותם כך שעכשיו קל מאוד להתייחס לזה לקהלים שונים. ניתן להשתמש בהם לשימוש חוזר בכל סביבת הדוגמנות. הם אובייקט אמיתי, לא רק מבנה שרטוט, אלא יש לנו גם היתרון הנוסף שכאשר אנו מתקשרים למעשה מנקודת מבט של דוגמנות, אנו יכולים לקרוס או להרחיב אותם באופן סלקטיבי, כך שנוכל להציג תצוגה מסכמת לדיאלוגים עם קהלים בעלי עניין מסוים, ואנחנו יכולים כמובן לשמור על התצוגה המפורטת יותר כמו שאנחנו רואים כאן עבור יותר מהקהלים הטכניים. זה באמת נותן לנו כלי תקשורת ממש טוב. מה שאנחנו רואים כעת הוא שילוב של מספר סוגים שונים של מודלים, הגדלתם עם המושג אובייקטים של נתונים עסקיים, ועכשיו אני הולך לדבר על האופן בו אנו מיישמים משמעות מסוימת יותר לסוגי דברים אלו ואיך אנו תופרים אותם יחד סביבות כוללות.

אני רק מנסה למצוא את ה- WebEx שלי כאן בכדי שאוכל לעשות זאת. והנה אנו חוזרים לשקופיות של הוט טק. אני רק הולך להעביר כמה שקופיות כאן מכיוון שכבר ראית את אלה בהדגמת הדוגמנית עצמה. אני רוצה לדבר על תקני שמות מהר מאוד. אנו רוצים להחיל ולאכוף תקני שמות שונים. מה שאנחנו רוצים לעשות הוא שיש לנו את היכולת לאחסן בפועל תבניות סטנדרטים של שמות במאגרינו לבנות בעצם את המשמעות באמצעות, דרך מילים או ביטויים או אפילו קיצורים, ולקשור אותם לסוג של אנגלית משמעותית. אנו נשתמש במונחים עסקיים, בקיצורים לכל אחד ואנחנו יכולים לציין את הסדר, את המקרים ולהוסיף קידומות וסיומות. מקרה השימוש האופייני לכך הוא בדרך כלל כאשר אנשים בונים מודל הגיוני ואז למעשה קדימה כדי ליצור מודל פיזי שבו יתכן שהם השתמשו בקיצורים וכל השאר.

הדבר היפה הוא שזה חזק באותה מידה, אפילו יותר חזק בהפוך, אם אנחנו רק יכולים לדעת מה היו כמה מאותם סטנדרטים של שמות בכמה מאותם מאגרי מידע פיזיים שהנדסנו לאחור, נוכל לקחת את אותם קיצורים, להפוך אותם לארוכים יותר מילים ולהביא אותן לאחור לביטויים באנגלית. אנו למעשה יכולים להפיק שמות ראויים עבור איך נראים הנתונים שלנו. כמו שאמרתי, מקרה השימוש הטיפוסי הוא שהיינו נעים קדימה, הגיוניים לפיזיים, וממפים את מאגרי הנתונים ואת סוג הדברים ההוא. אם אתה מסתכל על המסך שבצד ימין, אתה תראה שיש שמות מקוצרים משמות המקור וכאשר יישמנו תבנית סטנדרטים של שמות, למעשה יש לנו שמות מלאים יותר. ונוכל להכניס רווחים וכל דבר כזה אם נרצה, תלוי בתבנית תקני השמות בהם השתמשנו. אנחנו יכולים לגרום לזה להיראות בכל אופן שאנחנו רוצים שהוא ייראה למודלים שלנו. רק כשאנחנו יודעים איך קוראים למשהו, אנו יכולים להתחיל לצרף אליו הגדרות, כי אם איננו יודעים מה זה, כיצד נוכל ליישם לזה משמעות?

הדבר הנחמד הוא שאנו למעשה יכולים להפעיל זאת כשאנו עושים כל מיני דברים. דיברתי על הנדסת רוורס, אנו יכולים למעשה להפעיל תבניות סטנדרטיות של שמות במקביל כשאנחנו עושים הנדסת רוורס. אז במערכת אחת של שלבים באמצעות אשף, מה שאנחנו יכולים לעשות זה, אם אנחנו יודעים מה המוסכמות, נוכל להנדס מסד נתונים פיזי, זה יחזיר אותו כמודלים פיזיים בסביבת דוגמנות וזה גם הולך להחיל את מוסכמות השמות הללו. אז נראה מה הייצוגים של שמות הדומים לאנגלית במודל הלוגי המקביל בסביבה. אנחנו יכולים גם לעשות את זה ולשלב אותו עם דור ה- XML ​​Schema, כדי שנוכל לקחת מודל ואפילו לדחוף אותו עם הקיצורים שלנו, בין אם אנחנו מבצעים מסגרות SOA או סוג כזה של דבר, אז נוכל גם לדחוף מוסכמות שמות שונות שאנחנו למעשה שמרנו במודל עצמו. זה נותן לנו הרבה יכולות מאוד עוצמתיות.

שוב, הנה דוגמה כיצד היה נראה אם ​​הייתה לי תבנית. זה מראה למעשה שהיה לי EMP ל"עובד ", SAL עבור" משכורת ", PLN ל"תכנית" בוועידת תקני שמות. אני יכול גם ליישם אותם כדי שהם יפעלו באופן אינטראקטיבי, כשאני בונה מודלים ומכניס דברים. אם הייתי משתמש בקיצור הזה והקלדתי את "תוכנית שכר עובדים" על שם הישות, זה היה פועל בתבנית סטנדרטים של שמות. הגדרתי כאן, זה היה נותן לי EMP_SAL_PLN בזמן שאני יוצר את הישויות ומעניק לי מיד את השמות הפיזיים המתאימים.

שוב, טוב מאוד גם כשאנחנו מעצבים ומקדמים הנדסה. יש לנו מושג מאוד ייחודי וכאן אנו מתחילים להפגיש בין הסביבות הללו.וזה נקרא מיפוי אוניברסלי. לאחר שהבאנו את כל הדגמים הללו לסביבתנו, מה שאנחנו מסוגלים לעשות, בהנחה שעכשיו יישמנו את מוסכמות השמות הללו וקל למצוא אותם, נוכל כעת להשתמש במבנה שנקרא Universal Mappings ב- ER / סטודיו. אנו יכולים לקשר בין ישויות בין דגמים. בכל מקום בו אנו רואים "לקוח" - סביר להניח שיהיה לנו "לקוח" בהרבה מערכות שונות והרבה מאד מאגרי מידע שונים - נוכל להתחיל לקשר את כל אלה יחד, כך שכשאני עובד עם זה במודל אחד אני ניתן לראות היכן הביטויים של הלקוחות בדגמים האחרים. ומכיוון שיש לנו את שכבת הדגם המייצגת את זה, אנו יכולים אפילו לקשור אותו למקורות נתונים ולהביא אותו לשאלות המשומשות שלנו, באילו מאגרי מידע קיימים אלה. זה באמת נותן לנו יכולת לקשור את כל זה יחד בצורה מאוד מגובשת.

הראיתי לך את חפצי הנתונים העסקיים. אני גם רוצה לדבר על הרחבות המטא נתונים, שאנו מכנים קבצים מצורפים, מהר מאוד. מה שכן, זה נותן לנו את היכולת ליצור מטא נתונים נוספים עבור חפצי המודל שלנו. לעתים קרובות למדי הייתי מגדיר סוגים אלה של נכסים בכדי להוציא הרבה דברים שונים מנקודת מבט של ניהול נתונים ואיכות נתונים, וגם כדי לעזור לנו עם ניהול נתונים ראשיים ומדיניות שמירת נתונים. הרעיון הבסיסי הוא שאתה יוצר סיווגים אלה ותוכל לצרף אותם לכל מקום שתרצה, ברמת הטבלה, ברמת העמודה, אותם סוגים של דברים. מקרה השימוש הנפוץ ביותר הוא כמובן שישויות טבלאות ואז אוכל להגדיר: מהם אובייקטי נתוני האב שלי, מהן טבלאות הייחוס שלי, מהן טבלאות העסקאות שלי? מנקודת מבט לאיכות נתונים אני יכול לעשות סיווגים מבחינת חשיבות לעסק כך שנוכל לתעדף מאמצי טיהור נתונים וסוג כזה.

משהו שאי אפשר להתעלם ממנו הוא, מהי מדיניות השמירה עבור סוגים שונים של נתונים בארגון שלנו? אנחנו יכולים להגדיר את אלה ואנחנו יכולים למעשה לצרף אותם לסוגים שונים של חפצי מידע בסביבת הדוגמנות שלנו, וכמובן, גם למאגר שלנו. היופי הוא, אם קבצים מצורפים אלה חיים במילון הנתונים שלנו, כך שכאשר אנו משתמשים במילוני נתונים ארגוניים בסביבה, אנו יכולים לחבר אותם למספר דגמים. עלינו להגדיר אותם פעם אחת בלבד ונוכל למנף אותם שוב ושוב על פני הדגמים השונים בסביבתנו. זהו רק צילום מסך מהיר כדי להראות שאתה יכול למעשה לציין כשאתה מבצע קובץ מצורף, מהם כל החלקים שאתה רוצה לחבר אליו. והדוגמה הזו כאן היא למעשה רשימת ערכים, כך שכאשר הם נכנסים תוכלו לבחור מרשימת ערכים, יש לכם שליטה רבה בסביבת הדוגמנות של מה שנבחר, ותוכלו אפילו להגדיר מה ברירת המחדל ערך הוא אם ערך לא נבחר. אז הרבה כוח שם. הם חיים במילון הנתונים.

משהו שאני רוצה להראות לך קצת יותר למטה על המסך הזה, בנוסף אתה רואה את הקבצים המצורפים שמופיעים בחלק העליון, מתחתיו אתה רואה מידע על אבטחת מידע. אנו יכולים למעשה ליישם מדיניות אבטחת מידע גם על פיסות המידע השונות בסביבה. עבור מיפויי תאימות שונים, סיווגי אבטחת מידע, אנו שולחים מספר מהם מחוץ לקופסה שאתה יכול פשוט ליצור ולהתחיל להשתמש בהם, אך אתה יכול גם להגדיר מיפוי ותקנים משלך. בין אם אתה מבצע HIPAA או כל אחת מהיוזמות האחרות שם. ואתה באמת יכול להתחיל לבנות את מערכת המטא נתונים העשירה הזו בסביבתך.

ואז מילון המונחים והמונחים - כאן קשורה המשמעות העסקית. לרוב יש לנו מילוני נתונים בחוץ שלעתים קרובות ארגון משמש כנקודת מוצא כדי לגרש מילוני מונחים, אך המונחים והמונחים הם לעתים קרובות מאוד טכני. אז מה שאנחנו יכולים לעשות זה שנוכל, אם נרצה, להשתמש באלה כנקודת מוצא להוצאת מילון מונחים, אבל אנחנו באמת רוצים שהעסק יהיה בבעלות על אלה. מה שעשינו בסביבת שרת הצוות, אנו נותנים את היכולת של אנשים ליצור הגדרות עסקיות ואז נוכל לקשר אותם למוצרי המודל השונים אליהם הם תואמים גם בסביבת הדוגמנות. אנו מכירים גם בנקודה שנדונה קודם לכן שהיא, ככל שיש לך יותר אנשים להקליד, כך יש יותר פוטנציאל לטעות אנוש. מה שאנו עושים גם במבנה המילון שלנו הוא, אחד, אנו תומכים בהיררכיה של מילון מונחים, כך שנוכל להיות בסוגי מילון מונחים שונים או בסוגים שונים של דברים בארגון, אך חשוב לא פחות, אם כבר יש לכם כמה מקורות אלה בחוץ עם התנאים וכל מה שהוגדר, אנו יכולים למעשה לייבא CSV כדי למשוך אותם לסביבת הדוגמנות שלנו, לשרת הצוות שלנו או למילון המונחים שלנו, ואז להתחיל לקשר משם. ובכל פעם שמשהו משתנה יש מסלול ביקורת מלא של מה שהיו התמונות לפני ואחרי, מבחינת ההגדרות וכל השאר, ומה שתראו לראות שמתרחש בזמן הקרוב הוא גם יותר זרימת עבודה של הרשאה כך שנוכל באמת לשלוט על מי הממונה עליו, על אישורים של ועדות או אנשים, ועל סוג הדברים האלה, כדי להפוך את הניהול לממשל לחזק עוד יותר כשאנחנו הולכים קדימה.

מה שעושה לנו גם זה כאשר יש לנו מונחי מילון מונחים אלה במונחי מילון השרתים של הצוות שלנו, זו דוגמה לעריכה בישות במודל עצמו שהבאתי כאן. יכול להיות שיש לזה מונחים מקושרים, אבל מה שאנחנו גם עושים זה אם יש מילים שנמצאות באותו מילון מונחים המופיע בתווים או בתיאורים של מה שיש לנו בישויות שלנו כאן, אלה מוצגות אוטומטית בצבע היפר-קישור בהיר יותר, ואם אנחנו עם העכבר עליהם, אנו יכולים ממש לראות גם את ההגדרה ממילון המונחים העסקי. זה אפילו נותן לנו מידע עשיר יותר כאשר אנו צורכים את המידע עצמו, עם כל מונחי מילון המונחים שם. זה באמת עוזר להעשיר את החוויה וליישם את המשמעות על כל מה שאנחנו עובדים איתו.

אז שוב, זה היה זבוב מהיר מאוד. ברור שיכולנו לבלות על זה כמה ימים כשאנחנו מתעמקים בחלקים השונים, אבל זה זבוב מהיר מאוד על פני השטח. מה שאנחנו באמת שואפים לעשות זה להבין איך נראות סביבות נתונים מורכבות אלה. אנו רוצים לשפר את הנראות של כל ממצאי הנתונים הללו ולשתף פעולה בכדי להרחיק אותם עם ER / Studio. אנו רוצים לאפשר דוגמנות נתונים יעילה ואוטומטית יותר. וזה כל סוגי הנתונים שאנחנו מדברים עליהם, בין אם מדובר בנתונים גדולים, נתונים יחסיים מסורתיים, חנויות מסמכים או כל דבר אחר. ושוב, השגנו זאת מכיוון שיש לנו יכולות הנדסיות קדימה ואחוריות לפלטפורמות השונות וכלים אחרים שיש לכם שם. והכל עניין שיתוף ותקשורת ברחבי הארגון עם כל בעלי העניין המעורבים. כאן אנו מיישמים משמעות באמצעות תקני שמות. לאחר מכן אנו משתמשים בהגדרות באמצעות מילוני מונחים עסקיים שלנו. ואז נוכל לבצע סיווגים נוספים עבור כל יכולות הניהול האחרות שלנו באמצעות תוספי המטא נתונים כמו תוספי איכות נתונים, סיווגים לניהול נתוני אב או כל סוג אחר של סיווגים שתרצה להחיל על אותם נתונים. ואז נוכל לסכם עוד יותר ולשפר את התקשורת ביתר שאת עם אובייקטים של נתונים עסקיים, עם קהלי העניין השונים, במיוחד בין דוגמניות למפתחים.

ושוב, מה שמאוד חשוב בזה הוא שמאחורי כל זה מאגר משולב עם יכולות ניהול שינויים חזקות מאוד. לא היה לי זמן להראות את זה היום כי זה נהיה מורכב למדי, אבל למאגר יש יכולות ניהול חזקות מאוד ושבילי ביקורת. אתה יכול לעשות מהדורות שנקבעו, אתה יכול לעשות גרסאות ששמו, ויש לנו גם את היכולת לאלו מכם שעושים ניהול שינויים, נוכל לקשור את זה נכון למשימות שלך. יש לנו היום את היכולת להכניס משימות ולשייך את שינויי המודל שלך למשימות, ממש כמו שמפתחים היו משייכים את שינויי הקוד שלהם למשימות או לסיפורי המשתמשים שהם עובדים איתם.

שוב, זו הייתה סקירה מהירה מאוד. אני מקווה שזה הספיק כדי להשיג את התיאבון שלך כדי שנוכל לנהל שיחות עמוקות הרבה יותר על פיצול חלק מהנושאים האלה כשאנחנו הולכים קדימה בעתיד. תודה לך על הזמן שלך, ובחזרה אליך, רבקה.

רבקה יוז'ויאק: תודה, רון, זה היה פנטסטי ויש לי לא מעט שאלות מהקהל, אבל אני כן רוצה לתת לאנליסטים שלנו סיכוי לשקוע את שיניהם במה שהיה לך לומר. אריק, אני הולך להתקדם ואולי אם ברצונך להתייחס לשקופית הזו, או שקופית אחרת, מדוע אתה לא קדימה קודם? או כל שאלה אחרת.

אריק ליטל: בטוח. סליחה, מה הייתה השאלה, רבקה? אתה רוצה שאשאל משהו ספציפי או ...?

רבקה יוז'ויאק: אני יודע שהיו לך כמה שאלות בתחילה לרון. אם אתה רוצה לבקש עכשיו שהוא יפנה לאחד מאלה, או לחלק מהם מחוץ לשקופית שלך או כל דבר אחר שעורר את העניין שלך שאתה רוצה לשאול עליו? אודות פונקציות הדוגמנות של IDERA.

אריק ליטל: כן, אז אחד הדברים, רון, אז איך אתם, נראה שהדיאגרמות שהצגתם הם סוגים כלליים של דיאגרמות של יחסי ישויות כמו שבדרך כלל הייתם משתמשים בבניית בסיס נתונים, נכון?

רון הויזנגה: כן, באופן כללי, אבל כמובן שיש לנו את הסוגים המורחבים לחנויות המסמכים וגם לסוג הדברים הזה. אנחנו למעשה מגוונים מסימן יחסים טהור בלבד, הוספנו תוויות נוספות גם לחנויות האחרות האלה.

אריק ליטל: האם יש דרך בה אתם יכולים להשתמש בסוגים של דגמים מבוססי גרף, אז האם יש דרך לשלב, למשל, בואו נניח שיש לי משהו כמו רביע עליון, כלי מלחין TopBraid או שעשיתי משהו ב- Protégé או אתה יודע, כמו החבר'ה הפיננסיים ב- FIBO, הם עושים הרבה עבודה בסמנטיקה, דברים של RDF - האם יש דרך להכניס את הכלי הזה למודלים מסוג גרפי יחסי-יחסים לכלי הזה ולהשתמש בו?

רון הויזנגה: אנו למעשה בודקים כיצד אנו יכולים להתמודד עם גרפים. אנו לא מטפלים היום במפורש בבסיסי נתונים של גרפים וסוג כזה, אך אנו בוחנים דרכים שנוכל לעשות זאת כדי להרחיב את המטא נתונים שלנו. כלומר, אנחנו יכולים להביא דברים דרך XML וסוג כזה של דברים ברגע, אם נוכל לפחות לעשות איזשהו ביצוע של XML כדי להביא אותו כנקודת התחלה. אבל אנו בודקים דרכים אלגנטיות יותר להכניס את זה.

והראיתי לך גם את הרשימה של גשרי הנדסה הפוכה שיש לנו שם גם כן, ולכן אנחנו תמיד בוחנים להשיג הרחבות לגשרים האלה גם לפלטפורמות ספציפיות. זהו מאמץ מתמשך ומתמשך, אם זה הגיוני, להתחיל לאמץ הרבה מבנים חדשים אלה ופלטפורמות שונות שם. אבל אני יכול לומר שאנחנו בהחלט בחזית העשייה. הדברים שהראתי עליהם, למשל, MongoDB וסוג כזה, אנחנו הספקים הראשונים של דוגמנות הנתונים שעושים זאת באופן טבעי במוצר שלנו.

אריק ליטל: אוקיי כן. אז השאלה השנייה שהייתה לי עבורך, אם כן, הייתה מבחינת הממשל ושמירה על זה - כמו כשהשתמשת בדוגמא, כשהראית את הדוגמא של האדם שהוא "עובד", אני מאמין שזה היה " משכורת "ואז יש לך" תוכנית ", האם יש דרך, איך אתה מנהל, למשל, סוגים שונים של אנשים שעלולים להיות - בוא נניח שיש לך ארכיטקטורה גדולה, נכון, בוא נניח שיש לך עסק גדול ו אנשים מתחילים לחבר דברים בכלי הזה ויש לך קבוצה אחת כאן שיש לה את המילה "עובד" וקבוצה אחת כאן שיש לה את המילה "עובד." ואדם אחד כאן אומר "משכורת" ואדם אחר אומר "שכר."

איך אתם מיישבים ומנהלים ומנהלים את ההבחנות הללו? מכיוון שאני יודע איך היינו עושים את זה בעולם הגרפים, אתה יודע, היית משתמש ברשימות נרדפות או שאתה אומר שיש מושג אחד ויש לו כמה תכונות, או שאתה יכול לומר במודל SKOS יש לי תווית מועדפת ויש לי מספר תוויות חלופיות בהן אוכל להשתמש. איך אתם עושים את זה?

רון הויזנגה: אנו עושים זאת בכמה אופנים שונים ובעיקר נדבר תחילה על המינוח. אחד הדברים שאנחנו עושים, כמובן, הוא שאנחנו רוצים שיהיו המונחים המוגדרים או המחויבים, ובמילון המונחים העסקי ברור שהוא המקום בו אנו רוצים. ואנחנו מאפשרים גם קישורים למילים נרדפות במילון המונחים העסקי, ולכן מה שתוכלו לעשות זה שתוכלו לומר, הנה המונח שלי, אבל תוכלו גם להגדיר מה כל המילים נרדפות לאלה.

עכשיו, כמובן, הדבר המעניין הוא שכשאתה מתחיל להסתכל על נוף הנתונים העצום הזה עם כל המערכות השונות האלה שיש לך שם, אתה לא יכול פשוט לצאת לשם ולשנות את הטבלאות המתאימות ואת סוגי הדברים האלה ל תואמים את אותו תקן שמות מכיוון שייתכן שזו חבילה שקנית, כך שאין לך שליטה בשינוי מסד הנתונים או בכלל.

מה שיכולנו לעשות שם, בנוסף לכך שיכולנו לשייך את הגדרות המילון, הוא באמצעות המיפויים האוניברסאליים עליהם דיברתי, מה היינו עושים וסוג הגישה המומלצת הוא לקבל מודל לוגי עיקרי המפרט מה המושגים העסקיים השונים האלה הם שאתה מדבר עליהם. קשרו את מונחי המונחים העסקיים לאלו, והדבר הנחמד הוא שעכשיו שיש לכם את הבנייה הזו שמייצגת ישות לוגית כביכול, תוכלו להתחיל לקשר מאותו ישות לוגית לכל היישומים של אותה ישות לוגית ב- המערכות השונות.

אז איפה שאתה צריך לעשות זאת, אתה יכול לראות, הו, "אדם" כאן נקרא "עובד" במערכת זו. "שכר" כאן נקרא "שכר" כאן במערכת אחרת זו. מכיוון שתראה זאת, תראה את כל הביטויים השונים של אלה מכיוון שקשרת אותם זה לזה.

אריק ליטל: בסדר נהדר, כן, הבנתי. במובן זה, האם אפשר לומר שזה דומה לכמה מהגישות המכוונות לאובייקט?

רון הויזנגה: במידה מסוימת. זה קצת יותר אינטנסיבי מאשר, אני מניח שאפשר לומר. כלומר, אתה יכול לנקוט בגישה של קישור ידני ולעבור ולבדוק ולעשות את כולם גם כן. הדבר היחיד שלא היה לי באמת סיכוי לדבר עליו - כי שוב, יש לנו הרבה יכולות - יש לנו גם ממשק אוטומציה מלא בכלי Data Architect עצמו. ויכולת מאקרו, שהיא באמת שפת תכנות בכלי. כך שנוכל למעשה לעשות דברים כמו לכתוב מקרואים, שנלך לחקור דברים וליצור עבורך קישורים. אנו משתמשים בו לצורך ייבוא ​​וייצוא של מידע, אנו יכולים להשתמש בו לצורך שינוי דברים או הוספת תכונות, אירוע המבוסס במודל עצמו, או אנו יכולים להשתמש בו כדי לרוץ בקבוצות כדי לצאת לחקור דברים ולמעשה לאכלס מבנים שונים דגם. אז יש ממשק אוטומציה מלא שאנשים יכולים לנצל גם אותו. ושימוש במיפויים האוניברסאליים עם אלה יהיה דרך עוצמתית מאוד לעשות זאת.

רבקה יוז'ויאק: אוקיי, תודה לרון, ותודה לאריק. אלה היו שאלות נהדרות. אני יודע שאנחנו עוברים קצת מעבר לשעה, אבל אני רוצה לתת למלקולם הזדמנות להשליך כמה שאלות על דרכו של רון. מלקולם?

מלקולם שישולם: תודה, רבקה. אז, רון, זה מאוד מעניין, אני רואה שיש כאן הרבה יכולות. אחד התחומים שאני מאוד מתעניין בהם הוא, נניח אם יש לנו פרויקט פיתוח, איך אתה רואה את מעצב הנתונים המשתמש ביכולות האלה ועובד אולי יותר בשיתוף פעולה עם אנליסטים עסקיים, עם פרופיל נתונים, עם אנליסט איכות נתונים , ועם הספונסרים העסקיים שבסופו של דבר יהיו אחראים לדרישות המידע בפועל בפרויקט. איך באמת מעצב הנתונים, אתה יודע, הופך את הפרויקט ליעיל ויעיל יותר עם היכולות שאנו בוחנים?

רון הויזנגה: אני חושב שאחד הדברים הראשונים שאתה צריך לעשות שם הוא כמודנן נתונים - ואני לא מתכוון לבחור בכמה מהמודלים, אבל בכל מקרה אעשה זאת - האם יש אנשים שעדיין יש להם רושם שמעצב הנתונים הוא באמת סוג שומר הסף של תפקיד כמו, אנחנו מגדירים איך זה עובד, אנחנו השומרים שמוודאים שהכל נכון.

עכשיו יש היבט של זה, שאתה צריך לוודא שאתה מגדיר ארכיטקטורת נתוני קול וכל השאר. אבל הדבר החשוב יותר הוא כמעצב נתונים - ומצאתי את זה לא מעט ברור כאשר התייעצתי - האם אתה צריך להיות מנחה, אז אתה צריך לחבר את האנשים האלה יחד.

זה לא יהיה עיצוב מקדימה, ליצור, לבנות בסיסי נתונים יותר - מה שאתה צריך להיות מסוגל לעשות זה שאתה צריך להיות מסוגל לעבוד עם כל קבוצות בעלי העניין השונים האלה, לעשות דברים כמו הנדסת רוורס, ייבוא ​​מידע, אנשים אחרים משתפים פעולה, בין אם זה על מילון המונחים או על התיעוד, כל דבר כזה - והיה מנחה כדי למשוך את זה למאגר ולקשר את המושגים יחד במאגר ולעבוד עם אותם אנשים.

זה באמת הרבה יותר סוג של שיתוף פעולה של סביבה, שאפילו באמצעות הגדרת משימות או אפילו שרשור דיונים או סוג הדברים שיש לנו בשרת הצוות, שאנשים יכולים ממש לשתף פעולה, לשאול שאלות ולהגיע למוצרי הסיום הסופיים שהם צורך בארכיטקטורת הנתונים שלהם ובארגון שלהם. האם תשובה מסוג זה?

מלקולם שישולם: כן אני מסכימה. אתה יודע, אני חושב שמיומנות ההנחיה היא משהו שמאוד מבוקש אצל דוגמניות הנתונים. אני מסכים שאנחנו לא תמיד רואים את זה, אבל אני חושב שזה הכרחי והייתי מציע שיש לפעמים נטייה להישאר בפינה שלך ולעשות דוגמנות נתונים שלך, אבל אתה באמת צריך להיות שם בחוץ ולעבוד עם קבוצות בעלי העניין האחרים או שאתה פשוט לא מבין את סביבת הנתונים שאתה מתמודד איתה, ולדעתי המודל סובל כתוצאה מכך. אבל זו רק דעתי.

רון הויזנגה: וזה מעניין מכיוון שציינת משהו קודם בשקופית שלך על ההיסטוריה של האופן שבו עסקים מסוגלים להפנות אותם מ- IT מכיוון שהם לא סיפקו את הפתרונות בצורה מתוזמנת וסוגי הדברים האלה.

זה מעניין מאוד, כי בהתקשרותיי המאוחרות שלי, לפני שהפכתי למנהל מוצר, מרבית הפרויקטים שעשיתי בשנתיים האחרונות לפני כן, היו בחסות עסקית, שם היה זה העסק שהניע אותו ואדריכלי הנתונים. והמודלנים לא היו חלק מ- IT. היינו חלק מקבוצה בחסות עסק והיינו שם כמנחים שעבדו עם שאר צוותי הפרויקט.

מלקולם שישולם: אז אני חושב שזו נקודה מאוד מעניינת.אני חושב שאנחנו מתחילים לראות שינוי בעולם העסקים בו העסק מבקש, או לחשוב אולי, לא כל כך מה אני עושה, להיות בתהליך, אבל הם גם מתחילים לחשוב מה הנתונים שאני עובד איתם, מהם צרכי הנתונים שלי, מהם הנתונים שאני עוסק בהם כנתונים ובאיזו מידה נוכל להשיג מוצרים ויכולות של IDERA כדי לתמוך בנקודת מבט זו, ואני חושב שצרכי העסק, אפילו למרות שזה עדיין קצת מתנשא.

רון הויזנגה: אני מסכים איתך ואני חושב שאנחנו רואים את זה הולך יותר ויותר ככה. ראינו התעוררות ונגעת בזה קודם לכן מבחינת חשיבות הנתונים. ראינו את החשיבות של נתונים בשלב מוקדם ב- IT או בהתפתחות מסדי נתונים, ואז, כמו שאתה אומר, נכנסנו לכל מחזור ניהול התהליכים הזה - והתהליך חשוב ביותר, אל תבינו אותי לא נכון - אבל עכשיו מה שקרה כאשר זה קרה, נתונים מסוג מיקוד אבוד.

ועכשיו ארגונים מבינים כי נתונים הם באמת נקודת המוקד. נתונים מייצגים את כל מה שאנחנו עושים בעסק שלנו ולכן עלינו לוודא שיש לנו נתונים מדויקים, שנוכל למצוא את המידע הנכון שאנחנו צריכים בכדי לקבל את ההחלטות שלנו. כי לא הכל מגיע מתהליך מוגדר. חלק מהמידע הוא תוצר לוואי של דברים אחרים ואנחנו עדיין צריכים להיות מסוגלים למצוא אותו, לדעת מה המשמעות של זה, ולהיות מסוגלים לתרגם את הנתונים שאנו רואים שם בסופו של דבר לידע בו אנו יכולים להשתמש כדי להניע את העסקים שלנו.

מלקולם שישולם: נכון, ועכשיו תחום אחר שהתמודדתי איתו הוא מה שהייתי קורא לו מחזור חיי הנתונים שהוא, אתה יודע, אם אנו מסתכלים על סוג שרשרת אספקת הנתונים העוברת על ידי ארגון, נתחיל ברכישת נתונים או לכידת נתונים, אשר עשויה להיות הזנת הנתונים, אך באותה מידה, אני מקבל נתונים מחוץ לארגון מספק נתונים כלשהו.

ואז מלכידת נתונים אנו עוברים לתחזוקת נתונים, שם אני חושב על סטנדרטיזציה של נתונים אלה ומשלוח אותם למקומות שבהם הם נדרשים. ואז השימוש בנתונים, הנקודות האמיתיות בהן הנתונים נמצאים, אתה הולך להפיק ערך מהנתונים.

ובימים עברו כל זה נעשה בסגנון אינדיבידואלי אחד, אבל היום זה יכול להיות, אתה יודע, סביבת אנליטיקה, למשל, ואז מעבר לזה, ארכיב, חנות, שם אנו שמים את הנתונים כשאנחנו כבר לא צריך את זה ולבסוף סוג של תהליך הטיהור. איך אתה רואה דוגמנות נתונים שמתאימות לניהול כל מחזור חיי הנתונים הזה?

רון הויזנגה: זו שאלה טובה מאוד ודבר אחד שבאמת לא הספקתי להתעמק בפרטי כאן היום בכלל, זה מה שאנחנו באמת מתחילים לדבר עליו הוא שושלת נתונים. אז מה שאנחנו באמת יכולים לעשות זה שיש לנו יכולת שושלת נתונים בכלים שלנו, וכפי שאומר, אנו יכולים למעשה לחלץ חלק ממנו מכלי ETL, אבל אתה יכול גם למפות אותו רק על ידי ציור השושלת. כל אחד ממודלי הנתונים או מסדי הנתונים האלה שתפסנו והבאנו למודלים נוכל להתייחס למבנים מהם בתרשים שושלת הנתונים שלנו.

מה שאנחנו מסוגלים לעשות זה לצייר זרימת נתונים, כמו שאתה אומר, ממקור למטרה, ובאמצעות מחזור החיים הכולל של האופן שבו נתונים אלה עוברים דרך המערכות השונות ומה שאתה הולך למצוא הוא, בואו ניקח עובדים נתונים - זה אחד האהובים עלי על סמך פרויקט שעשיתי לפני שנים. עבדתי עם ארגון שהיה לו נתוני עובדים ב 30 מערכות שונות. מה שבסופו של דבר עשינו שם - ורבקה הציגה את שקופית שושלת הנתונים - זו שקופית שושלת נתונים פשטנית למדי כאן, אבל מה שהצלחנו לעשות זה להכניס את כל מבני הנתונים, להתייחס אליהם בתרשים ואז באמת יכול להתחיל להסתכל על מה הם הזרמים בין, ואיך ישויות נתונים שונות אלו קשורות זו לזו בזרימה? ואנחנו יכולים לחרוג גם כן. זה חלק מתרשים זרימת נתונים או שושלת שאנו רואים כאן. אם אתה רוצה לחרוג מכך יש לנו גם את האדריכל העסקי בסוויטה הזו ואותו הדבר תקף שם.

כל אחד ממבני הנתונים שתפסנו בסביבת דוגמנות הנתונים, ניתן להפנות אותם לכלי הדוגמנות העסקית כך שאפילו בתרשימי המודל העסקי שלך או בתרשימי התהליך העסקי שלך, אתה יכול להפנות לחנויות נתונים בודדות אם ברצונך לצאת בסביבת דוגמנות הנתונים, ובזמן שאתה משתמש בהן בתיקיות במודל התהליכים העסקיים שלך, אתה יכול אפילו לציין את ה- CRUD גם על אלה, כיצד לצרוך או להפיק מידע זה ואז נוכל להתחיל לייצר דברים כמו דוחות השפעה וניתוח ודיאגרמות מזה.

אל מה שאנו מכוונים להגיע, ויש לנו כבר הרבה יכולות, אבל אחד הדברים שיש לנו סוג כזה של עמדת יעד שאנו מסתכלים עליהם, כאשר אנו ממשיכים לפתח את הכלים שלנו קדימה, הוא מסוגל למפות את שושלת הנתונים הארגונית מקצה לקצה ואת מחזור החיים המלא של הנתונים.

מלקולם שישולם: בסדר. רבקה, האם מותר לי עוד אחת?

רבקה יוז'ויאק: אני אתן לך עוד אחד, מלקולם, קדימה.

מלקולם שישולם: תודה רבה לך. מתוך מחשבה על ממשל נתונים וחשיבה על מידול נתונים, כיצד אנו גורמים לשתי הקבוצות הללו לעבוד ביעילות ולהבין אחד את השני?

אריק ליטל: ובכן זה מעניין, אני חושב שזה באמת תלוי בארגון, וזה חוזר לתפיסה הקודמת שלי, בארגונים שבהם היוזמות היו מונעות עסקיות שקשרנו ישר. למשל, אני מוביל צוות אדריכלות נתונים אבל אנחנו נקשרו ממש עם המשתמשים העסקיים ובעצם עזרנו להם לעמוד על תוכנית ניהול הנתונים שלהם. שוב, יותר גישה מייעצת, אבל זה באמת יותר פונקציה עסקית.

מה שאתה באמת צריך כדי להיות מסוגל לעשות זאת הוא שאתה זקוק למודלי נתונים ואדריכלים של נתונים שמבינים באמת את העסק, יכולים להתייחס למשתמשים העסקיים ואז עזרו להם לעמוד בתהליכי הממשל סביבו. העסק רוצה לעשות את זה, אך באופן כללי יש לנו את הידע הטכנולוגי שנוכל לעזור להם להתבלט מסוגי התוכנות הללו. זה באמת צריך להיות שיתוף פעולה, אבל זה צריך להיות בבעלות עסקית.

מלקולם שישולם: אוקיי, זה נהדר. תודה.

ד"ר אריק ליטל: בסדר.

רבקה יוז'ויאק: אוקיי, תודה רבה. חברי קהל, אני חושש שלא הגענו לשאלות שלך, אבל אני אדאג שהם אכן יועברו לאורח המתאים שהיה לנו היום בקו. אני רוצה להודות לך כל כך לאריק, מלקולם ורון על היותם האורחים שלנו היום. אלה היו דברים נהדרים, אנשים. ואם נהניתם מהמהדורה המקוונת של IDERA היום, IDERA תעלה ביום רביעי הבא ב- Hot Technologies אם תרצו להצטרף, תדונו באתגרים של אינדקס ואורקלס, אז נושא מרתק נוסף.

תודה רבה אנשים, תשמרו על עצמכם ונראה אתכם בפעם הבאה. ביי ביי.