एक व्यवसाय संचालित डेटा वास्तुकला का निर्माण

ले जाओ: होस्ट रेबेका जोजवियाक OSTHUS के एरिक लिटिल, फर्स्ट सैन फ्रांसिस्को पार्टनर्स के मैल्कम चिशोल्म और आईडीईआरए के रॉन हुइजेंगा के साथ डेटा आर्किटेक्चर समाधान पर चर्चा करते हैं।

आप वर्तमान में लॉग इन नहीं हैं। वीडियो देखने के लिए कृपया लॉग-इन या साइन-अप करें।

रेबेका जोजवाक: देवियों और सज्जनों, नमस्ते, और 2016 के हॉट टेक्नोलॉजीज में आपका स्वागत है। आज हम "एक व्यापार-प्रेरित डेटा वास्तुकला का निर्माण" पर चर्चा कर रहे हैं, निश्चित रूप से एक गर्म विषय। मेरा नाम रेबेका जोजवाक है, मैं आज के वेबकास्ट के लिए आपका मेजबान बनूंगा। हम # HotTech16 के हैशटैग के साथ ट्वीट करते हैं यदि आप पहले से ही हैं, तो कृपया उस पर भी शामिल होने के लिए स्वतंत्र महसूस करें। यदि आपके पास किसी भी समय प्रश्न हैं, तो कृपया उन्हें अपनी स्क्रीन के नीचे दाईं ओर Q & A फलक में भेजें और हम सुनिश्चित करेंगे कि उन्हें उत्तर मिल जाए। यदि नहीं, तो हम सुनिश्चित करेंगे कि हमारे मेहमान उन्हें आपके लिए प्राप्त करें।

इसलिए आज हमें वास्तव में आकर्षक लाइनअप मिल गया है। आज हमारे साथ बहुत सारे भारी झगड़े। हमारे पास OSTHUS के डेटा विज्ञान के एरिक लिटिल, वीपी हैं। हमारे पास मैल्कम चीशोलम है, जो मुख्य नवाचार अधिकारी है, जो कि फर्स्ट सैन फ्रांसिस्को पार्टनर्स के लिए एक बहुत अच्छा शीर्षक है। और हमारे पास IDERA के वरिष्ठ उत्पाद प्रबंधक रॉन हुइजेंगा हैं। और, आप जानते हैं, IDERA को वास्तव में डेटा प्रबंधन और मॉडलिंग समाधान का पूर्ण सूट मिला है। और आज वह हमें एक डेमो देने जा रहा है कि उसका समाधान कैसे काम करता है। लेकिन इससे पहले कि हम, एरिक लिटिल, मैं आपको गेंद को पास करने जा रहा हूं।

एरिक लिटिल: ठीक है, बहुत बहुत धन्यवाद। इसलिए मुझे लगता है कि मुझे लगता है कि रॉन की बात से थोड़ा संबंधित होने जा रहा हूं और उम्मीद है कि इनमें से कुछ विषयों के लिए मंच तय करूंगा, कुछ प्रश्नोत्तर।

इसलिए जो चीज मुझे IDERA के साथ रूचि रखती है, वह यह है कि मुझे लगता है कि वे इस बात को सही ढंग से इंगित करते हैं कि वास्तव में जटिल वातावरण आजकल बहुत सारे व्यावसायिक मूल्यों को चला रहे हैं। और जटिल वातावरण से हमारा मतलब जटिल डेटा वातावरण से है। और प्रौद्योगिकी वास्तव में तेजी से आगे बढ़ रही है और आज के कारोबारी माहौल में इसे बनाए रखना मुश्किल है। इसलिए वे लोग जो प्रौद्योगिकी के क्षेत्र में काम करते हैं, अक्सर देखेंगे कि आपके पास ऐसे ग्राहक हैं जो समस्याओं से बाहर काम कर रहे हैं, “मैं बड़े डेटा का उपयोग कैसे करूं? मैं शब्दार्थ को कैसे शामिल करूं? मैं अपने पुराने डेटा के साथ इस नए सामान को कुछ कैसे लिंक करूं? ”और इसी तरह, और आजकल हमें इस तरह के चार बड़े डेटा में ले जाता है जिससे बहुत से लोग परिचित हैं, और मैं समझता हूं कि चार से अधिक हो सकते हैं कभी-कभी मैंने आठ या नौ के रूप में देखा है - लेकिन आम तौर पर, जब लोग बड़े डेटा जैसी चीजों के बारे में बात करते हैं या यदि आप बड़े डेटा के बारे में बात कर रहे हैं, तो आप आमतौर पर कुछ ऐसा देख रहे हैं जो उद्यम के पैमाने की तरह है। और इसलिए लोग कहेंगे, ठीक है, ठीक है, अपने डेटा की मात्रा के बारे में सोचें, जो आम तौर पर ध्यान केंद्रित करता है - यह आपके पास कितना है। डेटा के वेग के साथ या तो यह करना है कि मैं इसे कितनी तेजी से इधर-उधर कर सकता हूं या कितनी तेजी से मैं इसे क्वेरी कर सकता हूं या उत्तर प्राप्त कर सकता हूं, और इसी तरह। और व्यक्तिगत रूप से मुझे लगता है कि बाईं ओर कुछ ऐसा है जिसे हल किया जा रहा है और कई अलग-अलग तरीकों से अपेक्षाकृत जल्दी से नियंत्रित किया जाता है। लेकिन दाईं ओर मैं सुधार के लिए बहुत सारी क्षमता और बहुत सारी नई तकनीकों को देखता हूं जो वास्तव में अग्रभूमि में आ रही हैं। और यह वास्तव में तीसरे कॉलम, डेटा विविधता के साथ करना है।

इसलिए दूसरे शब्दों में, आजकल अधिकांश कंपनियां संरचित, अर्ध-संरचित और असंरचित डेटा देख रही हैं। छवि डेटा एक गर्म विषय बनना शुरू हो रहा है, इसलिए कंप्यूटर दृष्टि का उपयोग करने में सक्षम होने के लिए, पिक्सेल देखें, परिमार्जन करने में सक्षम होने के लिए, एनएलपी, इकाई निष्कर्षण, आपके पास ग्राफ संबंधी जानकारी है जो या तो सांख्यिकीय मॉडल से निकल रही है या जो अर्थ मॉडल से बाहर आ रही है , आपके पास संबंधपरक डेटा है जो तालिकाओं में मौजूद है, और इसी तरह। और इसलिए उन सभी डेटा को एक साथ खींचना और ये सभी अलग-अलग प्रकार वास्तव में एक बड़ी चुनौती का प्रतिनिधित्व करते हैं और आप इसे देखेंगे, आप गार्टनर और अन्य लोगों में जानते हैं, जो उद्योग में रुझानों का पालन करने के लिए तैयार हैं।

और फिर अंतिम बात जो लोग बड़े डेटा के बारे में बात करते हैं, यह अक्सर अस्पष्टता की धारणा है, जो वास्तव में आपके डेटा की अनिश्चितता है, इसका फ़िज़नेस है। आपको कितना पता है कि आपके डेटा के बारे में क्या है, आप कितनी अच्छी तरह समझते हैं कि वहाँ क्या है और आप जानते हैं? आँकड़ों का उपयोग करने की क्षमता और कुछ प्रकार की जानकारी का उपयोग करने की क्षमता जो आप जानते हैं या कुछ चोर का उपयोग कर सकते हैं, वहाँ मूल्य हो सकता है। और इसलिए डेटा को इस तरह से देखने की क्षमता है कि आपके पास कितना है, आपको इसे कितनी तेजी से इधर-उधर करने की आवश्यकता है या इसे प्राप्त करने की आवश्यकता है, आपके उद्यम में आपके पास मौजूद सभी प्रकार के डेटा और आप कितने निश्चित हैं यह है, यह क्या है, यह किस गुणवत्ता में है, इत्यादि। इसके लिए वास्तव में एक बड़े, समन्वित प्रयास की आवश्यकता है ताकि बहुत से व्यक्तियों के बीच अपने डेटा को प्रभावी ढंग से प्रबंधित किया जा सके। इसलिए, आज की दुनिया में मॉडलिंग डेटा तेजी से महत्वपूर्ण है। इसलिए अच्छे डेटा मॉडल वास्तव में उद्यम अनुप्रयोगों में बहुत सफलता प्राप्त कर रहे हैं।

आपके पास विभिन्न स्रोतों से डेटा स्रोत हैं, जैसे हम कह रहे थे, जिसके लिए वास्तव में विभिन्न प्रकार के एकीकरण की बहुत आवश्यकता है। इसलिए यह सभी को एक साथ खींचना वास्तव में उपयोगी है, ताकि प्रश्नों को चलाने में सक्षम हो, उदाहरण के लिए, कई प्रकार के डेटा स्रोत, और जानकारी को वापस खींच सकें। लेकिन ऐसा करने के लिए आपको अच्छी मैपिंग रणनीतियों की आवश्यकता होती है और इसलिए उन प्रकार के डेटा को मैप करना और उन मैपिंग को बनाए रखना एक वास्तविक चुनौती हो सकती है। और फिर आपके पास यह मुद्दा है, मैं अपने विरासत डेटा को इन सभी नए डेटा स्रोतों से कैसे जोड़ूं? तो मान लीजिए कि मुझे ग्राफ़ मिल गया है, क्या मैं अपने सभी संबंधपरक डेटा ले सकता हूँ और इसे ग्राफ़ में डाल सकता हूँ? आमतौर पर यह एक अच्छा विचार नहीं है। तो यह कैसे है कि लोग इन सभी प्रकार के डेटा मॉडल का प्रबंधन करने में सक्षम हैं जो चल रहे हैं? विश्लेषण वास्तव में इन विभिन्न प्रकार के डेटा स्रोतों और संयोजनों पर चलाया जाना है। तो इससे जो उत्तर निकल रहे हैं, वे जवाब जो लोगों को वास्तव में अच्छे व्यावसायिक निर्णय लेने की आवश्यकता है, महत्वपूर्ण है।

तो यह केवल प्रौद्योगिकी के निर्माण के लिए प्रौद्योगिकी के बारे में नहीं है, यह वास्तव में है, मैं क्या करने जा रहा हूं, मैं इसके साथ क्या कर सकता हूं, मैं किस तरह का विश्लेषण चला सकता हूं, और क्षमता, इसलिए, जैसा कि मैंने पहले ही कर लिया है। के बारे में बात कर रहा है, इस सामान को एक साथ खींचने के लिए, यह वास्तव में महत्वपूर्ण है। और इन प्रकार के विश्लेषणों में से एक फ़ेडरेटेड खोज और क्वेरी जैसी चीज़ों पर चलता है। यह वास्तव में एक होना चाहिए। आपके प्रश्नों को सामान्य रूप से कई प्रकार के स्रोतों में पिरोया जाना चाहिए और जानकारी को विश्वसनीय रूप से वापस खींचना चाहिए।

एक प्रमुख तत्व जो अक्सर, विशेष रूप से लोग सिमेंटिक प्रौद्योगिकियों जैसे महत्वपूर्ण चीजों को देखने के लिए जा रहे हैं - और यह कुछ ऐसा है जो मुझे उम्मीद है कि रॉन थोड़ा IDERA दृष्टिकोण के बारे में बात करने जा रहा है - आप कैसे अलग या प्रबंधित करते हैं डेटा परत से अपने डेटा की मॉडल परत, उस कच्चे डेटा से? इसलिए डेटा स्तर पर आपके पास डेटाबेस हो सकता है, आपके पास दस्तावेज़ डेटा हो सकता है, आपके पास स्प्रेडशीट डेटा हो सकता है, आपके पास छवि डेटा हो सकता है। यदि आप फार्मास्युटिकल उद्योगों जैसे क्षेत्रों में हैं, तो आपको बड़ी मात्रा में वैज्ञानिक डेटा मिला है। और फिर इसके ऊपर लोग आम तौर पर एक मॉडल बनाने के लिए रास्ता तलाशते हैं जो उन्हें उस डेटा को जल्दी से एकीकृत करने की अनुमति देता है और वास्तव में जब आप डेटा की तलाश कर रहे हैं तो आप सभी डेटा को मॉडल परत में खींचने के लिए नहीं देख रहे हैं। , आप जो मॉडल परत देख रहे हैं, वह आपको यह बताने के लिए है कि चीजें क्या हैं, सामान्य शब्दसंग्रह, सामान्य प्रकार की संस्थाएं और रिश्ते, और वास्तव में जहां यह है, डेटा तक पहुंचने की क्षमता का एक अच्छा तार्किक प्रतिनिधित्व देता है। तो यह कहना है कि यह क्या है, और यह कहना है कि यह कहाँ है, और यह कहना है कि इसे कैसे लाया जाए और इसे वापस लाया जाए।

इसलिए यह एक ऐसा दृष्टिकोण रहा है जो अर्थ संबंधी तकनीकों को आगे बढ़ाने में काफी सफल रहा है, जो एक ऐसा क्षेत्र है जहां मैं बहुत काम करता हूं। तो एक सवाल जो मैं रॉन के लिए करना चाहता था, और मुझे लगता है कि यह प्रश्नोत्तर खंड में उपयोगी होगा, यह देखना है कि यह IDERA प्लेटफॉर्म द्वारा कैसे पूरा किया जाता है? तो क्या मॉडल लेयर वास्तव में डेटा लेयर से अलग है? क्या वे अधिक एकीकृत हैं? यह कैसे काम करता है और उनके दृष्टिकोण से देखने के कुछ परिणाम और लाभ क्या हैं? इसलिए संदर्भ डेटा वास्तव में भी महत्वपूर्ण होता जा रहा है। इसलिए यदि आप इस प्रकार के डेटा मॉडल लेने जा रहे हैं, यदि आप चीजों को पूरा करने और खोज करने में सक्षम होने जा रहे हैं, तो आपके पास वास्तव में अच्छा संदर्भ डेटा होना चाहिए। लेकिन समस्या संदर्भ डेटा को बनाए रखने के लिए वास्तव में कठिन हो सकती है। इस तरह के नामकरण मानकों में और अपने आप में एक कठिन चुनौती है। एक समूह कुछ X को कॉल करेगा और एक समूह कुछ Y को कॉल करेगा और अब आपको इस बात की समस्या है कि कोई व्यक्ति इस प्रकार की जानकारी की तलाश में X और Y को कैसे ढूँढता है? क्योंकि आप उन्हें केवल डेटा का एक हिस्सा नहीं देना चाहते हैं, आप उन्हें सब कुछ संबंधित देना चाहते हैं। एक ही समय में शब्द बदलते हैं, सॉफ्टवेयर अपदस्थ हो जाता है, और इसी तरह, आप समय के साथ उस संदर्भ डेटा को कैसे बनाए रखते हैं और बनाए रखते हैं?

और, फिर से, शब्दार्थ प्रौद्योगिकियां, विशेष रूप से टैक्सोनॉमी और वोकैबुलरी, डेटा शब्दकोशों जैसी चीजों का उपयोग करते हुए, ऐसा करने का एक मानक स्थान प्रदान किया है, जो वास्तव में अत्यधिक मजबूत है, यह कुछ प्रकार के मानकों का उपयोग करता है, लेकिन डेटाबेस समुदाय ने इसके लिए यह किया है लंबे समय के रूप में अच्छी तरह से, बस अलग अलग तरीकों से। मुझे लगता है कि यहां एक कुंजी यह सोचने के लिए है कि शायद इकाई-संबंध मॉडल का उपयोग कैसे करें, शायद ग्राफ़ मॉडल या किसी प्रकार के दृष्टिकोण का उपयोग कैसे करें जो वास्तव में आपको उम्मीद है कि आपके संदर्भ डेटा को संभालने का एक मानक स्थान है। और फिर निश्चित रूप से एक बार जब आपके पास संदर्भ डेटा होता है, तो मैपिंग रणनीतियों को विभिन्न प्रकार के नामों और संस्थाओं का प्रबंधन करना पड़ता है। इसलिए विषय वस्तु विशेषज्ञ अक्सर अपनी शर्तों का उपयोग करना पसंद करते हैं।

