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

על ידי צוות Techopedia, 28 בספטמבר 2016

ברק: המארחת רבקה יוז'ויאק דנה בפתרונות לארכיטקטורת נתונים עם אריק ליטל מ- 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 Objects Data. ומה שמאפשר לנו לעשות זה שזה מאפשר לנו להכיל קבוצות של ישויות או טבלאות לאובייקטים עסקיים אמיתיים.

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

אני רק מנסה למצוא את ה- 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 אם תרצה להצטרף, תדון באתגרים של אינדקס ואורקלס, אז נושא מרתק נוסף.

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