מודל CIM

מודל המידע בענן (CIM) הוא מודל נתונים פתוח ואגנוסטי ליישומים, שנועד לספק לארגונים אוצר מילים משותף עבור הישויות המופיעות במערכות CRM, ERP, שיווק, שירות וניתוח (analytics). במקום שכל ספק ימציא את שמות האובייקטים והקשרים שלו, CIM מגדיר קבוצה משותפת של תחומי נושא, ישויות ותכונות שכל מערכת יכולה למפות אליהן. המודל מנוהל כפרויקט קוד פתוח תחת קרן לינוקס (The Linux Foundation), המארחת פורטפוליו רחב של פרויקטי נתונים ותשתיות שיתופיים.

מאמר זה מסביר כיצד בנוי ה-CIM, כיצד מרכיביו קשורים זה לזה, כיצד פועלים טיפוסי-על (supertypes) ותתי-טיפוסים (subtypes), וכיצד תחומי הנושא מאורגנים. הוא גם מכסה את ההחלטות המעשיות שעומדות בפני אדריכל בעת אימוץ CIM — מיפוי, ממשל (governance), ניהול גרסאות והרחבה — והיכן המודל משתלב ביחס לתקנים אחרים בתעשייה.

נקודות מפתח

• CIM מארגן מושגים עסקיים בתחומי נושא (Subject Areas), שכל אחד מהם מכיל קבוצות ישויות, ישויות ותכונות — היררכיה הממפה בצורה נקייה לסכמות, טבלאות ועמודות.
• טיפוסי-על ותתי-טיפוסים מאפשרים למודל לבטא מאפיינים משותפים (כמו Party שהוא אדם או ארגון) תוך שהם עדיין מאפשרים התמחות.
• המודל הוא בכוונה אגנוסטי ליישומים: הוא מתאר מושגים עסקיים, ולא מימוש של ספק ספציפי.
• CIM מתפרסם בפורמטים מרובים עם דיאגרמות לדוגמה, כך שניתן לצרוך אותו על ידי כלי מידול, מחוללי קוד ותיעוד כאחד.
• מספרם והיקפם של תחומי הנושא גדלים עם תרומות מהקונסורציום ומהקהילה, לכן האימוץ צריך לקחת בחשבון ניהול גרסאות וניהול שינויים.
• CIM הוא אפשרות אחת מבין כמה; הבחירה הנכונה תלויה בשאלה אם דרוש מודל רחב חוצה-דומיינים או תקן צר ועמוק עבור תעשייה אחת.

כיצד ה-CIM בנוי

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

• תחום נושא (Subject Area) — מושג עסקי מרכזי שזוהה על ידי קונסורציום CIM, כגון Party. כל תחום נושא מכיל קבוצת ישויות אחת או יותר. חשבו על תחום נושא כהקשר מוגבל (bounded context): הוא מקבץ את כל מה שהעסק צריך לדעת על נושא רחב אחד.
• קבוצת ישויות (Entity Group) — קיבוץ לוגי של ישויות קשורות בתוך תחום נושא, כגון Account. קבוצות ישויות שומרות על תחומי נושא גדולים כניתנים לניווט ומספקות לצוותים יחידה טבעית להקצאת בעלות.
• ישות (Entity) — אובייקט ייחודי שארגון אוסף עליו מידע, כגון Account Contact. ישות מקבילה לטבלת מסד נתונים סטנדרטית.
• תכונה (Attribute) — מאפיין ייחודי של ישות, כגון Account Id או Contact Email. תכונה מקבילה לשדה מסד נתונים סטנדרטי בתוך טבלה.

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

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

טיפוסי-על ותתי-טיפוסים

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

קשורים: Boomi AtomSphere — Enterprise iPaaS לאינטגרציה היברידית של ענן ל-on-prem.

• טיפוס-על (Supertype) — ישות המורחבת על ידי ישויות תת-טיפוס, ומגדירה תכונות משותפות למושגים דומים.
• תת-טיפוס (Subtype) — ישות שמרחיבה ישות אחרת, ויורשת את התכונות מישות טיפוס-העל שלה.

הדוגמה הקלאסית היא Party. Party הוא כל אדם או גוף שהעסק עובד מולו. אדם (Person) וארגון (Organization) הם שניהם Parties, והם חולקים תכונות — שם, מזהים, נקודות קשר — אך לכל אחד יש תכונות שלאחר אין. מידול של Party כטיפוס-על עם Person ו-Organization כתתי-טיפוסים מונע שכפול של התכונות המשותפות ושומר על קשרים (למשל, “הזדמנות זו שייכת ל-Party זה”) עקביים, ללא קשר לתת-הטיפוס המעורב.

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