तो इसमें एक चुनौती हमेशा यह होती है कि आप किसी को कैसे जानकारी देते हैं लेकिन उसे उस तरीके से प्रासंगिक बनाते हैं जिसके बारे में वे बात करते हैं? इसलिए एक समूह में किसी चीज़ को देखने का एक तरीका हो सकता है, उदाहरण के लिए, आप एक दवा पर काम करने वाला एक रसायनज्ञ हो सकता है, और आप एक ही दवा पर काम करने वाले एक संरचनात्मक जीवविज्ञानी हो सकते हैं, और आपके पास एक ही प्रकार की संस्थाओं के लिए अलग-अलग नाम हो सकते हैं। जो आपके क्षेत्र से संबंधित है। आपको उन वैयक्तिकृत शब्दावली को एक साथ लाने के तरीकों का पता लगाना होगा, क्योंकि दूसरा तरीका यह है, आपको लोगों को अपना पद छोड़ने और किसी और का उपयोग करने के लिए मजबूर करना होगा, जो वे अक्सर पसंद नहीं करते हैं। यहां एक और बिंदु बड़ी संख्या में समानार्थी को संभालना मुश्किल हो जाता है, इसलिए कई लोगों के डेटा में बहुत सारे अलग-अलग शब्द हैं जो एक ही चीज़ को संदर्भित कर सकते हैं। संबंधों के कई-एक सेट का उपयोग करके आपको संदर्भ की समस्या है। विशिष्ट शर्तें उद्योग से उद्योग में भिन्न होती हैं, इसलिए यदि आप इस प्रकार के डेटा प्रबंधन के लिए किसी तरह के ओवररचिंग समाधान के साथ आने वाले हैं, तो यह एक परियोजना से कितनी आसानी से पोर्टेबल है, या एक से दूसरे अनुप्रयोग पर? वह एक और चुनौती हो सकती है।

स्वचालन महत्वपूर्ण है और यह एक चुनौती भी है। संदर्भ डेटा को मैन्युअल रूप से संभालना महंगा है। मैन्युअल रूप से मैपिंग रखना महंगा है और विषय-विशेषज्ञों के पास अपने दिन-प्रतिदिन के काम करना बंद कर देना महंगा है और इसमें लगातार डेटा डिक्शनरी तय करनी पड़ती है और परिभाषाएँ वगैरह-वगैरह ठीक करनी पड़ती हैं। रिप्लेसेबल वोकैब्युलरीज़ वास्तव में बहुत अधिक मूल्य दिखाते हैं। तो वे शब्दार्थवाद के शब्द हैं जो आप अपने संगठन के लिए बाहरी पा सकते हैं। यदि आप कच्चे तेल में काम कर रहे हैं, उदाहरण के लिए, कुछ प्रकार के शब्दकोष होंगे जो आप खुले स्रोत वाले स्थानों से ले सकते हैं, उसी तरह फार्मास्यूटिकल्स के साथ, बैंकिंग उद्योग और वित्तीय के साथ, इस प्रकार के कई क्षेत्रों के साथ। लोग उपयोग के लिए पुन: प्रयोज्य, सामान्य, नकल योग्य शब्दशः डाल रहे हैं।

और, फिर से, IDERA टूल को देखकर, मैं यह देखने के लिए उत्सुक हूं कि वे किस प्रकार के मानकों का उपयोग करने के मामले में इसे संभाल रहे हैं। शब्दार्थ की दुनिया में आप अक्सर SKOS मॉडल जैसी चीजें देखते हैं जो रिश्तों की तुलना में कम से कम / अधिक के लिए मानक प्रदान करती हैं और उन चीजों को ईआर मॉडल में करना मुश्किल हो सकता है लेकिन, आप जानते हैं, असंभव नहीं है, यह सिर्फ उस पर निर्भर करता है कि कितना मशीनरी और यह जोड़ने कि आप उन प्रकार के सिस्टम में संभाल सकते हैं।

इसलिए अंत में मैं बस कुछ अर्थ-संबंधी इंजनों की तुलना करना चाहता था, जिन्हें मैं उद्योग में देखता हूं, और रॉन से पूछना चाहता हूं और उनसे थोड़ी सी बात करने के लिए कि शायद किसी भी अर्थ-संबंधी तकनीकों के साथ IDERA की प्रणाली का उपयोग कैसे किया जाए।क्या यह ट्रिपल स्टोर, ग्राफ डेटाबेस के साथ एकीकृत होने में सक्षम है? बाहरी स्रोतों का उपयोग करना कितना आसान है क्योंकि शब्दार्थ दुनिया में उन प्रकार की चीजों को अक्सर SPARQL समापन बिंदुओं का उपयोग करके उधार लिया जा सकता है? आप सीधे अपने मॉडल में RDF या OWL मॉडल आयात कर सकते हैं - उन्हें वापस देखें - इसलिए, उदाहरण के लिए, जीन ऑन्कोलॉजी या प्रोटीन ऑन्कोलॉजी, जो अपने स्वयं के शासन संरचना के साथ अपने स्वयं के स्थान पर कहीं रह सकते हैं और मैं बस आयात कर सकता हूं या उस हिस्से के रूप में मुझे अपने स्वयं के मॉडल में इसकी आवश्यकता है। और मुझे यह जानने की उत्सुकता है कि IDERA इस मुद्दे पर कैसे पहुंचता है। क्या आपको आंतरिक रूप से सब कुछ बनाए रखना है, या क्या अन्य प्रकार के मानकीकृत मॉडल का उपयोग करने और उन्हें अंदर खींचने के तरीके हैं और यह कैसे काम करता है? और आखिरी बात जो मैंने यहां बताई है कि शब्दावलियों और मेटाडेटा रिपॉजिटरी के निर्माण के लिए वास्तव में कितना मैनुअल काम शामिल है?

इसलिए मुझे पता है कि रॉन हमें इस तरह की चीजों पर कुछ डेमो दिखाने जा रहा है जो वास्तव में दिलचस्प होगा। लेकिन जो समस्याएं मुझे अक्सर ग्राहकों के साथ परामर्श करते हुए दिखाई देती हैं, वह यह है कि यदि लोग अपनी परिभाषा या अपने स्वयं के मेटाडेटा में लिख रहे हैं, तो बहुत सारी त्रुटियां होती हैं। तो आप गलत वर्तनी प्राप्त करते हैं, आपको मोटी-मोटी त्रुटियां मिलती हैं, यह एक बात है। आपको ऐसे लोग भी मिलते हैं जो आपसे कुछ ले सकते हैं, आप जानते हैं, सिर्फ विकिपीडिया या एक स्रोत जो जरूरी नहीं है कि आप अपनी परिभाषा में जिस गुणवत्ता को चाहते हैं, या आपकी परिभाषा केवल एक व्यक्ति के दृष्टिकोण से है, इसलिए यह पूर्ण नहीं है, और यह तब स्पष्ट नहीं है शासन प्रक्रिया कैसे काम करती है। शासन, बेशक, एक बहुत, बहुत बड़ा मुद्दा होने के नाते किसी भी समय आप संदर्भ डेटा के बारे में बात कर रहे हैं और किसी भी समय आप इस बारे में बात कर रहे हैं कि यह किसी के मास्टर डेटा में कैसे फिट हो सकता है, वे अपने मेटाडेटा का उपयोग कैसे करने जा रहे हैं, और जल्द ही।

इसलिए मैं इनमें से कुछ विषयों को वहां रखना चाहता था। ये वे वस्तुएं हैं जो मैं व्यापारिक अंतरिक्ष में बहुत सारे विभिन्न प्रकार के परामर्श संलग्नक और बहुत सारे विभिन्न स्थानों में देखता हूं, और मुझे वास्तव में यह देखने में दिलचस्पी है कि रॉन हमें IDERA के साथ इन विषयों में से कुछ को इंगित करने के लिए क्या दिखाने जा रहा है। । इसलिए आपको बहुत बहुत धन्यवाद।

रेबेका जोजवाक: बहुत बहुत धन्यवाद, एरिक, और मैं वास्तव में आपकी टिप्पणी को पसंद करता हूं कि कई त्रुटियां हो सकती हैं अगर लोग अपनी खुद की परिभाषा या मेटाडेटा लिख ​​रहे हैं। मैं पत्रकारिता की दुनिया में एक मंत्र जानता हूं कि "कई आँखें कुछ गलतियाँ करती हैं," लेकिन जब यह व्यावहारिक अनुप्रयोगों के लिए नीचे आता है, तो कुकी जार में बहुत सारे हाथ आपको टूटी हुई कुकीज़ के साथ छोड़ने के लिए कहते हैं, है ना?

एरिक लिटिल: हाँ, और रोगाणु।

रेबेका जोजवाक: हाँ। इसके साथ ही मैं आगे जा रहा हूं और इसे मैल्कम चिशोल्म को पास करूंगा। मैल्कम, मंजिल आपकी है।

मैल्कम चिशोल्म: बहुत बहुत धन्यवाद, रेबेका। मुझे लगता है कि एरिक किस बारे में बात कर रहा है, उस पर थोड़ा ध्यान देना चाहता हूं, और इस तरह के कुछ अवलोकन, जो आप जानते हैं, रॉन को भी जवाब देने की परवाह हो सकती है, के बारे में बात करने में "व्यापार-प्रेरित डेटा आर्किटेक्चर की ओर" "- व्यवसाय संचालित होने का क्या मतलब है और यह महत्वपूर्ण क्यों है? या यह सिर्फ प्रचार का कुछ रूप है? मुझे नहीं लगता कि यह है

यदि हम देखते हैं कि कब से चल रहा है, तो आप जानते हैं, मेनफ्रेम कंप्यूटर वास्तव में कंपनियों के लिए उपलब्ध हो गए हैं - कहते हैं, 1964 के आसपास - आज तक, हम देख सकते हैं कि बहुत सारे बदलाव हुए हैं। और ये बदलाव मैं प्रक्रिया-केंद्रितता से डेटा-केंद्रितता में बदलाव के रूप में संक्षेपित करूंगा। और जो व्यवसाय-संचालित डेटा आर्किटेक्चर को आज के लिए इतना महत्वपूर्ण और इतना प्रासंगिक बनाता है। और मुझे लगता है, आप जानते हैं, यह केवल एक चर्चा नहीं है, यह कुछ ऐसा है जो बिल्कुल वास्तविक है।

लेकिन हम इसकी थोड़ी और सराहना कर सकते हैं यदि हम इतिहास में गोता लगाते हैं, तो समय में वापस जा रहे हैं, 1960 के दशक में वापस आते हैं और कुछ समय के लिए, मेनफ्रेम हावी रहे। इसके बाद उन पीसी को रास्ता दिया गया जहाँ आप वास्तव में पीसी आने पर उपयोगकर्ताओं के विद्रोह कर चुके थे। केंद्रीकृत आईटी के खिलाफ विद्रोह, जिन्होंने सोचा था कि वे अपनी आवश्यकताओं को पूरा नहीं कर रहे थे, वे पर्याप्त रूप से चुस्त नहीं थे। यह जल्दी से वितरित कंप्यूटिंग को जन्म देता है, जब पीसी एक साथ जुड़े होते थे। और फिर इंटरनेट का होना शुरू हुआ, जिसने उद्यम की सीमाओं को धुंधला कर दिया - यह अब डेटा विनिमय के मामले में खुद से बाहर के पक्षों के साथ बातचीत कर सकता है, जो पहले नहीं हो रहा था। और अब हम क्लाउड और बड़े डेटा के युग में चले गए हैं जहाँ क्लाउड प्लेटफ़ॉर्म है जो वास्तव में बुनियादी ढाँचे का विकास कर रहे हैं और इसलिए हम जा रहे हैं, जैसा कि यह था, बड़े डेटा केंद्रों को चलाने की आवश्यकता के कारण, क्योंकि आप जानते हैं, हम हमें क्लाउड की क्षमता उपलब्ध हो गई है, और उस बड़े डेटा के साथ सहवर्ती, जो एरिक के पास है, आप जानते हैं, इसलिए बहुत चर्चा की गई। और कुल मिलाकर, जैसा कि हम देखते हैं, जैसा कि प्रौद्योगिकी में बदलाव हुआ है, यह अधिक डेटा-केंद्रित हो गया है, हम डेटा के बारे में अधिक ध्यान रखते हैं। जैसे इंटरनेट के साथ, डेटा का आदान-प्रदान कैसे किया जा रहा है। बड़े डेटा के साथ, डेटा का चार या अधिक v।

उसी समय, और शायद अधिक महत्वपूर्ण बात, व्यावसायिक उपयोग के मामलों को स्थानांतरित कर दिया गया। जब कंप्यूटर पहली बार पेश किए गए थे, तो उनका उपयोग पुस्तकों और रिकॉर्ड जैसी चीजों को स्वचालित करने के लिए किया गया था। और कुछ भी जो एक मैनुअल प्रक्रिया थी, जिसमें लीडर या उस तरह की चीजें शामिल थीं, जिन्हें अनिवार्य रूप से घर में प्रोग्राम किया गया था। यह 80 के दशक में परिचालन पैकेज की उपलब्धता में बदल गया। अब आपको अपना स्वयं का पेरोल लिखने की आवश्यकता नहीं है, आप ऐसा कुछ खरीद सकते हैं जो उसने किया। इसके परिणामस्वरूप कई आईटी विभागों में उस समय बड़ी गिरावट हुई, या पुनर्गठन हुआ। लेकिन तब व्यापार खुफिया, डेटा वेयरहाउस जैसी चीजों के साथ दिखाई दिया, ज्यादातर 90 के दशक में। डॉटकॉम व्यापार मॉडल द्वारा पीछा किया गया, जो निश्चित रूप से एक बड़ा उन्माद था। फिर एमडीएम। एमडीएम के साथ आप यह देखना शुरू करते हैं कि हम स्वचालन के बारे में नहीं सोच रहे हैं; हम वास्तव में डेटा के रूप में डेटा को क्यूरेट करने पर ध्यान केंद्रित कर रहे हैं। और फिर एनालिटिक्स, मूल्य का प्रतिनिधित्व करते हुए आप डेटा से बाहर निकल सकते हैं। और एनालिटिक्स के भीतर आप उन कंपनियों को देखते हैं जो बहुत सफल हैं जिनका मुख्य व्यवसाय मॉडल डेटा के आसपास घूमता है। Google, इसका हिस्सा होगा, लेकिन आप यह भी तर्क दे सकते हैं कि वॉलमार्ट है।

और इसलिए व्यापार अब वास्तव में डेटा के बारे में सोच रहा है। हम डेटा से मूल्य कैसे प्राप्त कर सकते हैं? डेटा व्यवसाय, रणनीति को कैसे चला सकता है, और हम डेटा के स्वर्ण युग में हैं। तो यह देखते हुए कि, हमारे डेटा आर्किटेक्चर के संदर्भ में क्या हो रहा है, यदि डेटा को अब केवल उस निकास के रूप में नहीं माना जाता है जो अनुप्रयोगों के पीछे के छोर से निकलता है, लेकिन क्या वास्तव में हमारे व्यापार मॉडल के लिए केंद्रीय है? खैर, इस समस्या का एक हिस्सा जो हमें हासिल करना है वह यह है कि सिस्टम विकास जीवन चक्र के साथ वास्तव में अतीत में फंस गया है, जो आईटी की कम उम्र में उस प्रक्रिया स्वचालन चरण के साथ तेजी से निपटने का परिणाम था, और इसमें काम करना प्रोजेक्ट एक समान चीज है। आईटी के लिए - और यह एक कैरिकेचर से थोड़ा सा है - लेकिन मैं जो कहना चाह रहा हूं वह यह है कि व्यवसाय-संचालित डेटा आर्किटेक्चर प्राप्त करने में कुछ बाधाएं हैं क्योंकि हम, आईटी में एक तरह से अनजाने में एक संस्कृति को स्वीकार कर चुके हैं। जो एक बीते युग से उत्पन्न होता है।

तो सब कुछ एक परियोजना है मुझे अपनी आवश्यकताओं के बारे में विस्तार से बताएं। यदि चीजें काम नहीं करती हैं, तो यह इसलिए है क्योंकि आपने मुझे अपनी आवश्यकताएं नहीं बताई हैं। वैसे यह आज डेटा के साथ काम नहीं करता है क्योंकि हम अन-ऑटोमेटेड मैनुअल प्रक्रियाओं या ए से शुरू नहीं कर रहे हैं, आप जानते हैं, व्यावसायिक प्रक्रियाओं का एक तकनीकी रूपांतरण, हम पहले से मौजूद उत्पादन डेटा के साथ बहुत बार शुरू कर रहे हैं जिसे हम कोशिश कर रहे हैं मूल्य प्राप्त करना लेकिन डेटा-केंद्रित परियोजना को प्रायोजित करने वाला कोई भी व्यक्ति वास्तव में उस डेटा को गहराई से नहीं समझता है। हमें डेटा की खोज करनी है, हमें स्रोत डेटा विश्लेषण करना है। और यह वास्तव में सिस्टम के विकास के साथ मेल नहीं खाता है, आप जानते हैं - झरना, एसडीएलसी जीवनचक्र - जिसमें से एजाइल, मैं बनाए रखूंगा, उस का एक बेहतर संस्करण है।

और जिस पर ध्यान केंद्रित किया जा रहा है वह तकनीक और कार्यक्षमता है, डेटा नहीं। उदाहरण के लिए, जब हम परीक्षण चरण में परीक्षण करते हैं, तो यह आमतौर पर होता है, क्या मेरी कार्यक्षमता कार्य करती है, मेरे ETL को बताएं, लेकिन हम डेटा का परीक्षण नहीं कर रहे हैं। हम आने वाले स्रोत डेटा के बारे में अपनी धारणाओं का परीक्षण नहीं कर रहे हैं। यदि हमने किया, तो हम शायद बेहतर आकार में होंगे और किसी ऐसे व्यक्ति के रूप में जिसने डेटा वेयरहाउस प्रोजेक्ट्स किए हैं और अपने ईटीएल का भंडाफोड़ करते हुए अपस्ट्रीम बदलावों का सामना करना पड़ा है, मैं इसकी सराहना करूंगा। और वास्तव में, जो हम देखना चाहते हैं वह निरंतर उत्पादन डेटा गुणवत्ता निगरानी के लिए प्रारंभिक कदम के रूप में परीक्षण कर रहा है। इसलिए हमें यहां बहुत सारे दृष्टिकोण मिल गए हैं जहां व्यवसाय संचालित डेटा वास्तुकला को प्राप्त करना मुश्किल है क्योंकि हम प्रक्रिया-केंद्रितता के युग से वातानुकूलित हैं। हमें डेटा-केंद्रितता के लिए एक परिवर्तन करने की आवश्यकता है। और यह कुल संक्रमण नहीं है, आप जानते हैं, वहाँ अभी भी बहुत सारी प्रक्रियाएँ करने की ज़रूरत है, लेकिन हम वास्तव में डेटा-केंद्रित शब्दों में नहीं सोच रहे हैं जब हमें ज़रूरत होती है, और परिस्थितियाँ जो तब होती हैं जब हम वास्तव में होते हैं। ऐसा करने के लिए बाध्य है।

अब व्यवसाय डेटा के मूल्य का एहसास करता है, वे डेटा को अनलॉक करना चाहते हैं, तो हम ऐसा कैसे करने जा रहे हैं? तो हम संक्रमण कैसे करते हैं? खैर, हम विकास प्रक्रियाओं के दिल में डेटा डालते हैं। और हम व्यापार को सूचना आवश्यकताओं के साथ आगे बढ़ने देते हैं। और हम समझते हैं कि परियोजना की शुरुआत में मौजूदा स्रोत डेटा को कोई नहीं समझता है। आप तर्क दे सकते हैं कि डेटा संरचना और डेटा क्रमशः आईटी और संचालन के माध्यम से वहां पहुंचे, इसलिए हमें यह जानना चाहिए, लेकिन वास्तव में, हम नहीं करते हैं। यह डेटा-केंद्रित विकास है। इसलिए हमें इस बात पर विचार करना है कि डेटा केंद्रित दुनिया में हम कहां और कैसे डेटा मॉडलिंग करते हैं, हमें उपयोगकर्ताओं को उनकी सूचना आवश्यकताओं को परिष्कृत करने के लिए फीडबैक लूप्स देना होगा, क्योंकि हम डेटा की खोज और डेटा प्रोफाइलिंग करते हैं , foresee स्रोत डेटा विश्लेषण, और जैसा कि हम धीरे-धीरे हमारे डेटा के बारे में अधिक से अधिक निश्चितता प्राप्त करते हैं। और अब मैं एमडीएम हब या डेटा वेयरहाउस जैसी अधिक पारंपरिक परियोजना की बात कर रहा हूं, जरूरी नहीं कि बड़ी डेटा परियोजनाएं, हालांकि यह अभी भी है, मैं इसे बनाए रखता हूं, जो काफी करीब है। और इसलिए उन फीडबैक लूप्स में डेटा मॉडलर्स शामिल हैं, जो आप जानते हैं, धीरे-धीरे अपने डेटा मॉडल को आगे बढ़ाते हैं और उपयोगकर्ताओं के साथ बातचीत करके यह सुनिश्चित करते हैं कि जो जानकारी संभव है, उसके आधार पर परिष्कृत किया जा सकता है, जो उपलब्ध है, स्रोत डेटा से, क्योंकि वे इसे बेहतर ढंग से समझते हैं, इसलिए यह डेटा मॉडल के होने का कोई मामला नहीं है, आप जानते हैं, एक ऐसी स्थिति में जो या तो पूरी तरह से नहीं है या पूरी तरह से किया गया है, यह धीरे-धीरे इसे ध्यान में ला रहा है।

इसी तरह, इससे भी अधिक महत्वपूर्ण बात यह है कि हमारे पास गुणवत्ता आश्वासन है जहां हम यह सुनिश्चित करने के लिए डेटा गुणवत्ता परीक्षण के लिए नियम विकसित करते हैं कि डेटा उन मापदंडों के भीतर है जिनके बारे में हम धारणा बना रहे हैं। अंदर जाकर, एरिक संदर्भ डेटा में परिवर्तन का उल्लेख कर रहा था, जो हो सकता है। आप ऐसा नहीं करना चाहते हैं, क्योंकि यह उस क्षेत्र में एक तरह का बहाव, अप्रबंधित परिवर्तन का शिकार था, इसलिए गुणवत्ता आश्वासन नियम पोस्ट-प्रोडक्शन, निरंतर डेटा गुणवत्ता निगरानी में जा सकते हैं। इसलिए आप यह देखना शुरू कर सकते हैं कि क्या हम डेटा-केंद्रित होने जा रहे हैं, हम डेटा-केंद्रित विकास कैसे करते हैं, यह कार्यक्षमता-आधारित SDLC और Agile से काफी भिन्न है। और फिर हमें व्यावसायिक विचारों पर भी ध्यान देना होगा। हमारे पास है - और फिर से यह बताता है कि एरिक क्या कह रहा था - हमारे पास हमारे डेटाबेस के लिए एक डेटा स्टोरी ब्लू को परिभाषित करने वाला एक डेटा मॉडल है, लेकिन साथ ही हमें उन वैचारिक मॉडल, डेटा के उन व्यापारिक विचारों की आवश्यकता है जो परंपरागत रूप से नहीं किए गए हैं भूतकाल। हमने कभी-कभी, मुझे लगता है, सोचा था कि डेटा मॉडल यह सब कर सकता है, लेकिन हमें वैचारिक दृष्टिकोण, शब्दार्थ, और डेटा को देखने की जरूरत है, इसे एक अमूर्त परत के माध्यम से प्रस्तुत करें जो व्यवसाय में भंडारण मॉडल का अनुवाद करता है। राय। और, फिर से, एरिक के बारे में सभी बातें जो शब्दार्थ के संदर्भ में बात कर रही थीं, ऐसा करना महत्वपूर्ण हो जाता है, इसलिए हमारे पास वास्तव में अधिक मॉडलिंग कार्य हैं। मुझे लगता है कि, यदि आप एक डेटा मॉडलर के रूप में रैंक में आते हैं, और फिर से कुछ नया है, तो आप जानते हैं, दिलचस्प है।

और अंत में मैं यह कहना चाहता हूं कि इस नई वास्तविकता को प्रतिबिंबित करने के लिए बड़े आर्किटेक्चर को भी मिला है। उदाहरण के लिए, पारंपरिक ग्राहक एमडीएम एक प्रकार का है, ठीक है, चलो हमारे ग्राहक डेटा को एक हब में प्राप्त करें जहां हम कर सकते हैं, आपको पता है कि बैक ऑफिस एप्लिकेशन के लिए वास्तव में सिर्फ डेटा गुणवत्ता के संदर्भ में इसका मतलब है। जो एक व्यापार रणनीति के दृष्टिकोण से एक जम्हाई की तरह है। आज, हालांकि, हम ग्राहक MDM हब को देख रहे हैं, जिसमें उनके पास अतिरिक्त ग्राहक प्रोफ़ाइल डेटा है, न कि केवल स्थैतिक डेटा, जो तब वास्तव में ग्राहक के लेनदेन अनुप्रयोगों के साथ एक द्विदिश इंटरफ़ेस है। हां, वे अभी भी बैक ऑफिस का समर्थन करते हैं, लेकिन अब हम अपने ग्राहकों के इन व्यवहारों के बारे में भी जानते हैं। यह निर्माण करने के लिए अधिक महंगा है। यह निर्माण करने के लिए अधिक जटिल है। लेकिन यह एक तरह से व्यापार-संचालित है जिसमें पारंपरिक ग्राहक MDM नहीं है। आप सरल डिजाइनों के खिलाफ व्यवसाय के लिए एक अभिविन्यास बंद कर रहे हैं जो लागू करना आसान है, लेकिन व्यवसाय के लिए, यह वही है जो वे देखना चाहते हैं। हम वास्तव में एक नए युग में हैं और मुझे लगता है कि कई स्तर हैं जो हमें व्यवसाय-ड्राइविंग डेटा वास्तुकला का जवाब देना है और मुझे लगता है कि यह काम करने के लिए एक बहुत ही रोमांचक समय है।

तो धन्यवाद, आप के लिए वापस रेबेका।

रेबेका जोजवाक: धन्यवाद मैल्कम, और मुझे वास्तव में मज़ा आया कि आपने डेटा मॉडल के बारे में क्या कहा था, व्यापार दृश्य को खिलाना चाहिए, क्योंकि आप जो कह रहे थे, उसके विपरीत, आईटी ने इतनी देर तक बागडोर संभाले रखी है और यह उस तरह का मामला नहीं है और संस्कृति को शिफ्ट करने की जरूरत है। और मुझे पूरा यकीन है कि बैकग्राउंड में एक कुत्ता था जो आपसे 100% सहमत था। और इसके साथ ही मैं रॉन को गेंद पास करने जा रहा हूं। मैं आपका डेमो देखने के लिए वास्तव में उत्साहित हूं। रॉन, मंजिल तुम्हारी है।

रॉन हुइज़ेंगा: बहुत बहुत धन्यवाद और इससे पहले कि हम उसमें कूदें, मैं कुछ स्लाइड्स से गुजरूंगा और फिर थोड़ा सा डेमो करूंगा क्योंकि जैसा कि एरिक और मैल्कम ने बताया है, यह एक बहुत ही व्यापक और गहन विषय है, और हम क्या करते हैं आज के बारे में बात कर रहे हैं कि हम सिर्फ इसकी सतह को खुरच रहे हैं क्योंकि बहुत सारे पहलू और बहुत सारी चीजें हैं जिन्हें हमें वास्तव में एक व्यवसाय-संचालित वास्तुकला से देखने और देखने की जरूरत है। और हमारा दृष्टिकोण वास्तव में उस मॉडल-आधारित और मॉडल से बाहर वास्तविक मूल्य प्राप्त करना है क्योंकि आप उन्हें संचार वाहन के साथ-साथ अन्य प्रणालियों को सक्षम करने के लिए एक परत के रूप में उपयोग कर सकते हैं। चाहे आप सर्विस-ओरिएंटेड आर्किटेक्चर, या अन्य चीजें कर रहे हों, मॉडल वास्तव में क्या चल रहा है, इसके चारों ओर मेटाडेटा और आपके व्यवसाय में आपके पास मौजूद डेटा के साथ जीवनदान बन जाता है।

हालाँकि, मैं जिस बारे में बात करना चाहता हूँ, वह लगभग इसे एक कदम पीछे ले जा रहा है, क्योंकि मैल्कम ने इस तरह के कुछ इतिहास को छुआ है कि समाधान विकसित हुए हैं और उस प्रकार की चीज। वास्तव में यह बताने का एक तरीका है कि ध्वनि डेटा आर्किटेक्चर का होना कितना महत्वपूर्ण है, एक ऐसा उपयोग मामला है जिसे मैं बहुत बार चलाता था जब मैं एक उत्पाद प्रबंधन भूमिका में आने से पहले परामर्श कर रहा था, और यह कि, मैं संगठनों में जाऊंगा चाहे वे व्यवसाय परिवर्तन कर रहे थे या केवल कुछ मौजूदा प्रणालियों और उस प्रकार की जगह ले रहे थे, और यह बहुत जल्दी से स्पष्ट हो गया कि खराब संगठन अपने स्वयं के डेटा को कैसे समझते हैं। यदि आप इस तरह के एक विशेष उपयोग के मामले को लेते हैं, चाहे आप एक सलाहकार के रूप में जा रहे हों या हो सकता है कि यह एक ऐसा व्यक्ति है जो अभी-अभी एक संगठन के साथ शुरू हुआ है, या आपका संगठन विभिन्न कंपनियों के अधिग्रहण के साथ वर्षों में बनाया गया है, तो आप क्या समाप्त करते हैं एक बहुत ही जटिल वातावरण बहुत जल्दी है, कई अलग-अलग नई तकनीकों के साथ-साथ विरासत प्रौद्योगिकी, ईआरपी समाधान और बाकी सब कुछ।

तो एक चीज जो हम अपने मॉडलिंग दृष्टिकोण के साथ वास्तव में कर सकते हैं, वह है इस प्रश्न का उत्तर देना कि मैं इस सब का कैसे अर्थ लगाऊं? हम वास्तव में जानकारी को एक साथ रखना शुरू कर सकते हैं, इसलिए व्यवसाय उन सूचनाओं का लाभ उठा सकता है जो हमारे पास ठीक से हैं। और यह बाहर आता है, ऐसा क्या है जो हम उन वातावरणों में हैं? मैं उस जानकारी को बाहर निकालने के लिए मॉडल का उपयोग कैसे कर सकता हूं जिसकी मुझे आवश्यकता है और उस जानकारी को बेहतर ढंग से समझ सकता हूं? और फिर हमारे पास अलग-अलग चीजों के लिए पारंपरिक प्रकार के मेटाडेटा हैं जैसे रिलेशनल डेटा मॉडल, और हम परिभाषाओं और डेटा शब्दकोशों जैसी चीजों को देखने के लिए उपयोग किए जाते हैं, आप जानते हैं, डेटा प्रकार और उस प्रकार की चीज़। लेकिन अतिरिक्त मेटाडेटा के बारे में क्या है जिसे आप वास्तव में और भी अधिक अर्थ देने के लिए कैप्चर करना चाहते हैं? जैसे कि, कौन सी इकाइयाँ वास्तव में उम्मीदवार हैं जिन्हें संदर्भ डेटा ऑब्जेक्ट होना चाहिए, जो मास्टर डेटा प्रबंधन ऑब्जेक्ट और उन प्रकार की चीजें होनी चाहिए और उन्हें एक साथ टाई होना चाहिए। और संगठन के माध्यम से जानकारी कैसे बहती है? डेटा का उपयोग कैसे किया जाता है, यह दोनों प्रक्रिया के दृष्टिकोण से उपभोग करते हैं, लेकिन यह भी हमारे व्यवसायों के माध्यम से सूचना की यात्रा के संदर्भ में डेटा वंश है और यह विभिन्न प्रणालियों के माध्यम से या डेटा स्टोर के माध्यम से अपना रास्ता कैसे बनाता है, इसलिए हम जानते हैं जब हम आई-सॉल्यूशन, या उन प्रकार की चीजों का निर्माण कर रहे हैं, तो हम वास्तव में कार्य के लिए सही जानकारी का उपभोग कर रहे हैं।