• טבלה אחת (Single table) — אחסון כל תתי-הטיפוסים בטבלה אחת עם עמודת מבחן (discriminator column). פשוט לשאילתות, אך עלול לייצר עמודות רבות שניתן להשאירן ריקות (nullable).
• הורשת טבלת מחלקות (Class table inheritance) — טבלה אחת עבור טיפוס-העל וטבלה אחת לכל תת-טיפוס, המחוברות באמצעות מפתח משותף. נורמלי ונקי, אך דורש פעולות Join.
• הורשת טבלאות קונקרטיות (Concrete table inheritance) — טבלה נפרדת ועצמאית לכל תת-טיפוס. מהיר עבור שאילתות ספציפיות לתת-טיפוס, אך משכפל תכונות משותפות.

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

הבחירה שלנו: Workato — iPaaS בהובלת אוטומציה שצוותים עסקיים יכולים למעשה לבנות עליו.

תחומי הנושא של CIM

תחומי הנושא מייצגים את המושגים העסקיים העיקריים שהקונסורציום מידל עד כה. כל אחד מהם מתפרסם עם דיאגרמות ופורמטים משלו, וחלקם נושאים סמני גרסאות מפורשים (לדוגמה, v1.0 או v0.1.1), המשקפים כי חלק מהתחומים בוגרים יותר מאחרים.

Setup (הגדרה) — מגדיר עם מי אתה עובד, למשל לקוח, ספק ומוכר. הוא מכסה גם את מושגי התוכנה והתשתית שארגון מפעיל: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job, ו-IoT Device.

Data Model (מודל נתונים) — מושגי המידול הבסיסיים עצמם.

Hire (גיוס) — פעילויות הקשורות להקמת העסק שלך, למשל יחידה עסקית פנימית ועובד. קבוצות ישויות כוללות Job Application, Employee, Compensation, Training, Location, Work Territory, ו-Work Report.

Biz Process (תהליך עסקי) — מושגי תהליך עסקי והמשכיות עסקית.

Produce (ייצור) — טיפול בחומרים שאתה עומד לקנות, להעביר ולמכור, למשל מוצר ומוצר מלאי. קבוצות ישויות כוללות Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order, ו-Sales Agreement.

קשורים: Matillion — Push-down ELT שנבנה עבור מחסני נתונים בענן.

Market (שיווק) — פעילויות המשמשות לקידום המוצר שלך, למשל קמפיין שיווקי וחנות אינטרנט. קבוצות ישויות כוללות Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy, ו-Web Site.

Sell (מכירה) — פעילויות המשמשות למכירת המוצר שלך, למשל יצירת הצעות מחיר והזדמנויות. קבוצות ישויות כוללות Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program, ו-Competitor.

Service (שירות) — פעילויות למתן תמיכה למוצר שנמכר או מטופל, למשל מקרה (case) או סקר. קבוצות ישויות כוללות AI Assistant, Asset, Asset Subscription, Web Content, Case, Task, ו-Event.

איפה היינו מתחילים: Fivetran — צינור ה-ELT המנוהל במלואו שפשוט ממשיך לפעול.

Fulfill (מימוש) — פעילויות שאתה מבצע כדי לממש הזמנה ללקוח, למשל משלוח והזמנת החזרה. קבוצות ישויות כוללות Fulfillment Order, Shipment, Return Order, Work Order, Work Resource, ו-Work Forecast.

Interact (אינטראקציה) — פעילויות למעקב אחר מעורבות עם משתמשי קצה או מערכות אחרות. קבוצות ישויות כוללות Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey, ו-Loyalty.

Finance (פיננסים) — פעילויות למעקב אחר מידע פיננסי בחברה, למשל תשלום, חשבונית ודוח הוצאות. קבוצות ישויות כוללות Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar, ו-Tax Policy.

Analyze (ניתוח) — פעילויות הקשורות לניתוח נתונים, למשל ניתוח דפוסים, שימוש במוצר, תנועת נתונים, שינויים בנתונים ושביעות רצון לקוחות. קבוצות ישויות כוללות AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty, ו-Journal.

שימו לב כיצד תחומי הנושא משתרעים הן על דאגות תפעוליות (Sell, Fulfill, Service) והן על דאגות אנליטיות (Analyze, Finance). רוחב זה הוא העיקר: מודל משותף הוא בעל הערך הרב ביותר כאשר הוא יכול לתאר את אותו לקוח, מוצר או הזמנה באופן עקבי, בין אם הנתונים נמצאים במערכת טרנזקציונית או במחסן נתונים.