और फिर बहुत महत्वपूर्ण बात यह है कि हम उन सभी हितधारकों को सहयोग करने के लिए कैसे प्राप्त कर सकते हैं, और विशेष रूप से व्यापार हितधारकों क्योंकि वे वे हैं जो हमें उस डेटा का सही अर्थ देते हैं। व्यापार, दिन के अंत में, डेटा का मालिक है। वे वोकैबुलरी और एरिक की जिन चीजों के बारे में बात कर रहे थे, उनके लिए परिभाषाओं की आपूर्ति करते हैं, इसलिए हमें उन सभी को एक साथ जोड़ने के लिए जगह चाहिए। और जिस तरह से हम अपने डेटा मॉडलिंग और डेटा रिपॉजिटरी आर्किटेक्चर के माध्यम से करते हैं।

मैं कुछ चीजों को छूने जा रहा हूं। मैं ईआर / स्टूडियो एंटरप्राइज टीम संस्करण के बारे में बात करने जा रहा हूं। मुख्य रूप से मैं डेटा आर्किटेक्चर उत्पाद के बारे में बात करने जा रहा हूं, जहां हम डेटा मॉडलिंग और उस प्रकार का काम करते हैं, लेकिन सूट के कई अन्य घटक हैं जो मैं अभी बहुत संक्षेप में छूने जा रहा हूं। आपको व्यवसाय वास्तुकार का एक स्निपेट दिखाई देगा, जहाँ हम वैचारिक मॉडल कर सकते हैं, लेकिन हम व्यावसायिक प्रक्रिया मॉडल भी कर सकते हैं और हम उन प्रक्रिया मॉडल को वास्तविक डेटा से जोड़ने के लिए बाँध सकते हैं जो हमारे डेटा मॉडल में हैं। यह वास्तव में हमें उस टाई को एक साथ लाने में मदद करता है। सॉफ्टवेयर आर्किटेक्ट हमें अतिरिक्त निर्माण करने की अनुमति देता है जैसे कि कुछ यूएमएल मॉडलिंग और उन प्रकार की चीजों को उन कुछ अन्य प्रणालियों और प्रक्रियाओं के लिए सहायक लॉजिक्स देना जो हम बात कर रहे हैं। लेकिन बहुत महत्वपूर्ण बात यह है कि हमारे पास रिपॉजिटरी और टीम सर्वर है, और मैं एक ही चीज़ के दो हिस्सों के बारे में बात करूँगा। रिपॉजिटरी वह जगह है जहां हम सभी मॉडल मेटाडेटा के साथ-साथ सभी व्यावसायिक मेटाडेटा को व्यापार शब्दावली और शर्तों के रूप में संग्रहीत करते हैं। और क्योंकि हमारे पास यह रिपॉजिटरी-आधारित वातावरण है, इसलिए हम इन सभी अलग-अलग चीजों को एक ही वातावरण में एक साथ सिलाई कर सकते हैं और फिर हम वास्तव में उपभोग के लिए उपलब्ध करा सकते हैं, न केवल तकनीकी लोगों के लिए बल्कि व्यवसायियों के लिए भी। और यह कि हम वास्तव में सहयोग करना कैसे शुरू करते हैं।

और फिर आखिरी टुकड़ा जिसके बारे में मैं संक्षेप में बात करता हूं, जब आप इन वातावरणों में चलते हैं, तो यह केवल डेटाबेस नहीं है जो आप वहां से बाहर आए हैं। आपके पास बहुत सारे डेटाबेस, डेटा स्टोर होने वाले हैं, आपके पास बहुत सारी चीजें हैं, जिन्हें मैं कॉल करूँगा, विरासत कलाकृतियाँ। हो सकता है कि लोगों ने कुछ चीजों को मैप करने के लिए Visio या अन्य आरेखों का उपयोग किया हो। हो सकता है कि उनके पास अन्य मॉडलिंग टूल और उस प्रकार की चीज़ हो।तो हम मेटावेयर के साथ जो कर सकते हैं, वह वास्तव में कुछ जानकारी निकालकर हमारे मॉडलों में लाते हैं, इसे वर्तमान बनाते हैं और इसका उपयोग करने में सक्षम होते हैं, इसका उपभोग करते हैं, एक वर्तमान फैशन में, बजाय इसे बाहर बैठने के। यह अब हमारे कामकाजी मॉडल का एक सक्रिय हिस्सा बन गया है, जो बहुत महत्वपूर्ण है।

जब आप किसी संगठन में चलते हैं, जैसे मैंने कहा, बहुत सारे असमान सिस्टम बाहर हैं, बहुत सारे ईआरपी समाधान, बेमेल विभागीय समाधान। कई संगठन सास समाधानों का भी उपयोग कर रहे हैं, जो बाहरी रूप से नियंत्रित और प्रबंधित भी हैं, इसलिए हम उन पर डेटाबेस और उन प्रकार की चीज़ों को मेजबान में नियंत्रित नहीं करते हैं, लेकिन हमें अभी भी यह जानना होगा कि डेटा कैसा दिखता है और, ज़ाहिर है, उसके आसपास मेटाडेटा। हम यह भी पाते हैं कि अप्रचलित विरासत प्रणालियों की एक बहुत बड़ी संख्या है, जो कि उस प्रोजेक्ट-आधारित दृष्टिकोण के कारण साफ नहीं हुई है, जिसके बारे में मैल्कम ने बात की थी। यह आश्चर्यजनक है कि हाल के वर्षों में संगठन परियोजनाओं को कैसे लागू करेंगे, वे एक प्रणाली या एक समाधान को बदल देंगे, लेकिन अक्सर अप्रचलित समाधानों को हटाने के लिए पर्याप्त परियोजना बजट नहीं बचा है, इसलिए अब वे बस रास्ते में हैं। और हमें यह पता लगाना होगा कि हम वास्तव में अपने पर्यावरण से छुटकारा पा सकते हैं और साथ ही आगे क्या उपयोगी है। और यह गरीब decommissioning रणनीति में शामिल है। यह उसी चीज़ का हिस्सा और पार्सल है।

हम यह भी पाते हैं, क्योंकि इन सभी अलग-अलग समाधानों से बहुत सारे संगठन बनाए गए हैं, क्या हमें बहुत सारे बिंदुओं के साथ बहुत सारे बिंदुओं के साथ बिंदु-दर-बिंदु इंटरफेस दिखाई दे रहा है। हमें उस डेटा वंश को युक्तिसंगत बनाने और उसका पता लगाने में सक्षम होने की आवश्यकता है जो मैंने पहले संक्षेप में उल्लेख किया है ताकि हमारे पास एक अधिक सामंजस्यपूर्ण रणनीति हो जैसे कि सेवा उन्मुख वास्तुकला, उद्यम सेवा बसों और उन प्रकार की चीजों का उपयोग, सही जानकारी देने के लिए। एक प्रकाशन-और-सदस्यता प्रकार का मॉडल जिसे हम अपने पूरे व्यवसाय में सही ढंग से उपयोग करते हैं। और फिर, निश्चित रूप से, हमें अभी भी कुछ प्रकार के एनालिटिक्स करने की आवश्यकता है, चाहे हम डेटा वेयरहाउस का उपयोग कर रहे हों, पारंपरिक ईटीएल के साथ डेटा कार्ट या कुछ नए डेटा झीलों का उपयोग कर रहे हों। यह सब एक ही चीज़ के लिए नीचे आता है। यह सभी डेटा, चाहे वह बड़ा डेटा हो, चाहे वह रिलेशनल डेटाबेस में पारंपरिक डेटा हो, हमें उस सभी डेटा को एक साथ लाने की आवश्यकता है ताकि हम इसे प्रबंधित कर सकें और जान सकें कि हम अपने पूरे मॉडल के साथ क्या व्यवहार कर रहे हैं।

फिर, हम जो जटिलता करने जा रहे हैं, वह है हमारे पास कई चरण हैं जिन्हें हम करने में सक्षम होना चाहते हैं। सबसे पहले, आप अंदर चलते हैं और आपके पास उन ब्लूज़ नहीं हो सकते हैं जो जानकारी परिदृश्य की तरह दिखते हैं। ईआर / स्टूडियो डेटा आर्किटेक्ट जैसे डेटा मॉडलिंग टूल में, आप सबसे पहले रिवर्स इंजीनियरिंग का एक बहुत कुछ करने जा रहे हैं, चलो डेटा स्रोतों पर इंगित करते हैं जो वहां हैं, उन्हें अंदर लाएं और फिर वास्तव में उन्हें और अधिक प्रतिनिधि में एक साथ सिलाई करें। मॉडल जो पूरे व्यवसाय का प्रतिनिधित्व करते हैं। महत्वपूर्ण बात यह है कि, क्या हम उन मॉडलों के साथ-साथ व्यावसायिक लाइनों को भी विघटित करने में सक्षम होना चाहते हैं ताकि हम उनसे छोटे-छोटे विखंडों में संबंधित हो सकें, जो हमारे व्यवसाय के लोग भी संबंधित हो सकते हैं, और हमारे व्यापार विश्लेषक और अन्य हितधारक जो काम कर रहे हैं इस पर।

नामकरण मानक अत्यंत महत्वपूर्ण हैं और मैं इसके बारे में यहां कुछ अलग-अलग तरीकों से बात कर रहा हूं। हम अपने मॉडल में चीजों को कैसे नाम देते हैं, इसके नामकरण के मानक। तार्किक मॉडल में करना काफी आसान है, जहां हमारे पास एक अच्छा नामकरण सम्मेलन और हमारे मॉडल के लिए एक अच्छा डेटा शब्दकोश है, लेकिन फिर भी, हम इन भौतिक मॉडलों के बहुत सारे नामकरण सम्मेलनों को देखते हैं जो हम ला रहे हैं। रिवर्स इंजीनियर, अक्सर हम संक्षिप्त नाम और उस प्रकार की चीज़ देखते हैं जिसके बारे में मैं बात करूँगा। और हमें उन सार्थक अंग्रेजी नामों का अनुवाद करने की आवश्यकता है जो व्यवसाय के लिए सार्थक हैं ताकि हम समझ सकें कि ये सभी डेटा टुकड़े पर्यावरण में हमारे पास क्या हैं। और फिर यूनिवर्सल मैपिंग है कि हम उन्हें एक साथ कैसे जोड़ते हैं।

उसके बाद हम फिर से दस्तावेज़ और परिभाषित करेंगे और जहाँ हम अपने डेटा को अनुलग्नक नामक चीज़ के साथ आगे वर्गीकृत कर सकते हैं, कि मैं आपको कुछ स्लाइड दिखाऊंगा। और फिर लूप को बंद करते हुए, हम उस व्यावसायिक अर्थ को लागू करना चाहते हैं, जिसे हम अपनी व्यावसायिक शब्दावली में बाँधते हैं और उन्हें हमारी विभिन्न मॉडल कलाकृतियों से जोड़ सकते हैं, इसलिए हम जानते हैं, जब हम एक निश्चित व्यावसायिक शब्द के बारे में बात कर रहे हैं, जहाँ वह है पूरे संगठन में हमारे डेटा में लागू किया गया। और फिर अंत में, मैंने पहले से ही इस तथ्य के बारे में बात की थी कि हमें बहुत सारे सहयोग और प्रकाशन क्षमताओं के साथ रिपॉजिटरी होने की आवश्यकता है, इसलिए हमारे हितधारक इसका उपयोग कर सकते हैं। मैं रिवर्स इंजीनियरिंग के बारे में बहुत जल्दी बात करने जा रहा हूं। मैं आपको पहले ही इस तरह का एक बहुत ही मुख्य आकर्षण बता चुका हूँ। मैं आपको एक वास्तविक डेमो में दिखाऊंगा, जिसमें हम आपको कुछ चीजें दिखा सकते हैं जो हम वहां ला सकते हैं।

और मैं कुछ अलग-अलग मॉडल प्रकार और आरेखों के बारे में बात करना चाहता हूं जो हम इस प्रकार के परिदृश्य में उत्पन्न करेंगे। जाहिर है कि हम बहुत सारे उदाहरणों में वैचारिक मॉडल नहीं करेंगे; मैं उस पर ज्यादा समय नहीं बिता रहा हूँ मैं वास्तव में तार्किक मॉडल, भौतिक मॉडल और विशेष प्रकार के मॉडल के बारे में बात करना चाहता हूं जो हम बना सकते हैं। और यह महत्वपूर्ण है कि हम इन सभी को एक ही मॉडलिंग प्लेटफॉर्म में बना सकते हैं ताकि हम उन्हें एक साथ सिलाई कर सकें। इसमें डायनामिक मॉडल और वे मॉडल भी शामिल हैं जो कुछ नए डेटा स्रोतों का उपयोग करते हैं, जैसे कि NoSQL जो मैं आपको दिखाऊंगा। और फिर, डेटा वंश मॉडल कैसा दिखता है? और हम उस डेटा को एक व्यवसाय प्रक्रिया मॉडल में कैसे सिलाई करते हैं, यह वही है जिसके बारे में हम आगे बात करेंगे।

मैं आपको केवल बहुत ही उच्च और त्वरित अवलोकन देने के लिए एक मॉडलिंग वातावरण में यहाँ जा रहा हूँ। और मेरा मानना ​​है कि अब आपको मेरी स्क्रीन देखने में सक्षम होना चाहिए। सबसे पहले मैं सिर्फ एक पारंपरिक प्रकार के डेटा मॉडल के बारे में बात करना चाहता हूं। और जिस तरह से हम मॉडल को व्यवस्थित करना चाहते हैं जब हम उन्हें लाते हैं, तो क्या हम उन्हें विघटित करने में सक्षम होना चाहते हैं। तो जो आप यहां बाईं ओर देख रहे हैं, वह इस विशेष मॉडल फ़ाइल में तार्किक और भौतिक मॉडल हैं। अगली बात यह है कि क्या हम इसे व्यापार के पतन के साथ तोड़ सकते हैं, इसलिए आप फ़ोल्डर्स को देखते हैं। हल्के नीले वाले तार्किक मॉडल हैं और हरे रंग के भौतिक मॉडल हैं। और हम नीचे ड्रिल भी कर सकते हैं, इसलिए ईआर / स्टूडियो के भीतर, यदि आपके पास एक व्यापार अपघटन है, तो आप जितने चाहें उतने गहरे या उप-मॉडल ले सकते हैं, और आपके द्वारा निचले स्तरों पर किए गए परिवर्तन स्वचालित रूप से उच्चतर पर प्रतिबिंबित होते हैं स्तरों। तो यह एक बहुत शक्तिशाली मॉडलिंग वातावरण बन जाता है बहुत जल्दी।

ऐसा कुछ जो मैं यह भी बताना चाहता हूं कि इस जानकारी को एक साथ खींचने के लिए शुरू करना बहुत महत्वपूर्ण है, हमारे पास कई भौतिक मॉडल हो सकते हैं जो एक तार्किक मॉडल के भी अनुरूप हैं। अक्सर आपके पास एक तार्किक मॉडल हो सकता है लेकिन आपके पास विभिन्न प्लेटफार्मों और उस प्रकार की चीज़ों पर भौतिक मॉडल हो सकते हैं। हो सकता है कि इसका एक SQL सर्वर उदाहरण हो, शायद किसी अन्य का Oracle उदाहरण। हमारे पास एक ही मॉडलिंग के माहौल में एक साथ सभी को बाँधने की क्षमता है। और फिर से, जो मुझे यहां मिला है वह एक वास्तविक डेटा वेयरहाउस मॉडल है जो फिर से, एक ही मॉडलिंग वातावरण में हो सकता है या हम इसे रिपॉजिटरी में रख सकते हैं और इसे अलग-अलग चीजों में भी लिंक कर सकते हैं।

मैं वास्तव में इस पर आपको दिखाना चाहता था कि कुछ अन्य चीजें और मॉडल के अन्य प्रकार हैं जो हमें मिलते हैं। इसलिए जब हम इस तरह से एक पारंपरिक डेटा मॉडल में आते हैं तो हम कॉलम और मेटाडेटा और उस प्रकार की चीज़ों के साथ विशिष्ट संस्थाओं को देखने के लिए उपयोग किया जाता है, लेकिन जब हम इन नई NoSQL प्रौद्योगिकियों से निपटने के लिए शुरू करते हैं, तो यह दृष्टिकोण बहुत तेज़ी से बदलता है , या जैसा कि कुछ लोग अभी भी उन्हें कॉल करना पसंद करते हैं, बड़ी डेटा प्रौद्योगिकियां।

तो अब हम कहते हैं कि हमें अपने पर्यावरण में भी हाइव मिला है। यदि हम एक हाइव पर्यावरण से इंजीनियर को उल्टा करते हैं - और हम हाइव से इस सटीक मॉडलिंग टूल के साथ इंजीनियर को आगे और पीछे कर सकते हैं - तो हम कुछ ऐसा देखते हैं जो थोड़ा अलग है। हम अभी भी सभी डेटा को वहां निर्माण के रूप में देखते हैं, लेकिन हमारा TDL अलग है। आप में से जो लोग SQL देखने के आदी हैं, जो आप अभी देखेंगे, वह Hive QL है, जो बहुत ही SQL-जैसा है, लेकिन उसी टूल से जो आप अलग-अलग स्क्रिप्टिंग भाषाओं के साथ काम करना शुरू करने में सक्षम हैं। तो आप इस वातावरण में मॉडल कर सकते हैं, इसे हाइव वातावरण में उत्पन्न कर सकते हैं, लेकिन बस महत्वपूर्ण रूप से, उस परिदृश्य में, जिसका मैंने वर्णन किया है, आप इसे इंजीनियर को उल्टा कर सकते हैं और इसे समझ सकते हैं और इसे एक साथ सिलाई करना शुरू कर सकते हैं ।

आइए एक और एक ले लें जो थोड़ा अलग है। MongoDB एक और मंच है जिसका हम मूल रूप से समर्थन करते हैं। और जब आप JSON के उन प्रकार के वातावरणों में जाने लगते हैं, जहाँ आपके पास दस्तावेज़ भंडार हैं, JSON का एक अलग जानवर है और उसमें ऐसे निर्माण हैं, जो संबंधपरक मॉडल के अनुरूप नहीं हैं। जब आप JSON से पूछताछ करना शुरू करते हैं, तो आप जल्द ही उन वस्तुओं और एम्बेडेड सरणियों जैसी अवधारणाओं से निपटना शुरू कर देते हैं, जो पारंपरिक अवधारणाओं से संबंधित नहीं हैं। हमने यहां जो किया है, वह वास्तव में इस संकेतन को बढ़ाया है और हमारी सूची को उसी वातावरण में संभालने में सक्षम होने के लिए।

यदि आप यहां बाईं ओर देखते हैं, तो संस्थाओं और तालिकाओं जैसी चीजों को देखने के बजाय, हम उन्हें ऑब्जेक्ट कह रहे हैं। और आप अलग-अलग नोटेशन देखते हैं। आप अभी भी यहाँ विशिष्ट प्रकार के संदर्भ संकेतन देखते हैं, लेकिन ये ब्लू इकाइयाँ जो मैं इस विशेष आरेख में दिखा रहा हूँ, वे वास्तव में एम्बेडेड ऑब्जेक्ट हैं। और हम अलग-अलग कार्डिनलिटी दिखाते हैं। हीरे की कार्डिनैलिटी का मतलब है कि यह एक छोर पर एक वस्तु है, लेकिन एक की कार्डिनैलिटी का मतलब है कि हमारे पास, प्रकाशक के भीतर अगर हम उस रिश्ते का पालन करते हैं, तो हमारे पास एक एम्बेडेड पता ऑब्जेक्ट है। JSON से पूछताछ में हमने पाया है कि यह ऑब्जेक्ट की समान संरचना है जो संरक्षक में एम्बेडेड है, लेकिन यह वास्तव में ऑब्जेक्ट की एक सरणी के रूप में एम्बेडेड है। हम यह देख रहे हैं कि न केवल कनेक्टर के माध्यम से, बल्कि यदि आप वास्तविक संस्थाओं को देखते हैं, तो आप देखेंगे कि आप संरक्षक के तहत पते देखते हैं जो इसे वस्तुओं की एक सरणी के रूप में वर्गीकृत करता है। आपको बहुत विवरणात्मक दृष्टिकोण मिलता है कि आप इसे कैसे ला सकते हैं।

और फिर, अब हमने जो कुछ ही सेकंड में देखा है वह पारंपरिक संबंध मॉडल हैं जो बहु-स्तरीय हैं, हम हाइव के साथ एक ही काम कर सकते हैं, हम मोंगोडीबी के साथ एक ही काम कर सकते हैं, और अन्य बड़े डेटा स्रोत कुंआ। हम जो भी कर सकते हैं, और मैं आपको यह बहुत जल्दी दिखाने जा रहा हूं, मैंने विभिन्न क्षेत्रों से चीजों को लाने के तथ्य के बारे में बात की है। मैं यह मानने जा रहा हूं कि मैं किसी डेटाबेस से मॉडल आयात करने जा रहा हूं या इसे रिवर्स इंजीनियर कर रहा हूं, लेकिन मैं इसे बाहरी मेटाडेटा से लाने जा रहा हूं। बस आपको सभी विभिन्न प्रकार की चीजों का एक बहुत ही त्वरित दृष्टिकोण देना है जिसे हम शुरू कर सकते हैं।

जैसा कि आप देख रहे हैं, हमारे पास ऐसी चीजें हैं जो हम वास्तव में मेटाडेटा को अपने मॉडलिंग परिवेश में ला सकते हैं। अमेज़ॅन रेडशिफ्ट, कैसंड्रा, बहुत सारे अन्य बड़े डेटा प्लेटफ़ॉर्म जैसी चीजों के साथ शुरू करना, इसलिए आप इनमें से बहुत सारे सूचीबद्ध हैं। यह वर्णमाला क्रम में है। हम बहुत से बड़े डेटा स्रोत और उस प्रकार की चीज़ देख रहे हैं। हम बहुत सारे पारंपरिक या पुराने मॉडलिंग परिवेशों को भी देख रहे हैं जिन्हें हम वास्तव में उस मेटाडेटा के माध्यम से ला सकते हैं। अगर मैं यहां से गुजरता हूं - और मैं उनमें से हर एक पर समय नहीं बिताने जा रहा हूं - हम बहुत से अलग-अलग चीजों को देखते हैं जो हम इसे मॉडलिंग प्लेटफॉर्म और डेटा प्लेटफॉर्म के संदर्भ में ला सकते हैं। और कुछ ऐसा है जो यहां महसूस करना बहुत महत्वपूर्ण है, एक और हिस्सा है जो हम तब कर सकते हैं जब हम डेटा वंश के बारे में बात करना शुरू करते हैं, एंटरप्राइज टीम संस्करण पर हम ईटीएल स्रोतों से भी पूछताछ कर सकते हैं, चाहे वह टैलेंड या एसक्यूएल सर्वर इंफॉर्मेशन सर्विसेज मैपिंग जैसी चीजें हों, हम कर सकते हैं। वास्तव में हमारे डेटा वंश आरेख शुरू करने के लिए और उन परिवर्तनों में क्या हो रहा है, इसकी एक तस्वीर खींचना। पूरी तरह से बॉक्स से बाहर हमारे पास इन विभिन्न पुलों में से 130 हैं जो वास्तव में एंटरप्राइज टीम संस्करण उत्पाद का हिस्सा हैं, इसलिए यह वास्तव में हमें एक कला के वातावरण में सभी कलाकृतियों को बहुत जल्दी से एक साथ खींचने में मदद करता है।

अंतिम लेकिन कम से कम, मैं इस तथ्य के बारे में भी बात करना चाहता हूं कि हम इस तथ्य को नहीं खो सकते हैं कि हमें अन्य प्रकार के निर्माणों की आवश्यकता है यदि हम डेटा वेयरहाउसिंग या किसी भी प्रकार के विश्लेषिकी कर रहे हैं। हम अभी भी आयामी मॉडल जैसी चीजों को करने की क्षमता चाहते हैं जहां हमारे पास तथ्य तालिकाएं हैं और हमारे पास आयाम और उन प्रकार की चीजें हैं। एक चीज जो मैं आपको दिखाना चाहता हूं, वह यह है कि हमारे मेटाडेटा के एक्सटेंशन भी हो सकते हैं जो हमें यह समझाने में मदद करते हैं कि आयाम और बाकी सभी प्रकार क्या हैं। इसलिए अगर मैं यहाँ आयामी डेटा टैब को देखता हूँ, उदाहरण के लिए, इनमें से एक पर, यह वास्तव में स्वचालित रूप से पता लगाएगा, जो उस मॉडल पैटर्न के आधार पर है जो इसे देखता है, और आपको एक प्रारंभिक बिंदु देता है कि क्या यह सोचता है कि यह एक आयाम है या नहीं तथ्य तालिका। लेकिन इससे परे, हम जो कर सकते हैं वह आयामों के भीतर है और उस प्रकार की चीज़ों के भी हमारे पास विभिन्न प्रकार के आयाम हैं जिनका उपयोग हम डेटा को डेटा वेयरहाउसिंग प्रकार के वातावरण में वर्गीकृत करने के लिए कर सकते हैं। इतनी शक्तिशाली क्षमताएं कि हम इसे पूरी तरह से सिलाई कर रहे हैं।

मैं अभी से इस में कूदने जा रहा हूं क्योंकि मैं अभी डेमो वातावरण में हूं और स्लाइड्स पर वापस जाने से पहले आपको कुछ अन्य चीजें दिखाएगा। उन चीजों में से एक जो हमने हाल ही में ईआर / स्टूडियो डेटा आर्किटेक्ट में जोड़ा है, क्या हम स्थितियों में चले गए हैं - और यह एक बहुत ही सामान्य उपयोग का मामला है जब आप परियोजनाओं पर काम कर रहे हैं - डेवलपर्स वस्तुओं के संदर्भ में सोचते हैं, जबकि हमारा डेटा मॉडलर टेबल और संस्थाओं और उस प्रकार की चीजों के बारे में सोचते हैं। यह एक बहुत ही सरल डेटा मॉडल है, लेकिन यह कुछ बुनियादी अवधारणाओं का प्रतिनिधित्व करता है, जहां डेवलपर्स या यहां तक ​​कि व्यापार विश्लेषक या व्यावसायिक उपयोगकर्ता, उन्हें अलग-अलग वस्तुओं या व्यावसायिक अवधारणाओं के रूप में सोच सकते हैं। अब तक इन्हें वर्गीकृत करना बहुत मुश्किल है, लेकिन 2016 की रिलीज़ में, हमने वास्तव में ईआर / स्टूडियो एंटरप्राइज टीम संस्करण में क्या किया है, क्या अब हमारे पास व्यवसाय डेटा ऑब्जेक्ट नामक एक अवधारणा है। और जो हमें करने की अनुमति देता है, वह हमें संस्थाओं या तालिकाओं के समूहों को वास्तविक व्यावसायिक वस्तुओं में संलग्न करने की अनुमति देता है।

उदाहरण के लिए, इस नए दृश्य पर हमें जो कुछ मिला है वह है खरीद ऑर्डर हेडर और ऑर्डर लाइन को अब एक साथ खींचा गया है, उन्हें एक वस्तु के रूप में समझाया गया है, जब हम डेटा को बनाए रखते हैं तो हम उन्हें कार्य की एक इकाई के रूप में सोचेंगे। , और हम उन्हें एक साथ लाते हैं, इसलिए अब अलग-अलग दर्शकों से संबंधित होना बहुत आसान है। वे पूरे मॉडलिंग परिवेश में पुन: प्रयोज्य हैं। वे एक सच्ची वस्तु हैं, न केवल एक ड्राइंग निर्माण, बल्कि हमें इसका अतिरिक्त लाभ भी है कि जब हम वास्तव में मॉडलिंग के नजरिए से संवाद कर रहे हैं, तो हम चुनिंदा रूप से पतन कर सकते हैं या उनका विस्तार कर सकते हैं ताकि हम कुछ हितधारक दर्शकों के साथ संवाद के लिए एक सारांश दृश्य का निर्माण कर सकें, और हम निश्चित रूप से, अधिक विस्तृत दृश्य रख सकते हैं जैसे हम तकनीकी दर्शकों के लिए यहां देख रहे हैं। यह वास्तव में हमें संचार का एक अच्छा वाहन देता है। अब हम जो देख रहे हैं वह कई अलग-अलग मॉडल प्रकारों को मिला रहा है, उन्हें व्यापार डेटा ऑब्जेक्ट की अवधारणा के साथ संवर्धित कर रहा है, और अब मैं इस बारे में बात करने जा रहा हूं कि हम वास्तव में इन प्रकार की चीजों पर कुछ और अर्थ कैसे लागू करते हैं और हम उन्हें एक साथ कैसे जोड़ते हैं। समग्र वातावरण।

मैं अभी अपने WebEx को यहाँ वापस खोजने की कोशिश कर रहा हूँ ताकि मैं ऐसा कर पाऊँ। और वहां हम वापस आते हैं, हॉट टेक स्लाइड्स पर। मैं यहाँ केवल कुछ स्लाइड्स को तेज़ी से आगे बढ़ाने जा रहा हूँ क्योंकि आपने इन्हें पहले ही मॉडल प्रदर्शन में देख लिया है। मैं नामकरण मानकों के बारे में बहुत जल्दी बात करना चाहता हूं। हम विभिन्न नामकरण मानकों को लागू और लागू करना चाहते हैं। हम क्या करना चाहते हैं, हमारे पास वास्तव में नाम या वाक्यांशों के माध्यम से मूल रूप से उस अर्थ का निर्माण करने के लिए अपने रिपॉजिटरी में नामकरण मानकों के टेम्पलेट्स को संग्रहीत करने की क्षमता है, और उन्हें वापस एक सार्थक अंग्रेजी प्रकार के शब्द के लिए टाई। हम व्यावसायिक शब्दों, प्रत्येक के लिए संक्षिप्त रूप का उपयोग करने जा रहे हैं, और हम आदेश, मामलों को निर्दिष्ट कर सकते हैं और उपसर्ग और प्रत्यय जोड़ सकते हैं। इसके लिए विशिष्ट उपयोग का मामला आम तौर पर तब होता है जब लोग एक तार्किक मॉडल का निर्माण कर रहे होते हैं और फिर वास्तव में एक भौतिक मॉडल बनाने के लिए आगे बढ़ते हैं जहां वे संक्षिप्त और अन्य सभी चीजों का उपयोग कर रहे होते हैं।