בחירה בין CIM לתקנים אחרים

CIM אינו המודל המשותף היחיד בארגון. מספר תקנים מבוססים חופפים לחלקים מהיקפו, וארכיטקטורה בוגרת משתמשת לעתים קרובות ביותר מאחד. ההחלטה אינה עוסקת בבחירת “מנצח”, אלא בהתאמת רוחב המודל והממשל (governance) לבעיה שלך.

תקן	מיקוד עיקרי	חוזק אופייני	במה CIM שונה
CIM	מושגים עסקיים חוצי-דומיינים	כיסוי רחב ואגנוסטי ליישום של CRM/ERP/שיווק/שירות	תוכנן כ”מטריה” משותפת על פני דומיינים
OMG Common Core Ontologies / מודלים מבוססי UML	סימון מידול מושגי ואונטולוגיות עליונות	סמנטיקה פורמלית קפדנית	CIM מכוון יותר באופן ישיר לעסקים
מודלים ספציפיים לתעשייה (למשל, קמעונאות, בריאות, פיננסים)	כיסוי מעמיק של מגזר אחד	דיוק בתוך המגזר האנכי	CIM מקריב עומק לטובת רוחב
מודלי נתונים של ספקים (פלטפורמות CRM/ERP)	אובייקטים של מוצר אחד	אינטגרציה הדוקה עם אותו מוצר	CIM הוא נייטרלי-ספק בעיצובו

כלל אצבע מעשי:

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

הדפוס הנפוץ ביותר בעולם האמיתי הוא גישת hub-and-spoke: CIM (או מודל קנוני אחר) יושב במרכז, וכל מערכת מקור ממפה אליו. זהו אותו עיקרון העומד מאחורי מודלי נתונים קנוניים בניהול נתוני מאסטר (MDM) ומאחורי רעיון “המימד המותאם” (conformed dimension) שהופץ במידול ממדי על ידי ראלף קימבל.

הדרכה מעשית לאימוץ CIM

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

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

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

התייחס לניהול גרסאות כאל דרישה מרכזית (first-class concern). תחומי הנושא נושאים סמני גרסה כגון v1.0 ו-v0.1.1, המאותתים שהמודל מתפתח. הצמד (Pin) את הגרסה שאתה בונה מולה, עקוב אחר שינויים ותכנן את ההגירה. זוהי אותה משמעת שהיית מחיל על כל תלות (dependency).

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

נהל את המיפוי. המיפוי בין מערכת מקור ל-CIM הוא בעצמו נכס. נהל לו גרסאות, סקור אותו והקצה לו בעלות. כלים במרחב שילוב הנתונים — פלטפורמות ETL ו-ELT, קטלוגי נתונים וכלי lineage — יכולים לעזור לך לעקוב אחר המקור של כל תכונה וכיצד היא זורמת, שזה בדיוק סוג המטא-נתונים שתחום הנושא Analyze צופה עם ישויות כמו Data Lineage.

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

פורמטים, דיאגרמות וצריכה

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

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

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

שאלות נפוצות

מהו מודל המידע בענן (CIM)?

מודל המידע בענן הוא מודל נתונים פתוח ואגנוסטי ליישומים, המגדיר מושגים עסקיים משותפים — כגון Party, Account ו-Sales Order — כך שמערכות ענן ומערכות on-premises שונות יכולות להחליף נתונים באמצעות אוצר מילים משותף. הוא מאורגן לפי תחומי נושא, קבוצות ישויות, ישויות ותכונות, ומנוהל כפרויקט קוד פתוח תחת The Linux Foundation.

מה ההבדל בין supertype ל-subtype ב-CIM?

Supertype הוא ישות המורחבת על ידי ישויות subtype ומגדירה את התכונות המשותפות למושגים דומים. Subtype מרחיב ישות אחרת ויורש את התכונות של ה-supertype שלה. לדוגמה, Party יכול לשמש כ-supertype כאשר Person ו-Organization הם ה-subtypes, כך שתכונות משותפות מוגדרות פעם אחת ותכונות ייחודיות נמצאות ב-subtype.

איך CIM קשור לסכימת מסד נתונים?

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

האם CIM מהווה תחליף לתקני נתונים ספציפיים לתעשייה?

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

מדוע לתחומי נושא ב-CIM יש מספרי גרסאות?

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

כיצד לטפל בתכונות ש-CIM אינו מגדיר?

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