खूबसूरत बात यह है कि यह बस के रूप में शक्तिशाली है, रिवर्स में भी अधिक शक्तिशाली है, अगर हम सिर्फ यह बता सकते हैं कि उन भौतिक डेटाबेसों में से कुछ पर क्या नामकरण मानक थे, जो हमने रिवर्स इंजीनियर हैं, हम उन संक्षिप्त रूपों को ले सकते हैं, उन्हें लंबे समय तक बदल सकते हैं। शब्द, और उन्हें अंग्रेजी वाक्यांशों में पीछे की ओर लाएं। हम वास्तव में अब हमारे डेटा जैसा दिखता है उसके लिए उचित नाम प्राप्त कर सकते हैं। जैसा कि मैं कहता हूं, विशिष्ट उपयोग का मामला है कि हम भौतिक, और डेटा स्टोर और उस प्रकार की चीजों को मैप करने के लिए तार्किक, आगे बढ़ेंगे। यदि आप दाईं ओर स्क्रीनशॉट को देखते हैं, तो आप देखेंगे कि स्रोत नामों से संक्षिप्त नाम हैं और जब हमने नामकरण मानक टेम्पलेट लागू किया है, तो हमें वास्तव में अधिक पूर्ण नाम मिल गए हैं। और हम रिक्त स्थान और सब कुछ उस तरह से रख सकते हैं, यदि हम चाहते हैं कि हमारे द्वारा उपयोग किए जाने वाले नामकरण मानकों के आधार पर। हम इसे अपने स्वरूप में लाने के लिए देखना चाहते हैं, हालांकि हम इसे देख सकते हैं। केवल जब हम जानते हैं कि किसी चीज को क्या कहा जाता है, क्या हम वास्तव में इसके लिए परिभाषाएं संलग्न करना शुरू कर सकते हैं, क्योंकि जब तक हम यह नहीं जानते कि यह क्या है, हम इसे कैसे लागू कर सकते हैं?

अच्छी बात यह है कि क्या हम वास्तव में इसे तब लागू कर सकते हैं जब हम सभी प्रकार की चीजें कर रहे हैं। मैंने रिवर्स इंजीनियरिंग के बारे में बात की थी, जब हम रिवर्स इंजीनियरिंग कर रहे होते हैं, तो हम वास्तव में नामकरण मानकों को एक साथ लागू कर सकते हैं। एक जादूगर के माध्यम से कदमों के एक सेट में, हम क्या करने में सक्षम हैं, अगर हम जानते हैं कि सम्मेलनों क्या हैं, हम इंजीनियर को एक भौतिक डेटाबेस को उल्टा कर सकते हैं, यह एक मॉडलिंग वातावरण में भौतिक मॉडल के रूप में इसे वापस लाने जा रहा है और यह उन नामकरण सम्मेलनों को लागू करने जा रहा है। इसलिए हम देखेंगे कि पर्यावरण में संबंधित तार्किक मॉडल में नामों के अंग्रेजी जैसे प्रतिनिधित्व क्या हैं। हम इसे कर भी सकते हैं और इसे XML स्कीमा पीढ़ी के साथ जोड़ सकते हैं ताकि हम एक मॉडल ले सकें और यहां तक ​​कि इसे अपने संक्षिप्ताक्षरों के साथ बाहर धकेल सकें, चाहे हम SOA फ्रेमवर्क कर रहे हों या उस प्रकार की चीज, इसलिए हम अलग-अलग नामकरण सम्मेलनों को भी धक्का दे सकते हैं। कि हम वास्तव में मॉडल में ही संग्रहीत हैं। यह हमें बहुत शक्तिशाली क्षमताएं प्रदान करता है।

फिर, यहां एक उदाहरण है कि यदि मेरा कोई टेम्प्लेट है तो यह कैसा दिखेगा। यह वास्तव में दिखा रहा है कि मैं "कर्मचारी," वेतन के लिए ईएमपी, नामकरण मानकों के सम्मेलन में "योजना" के लिए पीएलएन था। मैं उन्हें लागू भी कर सकता हूं, क्योंकि मैं मॉडल बना रहा हूं और चीजों को अंदर रख रहा हूं, अगर मैं इस संक्षिप्त नाम का उपयोग कर रहा हूं और मैं इकाई के नाम पर "कर्मचारी वेतन योजना" टाइप कर रहा हूं, तो यह नामकरण मानकों के साथ काम करेगा। मैंने यहां परिभाषित किया है, इसने मुझे EMP_SAL_PLN दिया होगा क्योंकि मैं संस्थाओं का निर्माण कर रहा था और मुझे इसी भौतिक अधिकार दिया गया था।

फिर से, जब हम डिजाइनिंग कर रहे हों और इंजीनियरिंग को आगे बढ़ाएं तो बहुत अच्छा होगा। हमारे पास एक बहुत ही अनूठी अवधारणा है और यही वह जगह है जहां हम वास्तव में इन वातावरणों को एक साथ लाना शुरू करते हैं।और इसे यूनिवर्सल मैपिंग कहा जाता है। एक बार जब हम इन सभी मॉडलों को अपने पर्यावरण में लाएंगे, तो हम क्या करने में सक्षम हैं, यह मानते हुए कि हमने अब इन नामकरण सम्मेलनों को लागू किया है और वे आसानी से मिल जाते हैं, हम अब ईआर में यूनिवर्सल मैपिंग नामक एक निर्माण का उपयोग कर सकते हैं। / स्टूडियो। हम मॉडल भर में संस्थाओं को लिंक कर सकते हैं। जहाँ भी हम "ग्राहक" देखते हैं - हमारे पास बहुत सारे अलग-अलग प्रणालियों और बहुत सारे डेटाबेस में "ग्राहक" होंगे - हम उन सभी को एक साथ जोड़ना शुरू कर सकते हैं ताकि जब मैं एक मॉडल में इसके साथ काम करूं देख सकते हैं कि अन्य मॉडलों में ग्राहकों की अभिव्यक्तियाँ कहाँ हैं। और क्योंकि हमें उस मॉडल की परत का प्रतिनिधित्व मिल गया है, इसलिए हम इसे डेटा स्रोतों में भी बाँध सकते हैं और इसे अपने नीचे ला सकते हैं जहाँ इस्तेमाल किए गए पूछताछ में डेटाबेस इन के रूप में अच्छी तरह से रहते हैं। यह वास्तव में हमें बहुत ही सामंजस्यपूर्वक एक साथ यह सब बाँधने की क्षमता देता है।

मैंने आपको व्यवसाय डेटा ऑब्जेक्ट दिखाया है। मैं मेटाडेटा एक्सटेंशन के बारे में भी बात करना चाहता हूं, जिसे हम अटैचमेंट कहते हैं, बहुत जल्दी। वह जो करता है वह हमें अपने मॉडल ऑब्जेक्ट के लिए अतिरिक्त मेटाडेटा बनाने की क्षमता देता है। काफी बार मैं इस प्रकार के गुणों की स्थापना एक डाटा गवर्नेंस और डेटा क्वालिटी के नजरिए से बहुत सी अलग-अलग चीजों को चलाने के लिए करता हूँ, और मास्टर डेटा मैनेजमेंट और डेटा रिटेंशन नीतियों के साथ हमारी मदद करने के लिए भी। मूल विचार यह है कि आप इन वर्गीकरणों का निर्माण करते हैं और आप उन्हें टेबल टेबल, कॉलम स्तर, उन प्रकार की चीजों में, जहाँ भी आप चाहते हैं, संलग्न कर सकते हैं। सबसे आम उपयोग का मामला, निश्चित रूप से, यह है कि संस्थाएं टेबल हैं, और फिर मैं परिभाषित कर सकता हूं: मेरे मास्टर डेटा ऑब्जेक्ट क्या हैं, मेरी संदर्भ तालिकाएं क्या हैं, मेरी लेनदेन तालिकाएं क्या हैं? डेटा गुणवत्ता के दृष्टिकोण से मैं व्यवसाय के लिए महत्व के संदर्भ में वर्गीकरण कर सकता हूं ताकि हम डेटा सफाई के प्रयासों और उस प्रकार की चीजों को प्राथमिकता दे सकें।

कुछ ऐसा है जिसे अक्सर अनदेखा किया जाता है, हमारे संगठन में विभिन्न प्रकार के डेटा के लिए अवधारण नीति क्या है? हम इन्हें स्थापित कर सकते हैं और हम वास्तव में इन्हें हमारे मॉडलिंग वातावरण में विभिन्न प्रकार की सूचना कलाकृतियों से जोड़ सकते हैं और निश्चित रूप से, हमारे भंडार को भी। सुंदरता यह है कि क्या ये अटैचमेंट हमारे डेटा शब्दकोश में रहते हैं, इसलिए जब हम पर्यावरण में एंटरप्राइज़ डेटा शब्दकोशों का उपयोग कर रहे हैं, तो हम उन्हें कई मॉडल में संलग्न कर सकते हैं। हमें केवल उन्हें एक बार परिभाषित करना है और हम अपने परिवेश में विभिन्न मॉडलों में उनका बार-बार लाभ उठा सकते हैं। यह दिखाने के लिए बस एक त्वरित स्क्रीनशॉट है कि आप वास्तव में निर्दिष्ट कर सकते हैं जब आप एक अनुलग्नक करते हैं, तो वे सभी टुकड़े क्या हैं जो आप इसे संलग्न करना चाहते हैं। और यह उदाहरण वास्तव में मूल्यों की एक सूची है, इसलिए जब वे आप में जा रहे हैं तो आप मूल्यों की एक सूची से चुन सकते हैं, आपके पास जो उठाया जा रहा है, उसके मॉडलिंग परिवेश में आपका बहुत नियंत्रण है, और आप यह भी निर्धारित कर सकते हैं कि डिफ़ॉल्ट क्या है मान है यदि कोई मान नहीं उठाया गया है। इसलिए वहां बहुत शक्ति है। वे डेटा डिक्शनरी में रहते हैं।

कुछ मैं आपको इस स्क्रीन पर थोड़ा और नीचे दिखाना चाहता हूं, इसके अलावा आप शीर्ष भाग में दिखावे के प्रकार को देखते हैं, इसके नीचे आपको डेटा सुरक्षा जानकारी दिखाई देती है। हम वास्तव में डेटा सुरक्षा नीतियों को पर्यावरण में सूचना के विभिन्न टुकड़ों पर भी लागू कर सकते हैं। विभिन्न अनुपालन मैपिंग, डेटा सुरक्षा वर्गीकरण के लिए, हम उनमें से एक नंबर को उस बॉक्स से बाहर निकालते हैं, जिसे आप केवल उत्पन्न कर सकते हैं और उपयोग करना शुरू कर सकते हैं, लेकिन आप अपने स्वयं के अनुपालन मैपिंग और मानकों को भी परिभाषित कर सकते हैं। चाहे आप HIPAA कर रहे हों या कोई अन्य पहल वहाँ से कर रहे हों। और आप वास्तव में अपने वातावरण में मेटाडेटा के इस बहुत समृद्ध सेट का निर्माण शुरू कर सकते हैं।

और फिर शब्दावली और शर्तें - यह वह जगह है जहां व्यापार का अर्थ बंधा हुआ है। हमारे पास अक्सर डेटा शब्दकोशों हैं जो अक्सर एक संगठन का उपयोग करते हैं, जो शब्दावली शुरू करने के लिए एक प्रारंभिक बिंदु के रूप में उपयोग कर रहे हैं, लेकिन शब्दावली और क्रिया है अक्सर बहुत तकनीकी। इसलिए हम जो कर सकते हैं, वह यह है कि अगर हम चाहें, तो उन्हें ग्लोरीज़ को बाहर निकालने के लिए एक शुरुआती बिंदु के रूप में उपयोग कर सकते हैं, लेकिन हम वास्तव में चाहते हैं कि व्यवसाय इन का मालिक हो। टीम सर्वर वातावरण में हमने जो किया है, वह है कि हम लोगों के लिए व्यावसायिक परिभाषाएँ बनाने की क्षमता दी जाए और फिर हम उन्हें अलग-अलग मॉडल कलाकृतियों से जोड़ सकें, जो वे मॉडलिंग परिवेश में भी अनुरूप हैं। हम उस बिंदु को भी पहचानते हैं जो पहले चर्चा की गई थी, जो आपके पास जितने अधिक लोग टाइप करते हैं, मानव त्रुटि के लिए उतनी अधिक संभावना है। हम अपनी शब्दावली संरचना में भी क्या करते हैं, एक, हम शब्दावली के एक पदानुक्रम का समर्थन करते हैं, इसलिए हमारे पास संगठन में अलग-अलग शब्द या विभिन्न प्रकार की चीजें हो सकती हैं, लेकिन जैसा कि महत्वपूर्ण है, अगर आपके पास इनमें से कुछ स्रोत हैं वहाँ शर्तों और सब कुछ परिभाषित के साथ, हम वास्तव में हमारे मॉडलिंग वातावरण, और हमारे टीम सर्वर या हमारे शब्दकोष में खींचने के लिए एक सीएसवी आयात कर सकते हैं और फिर वहां से लिंक करना शुरू कर सकते हैं। और हर बार जब कुछ बदला जाता है तो परिभाषाओं और बाकी चीजों के संदर्भ में पहले और बाद की छवियां क्या हैं, इसका पूरा ऑडिट ट्रेल है, और जो आप निकट भविष्य में आने जा रहे हैं, वह भी एक प्राधिकरण वर्कफ़्लो से अधिक है इसलिए हम वास्तव में नियंत्रित कर सकते हैं कि इसका प्रभारी कौन है, समितियों या व्यक्तियों द्वारा अनुमोदन, और उस प्रकार की बात, जिससे हम आगे बढ़ते हैं, शासन प्रक्रिया को और भी अधिक मजबूत बनाते हैं।

यह हमारे लिए भी क्या है जब हमारे टीम सर्वर शब्दकोष में ये शब्दावली शब्द होते हैं, यह मॉडल में एक इकाई में खुद को संपादित करने का एक उदाहरण है जिसे मैंने यहां लाया है। इसमें लिंक किए गए शब्द हो सकते हैं, लेकिन हम जो भी करते हैं, यदि उस शब्दकोष में ऐसे शब्द हैं, जो हमारे संस्थानों में हमारे पास मौजूद नोट्स या विवरण में दिखाई देते हैं, तो वे स्वचालित रूप से हल्के हाइपरलिंक रंग में दिखाए जाते हैं, और यदि हम उन पर माउस, हम वास्तव में व्यापार शब्दावली से परिभाषा देख सकते हैं। यहां तक ​​कि जब हम सूचनाओं का उपभोग करते हैं, तो यह हमें और भी समृद्ध जानकारी देता है। यह वास्तव में अनुभव को समृद्ध करने में मदद करता है और उन सभी चीजों के लिए अर्थ लागू करता है जिनके साथ हम काम कर रहे हैं।

तो, फिर से, यह एक बहुत जल्दी उड़ गया था। जाहिर है कि हम इस पर दिन बिता सकते हैं क्योंकि हम अलग-अलग हिस्सों में हैं, लेकिन सतह पर यह बहुत जल्दी उड़ने वाला है। हम वास्तव में ऐसा करने के लिए प्रयास कर रहे हैं, यह समझने के लिए कि उन जटिल डेटा वातावरण क्या दिखते हैं। हम उन सभी डेटा कलाकृतियों की दृश्यता में सुधार करना चाहते हैं और उन्हें ईआर / स्टूडियो के साथ चलाने के लिए सहयोग करते हैं। हम अधिक कुशल और स्वचालित डेटा मॉडलिंग सक्षम करना चाहते हैं। और यह सभी प्रकार के डेटा हैं जिनके बारे में हम बात कर रहे हैं, चाहे वह बड़ा डेटा, पारंपरिक संबंध डेटा, दस्तावेज़ स्टोर या कुछ और हो। और फिर, हमने इसे पूरा किया क्योंकि हमारे पास विभिन्न प्लेटफार्मों के लिए शक्तिशाली आगे और रिवर्स इंजीनियरिंग क्षमताएं हैं और अन्य उपकरण जो आपके पास हो सकते हैं। और यह उन सभी हितधारकों के साथ संगठन में साझा करने और संचार करने के बारे में है जो शामिल हैं। नामकरण के मानकों के माध्यम से इसका अर्थ लागू होता है। फिर हम अपनी व्यावसायिक शब्दावली के माध्यम से परिभाषाएँ लागू करते हैं। और फिर हम मेटाडेटा एक्सटेंशन जैसे डेटा गुणवत्ता एक्सटेंशन, मास्टर डेटा प्रबंधन के लिए वर्गीकरण या किसी अन्य प्रकार के वर्गीकरण जो आप उस डेटा पर लागू करना चाहते हैं, के साथ अपनी सभी अन्य शासन क्षमताओं के लिए आगे वर्गीकरण कर सकते हैं। और फिर हम अलग-अलग हितधारक दर्शकों के साथ, विशेष रूप से मॉडलर्स और डेवलपर्स के बीच, व्यापारिक डेटा ऑब्जेक्ट्स के साथ संचार को और भी अधिक बढ़ा सकते हैं।

और फिर, इसके बारे में बहुत महत्वपूर्ण है, इसके पीछे सभी एक बहुत मजबूत परिवर्तन प्रबंधन क्षमताओं के साथ एक एकीकृत भंडार है। मेरे पास आज इसे दिखाने का कोई समय नहीं था क्योंकि यह काफी जटिल हो जाता है, लेकिन भंडार में प्रबंधन क्षमताओं और ऑडिट ट्रेल्स में बहुत मजबूत बदलाव हैं। आप नाम जारी कर सकते हैं, आप नामांकित संस्करण कर सकते हैं, और हमारे पास आपके लिए भी क्षमता है जो परिवर्तन प्रबंधन कर रहे हैं, हम उस अधिकार को अपने कार्यों में बाँध सकते हैं। आज आपके पास अपने मॉडल परिवर्तनों को कार्यों के साथ जोड़ने और कार्य करने की क्षमता है, जैसे डेवलपर्स अपने कोड परिवर्तन को उन कार्यों या उपयोगकर्ता कहानियों के साथ जोड़ते हैं, जिनके साथ वे काम कर रहे हैं।

फिर से, यह एक बहुत ही त्वरित अवलोकन था। मुझे आशा है कि यह आपकी भूख को बढ़ाने के लिए पर्याप्त है, ताकि हम भविष्य में आगे बढ़ने के साथ इनमें से कुछ विषयों को विभाजित करने पर अधिक गहन बातचीत में संलग्न हो सकें। आपके समय के लिए धन्यवाद, और आपके पास वापस, रेबेका।

रेबेका जोजवाक: धन्यवाद, रॉन, यह शानदार था और मेरे पास दर्शकों के कुछ सवाल हैं, लेकिन मैं अपने विश्लेषकों को अपने दांतों को डूबने का मौका देना चाहता हूं जो आपको कहना था। एरिक, मैं आगे बढ़ने जा रहा हूं और शायद अगर आप इस स्लाइड, या एक दूसरे को संबोधित करना चाहते हैं, तो आप पहले से आगे क्यों नहीं बढ़ेंगे? या कोई और सवाल।

एरिक लिटिल: ज़रूर। क्षमा करें, क्या सवाल था, रेबेका? आप मुझसे कुछ विशिष्ट पूछना चाहते हैं या…?

रेबेका जोजवाक: मुझे पता है कि रॉन के लिए शुरू में आपके कुछ सवाल थे। यदि आप उनसे उन लोगों में से किसी को संबोधित करने के लिए अभी पूछना चाहते हैं, या उनमें से कुछ आपकी स्लाइड को बंद करते हैं या कुछ और जो आपकी रुचि को बढ़ाता है, जिसके बारे में आप पूछना चाहते हैं? IDERA की मॉडलिंग कार्यक्षमता के बारे में।

एरिक लिटिल: हाँ, तो चीजों में से एक, रॉन, तो आप लोग कैसे हैं, यह उन आरेखों की तरह दिखता है जो आप दिखा रहे थे सामान्य प्रकार के इकाई संबंध आरेख हैं जैसे आप सामान्य रूप से डेटाबेस निर्माण में उपयोग करेंगे, सही?

रॉन हुइज़ेंगा: हाँ, आम तौर पर बोल रहा हूँ, लेकिन निश्चित रूप से हमारे पास दस्तावेज़ भंडार और उस प्रकार की चीज़ों के लिए विस्तारित प्रकार हैं। हम वास्तव में सिर्फ शुद्ध संबंधपरक संकेतन से अलग हैं, हमने वास्तव में उन अन्य दुकानों के लिए अतिरिक्त अंकन भी जोड़े हैं।

एरिक लिटिल: क्या कोई तरीका है कि आप लोग ग्राफ़-आधारित प्रकार के मॉडलिंग का उपयोग कर सकते हैं, इसलिए वहाँ एक तरीका है एकीकृत करने के लिए, उदाहरण के लिए, मान लें कि मेरे पास एक शीर्ष क्वाड्रंट, टॉपबॉयर संगीतकार उपकरण जैसा कुछ है या मैंने प्रोटेग में कुछ किया है या , तुम्हें पता है, FIBO में वित्तीय लोगों की तरह, वे शब्दार्थ, RDF सामान में बहुत काम कर रहे हैं - क्या इस उपकरण में उस प्रकार के इकाई-संबंध ग्राफ़ प्रकार मॉडलिंग में लाने का एक तरीका है, और इसका उपयोग करें?

रॉन हुइज़ेंगा: हम वास्तव में देख रहे हैं कि हम ग्राफ़ को कैसे संभाल सकते हैं। हम आज स्पष्ट रूप से ग्राफ़ डेटाबेस और उस प्रकार की चीज़ों को नहीं संभाल रहे हैं, लेकिन हम उन तरीकों को देख रहे हैं जो हम अपने मेटाडेटा को विस्तारित करने के लिए कर सकते हैं। मेरा मतलब है, हम अभी एक्सएमएल के माध्यम से और उस प्रकार की चीजों को ला सकते हैं, अगर हम कम से कम एक्सएमएल के किसी तरह का प्रतिपादन इसे शुरुआती बिंदु के रूप में कर सकते हैं। लेकिन हम इसे लाने के लिए और अधिक सुरुचिपूर्ण तरीके देख रहे हैं।

और मैंने आपको रिवर्स इंजीनियरिंग पुलों की वह सूची भी दिखाई जो हमारे पास भी है, इसलिए हम हमेशा उन पुलों के साथ-साथ विशिष्ट प्लेटफार्मों के लिए एक्सटेंशन प्राप्त करना चाहते हैं। यह एक निरंतर, चल रहा प्रयास है, अगर यह समझ में आता है, तो इन नए निर्माणों और बहुत सारे प्लेटफार्मों को गले लगाने के लिए शुरू करना है। लेकिन मैं कह सकता हूं कि ऐसा करने में हम निश्चित रूप से सबसे आगे हैं। उदाहरण के लिए, मोंगोबीडी और उस प्रकार की चीज़ों को मैंने दिखाया, हम वास्तव में अपने उत्पाद में मूल रूप से ऐसा करने वाले पहले डेटा मॉडलिंग विक्रेता हैं।

एरिक लिटिल: ठीक है, हाँ। अतः आपके लिए मेरे पास जो दूसरा प्रश्न था, वह था, शासन और उसे बनाए रखने के संदर्भ में - जैसे आपने उदाहरण का उपयोग किया, जब आपने उस व्यक्ति का उदाहरण दिखाया, जो "कर्मचारी" है, तो मेरा मानना ​​है कि यह एक "था" वेतन "और फिर आपके पास एक" योजना है, "एक तरीका है, आप कैसे प्रबंधन करते हैं, उदाहरण के लिए, विभिन्न प्रकार के लोग जो हो सकते हैं - मान लीजिए कि आपके पास एक बड़ा आर्किटेक्चर है, ठीक है, मान लीजिए कि आपके पास एक बड़ा उद्यम है और लोग इस टूल में एक साथ चीजों को खींचना शुरू करते हैं और आपको यहां एक समूह मिला है जिसमें "कर्मचारी" शब्द है और यहां एक समूह है जिसमें "कार्यकर्ता" शब्द है और यहां पर एक व्यक्ति "वेतन" कहता है और दूसरा व्यक्ति कहता है। "वेतन।"

आप लोग किस प्रकार के सामंजस्य स्थापित करते हैं और उन प्रकार के भेदों को प्रबंधित और नियंत्रित करते हैं? क्योंकि मुझे पता है कि हम इसे ग्राफ की दुनिया में कैसे करेंगे, आप जानते हैं, आप पर्यायवाची सूचियों का उपयोग करेंगे या आप कहेंगे कि इसकी एक अवधारणा है और इसमें कई विशेषताएं हैं, या आप कह सकते हैं कि SKOS मॉडल में मेरे पास एक पसंदीदा लेबल है और मेरे पास है कई वैकल्पिक लेबल जिनका मैं उपयोग कर सकता हूं। आप लोग कैसे करते हैं?

रॉन हुइज़ेंगा: हम इसे अलग-अलग तरीकों से करते हैं, और प्राथमिक तौर पर पहले शब्दावली के बारे में बात करते हैं। एक चीज जो हम करते हैं, निश्चित रूप से, हम चाहते हैं कि परिभाषित या स्वीकृत शर्तें हों और व्यापार शब्दावली में स्पष्ट रूप से वह जगह है जहां हम उन्हें चाहते हैं। और हम व्यापार शब्दावली में पर्यायवाची के लिंक की अनुमति देते हैं और साथ ही साथ आप क्या कर सकते हैं, आप यह कह सकते हैं, यहाँ मेरा कार्यकाल है, लेकिन आप यह भी परिभाषित कर सकते हैं कि उनके लिए सभी समानार्थी शब्द क्या हैं।

अब, दिलचस्प बात यह है कि जब आप इस विशाल डेटा परिदृश्य को इन सभी अलग-अलग प्रणालियों के साथ देखना शुरू करते हैं, जो आप वहां से निकल चुके होते हैं, तो आप बस वहां नहीं जा सकते हैं और संबंधित तालिकाओं और उन प्रकार की चीजों को बदल सकते हैं। उस नामकरण मानक के अनुरूप है क्योंकि यह एक पैकेज हो सकता है जिसे आपने खरीदा है, इसलिए आपके पास डेटाबेस या कुछ भी बदलने पर कोई नियंत्रण नहीं है।

हम वहाँ क्या कर सकते हैं, शब्दावली परिभाषाओं को जोड़ने में सक्षम होने के अलावा, उन सार्वभौमिक मैपिंग के माध्यम से है जिनके बारे में मैंने बात की थी, हम क्या करेंगे, और एक अनुशंसित दृष्टिकोण की तरह, एक अति तार्किक तार्किक मॉडल है जो बाहर देता है ये विभिन्न व्यावसायिक अवधारणाएँ हैं जिनके बारे में आप बात कर रहे हैं। उन में व्यावसायिक शब्दावली शर्तों को बाँधें, और अच्छी बात यह है कि अब आपको यह निर्माण मिल गया है जो एक तार्किक इकाई का प्रतिनिधित्व करता है, जैसा कि आप थे, तब आप उस तार्किक इकाई से उस तार्किक इकाई के सभी कार्यान्वयनों से जुड़ना शुरू कर सकते हैं। विभिन्न प्रणालियों।

फिर आपको उस जगह पर जाने की आवश्यकता है, आप देख सकते हैं, ओह, "व्यक्ति" को इस प्रणाली में "कर्मचारी" कहा जाता है। यहाँ "वेतन" को इस अन्य प्रणाली में यहाँ "वेतन" कहा जाता है। क्योंकि आप देखेंगे कि, आप उन सभी की अलग-अलग अभिव्यक्तियाँ देखेंगे क्योंकि आपने उन्हें एक साथ जोड़ा है।

एरिक लिटिल: ठीक है महान, हाँ, मिल गया। उस अर्थ में, क्या यह कहना सुरक्षित है कि वस्तु-उन्मुख दृष्टिकोणों में से कुछ की तरह है?

रॉन हुइज़ेंगा: कुछ हद तक। यह थोड़ा अधिक गहन है, मुझे लगता है कि आप कह सकते हैं। मेरा मतलब है, आप मैन्युअल रूप से जोड़ने और जाने के माध्यम से निरीक्षण कर सकते हैं और निरीक्षण कर सकते हैं और उन सभी को भी कर सकते हैं। एक बात जो मुझे सच में पसंद नहीं है, वह है - क्योंकि फिर से, हमारे पास बहुत सारी क्षमताएं हैं - हमारे पास डेटा आर्किटेक्चर टूल में एक पूर्ण स्वचालन इंटरफ़ेस भी है। और एक मैक्रो क्षमता, जो वास्तव में टूल में एक प्रोग्रामिंग भाषा है। इसलिए हम वास्तव में मैक्रोज़ लिखने जैसे काम कर सकते हैं, क्या यह बाहर जाकर चीजों पर पूछताछ कर सकता है और आपके लिए लिंक बना सकता है। हम इसका उपयोग आयात और निर्यात की जानकारी के लिए करते हैं, हम इसका उपयोग चीजों को बदलने या विशेषताओं को जोड़ने के लिए कर सकते हैं, मॉडल में आधारित घटना, या हम इसका उपयोग बैचों में चलाने के लिए वास्तव में बाहर जाने और चीजों से पूछताछ करने और वास्तव में विभिन्न निर्माणों को आबाद करने के लिए कर सकते हैं। आदर्श। इसलिए एक पूर्ण स्वचालन इंटरफ़ेस है जिसका लोग लाभ उठा सकते हैं। और उन लोगों के साथ सार्वभौमिक मैपिंग का उपयोग करना ऐसा करने का एक बहुत शक्तिशाली तरीका होगा।

रेबेका जोजवाक: ठीक है, धन्यवाद रॉन, और धन्यवाद एरिक। वे महान प्रश्न थे। मुझे पता है कि हम घंटे के शीर्ष से थोड़ा पीछे चल रहे हैं, लेकिन मैं मैल्कम को कुछ सवालों के जवाब देने का मौका देना चाहता हूं। मैल्कम?

मैल्कम चिशोल्म: धन्यवाद, रेबेका। तो, रॉन, यह बहुत दिलचस्प है, मुझे लगता है कि यहां बहुत सारी क्षमताएं हैं। उन क्षेत्रों में से एक जो मुझे बहुत दिलचस्पी है, कहते हैं कि अगर हमारे पास एक विकास परियोजना है, तो आप इन क्षमताओं का उपयोग करके डेटा मॉडलर को कैसे देखते हैं और शायद डेटा विश्लेषकों के साथ, डेटा प्रोफाइलर के साथ, डेटा गुणवत्ता विश्लेषक के साथ काम कर रहे हैं। , और व्यवसाय प्रायोजकों के साथ जो अंततः परियोजना में वास्तविक सूचना आवश्यकताओं के लिए जिम्मेदार होने जा रहे हैं। डेटा मॉडलर वास्तव में आपको कैसे पता चलता है, इस परियोजना को उन क्षमताओं के साथ अधिक प्रभावी और कुशल बनाते हैं जिन्हें हम देख रहे हैं?

रॉन हुइज़ेंगा: मुझे लगता है कि पहली चीज़ जो आपको करनी है वह एक डेटा मॉडलर के रूप में है - और मेरा मतलब कुछ मॉडलर्स को चुनना नहीं है, लेकिन मैं वैसे भी करूंगा - कुछ लोगों को अभी भी यह आभास है कि डेटा मॉडलर वास्तव में द्वारपाल प्रकार की भूमिका की तरह है, हम परिभाषित कर रहे हैं कि यह कैसे काम करता है, हम गार्ड हैं जो सुनिश्चित करते हैं कि सब कुछ सही है।

अब इसका एक पहलू यह है, कि आपको यह सुनिश्चित करना होगा कि आप ध्वनि डेटा वास्तुकला और अन्य सभी चीजों को परिभाषित कर रहे हैं। लेकिन अधिक महत्वपूर्ण बात एक डेटा मॉडलर के रूप में है - और मुझे यह स्पष्ट रूप से थोड़ा सा मिला जब मैं परामर्श कर रहा था - क्या आपको एक सुविधाकर्ता बनना है, इसलिए आपको इन लोगों को एक साथ खींचना होगा।

यह अब एक डिजाइन के रूप में सामने नहीं जा रहा है, उत्पन्न करता है, डेटाबेस का निर्माण करता है - आपको क्या करने में सक्षम होने की आवश्यकता है क्या आपको इन सभी अलग-अलग हितधारक समूहों के साथ काम करने में सक्षम होने की आवश्यकता है, रिवर्स इंजीनियरिंग जैसी चीजें करना, जानकारी आयात करना, होना अन्य लोग सहयोग करते हैं, चाहे वह शब्दावलियों या दस्तावेज़ीकरण पर हो, जैसे कि सब कुछ - और इसे रिपॉजिटरी में खींचने के लिए एक सूत्रधार हो, और अवधारणाओं को रिपॉजिटरी में एक साथ जोड़ते हैं, और उन लोगों के साथ काम करते हैं।

यह वास्तव में एक सहयोगी प्रकार का वातावरण है, जहां कार्यों की परिभाषा के माध्यम से या यहां तक ​​कि चर्चा के धागे या उस प्रकार की चीज है जो हमारे पास टीम सर्वर में है, कि लोग वास्तव में सहयोग कर सकते हैं, प्रश्न पूछ सकते हैं और अंतिम अंतिम उत्पादों पर पहुंच सकते हैं। उनके डेटा आर्किटेक्चर और उनके संगठन की आवश्यकता है। उस तरह का जवाब दिया?

मैल्कम चिशोल्म: हाँ मै सह्मत हूँ। आप जानते हैं, मुझे लगता है कि सुविधा कौशल कुछ ऐसा है जो डेटा मॉडलर्स में वास्तव में अत्यधिक वांछनीय है। मैं मानता हूं कि हम हमेशा ऐसा नहीं देखते हैं, लेकिन मुझे लगता है कि यह आवश्यक है और मैं सुझाव दूंगा कि आपके डेटा मॉडलिंग करने वाले कोने में रहने के लिए कभी-कभी एक झुकाव होता है, लेकिन आपको वास्तव में अन्य हितधारक समूहों के साथ काम करने की आवश्यकता है या आप केवल उस डेटा वातावरण को नहीं समझते हैं, जिसके साथ आप काम कर रहे हैं, और मुझे लगता है कि मॉडल परिणाम के रूप में ग्रस्त है। लेकिन यह महज मेरी राय है।

रॉन हुइज़ेंगा: और यह दिलचस्प है क्योंकि आपने इतिहास के बारे में अपनी स्लाइड में कुछ पहले उल्लेख किया है कि व्यवसाय आईटी से किस तरह से दूर हैं क्योंकि वे समय पर फैशन और उन प्रकारों में समाधान नहीं दे रहे हैं।

यह बहुत दिलचस्प है कि मेरे बाद के परामर्श कार्यों में, उत्पाद प्रबंधक बनने से पहले, उन परियोजनाओं में से अधिकांश जो मैंने पिछले दो वर्षों में किए थे, व्यवसाय प्रायोजित थे, जहां यह वास्तव में व्यवसाय था जो इसे चला रहा था और डेटा आर्किटेक्ट और मॉडलर आईटी का हिस्सा नहीं थे। हम एक व्यवसाय-प्रायोजित समूह का एक हिस्सा थे और हम बाकी प्रोजेक्ट टीमों के साथ काम करने वाले सूत्रधार के रूप में थे।

मैल्कम चिशोल्म: इसलिए मुझे लगता है कि एक बहुत ही दिलचस्प बिंदु है।मुझे लगता है कि हम व्यवसाय की दुनिया में एक बदलाव देखना शुरू कर रहे हैं, जहां व्यवसाय पूछ रहा है, या शायद सोच रहा है, इतना नहीं कि मैं क्या करूं, प्रक्रिया की तरह, लेकिन वे यह भी सोचना शुरू कर रहे हैं कि डेटा क्या है मैं काम करता हूं, मेरी डेटा की जरूरतें क्या हैं, मैं डेटा को डेटा के रूप में किसके साथ काम कर रहा हूं, और उस दृष्टिकोण के समर्थन के लिए हम IDERA उत्पादों और क्षमताओं को किस हद तक प्राप्त कर सकते हैं, और मुझे लगता है कि व्यापार की जरूरत है, यहां तक ​​कि हालांकि यह अभी भी थोड़ा सा नवजात की तरह है।

रॉन हुइज़ेंगा: मैं आपसे सहमत हूं और मुझे लगता है कि हम इसे और अधिक इस तरह से देख रहे हैं। हमने एक जागृति देखी है और आपने पहले डेटा के महत्व के संदर्भ में इसे छुआ है। हमने आईटी में या डेटाबेस के विकास में डेटा के महत्व को देखा, फिर जैसा कि आप कहते हैं, हम इस पूरी प्रक्रिया प्रबंधन चक्र में शामिल हो गए हैं - और यह प्रक्रिया अत्यंत महत्वपूर्ण है, मुझे वहां गलत न करें - लेकिन अब जो हुआ है जब ऐसा होता है, तो डेटा का फोकस खो जाता है।

और अब संगठनों को एहसास हो रहा है कि डेटा वास्तव में केंद्र बिंदु है। डेटा वह सब कुछ दर्शाता है जो हम अपने व्यवसाय में कर रहे हैं, इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि हमारे पास सटीक डेटा है, कि हम सही जानकारी पा सकें, जिसे हमें अपने निर्णय लेने की आवश्यकता है। क्योंकि सब कुछ परिभाषित प्रक्रिया से नहीं होता है। जानकारी में से कुछ अन्य चीजों का उपोत्पाद है और हमें अभी भी इसे खोजने में सक्षम होने की जरूरत है, जानते हैं कि इसका क्या मतलब है, और डेटा को अनुवाद करने में सक्षम होने के लिए, जिसे हम अंततः ज्ञान में देखते हैं जिसका उपयोग हम अपने व्यवसायों को बेहतर ढंग से चलाने के लिए कर सकते हैं।

मैल्कम चिशोल्म: ठीक है, और अब एक और क्षेत्र के साथ मैं संघर्ष कर रहा हूं जिसे मैं डेटा जीवन चक्र कहूंगा, जो कि आप जानते हैं, अगर हम किसी उद्यम के माध्यम से जाने वाले डेटा आपूर्ति श्रृंखला को देखते हैं, तो हम डेटा अधिग्रहण के साथ शुरू करेंगे या डेटा कैप्चर, जो डेटा प्रविष्टि हो सकती है, लेकिन यह समान रूप से हो सकती है, मैं कुछ डेटा विक्रेता से एंटरप्राइज़ के बाहर डेटा प्राप्त कर रहा हूं।

और फिर डेटा कैप्चर से हम डेटा रखरखाव पर जाते हैं जहां मैं इस डेटा को मानकीकृत करने के बारे में सोच रहा हूं और इसे उन जगहों पर शिपिंग कर रहा हूं जहां इसकी आवश्यकता है। और फिर डेटा का उपयोग, वास्तविक बिंदु जहां डेटा है, आप डेटा से मूल्य प्राप्त करने जा रहे हैं।

और पुराने दिनों में यह सब एक व्यक्तिगत शैली में किया जाता है, लेकिन आज यह हो सकता है, आप जानते हैं, एक विश्लेषिकी वातावरण, उदाहरण के लिए, और फिर उससे परे, एक संग्रह, एक स्टोर, जहां हम डेटा डालते हैं जब हम नहीं रह जाते हैं इसकी आवश्यकता है और अंत में एक शुद्ध प्रकार की प्रक्रिया है। आप डेटा मॉडलिंग को इस संपूर्ण डेटा जीवन चक्र के प्रबंधन में कैसे देखते हैं?

रॉन हुइज़ेंगा: यह एक बहुत अच्छा सवाल है और एक बात जो मुझे आज बिल्कुल भी विस्तार से बताने का समय नहीं है, वह यह है कि क्या हम वास्तव में डेटा वंश के बारे में बात करना शुरू कर रहे हैं। तो हम वास्तव में क्या करने में सक्षम हैं, हमारे पास हमारे उपकरणों में एक डेटा वंश क्षमता है, और जैसा कि मैं कहता हूं, हम वास्तव में ईटीएल टूल्स से इसे निकाल सकते हैं, लेकिन आप इसे केवल वंशावली के अनुसार भी चित्रित कर सकते हैं। इनमें से कोई भी डेटा मॉडल या डेटाबेस जिसे हमने कैप्चर किया है और मॉडल में लाया है हम अपने डेटा वंश आरेख में उस से निर्माण का संदर्भ दे सकते हैं।

हम जो करने में सक्षम हैं, वह एक डेटा प्रवाह खींचता है, जैसा कि आप कहते हैं, स्रोत से लक्ष्य के लिए, और समग्र जीवन चक्र के माध्यम से कि डेटा विभिन्न प्रणालियों के माध्यम से कैसे पार करता है और आप क्या खोजने जा रहे हैं, चलो कर्मचारियों को लेते हैं 'डेटा - यह मेरे पसंदीदा प्रोजेक्ट में से एक है जो मैंने सालों पहले किया था। मैंने एक संगठन के साथ काम किया जिसमें 30 विभिन्न प्रणालियों में कर्मचारी डेटा था। हमने वहाँ क्या किया - और रेबेका ने डेटा वंश स्लाइड को पॉप अप किया - यह यहाँ एक काफी सरलीकृत डेटा वंश स्लाइड है, लेकिन हम जो करने में सक्षम थे, वे सभी डेटा संरचनाओं में लाए, उन्हें आरेख में संदर्भित किया, और फिर हम वास्तव में यह देखना शुरू कर सकता है कि प्रवाह के बीच क्या हैं, और उन विभिन्न डेटा संस्थाओं को एक प्रवाह में एक साथ कैसे जोड़ा जाता है? और हम उससे भी आगे जा सकते हैं। यह एक डेटा प्रवाह या वंश आरेख का हिस्सा है जो हम यहां देखते हैं। यदि आप उस पार जाना चाहते हैं, तो हमारे पास इस सूट का व्यावसायिक वास्तुकार हिस्सा भी है और यही बात वहाँ लागू होती है।

डेटा मॉडलिंग परिवेश में हमारे द्वारा कैप्चर की गई कोई भी डेटा संरचना, जिन्हें व्यवसाय मॉडलिंग टूल में संदर्भित किया जा सकता है ताकि आपके व्यवसाय मॉडल आरेख या आपकी व्यवसाय प्रक्रिया आरेख में भी, आप अलग-अलग डेटा स्टोर का संदर्भ ले सकते हैं यदि आप बाहर जाना चाहते हैं डेटा मॉडलिंग वातावरण, और जब आप उन्हें अपने व्यवसाय प्रक्रिया मॉडल में फ़ोल्डरों में उपयोग कर रहे हैं, तो आप उन लोगों पर भी CRUD निर्दिष्ट कर सकते हैं, साथ ही यह भी कि कैसे जानकारी का उपभोग या उत्पादन किया जाता है, और फिर हम उत्पन्न करना शुरू कर सकते हैं प्रभाव और विश्लेषण रिपोर्ट और आरेख जैसी चीजें।

हम क्या करने के लिए लक्ष्य कर रहे हैं, और हमारे पास पहले से ही बहुत सारी क्षमताएं हैं, लेकिन उनमें से एक चीज़ जो हमारे पास है वह एक तरह की गोलपोस्ट है जिसे हम देख रहे हैं, जैसा कि हम अपने उपकरणों को आगे बढ़ाना जारी रखते हैं, उस अंत-टू-एंड, संगठनात्मक डेटा वंश और डेटा के पूर्ण जीवन चक्र को मैप करने में सक्षम हो रहा है।

मैल्कम चिशोल्म: ठीक है। रेबेका, क्या मुझे एक और की अनुमति है?

रेबेका जोजवाक: मैं आपको एक और अनुमति दूंगा, मैल्कम, आगे बढ़ो।

मैल्कम चिशोल्म: बहुत बहुत धन्यवाद। डेटा शासन के बारे में और डेटा मॉडलिंग के बारे में सोचकर, हम उन दो समूहों को प्रभावी रूप से एक साथ काम करने और एक दूसरे को समझने के लिए कैसे प्राप्त करते हैं?

एरिक लिटिल: वैसे यह दिलचस्प है, मुझे लगता है कि यह वास्तव में संगठन पर निर्भर करता है, और यह मेरे पहले की अवधारणा पर वापस जाता है, उन संगठनों में जहां व्यवसाय संचालित किए गए थे हम सही में बंधे हुए थे। उदाहरण के लिए, मैं एक डेटा आर्किटेक्चर टीम का नेतृत्व कर रहा था लेकिन हम। व्यवसाय उपयोगकर्ताओं के साथ सही तरीके से बंधे थे और हम वास्तव में उनके डेटा गवर्नेंस प्रोग्राम को खड़ा करने में उनकी मदद कर रहे थे। फिर से, एक परामर्शी दृष्टिकोण का अधिक लेकिन यह वास्तव में एक व्यावसायिक कार्य है।

आपको वास्तव में ऐसा करने में सक्षम होने की आवश्यकता है जो आपको डेटा मॉडलर और आर्किटेक्ट की आवश्यकता है जो वास्तव में व्यापार को समझते हैं, व्यापार उपयोगकर्ताओं से संबंधित हो सकते हैं और फिर उन्हें इसके चारों ओर शासन प्रक्रियाओं को खड़ा करने में मदद की है। व्यवसाय इसे करना चाहता है, लेकिन आम तौर पर बोलना हमारे पास तकनीकी ज्ञान है जो उन प्रकार के कार्यक्रमों को खड़ा करने में उनकी मदद करने में सक्षम है। यह वास्तव में एक सहयोग होना चाहिए, लेकिन इसके लिए व्यवसाय के स्वामित्व की आवश्यकता है।

मैल्कम चिशोल्म: ठीक है, यह बहुत अच्छा है। धन्यवाद।

डॉ। एरिक लिटिल: ठीक है।

रेबेका जोजवाक: ठीक है, बहुत बहुत धन्यवाद। श्रोतागण, मुझे डर है कि हम आपके प्रश्नों के लिए नहीं आए, लेकिन मैं यह सुनिश्चित करूँगा कि वे उस उपयुक्त अतिथि को अग्रेषित करें जो आज हम लाइन पर थे। मैं आज हमारे मेहमान होने के लिए एरिक, मैल्कम और रॉन को बहुत-बहुत धन्यवाद देना चाहता हूं। यह बहुत अच्छा सामान था, दोस्तों। और अगर आपको आज के IDERA वेबकास्ट में मज़ा आया, तो IDERA भी अगले बुधवार को हॉट टेक्नोलॉजीज पर होने वाला है, अगर आप इसमें शामिल होना चाहते हैं, तो इंडेक्सिंग और ओरेकल की चुनौतियों पर चर्चा करना, इसलिए एक और आकर्षक विषय है।

बहुत बहुत धन्यवाद, दोस्तों, ध्यान रखना, और हम आपको अगली बार देखेंगे। अलविदा।