بيت قواعد بيانات بناء بنية بيانات يحركها العمل

بناء بنية بيانات يحركها العمل

Anonim

بواسطة Techopedia Staff ، 28 سبتمبر 2016

الوجبات الجاهزة: يناقش المضيف ريبيكا جوزويك حلول هندسة البيانات مع إريك ليتل من OSTHUS ومالكولم تشيشولم من فيرست سان فرانسيسكو بارتنرز ورون هويزنجا من IDERA.

أنت لم تسجل الدخول حاليًا. يرجى تسجيل الدخول أو التسجيل لمشاهدة الفيديو.

ريبيكا جوزويك: سيداتي وسادتي ، مرحبًا بكم في Hot Technologies لعام 2016. نناقش اليوم "بناء بنية بيانات يحركها رجال الأعمال" ، وهو بالتأكيد موضوع ساخن. اسمي ريبيكا جوزويك ، سأكون مضيفك للبث على شبكة الإنترنت اليوم. نقوم بالتغريد باستخدام علامة تصنيف # HotTech16 ، لذلك إذا كنت في Twitter بالفعل ، فلا تتردد في الانضمام إليها أيضًا. إذا كانت لديك أسئلة في أي وقت ، فيرجى إرسالها إلى جزء الأسئلة والأجوبة في أسفل يمين الشاشة وسنتأكد من الرد عليها. إذا لم يكن الأمر كذلك ، فسنتأكد من أن ضيوفنا سيحصلون عليها من أجلك.

حتى اليوم لدينا تشكيلة رائعة حقًا. الكثير من الضاربون الثقيلة معنا اليوم. لدينا إريك ليتل ، نائب رئيس علم البيانات من OSTHUS. لدينا مالكولم تشيشولم ، كبير مسؤولي الابتكار ، وهو لقب رائع حقًا ، لفيرست سان فرانسيسكو بارتنرز. ولدينا Ron Huizenga ، كبير مديري المنتجات من IDERA. وكما تعلم ، فإن IDERA هي مجموعة كاملة من حلول إدارة البيانات والنمذجة. واليوم سوف يقدم لنا عرضًا حول كيفية عمل حله. ولكن قبل أن نصل إلى ذلك ، إيريك ليتل ، سأقوم بتمرير الكرة إليك.

إريك ليتل: حسنًا ، شكرًا جزيلًا. لذلك سوف أتطرق إلى موضوعين هنا أعتقد أنهما سيتعلقان بمحادثة رون قليلاً ونأمل أن يمهد الطريق لبعض هذه الموضوعات أيضًا ، بعض الأسئلة والأجوبة.

لذا فإن الشيء الذي أثار اهتمامي بما تفعله IDERA هو أنني أعتقد أنها تشير بشكل صحيح إلى أن البيئات المعقدة تقود فعليًا الكثير من قيم الأعمال في الوقت الحاضر. وفي البيئات المعقدة نعني بيئات البيانات المعقدة. التكنولوجيا تتحرك بسرعة كبيرة ومن الصعب مواكبة بيئة الأعمال اليوم. لذلك سوف يرى هؤلاء الأشخاص الذين يعملون في مساحات التكنولوجيا غالبًا أن لديك عملاء يعالجون المشكلات ، "كيف يمكنني استخدام البيانات الضخمة؟ كيف يمكنني دمج دلالات؟ كيف أقوم بربط بعض هذه الأشياء الجديدة ببياناتي القديمة؟ "وما إلى ذلك ، وهذا النوع من يقودنا في الوقت الحاضر إلى البيانات الأربع الكبيرة هذه التي يعرفها الكثير من الناس ، وأفهم أنه يمكن أن يكون هناك أكثر من أربعة في بعض الأحيان - رأيت ما يصل إلى ثمانية أو تسعة - ولكن عادةً ، عندما يتحدث الناس عن أشياء مثل البيانات الضخمة أو إذا كنت تتحدث عن بيانات كبيرة ، فأنت عادةً ما تبحث عن شيء من نوع المؤسسة. وهكذا سيقول الناس ، حسناً ، حسناً ، فكروا في حجم بياناتك ، وهو عادة ما يكون التركيز - هذا هو بالضبط ما لديك. تتعلق سرعة البيانات إما بالسرعة التي يمكنني بها نقلها أو مدى السرعة التي يمكنني الاستعلام عنها أو الحصول على الإجابات ، وما إلى ذلك. وأنا شخصياً أعتقد أن الجانب الأيسر من ذلك هو شيء يتم حله والتعامل معه بسرعة نسبية من خلال الكثير من الأساليب المختلفة. لكن على الجانب الأيمن ، أرى الكثير من القدرة على التحسين والكثير من التقنيات الجديدة التي تأتي بالفعل إلى المقدمة. ويتعلق الأمر حقًا بالعمود الثالث ، مجموعة البيانات.

بمعنى آخر ، فإن معظم الشركات تبحث في الوقت الحاضر عن بيانات منظمة وشبه منظمة وغير منظمة. لقد أصبحت بيانات الصور موضوعًا ساخنًا ، بحيث تكون قادرًا على استخدام رؤية الكمبيوتر ، والنظر إلى البيكسلات ، والقدرة على كشط النص ، و البرمجة اللغوية العصبية ، واستخراج الكيان ، لديك معلومات بيانية تخرج عن النماذج الإحصائية أو التي تخرج عن الدلالات النماذج ، لديك بيانات علائقية موجودة في الجداول ، وهكذا. وهكذا ، فإن جمع كل هذه البيانات معًا وجميع هذه الأنواع المختلفة يمثل تحديًا كبيرًا وستجد هذا في ، كما تعلمون ، في Gartner وغيرهم من الأشخاص الذين يتابعون الاتجاهات في الصناعة.

ثم إن الشيء الأخير الذي يتحدث عنه الناس في البيانات الضخمة غالبًا ما يكون هذا المفهوم من البراعة ، وهو حقًا عدم اليقين في البيانات الخاصة بك ، أو غموضها. إلى أي مدى تعرف جيدًا ما تدور حوله بياناتك ، وكيف تفهم جيدًا ما الذي يوجد هناك ، كما تعلم؟ إن القدرة على استخدام الإحصاءات والقدرة على استخدام نوع من المعلومات حول ما قد تعرفه أو استخدام بعض السياق ، يمكن أن تكون ذات قيمة هناك. وبالتالي القدرة على الاطلاع على البيانات بهذه الطريقة من حيث مقدار ما لديك ، ومدى السرعة التي تحتاجها لنقلها أو الحصول عليها ، وجميع أنواع البيانات التي قد تكون في مؤسستك ، ومدى يقينك حول المكان هو ، ما هو عليه ، ما هي الجودة فيه ، وهلم جرا. يتطلب ذلك حقًا جهدًا كبيرًا ومنسقًا الآن بين الكثير من الأفراد لإدارة بياناتهم بشكل فعال. نموذج البيانات ، لذلك ، أهمية متزايدة في عالم اليوم. تحظى نماذج البيانات الجيدة بالفعل بالكثير من النجاح في تطبيقات المؤسسات.

لديك مصادر بيانات من مجموعة متنوعة من المصادر ، كما كنا نقول ، والتي تتطلب الكثير من أنواع التكامل المختلفة. لذا ، فإن جمعها معًا أمر مفيد حقًا لتكون قادرًا على تشغيل الاستعلامات ، على سبيل المثال ، عبر أنواع عديدة من مصادر البيانات ، وسحب المعلومات مرة أخرى. ولكن من أجل القيام بذلك ، فإنك تحتاج إلى استراتيجيات جيدة لرسم الخرائط ، لذا فإن تعيين هذه الأنواع من البيانات ومتابعة تلك التعيينات يمكن أن يمثل تحديًا حقيقيًا. ثم لديك هذه المشكلة ، كيف يمكنني ربط بياناتي القديمة بكل مصادر البيانات الجديدة هذه؟ لنفترض إذن أن لدي الرسم البياني ، فهل يمكنني أخذ جميع بياناتي العلائقية ووضعها في الرسم البياني؟ عادة ليست هذه فكرة جيدة. إذن كيف يمكن للأشخاص إدارة جميع أنواع نماذج البيانات هذه التي تحدث؟ يجب أن يتم تشغيل التحليل على الكثير من هذه الأنواع المختلفة من مصادر البيانات ومجموعاتها. لذا فإن الإجابات التي تأتي من هذا ، والإجابات التي يحتاجها الأشخاص لاتخاذ قرارات تجارية جيدة أمر بالغ الأهمية.

إذاً هذا لا يتعلق فقط ببناء التكنولوجيا من أجل التكنولوجيا ، إنه في الحقيقة ، ما الذي سأفعله ، ماذا يمكنني أن أفعل بها ، ما نوع التحليل الذي يمكنني إجراؤه ، والقدرة ، لذلك ، كما قلت بالفعل كان يتحدث عن ، لسحب هذه الأشياء معا ، لدمجها هو حقا ، من المهم حقا. ثم يعمل أحد هذه الأنواع من التحليلات على أشياء مثل البحث والاستعلام الموحد. هذا أصبح حقا لا بد منه. يجب أن تكون استعلاماتك مترابطة عادةً عبر أنواع متعددة من المصادر وأن تسحب المعلومات مرة أخرى بشكل موثوق.

إن العنصر الرئيسي الذي غالبًا ما يبحث الناس في الأشياء الرئيسية مثل التقنيات الدلالية - وهذا أمر آمل أن يتحدث عنه رون قليلاً في منهج IDERA - هو كيفية فصلك أو إدارته طبقة نموذجية لبياناتك من طبقة البيانات نفسها ، من تلك البيانات الأولية؟ لذلك في قاعدة البيانات قد يكون لديك قواعد بيانات ، قد يكون لديك بيانات وثيقة ، قد يكون لديك بيانات جدول بيانات ، قد يكون لديك بيانات صورة. إذا كنت في مجالات مثل الصناعات الدوائية ، فستحصل على كميات هائلة من البيانات العلمية. ثم فوق هذا الأشخاص عادةً يبحثون عن طريقة لبناء نموذج يسمح لهم بدمج تلك البيانات بسرعة ، وحين تبحث عن البيانات الآن ، فأنت لا تبحث عن سحب جميع البيانات إلى طبقة نموذجك ، ما تبحثه في طبقة النموذج الذي يجب القيام به هو إعطائك تمثيلًا منطقيًا جيدًا لماهية الأشياء ، والمفردات الشائعة ، والأنواع الشائعة من الكيانات والعلاقات ، والقدرة على الوصول حقًا إلى البيانات في مكانها. لذلك عليه أن يقول ما هو عليه ، ويجب أن يقول أين هو ، ويجب أن يقول كيفية الذهاب لإحضاره وإعادته.

لذا فقد كان هذا النهج ناجحًا جدًا في دفع التقنيات الدلالية إلى الأمام ، وهو مجال أعمل فيه كثيرًا. لذا فإن السؤال الذي أردت طرحه على رون ، وأعتقد أنه سيكون مفيدًا في قسم الأسئلة والأجوبة ، هو معرفة كيف يتم تحقيق ذلك من خلال منصة IDERA؟ فهل طبقة النموذج منفصلة بالفعل عن طبقة البيانات؟ هل هم أكثر تكاملا؟ كيف يعمل ذلك وما هي بعض النتائج والفوائد التي يراها من مقاربتهم؟ لذلك أصبحت البيانات المرجعية مهمة بالفعل أيضًا. لذلك إذا كان لديك أنواع النماذج هذه ، إذا كنت ستتمكن من الاتحاد والبحث في الأشياء ، فعليك امتلاك بيانات مرجعية جيدة. ولكن المشكلة هي أن البيانات المرجعية يمكن أن يكون من الصعب الحفاظ عليها. في كثير من الأحيان تسمية المعايير في حد ذاتها تشكل تحديا صعبا. ستتصل مجموعة واحدة بشيء X وستتصل مجموعة واحدة بشيء Y والآن تواجهك مشكلة كيف يجد شخص ما X و Y عندما يبحث عن هذا النوع من المعلومات؟ لأنك لا ترغب فقط في منحهم جزءًا من البيانات ، فأنت ترغب في منحهم كل ما يتعلق بهم. في نفس الوقت تتغير الشروط ، يصبح البرنامج مهملاً ، وهكذا ، كيف يمكنك الحفاظ على البيانات المرجعية والحفاظ عليها مع مرور الوقت؟

ومرة أخرى ، فإن التقنيات الدلالية ، وبالأخص استخدام أشياء مثل التصنيفات والمفردات وقواميس البيانات ، قد وفرت طريقة مساحة قياسية للقيام بذلك ، وهي قوية للغاية حقًا ، وتستخدم أنواعًا معينة من المعايير ، لكن مجتمع قاعدة البيانات قام بذلك وقت طويل كذلك ، فقط بطرق مختلفة. أعتقد أن أحد المفاتيح هنا هو التفكير في كيفية استخدام نماذج لعلاقة الكيان ، أو ربما استخدام نماذج الرسوم البيانية أو نوع من النهج هنا الذي يمنحك حقًا طريقة متباعدة قياسية للتعامل مع بياناتك المرجعية. وبعد ذلك بالطبع بمجرد حصولك على البيانات المرجعية ، يتعين على استراتيجيات التعيين إدارة مجموعة واسعة من الأسماء والكيانات. لذلك غالباً ما يحب خبراء الموضوعات استخدام مصطلحاتهم الخاصة.

لذا فإن التحدي في هذا الأمر دائمًا هو كيف يمكنك تقديم معلومات لشخص ما ولكن تجعله ذا صلة بالطريقة التي يتحدثون عنها؟ لذلك قد يكون لدى إحدى المجموعات طريقة واحدة للنظر إلى شيء ما ، على سبيل المثال ، قد تكون كيميائيًا يعمل على دواء ، وقد تكون عالِم بيولوجي هيكلي يعمل على نفس الدواء ، وقد يكون لديك أسماء مختلفة لنفس الأنواع من الكيانات التي تتصل مجال عملك. يجب عليك معرفة طرق الجمع بين هذه المصطلحات المخصصة ، نظرًا لأن النهج الآخر هو ، عليك إجبار الناس على التخلي عن مصطلحاتهم واستخدام شخص آخر ، وهو ما لا يحبونه في الغالب. هناك نقطة أخرى هنا تتمثل في التعامل مع أعداد كبيرة من المرادفات ، لذا فإن هناك الكثير من الكلمات المختلفة في بيانات العديد من الأشخاص يمكن أن تشير إلى نفس الشيء. لديك مشكلة مرجعية هناك باستخدام مجموعة علاقات متعددة. تختلف المصطلحات المتخصصة من صناعة إلى أخرى ، لذا إذا كنت ستخرج بنوع من الحلول الشاملة لهذا النوع من إدارة البيانات ، ما مدى سهولة انتقاله من مشروع أو تطبيق إلى آخر؟ يمكن أن يكون تحديا آخر.

الأتمتة مهمة وهي أيضًا تحدٍ. يعد التعامل مع البيانات المرجعية يدويًا مكلفًا. من المكلف الاحتفاظ بالتعيين يدويًا ومن المكلف إيقاف خبراء الموضوعات عن أداء مهامهم اليومية وتوجيه مهام قواميس البيانات باستمرار وإعادة تحديث التعريفات وما إلى ذلك ، وهكذا دواليك. المفردات القابلة للنسخ تظهر حقًا الكثير من القيمة. هذه هي المفردات في كثير من الأحيان التي يمكنك أن تجد خارج لمؤسستك. إذا كنت تعمل في مجال النفط الخام ، على سبيل المثال ، سيكون هناك أنواع معينة من المفردات التي يمكنك الاقتراض من مساحات مفتوحة المصدر ، وكذلك مع المستحضرات الصيدلانية ، وكذلك مع القطاع المصرفي والمالي ، مع الكثير من هذه الأنواع من المجالات. يضع الناس مفردات قابلة لإعادة الاستخدام وعامة وقابلة للتكرار لاستخدامها من قبل الناس.

ومرة أخرى ، عند النظر إلى أداة IDERA ، أشعر بالفضول لمعرفة كيفية تعاملهم مع هذا فيما يتعلق باستخدام أنواع المعايير. في عالم الدلالات ، غالبًا ما تشاهد أشياء مثل نماذج SKOS التي توفر معايير لما لا يقل عن / أضيق من العلاقات وتلك الأشياء قد يصعب القيام بها في نماذج ER ولكن ، كما تعلم ، ليس مستحيلًا ، يعتمد ذلك فقط على مقدار ذلك الآلات والتي تربط التي يمكنك التعامل معها في هذه الأنواع من النظم.

أخيرًا ، أردت فقط إجراء مقارنة بين بعض المحركات الدلالية التي أراها في الصناعة ، ونوعًا ما أسأل رون وأتحدث معه قليلاً للحديث عن كيفية استخدام نظام IDERA بالتزامن مع أي تقنيات الدلالية. هل هي قادرة على أن تكون متكاملة مع مخازن ثلاثية ، وقواعد البيانات الرسم البياني؟ ما مدى سهولة استخدام المصادر الخارجية لأن هذه الأنواع من الأشياء في العالم الدلالي يمكن استعارتها باستخدام نقاط SPARQL النهاية؟ يمكنك استيراد نماذج RDF أو OWL مباشرة إلى النموذج الخاص بك - الرجوع إليها - لذلك ، على سبيل المثال ، علم الجينات أو علم البروتين ، الذي يمكن أن يعيش في مكان ما في مساحته الخاصة به مع هيكل الإدارة الخاص به ، ويمكنني ببساطة استيراد الكل أو جزء من ذلك كما أحتاجه في النماذج الخاصة بي. وأنا فضولي لمعرفة كيفية تعامل IDERA مع هذه المشكلة. هل لديك للحفاظ على كل شيء داخليا ، أو هل هناك طرق للذهاب إلى استخدام أنواع أخرى من النماذج الموحدة وسحبها وكيف يعمل ذلك؟ والشيء الأخير الذي ذكرته هنا هو مقدار العمل اليدوي الذي ينطوي عليه الأمر بالفعل لإنشاء المسارد ومستودعات البيانات الوصفية؟

لذلك أعرف أن رون سوف يعرض لنا بعض العروض حول هذه الأنواع من الأشياء التي ستكون مثيرة للاهتمام حقًا. لكن المشاكل التي كثيراً ما أراها تتشاور مع العملاء هي أن الكثير من الأخطاء تحدث إذا كان الناس يكتبون في تعريفاتهم الخاصة أو بيانات التعريف الخاصة بهم. إذاً لديك أخطاء إملائية ، وأخطاء في الإصبع ، هذا شيء واحد. يمكنك أيضًا الحصول على أشخاص قد يأخذون شيئًا من ، كما تعلمون ، مجرد ويكيبيديا أو مصدرًا ليس بالضرورة بالجودة التي قد تريدها في التعريف الخاص بك ، أو أن تعريفك هو فقط من منظور شخص واحد لذلك فهو غير كامل ، ومن غير الواضح بعد ذلك كيف تعمل عملية الحوكمة. الحوكمة ، بالطبع ، كونها مشكلة كبيرة جدًا في أي وقت تتحدث فيه عن البيانات المرجعية وأي وقت تتحدث فيه عن مدى ملاءمته للبيانات الرئيسية الخاصة بشخص ما ، وكيف سيستخدمون بيانات التعريف الخاصة بهم ، و هكذا.

لذلك أردت فقط أن أضع بعض هذه المواضيع هناك. هذه هي العناصر التي أراها في مساحة العمل عبر العديد من الأنواع المختلفة من التعاقدات الاستشارية والعديد من المساحات المختلفة ، وأنا مهتم حقًا برؤية ما سوف يعرضه رون لنا مع IDERA للإشارة إلى بعض هذه المواضيع . شكرا جزيلا.

ريبيكا جوزويك: شكرًا جزيلاً ، إريك وأنا معجب بتعليقك على أن العديد من الأخطاء يمكن أن تحدث إذا كان الناس يكتبون تعاريفهم أو بياناتهم التعريفية. أعلم في عالم الصحافة أن هناك تعويذة مفادها أن "العديد من العيون ترتكب القليل من الأخطاء" ، لكن عندما يتعلق الأمر بالتطبيقات العملية ، فإن الكثير من الأيدي في جرة ملفات تعريف الارتباط تميل إلى تركك مع الكثير من ملفات تعريف الارتباط المعطلة ، أليس كذلك؟

إريك ليتل: نعم ، والجراثيم.

ريبيكا جوزويك: نعم. مع ذلك سأذهب إلى الأمام وأمره إلى مالكولم تشيشولم. مالكولم ، الكلمة لك.

مالكولم تشيشولم: شكرًا جزيلاً ، ريبيكا. أرغب في إلقاء نظرة سريعة على ما يتحدث عنه إريك ، وإضافة إلى ذلك ، بعض الملاحظات القليلة التي ، كما تعلمون ، قد يهتم رون بالرد عليها أيضًا ، في الحديث عن "نحو بنية بيانات تستند إلى الأعمال" "- ماذا يعني أن تكون مدفوعة بالعمل ولماذا هذا مهم؟ أم أنها مجرد شكل من أشكال الضجيج؟ أنا لا أعتقد أنه هو.

إذا نظرنا إلى ما يجري منذ ذلك الحين ، كما تعلمون ، أصبحت أجهزة الكمبيوتر المركزية متاحة بالفعل للشركات - على سبيل المثال ، حوالي عام 1964 - حتى اليوم ، يمكننا أن نرى أنه كان هناك الكثير من التغييرات. وهذه التغييرات أود أن ألخصها بأنها تحول من مركزية العملية إلى مركزية البيانات. وهذا ما يجعل هياكل البيانات التي تعتمد على الأعمال مهمة جدًا وذات صلة كبيرة لهذا اليوم. وأعتقد ، كما تعلمون ، أنها ليست مجرد كلمة طنانة ، إنها شيء حقيقي تمامًا.

لكننا نستطيع أن نقدر ذلك أكثر قليلاً إذا استطعنا الغوص في التاريخ ، لذلك عدنا إلى الوراء في الزمن ، ونعود إلى الستينيات ، ولبعض الوقت بعد ذلك ، سيطرت الحاسبات الكبيرة. ثم أفسح المجال أمام أجهزة الكمبيوتر الشخصية حيث كان لديك بالفعل تمرد من المستخدمين عندما دخلت أجهزة الكمبيوتر. التمرد ضد تكنولوجيا المعلومات المركزية ، الذين اعتقدوا أنهم لا يلبون احتياجاتهم ، لم تكن سريعة بما فيه الكفاية. وسرعان ما أدى ذلك إلى الحوسبة الموزعة ، عندما تم ربط أجهزة الكمبيوتر ببعضها. ثم بدأت شبكة الإنترنت تحدث ، الأمر الذي طمس حدود المؤسسة - فقد أصبح بإمكانها الآن التفاعل مع أطراف خارج نفسها من حيث تبادل البيانات ، وهو ما لم يحدث من قبل. والآن ، دخلنا في عصر السحابة والبيانات الضخمة حيث السحابة عبارة عن منصات تعمل فعليًا على إضفاء الطابع السلعي على البنية التحتية ، ولذا فإننا نترك ، كما كان ، الحاجة إلى تشغيل مراكز البيانات الضخمة لأننا ، كما تعلمون ، لدينا القدرة السحابية المتاحة لنا ، وما يصاحبها من تلك البيانات الضخمة التي ناقشها إريك ، كما تعلمون ، ببلاغة. وبشكل عام ، كما نرى ، نظرًا لتغير التكنولوجيا ، فقد أصبح أكثر تركيزًا على البيانات ، ونهتم أكثر بالبيانات. كما هو الحال مع الإنترنت ، كيف يتم تبادل البيانات. مع البيانات الكبيرة ، أربعة أو أكثر من البيانات نفسها.

في الوقت نفسه ، وربما الأهم من ذلك ، تحولت حالات استخدام الأعمال. عندما تم تقديم أجهزة الكمبيوتر لأول مرة ، كانت تستخدم لأتمتة أشياء مثل الكتب والسجلات. وأي شيء كان عملية يدوية ، والتي تنطوي على دفتر الأستاذ أو أشياء من هذا القبيل ، كانت مبرمجة ، في الأساس ، في المنزل. تحول ذلك في الثمانينات إلى توافر حزم التشغيل. لم تعد بحاجة إلى كتابة كشوف المرتبات الخاصة بك ، يمكنك شراء شيء فعله. وقد أدى ذلك إلى تقليص كبير الحجم في ذلك الوقت ، أو إعادة الهيكلة ، في العديد من أقسام تكنولوجيا المعلومات. ولكن بعد ذلك ظهرت ذكاء الأعمال ، مع أشياء مثل مستودعات البيانات ، معظمها في التسعينيات. تليها نماذج الأعمال الدوت كوم التي كانت ، بطبيعة الحال ، جنون كبير. ثم MDM. مع MDM تبدأ في رؤية أننا لا نفكر في الأتمتة ؛ نحن فقط نركز في الواقع على تنسيق البيانات كبيانات. ثم التحليلات ، والتي تمثل القيمة التي يمكنك الحصول عليها من البيانات. وضمن التحليلات ، ترى الشركات الناجحة للغاية التي يدور نموذج أعمالها الأساسي حول البيانات. ستكون Google و Twitter و Facebook جزءًا من ذلك ، ولكن يمكنك القول أيضًا أن Walmart.

وبالتالي فإن العمل الآن يفكر حقًا في البيانات. كيف يمكننا الحصول على قيمة من البيانات؟ كيف يمكن للبيانات أن تقود العمل والاستراتيجية ، ونحن في عصر البيانات الذهبي. إذاً بالنظر إلى ذلك ، ما الذي يحدث فيما يتعلق بهيكل البيانات الخاص بنا ، إذا لم تعد البيانات تعتبر مجرد العادم الذي يخرج من النهاية الخلفية للتطبيقات ، ولكن هل هو حقًا أساسي لنماذج أعمالنا؟ حسنًا ، جزء من المشكلة التي نواجهها في تحقيق ذلك هو أن تكنولوجيا المعلومات عالقة حقًا في الماضي مع دورة حياة تطوير الأنظمة التي كانت نتيجة الاضطرار إلى التعامل بسرعة مع مرحلة أتمتة العملية في سن مبكرة من تكنولوجيا المعلومات ، والعمل في المشاريع هي شيء مماثل. بالنسبة لتكنولوجيا المعلومات - وهذا نوع من الرسوم الكاريكاتورية قليلاً - لكن ما أحاول قوله هو أن بعض العوائق التي تحول دون الحصول على بنية بيانات تستند إلى الأعمال التجارية هي لأننا ، نوعًا ما ، قبلنا ثقافة في تكنولوجيا المعلومات وهو مستمد من عصر مضى.

لذلك كل شيء مشروع. قل لي الاحتياجات الخاصة بك بالتفصيل. إذا لم تعمل الأشياء ، فذلك لأنك لم تخبرني بمتطلباتك. حسنًا ، لا يعمل اليوم مع البيانات لأننا لا نبدأ بالعمليات اليدوية غير المؤتمتة أو ، كما تعلم ، تحويل تقني للعمليات التجارية ، نبدأ كثيرًا ببيانات الإنتاج الموجودة بالفعل التي نحاولها للحصول على قيمة من. لكن لا أحد يفهم مشروعًا يرتكز على البيانات يفهم حقًا تلك البيانات بعمق. علينا أن نفعل اكتشاف البيانات ، علينا أن نفعل تحليل البيانات المصدر. وهذا لا يتطابق حقًا مع تطوير النظم ، كما تعلمون - الشلال ، دورة حياة SDLC - التي أوافق عليها Agile ، هي نوع من نسخة أفضل من ذلك.

وما يتم التركيز عليه هو التكنولوجيا والوظائف ، وليس البيانات. على سبيل المثال ، عندما نجري اختبارًا في مرحلة اختبار ، عادةً ، هل تعمل وظيفتي ، دعنا نقول ETL ، لكننا لا نختبر البيانات. نحن لا نختبر افتراضاتنا حول البيانات المصدر الواردة. إذا فعلنا ذلك ، فسنكون في وضع أفضل وكشخص قام بمشروعات مستودع البيانات وعانى من خلال التغييرات الأولية ، وخرق ETLs ، سأكون ممتناً لذلك. وفي الحقيقة ، ما نريد أن نراه هو الاختبار كخطوة أولية للمراقبة المستمرة لجودة بيانات الإنتاج. لذلك لدينا هنا الكثير من المواقف حيث من الصعب تحقيق بنية البيانات التي تحركها الأعمال لأننا مشروطون بعصر مركزية العملية. نحن بحاجة إلى الانتقال إلى مركزية البيانات. وهذا ليس انتقالًا تامًا ، كما تعلمون ، لا يزال هناك الكثير من العمل الذي يجب القيام به هناك ، لكننا لا نفكر حقًا في المصطلحات التي تركز على البيانات عندما نحتاج إلى ذلك ، والظروف التي تحدث عندما نكون حقًا مجبر على القيام بذلك.

الآن يدرك رجال الأعمال قيمة البيانات ، فهم يريدون إلغاء قفل البيانات ، فكيف سنفعل ذلك؟ فكيف نفعل الانتقال؟ حسنًا ، نضع البيانات في قلب عمليات التطوير. وندع العمل يؤدي بمتطلبات المعلومات. ونحن نفهم أن لا أحد يفهم بيانات المصدر الموجودة في بداية المشروع. يمكنك القول أن بنية البيانات والبيانات نفسها وصلت إلى هناك من خلال تكنولوجيا المعلومات والعمليات ، على التوالي ، لذلك يجب أن نعرف ذلك ، لكن في الحقيقة ، نحن لا نعرف ذلك. هذا هو تطوير البيانات. لذلك يتعين علينا ، عند التفكير في أين نحن وكيف نفعل نمذجة البيانات في عالم يركز على البيانات ، علينا أن نوفر حلقات تغذية مرتدة للمستخدمين فيما يتعلق بتحسين متطلبات المعلومات الخاصة بهم ، كما نفعل اكتشاف البيانات وتصنيف البيانات ، نتوقع تحليل البيانات المصدر ، ونحن تدريجيا الحصول على المزيد والمزيد من اليقين حول البيانات لدينا. والآن أتحدث عن مشروع أكثر تقليدية مثل محور MDM أو مستودع بيانات ، وليس بالضرورة مشاريع البيانات الكبيرة ، على الرغم من أن هذا لا يزال ، مع ذلك ، أقترب من ذلك إلى حد ما. ومن ثم ، فإن حلقات التعليقات هذه تشمل مصممي البيانات ، كما تعلمون ، على تطوير نموذج البيانات الخاص بهم تدريجياً والتفاعل مع المستخدمين للتأكد من أن متطلبات المعلومات قد تم تنقيحها بناءً على ما هو ممكن ، وما هو متاح ، من البيانات المصدر عندما يفهمونها بشكل أفضل ، لذلك لم يعد الأمر كذلك في حالة وجود نموذج بيانات ، كما تعلمون ، في حالة إما غير موجودة أو كاملة ، فهي تدريجيًا تركز عليه.

وبالمثل ، لدينا مزيد من المعلومات النهائية لضمان الجودة حيث نقوم بتطوير قواعد لاختبار جودة البيانات للتأكد من أن البيانات ضمن المعلمات التي نفترض عنها. الآن ، كان Eric يشير إلى التغييرات في البيانات المرجعية ، والتي قد تحدث. لا تريد أن تكون ، كما كان الحال ، ضحية لمرور ما ، من نوع ما ، التغيير غير المُدار في هذا المجال ، بحيث يمكن لقواعد ضمان الجودة أن تدخل في مرحلة ما بعد الإنتاج ، ومراقبة جودة البيانات المستمرة. لذلك يمكنك أن تبدأ في معرفة ما إذا كنا سنركز على البيانات ، وكيف نفعل التطوير الذي يركز على البيانات يختلف تمامًا عن SDLC و Agile القائم على الوظائف. ثم علينا أن نولي اهتماما لآراء العمل كذلك. لدينا - ومرة ​​أخرى هذا يردد ما كان يقوله إريك - لدينا نموذج بيانات يحدد مخطط قصة البيانات لقاعدة البيانات الخاصة بنا ، ولكن في الوقت نفسه نحن بحاجة إلى تلك النماذج المفاهيمية ، وجهات نظر الأعمال التجارية للبيانات التي لم يتم تنفيذها في العادة الماضي. في بعض الأحيان ، أعتقد أن نموذج البيانات يمكن أن يفعل كل شيء ، لكننا بحاجة إلى الحصول على وجهة نظر مفاهيمية ، ودلالات ، والنظر في البيانات ، وجعلها من خلال طبقة تجريدية تترجم نموذج التخزين إلى عمل رأي. ومرة أخرى ، فإن كل الأشياء التي تحدث عنها إريك من حيث الدلالات ، تصبح مهمة للقيام بذلك ، لذلك لدينا بالفعل مهام إضافية للنمذجة. أعتقد أن هذا ، كما تعلمون ، مثير للاهتمام إذا صعدت إلى صفوف مصمم الأزياء مثلما فعلت ، ومرة ​​أخرى ، شيء جديد.

وأخيرا أود أن أقول إن العمارة الأكبر يجب أن تعكس هذا الواقع الجديد. على سبيل المثال ، العميل التقليدي MDM ، نوعًا ما ، حسناً ، دعنا ننقل بيانات عملائنا إلى مركز حيث يمكننا ، كما تعلمون ، فهمها من حيث جودة البيانات فقط لتطبيقات المكاتب الخلفية. وهو من وجهة نظر استراتيجية العمل هو نوع من التثاؤب. ومع ذلك ، فإننا ننظر اليوم إلى مراكز MDM للعميل التي تحتوي على بيانات ملف تعريف العميل الإضافية فيها ، وليس فقط البيانات الثابتة ، والتي عندها تتمتع بواجهة ثنائية الاتجاه مع تطبيقات المعاملات الخاصة بالعميل. نعم ، لا يزالون يدعمون المكتب الخلفي ، لكننا نعرف الآن عن هذه السلوكيات لعملائنا أيضًا. هذا هو أكثر تكلفة للبناء. هذا هو أكثر تعقيدا للبناء. ولكنه يعتمد على الأعمال التجارية بطريقة لا يتبعها العميل التقليدي MDM. إنك تتداول في اتجاه موجه نحو العمل مقابل تصميمات أبسط يسهل تنفيذها ، ولكن بالنسبة إلى العمل ، هذا ما يريدون رؤيته. نحن حقًا في حقبة جديدة وأعتقد أن هناك عددًا من المستويات التي يجب أن نستجيب لها في بنية بيانات القيادة التجارية وأعتقد أنه وقت مثير للغاية للقيام بالأشياء.

شكراً لك ، رجوع إليك ريبيكا.

ريبيكا جوزويك: شكرًا Malcolm ، ولقد استمتعت حقًا بما قلته حول نماذج البيانات ، يجب أن تغذي وجهة نظر الأعمال ، لأنه ، على عكس ما كنت تقوله ، حيث يحتفظ IT بزمام الأمور لفترة طويلة ولم يعد الأمر كذلك ، أن الثقافة لا تحتاج إلى التحول. وأنا متأكد من وجود كلب في الخلفية وافق معك 100٪. ومع ذلك سأمرر الكرة إلى رون. أنا متحمس جدا لرؤية التجريبي الخاص بك. رون ، الكلمة لك.

رون هويزنجا: شكرًا جزيلاً وقبل أن ننتقل إلى ذلك ، سأخوض بعض الشرائح ثم قليلاً من العرض التوضيحي ، كما أشار إريك ومالكولم ، هذا موضوع واسع وعميق للغاية ، و مع ما نتحدث عنه اليوم ، نحن فقط نلغي سطحه لأن هناك العديد من الجوانب والكثير من الأشياء التي نحتاج إليها حقًا في النظر والنظر من بنية تعتمد على الأعمال. يتمثل نهجنا في جعل تلك النماذج قائمة على أساس حقيقي واستخلاص القيمة الحقيقية من النماذج لأنه يمكنك استخدامها كوسيلة اتصال وكذلك طبقة لتمكين الأنظمة الأخرى. سواء كنت تقوم بهندسة موجهة نحو الخدمة ، أو أشياء أخرى ، فإن هذا النموذج يصبح حقًا شريان الحياة لما يجري ، مع جميع البيانات التعريفية المحيطة به والبيانات الموجودة في عملك.

ما أريد أن أتحدث عنه ، مع ذلك ، هو أخذ هذه الخطوة إلى الوراء تقريبًا ، لأن Malcolm قد تطرقت إلى بعض من تاريخ الطريقة التي تطورت بها الحلول وهذا النوع من الأشياء. تتمثل إحدى الطرق لتوضيح مدى أهمية وجود بنية بيانات سليمة في حالة الاستخدام التي اعتدت أن أواجهها كثيرًا عندما كنت أستشير قبل أن أتولى دورًا في إدارة المنتج ، وهذا كان ، سأذهب إلى المؤسسات سواء كانوا يقومون بتحويل الأعمال أو مجرد استبدال بعض الأنظمة الحالية وهذا النوع من الأشياء ، وأصبح من الواضح بسرعة كبيرة كيف تفهم المؤسسات الضعيفة بياناتها الخاصة. إذا كنت تأخذ حالة استخدام معينة مثل هذه الحالة ، سواء كنت خبيرًا استشاريًا أو ربما يكون شخصًا قد بدأ لتوه مع مؤسسة أو تم بناء مؤسستك على مدار السنوات من خلال الاستحواذ على شركات مختلفة ، ما الذي تنتهي به تعد up with بيئة معقدة للغاية بسرعة كبيرة ، مع عدد من التقنيات المختلفة الجديدة ، بالإضافة إلى التكنولوجيا القديمة وحلول ERP وكل شيء آخر.

لذا فإن أحد الأشياء التي يمكننا فعلها حقًا باستخدام منهجنا للنمذجة هو الإجابة على سؤال ، كيف أفهم كل هذا؟ يمكننا حقًا البدء في تجميع المعلومات معًا ، بحيث يمكن لرجال الأعمال الاستفادة من المعلومات التي لدينا بشكل صحيح. ويأتي إلى ما الذي يوجد لدينا في تلك البيئات؟ كيف يمكنني استخدام النماذج لطرد المعلومات التي أحتاجها وفهمها بشكل أفضل؟ ثم لدينا الأنواع التقليدية من البيانات الوصفية لجميع الأشياء المختلفة مثل نماذج البيانات العلائقية ، وقد اعتدنا على رؤية أشياء مثل التعاريف وقواميس البيانات ، كما تعلمون ، أنواع البيانات وهذا النوع من الأشياء. ولكن ماذا عن البيانات الوصفية الإضافية التي تريد التقاطها لإعطاء معنى أكبر لها؟ على سبيل المثال ، أي الكيانات هي بالفعل المرشحون الذين يجب أن يكونوا كائنات بيانات مرجعية ، والتي يجب أن تكون كائنات إدارة البيانات الرئيسية وأنواع الأشياء هذه وربطها معًا. وكيف تتدفق المعلومات عبر المنظمة؟ تتدفق البيانات من كيفية استهلاكها من كل من وجهة نظر العملية ، ولكن أيضًا من سلالة البيانات من حيث رحلة المعلومات من خلال أعمالنا وكيف يتم شق طريقها من خلال الأنظمة المختلفة ، أو من خلال مخازن البيانات ، لذلك نعرف عندما نبني الحلول I ، أو تلك الأنواع من الأشياء ، فإننا نستهلك بالفعل المعلومات الصحيحة للمهمة قيد البحث.

والأهم من ذلك هو كيف يمكننا أن نجعل جميع أصحاب المصلحة يتعاونون ، ولا سيما أصحاب المصلحة في الأعمال لأنهم هم الذين يعطوننا المعنى الحقيقي لماهية تلك البيانات. تمتلك الشركة ، في نهاية اليوم ، البيانات. إنها توفر تعريفات للمفردات والأشياء التي كان يتحدث عنها إريك ، لذلك نحن بحاجة إلى مكان لربط كل ذلك معًا. والطريقة التي نقوم بها هي من خلال نمذجة البيانات ومخازن مستودع البيانات الخاصة بنا.

سوف أتطرق إلى بعض الأشياء. سأتحدث عن ER / Studio Enterprise Team Edition. في المقام الأول سأتحدث عن منتج بنية البيانات حيث نقوم بنمذجة البيانات وهذا النوع من الأشياء ، ولكن هناك الكثير من المكونات الأخرى في المجموعة التي سأتطرق إليها لفترة وجيزة. سترى مقتطفًا واحدًا من Business Architect ، والذي يمكننا من خلاله القيام بنماذج مفاهيمية ، ولكن يمكننا أيضًا القيام بنماذج العمليات التجارية ويمكننا ربط نماذج العمليات هذه لربط البيانات الفعلية الموجودة في نماذج البيانات الخاصة بنا. إنها تساعدنا حقًا على الجمع بين هذه الروابط يسمح لنا Software Architect بالقيام ببنيات إضافية مثل بعض نماذج UML وتلك الأنواع من الأشياء لمنح المنطق المنطقي الداعم لبعض الأنظمة والعمليات الأخرى التي نتحدث عنها. ولكن من المهم جدًا أن نتحرك في المستودع وخادم الفريق ، ونحن نتحدث عن ذلك كنوعين من نفس الشيء. مستودع التخزين هو المكان الذي نخزن فيه جميع البيانات الوصفية النموذجية وكذلك جميع بيانات تعريف الأعمال من حيث مسرد المصطلحات وشروط العمل. ولأن لدينا هذه البيئة القائمة على المستودع ، يمكننا بعد ذلك تجميع كل هذه الأشياء المختلفة معًا في نفس البيئة وبعد ذلك يمكننا في الواقع إتاحة تلك الأشياء للاستهلاك ، ليس فقط للأشخاص التقنيين ولكن أيضًا لرجال الأعمال أيضًا. وهذه هي الطريقة التي نبدأ بها بالفعل في دفع التعاون.

ثم آخر قطعة سأتحدث عنها لفترة وجيزة هي ، عندما تمشي في هذه البيئات ، ليست مجرد قواعد البيانات الموجودة لديك. سيكون لديك عددًا من قواعد البيانات ومخازن البيانات ، وستحصل أيضًا على الكثير من الأعمال الفنية القديمة. ربما استخدم الناس Visio أو مخططات أخرى لرسم بعض الأشياء. ربما لديهم أدوات النمذجة الأخرى وهذا النوع من الأشياء. إذن ما يمكننا فعله باستخدام MetaWizard هو في الواقع استخراج بعض هذه المعلومات وإدخالها في النماذج الخاصة بنا ، وجعلها حديثة وتمكّن من استخدامها ، واستهلاكها ، بطريقة عصرية مرة أخرى ، بدلاً من مجرد الجلوس فيها. أصبح الآن جزءًا نشطًا من نماذج العمل لدينا ، وهو أمر مهم للغاية.

عندما تمشي في مؤسسة ، كما قلت ، هناك الكثير من الأنظمة المتباينة ، والكثير من حلول تخطيط موارد المؤسسات ، وحلول الأقسام غير متطابقة. تستخدم العديد من المؤسسات أيضًا حلول SaaS ، والتي يتم التحكم فيها وإدارتها خارجيًا ، لذلك لا نتحكم في قواعد البيانات وأنواع الأشياء الموجودة في المضيفين على تلك ، لكن لا نزال بحاجة إلى معرفة شكل هذه البيانات ، وبالطبع ، الفوقية حول ذلك. ما نجده أيضًا هو وجود الكثير من الأنظمة القديمة التي لم يتم تنظيفها بسبب هذا النهج القائم على المشاريع والذي تحدثت عنه مالكولم. إنه لأمر مدهش كيف ستقوم المؤسسات في السنوات الأخيرة بتطوير المشاريع ، وسوف تحل محل نظام أو حل ، ولكن في كثير من الأحيان لا توجد ميزانية كافية للمشروع لإيقاف تشغيل الحلول القديمة ، لذلك فهي الآن في الطريق. وعلينا أن نتعرف على ما يمكننا فعلاً التخلص منه في بيئتنا بالإضافة إلى ما هو مفيد للتقدم إلى الأمام. وهذا يرتبط باستراتيجية وقف التشغيل السيئة. هذا جزء لا يتجزأ من نفس الشيء.

ما نجده أيضًا ، نظرًا لأن العديد من المؤسسات قد تم بناؤه من كل هذه الحلول المختلفة ، هو أننا نرى الكثير من الواجهات من نقطة إلى نقطة مع الكثير من البيانات تتنقل في عدد من الأماكن. نحن بحاجة إلى أن نكون قادرين على ترشيد ذلك ومعرفة نسب البيانات التي ذكرتها بإيجاز من قبل ، حتى نتمكن من وضع استراتيجية أكثر تماسكًا مثل استخدام الهندسة الموجهة نحو الخدمات وحافلات خدمة المؤسسات وتلك الأنواع من الأشياء ، لتقديم المعلومات الصحيحة لنوع النشر والاشتراك في النموذج الذي نستخدمه بشكل صحيح في جميع أعمالنا. وبعد ذلك ، بالطبع ، ما زلنا بحاجة إلى إجراء نوع من التحليلات ، سواء كنا نستخدم مستودعات البيانات أو علامات البيانات مع ETL التقليدية أو نستخدم بعض بحيرات البيانات الجديدة. كل هذا يأتي إلى نفس الشيء. إنها جميع البيانات ، سواء كانت بيانات كبيرة ، أو ما إذا كانت بيانات تقليدية في قواعد البيانات الترابطية ، نحتاج إلى تجميع كل هذه البيانات معًا حتى نتمكن من إدارتها ومعرفة ما نتعامل معه عبر نماذجنا.

مرة أخرى ، التعقيد الذي سنفعله هو أن لدينا عددًا من الخطوات التي نريد أن نكون قادرين على القيام بها. بادئ ذي بدء ، أنت تمشي وقد لا يكون لديك تلك المخططات لما يبدو عليه مشهد المعلومات هذا. في أداة نمذجة البيانات ، مثل ER / Studio Data Architect ، ستقوم أولاً بالكثير من الهندسة العكسية من حيث دعونا نتحدث عن مصادر البيانات الموجودة هناك ، وقم بإحضارها ثم دمجها معًا في تمثيل أكثر النماذج التي تمثل العمل بأكمله. الشيء المهم هو ، أننا نريد أن نكون قادرين على تحليل هذه النماذج بالإضافة إلى خطوط العمل حتى نتمكن من ربطها بأجزاء أصغر ، والتي يمكن لرجال الأعمال أن يتصلوا بها ، وكذلك محللي أعمالنا وأصحاب المصلحة الآخرين الذين يعملون عليه.

تعتبر معايير التسمية مهمة للغاية وأنا أتحدث عنها بطريقتين مختلفتين هنا. تسمية المعايير من حيث كيفية تسمية الأشياء في نماذجنا. من السهل إلى حد ما القيام به في النماذج المنطقية ، حيث لدينا اصطلاح تسمية جيد وقاموس بيانات جيد لنماذجنا ، ولكن بعد ذلك أيضًا ، نرى اصطلاحات تسمية مختلفة للعديد من هذه النماذج المادية التي نقدمها. مهندس عكسي ، في كثير من الأحيان نرى أسماء مختصرة وهذا النوع من الأشياء التي سأتحدث عنها. ونحتاج إلى ترجمة هؤلاء الأشخاص إلى أسماء إنجليزية ذات معنى وذات مغزى بالنسبة إلى العمل حتى يتسنى لنا فهم ماهية كل هذه البيانات التي لدينا في البيئة. ثم التعيينات العالمية هي كيف نجمعها معًا.

علاوة على ذلك ، فإننا سنوثق ونحدد أكثر ، وهنا يمكننا تصنيف بياناتنا بشكل أكبر باستخدام شيء يسمى المرفقات ، وسأريكم بعض الشرائح. ثم بعد إغلاق الحلقة ، نريد تطبيق هذا المعنى التجاري ، وهو المكان الذي نربط فيه مسارد أعمالنا ويمكننا ربطها بمصنوعاتنا الفنية المختلفة ، لذلك نحن نعرف ، عندما نتحدث عن مصطلح عمل معين ، حيث نفذت في بياناتنا في جميع أنحاء المنظمة. ثم أخيرًا ، تحدثت بالفعل عن حقيقة أننا نحتاج إلى أن يكون كل هذا مستودعًا قائمًا على الكثير من إمكانيات التعاون والنشر ، حتى يتمكن أصحاب المصلحة لدينا من الاستفادة منه. سأتحدث عن الهندسة العكسية بسرعة إلى حد ما. لقد أعطيت لك بالفعل تسليط الضوء على ذلك بسرعة كبيرة. سأظهر لك ذلك في عرض فعلي فقط لأعرض لك بعض الأشياء التي يمكن أن نقدمها هناك.

وأريد أن أتحدث عن بعض أنواع النماذج والرسوم البيانية المختلفة التي سننتجها في هذا النوع من السيناريو. من الواضح أننا سنفعل النماذج المفاهيمية في كثير من الحالات ؛ لن أقضي الكثير من الوقت في ذلك. أريد حقًا التحدث عن النماذج المنطقية والنماذج المادية والأنواع المتخصصة من النماذج التي يمكننا إنشاؤها. ومن المهم أن نتمكن من إنشاء كل ذلك في نفس منصة النمذجة حتى نتمكن من تجميعها معًا. يتضمن ذلك نماذج الأبعاد وأيضًا النماذج التي تستخدم بعض مصادر البيانات الجديدة ، مثل NoSQL التي سأريكها. ثم ، ما شكل نموذج النسب البيانات؟ وكيف يمكننا دمج هذه البيانات في نموذج عملية تجارية ، هو ما سنتحدث عنه بعد ذلك.

سأنتقل إلى بيئة النمذجة هنا فقط لأقدم لك نظرة سريعة وسريعة للغاية. وأعتقد أنه يجب أن تكون قادرًا على رؤية شاشتي الآن. بادئ ذي بدء ، أود التحدث عن مجرد نموذج تقليدي لنموذج البيانات. والطريقة التي نريد تنظيم النماذج بها عندما نأتي بها ، هي أننا نريد أن نكون قادرين على تحليلها. إذن ما تراه هنا على الجانب الأيسر هو أن لدينا نماذج منطقية ومادية في ملف النماذج هذا. الشيء التالي هو ، هل يمكننا تقسيمها على طول تحاليل الأعمال ، ولهذا السبب ترى المجلدات. اللون الأزرق الفاتح عبارة عن نماذج منطقية والنماذج الخضراء نماذج طبيعية. ويمكننا أيضًا التنقل لأسفل ، حتى داخل ER / Studio ، إذا كان لديك تحلل في العمل ، فيمكنك الانتقال إلى العديد من المستويات بعمق أو النماذج الفرعية كما تريد ، والتغييرات التي تجريها على المستويات السفلية تنعكس تلقائيًا في الأعلى المستويات. لذلك تصبح بيئة نمذجة قوية جدا بسرعة كبيرة.

شيء أريد أن أوضح أنه من المهم للغاية البدء في جمع هذه المعلومات معًا ، وهو أنه يمكن أن يكون لدينا نماذج مادية متعددة تتوافق مع نموذج منطقي واحد أيضًا. في كثير من الأحيان قد يكون لديك نموذج منطقي ولكن قد يكون لديك نماذج مادية على منصات مختلفة وهذا النوع من الأشياء. ربما أحد مثيل SQL Server منه ، وربما الآخر مثيل أوراكل. لدينا القدرة على ربط كل ذلك معًا في نفس بيئة النمذجة. وهناك مرة أخرى ، ما وصلت إليه هنا هو نموذج حقيقي لمستودع البيانات يمكن أن يكون ، مرة أخرى ، في نفس بيئة التصميم أو يمكننا وضعه في المستودع وربطه في أشياء مختلفة أيضًا.

ما أردت حقاً أن أريكه في هذا هو بعض الأشياء الأخرى والمتغيرات الأخرى للنماذج التي ندخلها. لذلك عندما ندخل في نموذج بيانات تقليدي مثل هذا ، اعتدنا على رؤية الكيانات النموذجية بالأعمدة والبيانات الوصفية وهذا النوع من الأشياء ، لكن وجهة النظر هذه تختلف بسرعة كبيرة عندما نبدأ في التعامل مع بعض تقنيات NoSQL الأحدث هذه ، أو كما لا يزال بعض الناس يسمونهم ، تقنيات البيانات الكبيرة.

فلنفترض الآن أن لدينا أيضًا خلية النحل في بيئتنا. إذا قمنا بالعكس من مهندس من بيئة Hive - واستطعنا إعادة توجيه وعكس مهندس من Hive باستخدام أداة النمذجة نفسها هذه بالضبط - نرى شيئًا مختلفًا إلى حد ما. ما زلنا نرى جميع البيانات كما يبني هناك ، ولكن لدينا TDL مختلفة. من هؤلاء الذين اعتدوا على رؤية SQL ، ما تراه الآن هو Hive QL ، والذي يشبه لغة SQL تمامًا ولكن من الأداة نفسها ، يمكنك الآن بدء العمل مع لغات البرمجة النصية المختلفة. لذلك يمكنك تصميم نموذج في هذه البيئة ، وتوليدها في بيئة Hive ، ولكن بنفس القدر من الأهمية ، في السيناريو الذي وصفته ، يمكنك عكس كل ذلك في الهندسة وفهمها والبدء في ربطها معًا أيضًا .

لنأخذ واحدة أخرى مختلفة بعض الشيء. MongoDB هي منصة أخرى ندعمها محليًا. وعندما تبدأ في الدخول في أنواع JSON من البيئات التي يوجد بها مستندات ، JSON حيوان مختلف وهناك بنى في ذلك ، لا تتوافق مع النماذج العلائقية. ستبدأ قريبًا في التعامل مع مفاهيم مثل الكائنات المضمنة والمصفوفات المدمجة للكائنات عندما تبدأ في استجواب JSON ولا توجد تلك المفاهيم في الترميز العلائقي التقليدي. ما قمنا به هنا هو أننا قمنا بالفعل بتوسيع الترميز وكتالوجنا حتى نتمكن من التعامل مع ذلك في نفس البيئة.

إذا نظرت إلى اليسار هنا ، بدلاً من رؤية أشياء مثل الكيانات والجداول ، فإننا ندعو لهم الكائنات. وترى الرموز المختلفة. لا تزال ترى الأنواع النموذجية من الرموز المرجعية هنا ، لكن هذه الكيانات الزرقاء التي أراها في هذا المخطط المعين هي في الواقع كائنات مدمجة. ونحن نظهر الكاردينالات المختلفة. يعني أصل الماس أنه كائن على النهاية ، لكن أصل واحد يعني أنه لدينا داخل الناشر إذا تابعنا هذه العلاقة ، لدينا كائن عنوان مضمن. في استجواب JSON ، وجدنا أنه بالضبط نفس بنية الكائنات المضمنة في المستفيد ، ولكن هذا مضمن بالفعل كصفيف من الكائنات. نحن نرى ذلك ، ليس فقط من خلال الموصلات نفسها ، ولكن إذا نظرت إلى الكيانات الفعلية سترى أنك ترى عناوين تحت المستفيد والتي صنفتها أيضًا كمجموعة من الكائنات. تحصل على وجهة نظر وصفية للغاية حول كيفية تحقيق ذلك.

ومرة أخرى ، الآن ما رأيناه حتى الآن في بضع ثوانٍ فقط هو النماذج العلائقية التقليدية متعددة المستويات ، يمكننا أن نفعل الشيء نفسه مع Hive ، يمكننا أن نفعل الشيء نفسه مع MongoDB ، وغيرها من مصادر البيانات الضخمة مثل حسنا. ما يمكننا القيام به أيضًا ، وسأوضح لك هذا بسرعة كبيرة ، تحدثت عن حقيقة جلب الأشياء من مناطق مختلفة أخرى. سأفترض أنني سأستورد نموذجًا من قاعدة بيانات أو أعمل عليه ، لكنني سأحضره من بيانات وصفية خارجية. فقط لإعطائك وجهة نظر سريعة للغاية لجميع أنواع الأشياء المختلفة التي يمكننا أن نبدأ في تحقيقها.

كما ترون ، لدينا عدد لا يحصى من الأشياء التي يمكننا فعلاً إدخالها في بيئة التصميم الخاصة بنا. بدءًا من أشياء مثل Amazon Redshift و Cassandra والكثير من منصات البيانات الكبيرة الأخرى ، لذلك ترى الكثير من هذه القوائم. هذا في الترتيب الأبجدي. نحن نرى الكثير من مصادر البيانات الكبيرة وهذا النوع من الأشياء. نشهد أيضًا الكثير من بيئات النماذج التقليدية أو الأقدم التي يمكننا في الواقع نقل بيانات التعريف إليها. إذا مررت هنا - ولن أقضي بعض الوقت في كل منها - فسوف نرى الكثير من الأشياء المختلفة التي يمكننا إحضارها منها ، من حيث نماذج النماذج ومنصات البيانات. والشيء المهم للغاية الذي ندركه هنا هو جزء آخر يمكننا القيام به عندما نبدأ في الحديث عن نسب البيانات ، في Enterprise Team Edition ، يمكننا أيضًا استجواب مصادر ETL ، سواء كانت تعيينات مثل Talend أو SQL Server Information Services ، يمكننا جلب ذلك فعليًا لبدء مخططات نسق بياناتنا أيضًا ورسم صورة لما يحدث في هذه التحولات. إجمالاً ، لدينا أكثر من 130 من هذه الجسور المختلفة التي هي في الواقع جزء من منتج Enterprise Team Edition ، لذلك فهي تساعدنا حقًا على الجمع بين جميع القطع الأثرية في بيئة نموذج واحدة بسرعة كبيرة.

أخيرًا وليس آخرًا ، أريد أيضًا أن أتحدث عن حقيقة أننا لا نستطيع أن نغفل حقيقة أننا نحتاج إلى أنواع أخرى من التركيبات إذا كنا نقوم بتخزين البيانات أو أي أنواع من التحليلات. ما زلنا نريد أن تكون لدينا القدرة على القيام بأشياء مثل النماذج الأبعاد حيث لدينا جداول حقائق ولدينا أبعاد وأنواع من هذه الأشياء. شيء واحد أريد أن أوضحه لك هو أننا يمكن أن يكون لدينا امتدادات لبياناتنا الوصفية التي تساعدنا على تصنيف أنواع الأبعاد وكل شيء آخر. لذلك إذا نظرت إلى علامة تبويب البيانات ذات الأبعاد هنا ، على سبيل المثال ، على واحدة من هذه ، فسوف تكشف في الواقع تلقائيًا ، استنادًا إلى نموذج النموذج الذي تراه ، وتمنحك نقطة بداية لمعرفة ما إذا كانت تعتقد أنه بعد أم جدول الحقائق. ولكن أبعد من ذلك ، ما يمكننا القيام به هو ضمن الأبعاد وهذا النوع من الأشياء حتى لدينا أنواع مختلفة من الأبعاد التي يمكننا استخدامها لتصنيف البيانات في نوع تخزين بيانات البيئة أيضًا. قدرات قوية للغاية بحيث نقوم بتطريزها بالكامل.

سأقفز إلى هذا واحد لأنني في بيئة العرض التوضيحي الآن وأريكم بضعة أشياء أخرى قبل أن أعود إلى الشرائح. أحد الأمور التي أضفناها مؤخرًا إلى ER / Studio Data Architect هو أننا واجهنا مواقف - وهذه حالة شائعة جدًا عند العمل على المشاريع - يفكر المطورون فيما يتعلق بالكائنات ، في حين أن بياناتنا يميل المصممون إلى التفكير من حيث الجداول والكيانات وهذا النوع من الأشياء. هذا نموذج بيانات مبسّط للغاية ، لكنه يمثل بعض المفاهيم الأساسية ، حيث يمكن للمطورين أو حتى محللي الأعمال أو مستخدمي الأعمال ، اعتبارهم كائنات مختلفة أو مفاهيم أعمال. كان من الصعب جدًا تصنيف هذه العناصر حتى الآن ، لكن ما قمنا به بالفعل في إصدار ER / Studio Enterprise Team Edition ، في إصدار 2016 ، هو أننا لدينا الآن مفهوم يسمى كائنات بيانات الأعمال. وما يسمح لنا بذلك هو أنه يسمح لنا بتجميع مجموعات من الكيانات أو الجداول في كائنات أعمال حقيقية.

على سبيل المثال ، ما وصلنا إليه هنا في هذا العرض الجديد هو رأس أمر الشراء وتم تجميع سطر الأوامر معًا الآن ، حيث يتم تغليفهما ككائن ، وسنفكر فيهم كوحدة عمل عندما نستمر في البيانات ، ونحن نجمعها معًا بحيث أصبح من السهل جدًا ربط ذلك بجماهير مختلفة. انها قابلة لإعادة الاستخدام في جميع أنحاء بيئة النمذجة. إنها كائن حقيقي ، وليست مجرد رسم ، ولكن لدينا أيضًا ميزة إضافية تتمثل في أنه عندما نتواصل فعليًا من منظور النمذجة ، فيمكننا طيها أو توسيعها بشكل انتقائي حتى نتمكن من إنتاج طريقة عرض موجزة للحوارات مع جمهور معين من أصحاب المصلحة ، ويمكننا أيضًا ، بالطبع ، الحفاظ على وجهة نظر أكثر تفصيلًا كما نراها هنا لمزيد من الجماهير التقنية. انها حقا تعطينا وسيلة جيدة حقا للاتصال. ما نراه الآن هو الجمع بين عدة أنواع مختلفة من النماذج ، مما يزيدها بمفهوم كائنات بيانات الأعمال ، والآن سأتحدث عن كيفية تطبيقنا فعليًا لبعض المعنى على هذه الأنواع من الأشياء وكيف ندمجها معًا في البيئات الشاملة.

أحاول فقط العثور على WebEx الخاص بي هنا حتى أتمكن من القيام بذلك. وهناك نعود إلى شرائح Hot Tech. أنا فقط سأقدم بعض الشرائح هنا سريعًا لأنك رأيتها بالفعل في العرض التوضيحي النموذجي نفسه. أريد التحدث عن معايير التسمية بسرعة كبيرة. نريد تطبيق وتطبيق معايير التسمية المختلفة. ما نريد القيام به هو ، لدينا القدرة على تخزين قوالب معايير التسمية في مستودعاتنا لإنشاء هذا المعنى بشكل أساسي من خلال الكلمات أو العبارات أو حتى الاختصارات ، وربطها مرة أخرى بنوع من الكلمات الإنجليزية ذات معنى. سنستخدم مصطلحات العمل ، الاختصارات لكل منها ، ويمكننا تحديد الترتيب والحالات وإضافة البادئات واللواحق. عادةً ما تكون حالة الاستخدام النموذجية لذلك عندما يبني الأشخاص نموذجًا منطقيًا ثم يتقدمون لإنشاء نموذج مادي حيث ربما يستخدمون الاختصارات وكل شيء آخر.

الشيء الجميل هو أنها بنفس القوة ، بل وأكثر قوة في الاتجاه المعاكس ، إذا استطعنا أن نقول فقط ما هي بعض معايير التسمية تلك في بعض قواعد البيانات المادية التي قمنا بتصميمها عكسيًا ، يمكننا أن نأخذ هذه الاختصارات ، ونحولها إلى وقت أطول الكلمات ، وجعلهم الى الوراء في العبارات الإنجليزية. في الواقع يمكننا الآن اشتقاق أسماء مناسبة لما تبدو عليه بياناتنا. كما أقول ، حالة الاستخدام النموذجي هي أننا نمضي قدمًا ، ومنطقيًا إلى ماديًا ، ونرسم خرائط مخازن البيانات وهذا النوع من الأشياء. إذا نظرت إلى لقطة الشاشة على الجانب الأيمن ، سترى أن هناك أسماء مختصرة من أسماء المصادر وعندما نطبق قالب معايير التسمية ، لدينا بالفعل المزيد من الأسماء الكاملة. ويمكننا وضع مسافات وكل شيء كهذا إذا أردنا ذلك ، اعتمادًا على قالب معايير التسمية الذي استخدمناه. يمكننا أن نجعلها تبدو لكننا نريد أن ننظر إلى نماذجنا. فقط عندما نعرف ما يسمى شيئًا ما ، يمكننا أن نبدأ بالفعل في إرفاق تعريفات به ، لأنه ما لم نعرف ما هو ، كيف يمكننا تطبيق معنى عليه؟

الشيء الجميل هو ، هل يمكننا فعلاً الاحتجاج بهذا عندما نقوم بجميع أنواع الأشياء. تحدثت عن الهندسة العكسية ، يمكننا بالفعل استدعاء قوالب معايير التسمية في وقت واحد عندما نقوم بهندسة عكسية. لذلك في مجموعة واحدة من الخطوات من خلال المعالج ، ما يمكننا القيام به هو ، إذا كنا نعرف ماهية الاتفاقيات ، فيمكننا عكس هندسة قاعدة البيانات المادية ، وسوف نعيدها كنماذج مادية في بيئة نمذجة وهي أيضا الذهاب إلى تطبيق تلك اصطلاحات التسمية. لذلك سوف نرى ما هي تمثيلات الأسماء الإنجليزية المشابهة في النموذج المنطقي المقابل في البيئة. يمكننا أيضًا القيام بذلك ودمجها مع إنشاء مخطط XML حتى نتمكن من اتخاذ نموذج وحتى دفعه خارجًا مع اختصاراتنا ، سواء كنا نقوم بعمل أطر عمل SOA أو هذا النوع من الأشياء ، حتى نتمكن أيضًا من دفع اصطلاحات تسمية مختلفة أننا بالفعل تخزينها في النموذج نفسه. إنه يعطينا الكثير من القدرات القوية للغاية.

مرة أخرى ، إليك مثال على ما سيكون عليه إذا كان لدي قالب. يوضح هذا في الواقع أنني حصلت على EMP لـ "الموظف" و SAL مقابل "الراتب" و PLN لـ "الخطة" في اتفاقية معايير التسمية. يمكنني أيضًا تطبيقها ليتم تشغيلها بشكل تفاعلي أثناء إعداد النماذج ووضع الأشياء فيها. إذا كنت أستخدم هذا الاختصار وكتبت في "خطة راتب الموظف" على اسم الكيان ، فسيتم ذلك باستخدام قالب معايير التسمية لقد عرّفتني هنا ، لقد أعطاني EMP_SAL_PLN بينما كنت أقوم بإنشاء الكيانات ومنحتني الأسماء المادية المقابلة على الفور.

مرة أخرى ، جيد جدًا عندما نقوم بتصميم هندسة وأمامها أيضًا. لدينا مفهوم فريد للغاية وهذا هو المكان الذي نبدأ فيه حقًا في الجمع بين هذه البيئات. ويطلق عليه تعيينات عالمية. بمجرد إدخال كل هذه النماذج في بيئتنا ، ما يمكننا القيام به ، على افتراض أننا قد طبقنا الآن اصطلاحات التسمية هذه ويسهل العثور عليها ، يمكننا الآن استخدام بنية تسمى Universal Mappings في ER / ستوديو. يمكننا ربط الكيانات عبر النماذج. أينما رأينا "عميل" - سيكون لدينا على الأرجح "عميل" في العديد من الأنظمة المختلفة والكثير من قواعد البيانات المختلفة - يمكننا أن نبدأ في ربط كل هذه العناصر معًا حتى عندما أعمل معها في نموذج واحد أنا يمكن أن نرى أين هي مظاهر العملاء في النماذج الأخرى. ولأننا نملك طبقة النموذج التي تمثل ذلك ، فيمكننا حتى ربطها بمصادر البيانات وإخضاعها في استفساراتنا أين تستخدم قواعد البيانات الموجودة في قواعد البيانات هذه. إنه يعطينا حقًا القدرة على ربط كل هذا معًا بشكل متماسك للغاية.

لقد أظهر لك كائنات بيانات الأعمال. أريد أيضًا أن أتحدث عن امتدادات البيانات الوصفية ، والتي نسميها المرفقات ، بسرعة كبيرة. ما يفعله هو أنه يمنحنا القدرة على إنشاء بيانات تعريف إضافية للكائنات النموذجية لدينا. غالبًا ما أقوم بإعداد هذه الأنواع من الخصائص لطرد الكثير من الأشياء المختلفة من منظور حوكمة البيانات وجودة البيانات ، وكذلك لمساعدتنا في سياسات إدارة البيانات الرئيسية والاحتفاظ بها. الفكرة الأساسية هي إنشاء هذه التصنيفات ويمكنك إرفاقها أينما تريد ، على مستوى الجدول ، مستوى العمود ، تلك الأنواع من الأشياء. حالة الاستخدام الأكثر شيوعًا ، بالطبع ، هي أن الكيانات عبارة عن جداول ، ومن ثم يمكنني تحديد: ما هي كائنات البيانات الرئيسية الخاصة بي ، ما هي جداول المراجع الخاصة بي ، ما هي جداول المعاملات الخاصة بي؟ من منظور جودة البيانات ، يمكنني القيام بتصنيفات من حيث الأهمية لرجال الأعمال حتى نتمكن من إعطاء الأولوية لجهود تطهير البيانات وهذا النوع من الأشياء.

غالبًا ما يتم تجاهله ، ما هي سياسة الاحتفاظ لأنواع مختلفة من البيانات في مؤسستنا؟ يمكننا إعدادها ويمكننا في الواقع إرفاقها بأنواع مختلفة من القطع الأثرية للمعلومات في بيئة نمذجةنا ، وبالطبع مستودعنا أيضًا. الجمال هو ، هل هذه المرفقات مباشرة في قاموس البيانات الخاص بنا ، لذلك عندما نستخدم قواميس بيانات المؤسسة في البيئة ، يمكننا إرفاقها بنماذج متعددة. علينا فقط تحديدها مرة واحدة ويمكننا الاستفادة منها مرارًا وتكرارًا عبر النماذج المختلفة في بيئتنا. هذه مجرد لقطة شاشة سريعة لإظهار أنه يمكنك بالفعل تحديد متى تقوم بإجراء مرفق ، ما كل القطع التي تريد إرفاقها بها. وهذا المثال هنا هو في الواقع قائمة من القيم ، لذلك عندما تدخل ، يمكنك الاختيار من قائمة القيم ، لديك الكثير من التحكم في بيئة النمذجة لما يتم اختياره ، ويمكنك حتى ضبط ما هو الافتراضي القيمة هي إذا لم يتم اختيار القيمة. الكثير من القوة هناك. كانوا يعيشون في قاموس البيانات.

شيء ما أريد أن أريكه قليلاً على هذه الشاشة ، بالإضافة إلى أنك ترى نوع المرفقات يظهر في الجزء العلوي ، تحته ترى معلومات أمان البيانات. يمكننا بالفعل تطبيق سياسات أمان البيانات على الأجزاء المختلفة من المعلومات في البيئة أيضًا. بالنسبة لتعيينات التوافق المختلفة ، تصنيفات أمان البيانات ، نقوم بشحن عدد منها خارج الصندوق بحيث يمكنك إنشاء وبدء الاستخدام فقط ، ولكن يمكنك تحديد تعيينات ومعايير الامتثال الخاصة بك أيضًا. سواء كنت تفعل HIPAA أو أي من المبادرات الأخرى هناك. ويمكنك حقًا البدء في بناء مجموعة البيانات التعريفية الغنية جدًا هذه في بيئتك.

ثم المسرد والمصطلحات - هذا هو المكان الذي يرتبط فيه معنى العمل. غالبًا ما يكون لدينا قواميس بيانات هناك غالبًا ما تستخدمها المنظمة كنقطة بداية للبدء في إخراج المصطلحات ، ولكن المصطلحات والنصوص هي في كثير من الأحيان تقنية للغاية. إذن ما يمكننا القيام به هو أننا نستطيع ، إذا رغبت في ذلك ، استخدام تلك كنقطة انطلاق لطرد المسارد ، لكننا نريد حقًا أن يمتلكها هؤلاء. ما قمنا به في بيئة خادم الفريق هو منحنا القدرة للأشخاص على إنشاء تعريفات أعمال ومن ثم يمكننا ربطها بمصنوعات نموذجية مختلفة يتوافقون معها في بيئة النمذجة أيضًا. نحن ندرك أيضًا النقطة التي تمت مناقشتها مسبقًا وهي أنه كلما زاد عدد الأشخاص الذين تكتبهم ، زاد احتمال وجود خطأ بشري. ما نقوم به أيضًا في هيكلنا الخاص بالمصطلحات هو ، نحن ندعم تسلسل هرمي للمعاجم ، بحيث يمكن أن يكون لدينا أنواع مختلفة من المصطلحات أو أنواع مختلفة من الأشياء في المنظمة ، ولكن بنفس القدر من الأهمية ، إذا كان لديك بالفعل بعض هذه المصادر من خلال المصطلحات وكل ما تم تحديده ، يمكننا فعلًا استيراد ملف CSV لسحبها إلى بيئة النمذجة الخاصة بنا ، وكذلك خادم فريقنا أو معجمنا ، ثم البدء في الارتباط من هناك. وفي كل مرة يتم فيها تغيير شيء ما ، يكون هناك مسار تدقيق كامل لما كانت عليه الصور قبل وبعد ، من حيث التعريفات وكل شيء آخر ، وما ستراه في المستقبل القريب جدًا هو أيضًا سير عمل تخويل لذلك يمكننا حقًا التحكم في من المسؤول عن ذلك ، والموافقات من قبل اللجان أو الأفراد ، وهذا النوع من الأشياء ، لجعل عملية الحوكمة أكثر قوة مع تقدمنا.

ما يفعله هذا أيضًا بالنسبة لنا هو عندما يكون لدينا مصطلحات المسرد هذه في قاموس مصطلحات خادم فريقنا ، وهذا مثال على التحرير في كيان في النموذج نفسه الذي طرحته هنا. قد تحتوي على مصطلحات مرتبطة ، ولكن ما نقوم به أيضًا هو وجود كلمات في هذا المسرد تظهر في الملاحظات أو أوصاف ما لدينا في كياناتنا هنا ، ويتم عرض تلك الكلمات تلقائيًا بلون ارتباط تشعبي أفتح ، وإذا كنا الماوس فوقها ، يمكننا أن نرى في الواقع تعريف من مسرد الأعمال كذلك. حتى أنه يوفر لنا معلومات أكثر ثراء عندما نستهلك المعلومات نفسها ، مع كل المصطلحات الموجودة هناك. إنها تساعد حقًا في إثراء التجربة وتطبيق المعنى على كل شيء نعمل معه.

لذلك ، مرة أخرى ، كان ذلك ذبابة سريعة للغاية. من الواضح أننا يمكن أن نقضي أيامًا في هذا بينما ندخل في الأجزاء المختلفة ، ولكن هذا نفاث سريع للغاية فوق السطح. ما نسعى جاهدين فعله هو فهم كيف تبدو بيئات البيانات المعقدة هذه. نريد تحسين وضوح كل هذه القطع الأثرية للبيانات والتعاون من أجل إخراجها باستخدام ER / Studio. نريد تمكين نمذجة بيانات أكثر كفاءة وأتمتة. وهذه جميع أنواع البيانات التي نتحدث عنها ، سواء كانت بيانات كبيرة أو بيانات علائقية تقليدية أو مخازن وثائق أو أي شيء آخر. ومرة أخرى ، أنجزنا ذلك لأن لدينا قدرات هندسية أمامية وعكسية قوية للمنصات المختلفة والأدوات الأخرى التي قد تكون لديك هناك. والأمر كله يتعلق بالمشاركة والتواصل عبر المؤسسة مع جميع أصحاب المصلحة المعنيين. هنا نطبق المعنى من خلال معايير التسمية. ثم نطبق التعاريف من خلال مسارد أعمالنا. ومن ثم يمكننا القيام بتصنيفات إضافية لجميع إمكانيات الحوكمة الأخرى الخاصة بنا مع امتدادات البيانات الأولية مثل امتدادات جودة البيانات أو تصنيفات إدارة البيانات الرئيسية أو أي أنواع أخرى من التصنيفات التي تريد تطبيقها على تلك البيانات. وبعد ذلك يمكننا تلخيص المزيد وتعزيز التواصل أكثر مع كائنات بيانات الأعمال ، مع جماهير أصحاب المصلحة المختلفة ، لا سيما بين المصممين والمطورين.

ومرة أخرى ، المهم في هذا الأمر هو أن كل هذا هو مستودع متكامل بقدرات إدارة تغيير قوية للغاية. لم يكن لدي وقت لعرضه اليوم لأنه أصبح معقدًا إلى حد ما ، لكن المستودع لديه قدرات إدارة التغيير قوية للغاية ومسارات التدقيق. يمكنك القيام بالإصدارات المسماة ، كما يمكنك القيام بالإصدارات المسماة ، ولدينا أيضًا القدرة على إصدار منكم إدارة التغيير ، ويمكننا ربط هذا الحق بمهامك. لدينا اليوم القدرة على وضع المهام وربط التغييرات في النموذج الخاص بك بالمهام ، تمامًا مثل قيام المطورين بربط تغييرات التعليمات البرمجية الخاصة بهم بالمهام أو قصص المستخدم التي يعملون معها أيضًا.

مرة أخرى ، كان ذلك لمحة سريعة للغاية. آمل أن يكون هذا كافياً لإثارة شهيتك حتى نتمكن من الدخول في محادثات أعمق بكثير حول فصل بعض هذه الموضوعات مع تقدمنا ​​في المستقبل. شكراً لك على وقتك ، وأعود إليك ، ريبيكا.

ريبيكا جوزويك: شكراً ، رون ، كان ذلك رائعًا ولديّ بعض الأسئلة من الجمهور ، لكنني أريد إعطاء محللينا فرصة لتغميس أسنانهم في ما كان عليك قوله. إريك ، سأذهب إلى الأمام ، وربما إذا كنت ترغب في معالجة هذه الشريحة ، أو شريحة أخرى ، فلماذا لا تمضي قدمًا أولاً؟ أو أي سؤال آخر.

اريك ليتل: بالتأكيد. آسف ، ما هو السؤال ، ريبيكا؟ تريد مني أن أسأل شيئا محددا أو …؟

ريبيكا جوزويك: أعرف أن لديك بعض الأسئلة في البداية لصالح رون. إذا كنت تريد أن تطلب الآن منه أن يتناول أيًا من هؤلاء ، أو البعض الآخر من الشريحة الخاصة بك أو أي شيء آخر أثار اهتمامك الذي تريد أن تسأل عنه؟ حول وظائف النمذجة IDERA.

إريك ليتل: نعم ، إذن أحد الأشياء ، رون ، فكيف يا رفاق ، يبدو أن المخططات التي كنت تعرضها هي أنواع عامة من الرسوم البيانية لعلاقة الكيان كما لو كنت تستخدمها عادةً في بناء قاعدة البيانات ، صحيحة؟

رون هويزنجا: نعم ، بصفة عامة ، لكن بالطبع لدينا الأنواع الموسعة لمخازن الوثائق وهذا النوع من الأشياء أيضًا. لقد تبايننا فعلاً من مجرد تدوين علائقي خالص ، لقد أضفنا بالفعل ترميزات إضافية لتلك المتاجر الأخرى أيضًا.

إريك ليتل: هل هناك طريقة يمكنك من خلالها استخدام أنواع النماذج القائمة على الرسم البياني ، فهل هناك طريقة لدمجها ، على سبيل المثال ، دعنا نفترض أن لدي شيء يشبه الربع الأعلى أو أداة الملحن TopBraid أو قمت بعمل شيء ما في Protégé أو ، كما تعلمون ، مثل اللاعبين الماليين في FIBO ، فإنهم يقومون بالكثير من العمل في الدلالات والأشياء RDF - هل هناك طريقة لجلب هذا النوع من نمذجة نوع الرسم البياني للعلاقة بين الكيانات في هذه الأداة ، والاستفادة من ذلك؟

رون Huizenga: نحن في الواقع ننظر في كيفية التعامل مع الرسوم البيانية. نحن لا نتعامل بصراحة مع قواعد بيانات الرسم البياني وهذا النوع من الأشياء اليوم ، لكننا نبحث في طرق يمكننا القيام بها لتوسيع البيانات الوصفية الخاصة بنا. أقصد أنه يمكننا إحضار أشياء من خلال XML وهذا النوع من الأشياء في الوقت الحالي ، إذا كان بإمكاننا على الأقل القيام بنوع ما من تسليم XML لإدخاله كنقطة بداية. لكننا نبحث في طرق أكثر أناقة لتحقيق ذلك.

كما أوضحت لك تلك القائمة من الجسور الهندسية العكسية الموجودة لدينا أيضًا ، لذلك نحن نبحث دائمًا عن الحصول على ملحقات لتلك الجسور لمنصات معينة أيضًا. إنه جهد مستمر ومستمر ، إذا كان ذلك منطقيًا ، للبدء في احتضان الكثير من هذه الهياكل الجديدة والمنصات المختلفة هناك. لكن يمكنني القول أننا بالتأكيد في طليعة القيام بذلك. الأشياء التي عرضتها ، على سبيل المثال ، MongoDB وهذا النوع من الأشياء ، نحن أول بائع لنمذجة البيانات يقوم بذلك فعليًا بالفعل في منتجنا الخاص.

إريك ليتل: حسنًا ، نعم. لذا فإن السؤال الآخر الذي طرحته من أجلك ، كان فيما يتعلق بالحوكمة والحفاظ على - كما هو الحال عند استخدامك للمثال ، عندما أوضحت مثال الشخص "الموظف" ، وأعتقد أنه كان " الراتب "وبعد ذلك لديك" خطة "، هل هناك طريقة ، كيف تدير ، على سبيل المثال ، أنواع مختلفة من الأشخاص الذين قد يكون لديهم - دعنا نفترض أن لديك بنية كبيرة ، صحيح ، دعنا نفترض أن لديك مؤسسة كبيرة و يبدأ الأشخاص في تجميع الأشياء معًا في هذه الأداة ، ولديك مجموعة واحدة هنا تحتوي على كلمة "موظف" ومجموعة واحدة هنا تحتوي على كلمة "عامل". وهناك شخص هنا يقول "راتب" وشخص آخر يقول "الأجور".

كيف يا رفاق التوفيق وإدارة وتحكم هذه الأنواع من الفروق؟ لأنني أعرف كيف يمكننا أن نفعل ذلك في عالم الرسم البياني ، كما تعلمون ، ستستخدم قوائم مرادفات أو ستقول أن هناك مفهومًا واحدًا وله العديد من السمات ، أو يمكنك أن تقول في نموذج SKOS لدي تسمية مميزة ولدي العديد من التسميات البديلة التي يمكنني استخدامها. كيف يا رفاق تفعل ذلك؟

رون هويزنجا: نحن نفعل ذلك بطريقتين مختلفتين ، ودعونا نتحدث أولاً عن المصطلحات أولاً. أحد الأشياء التي نقوم بها ، بالطبع ، هو أننا نريد أن يكون لدينا مصطلحات محددة أو معترف بها ، ومن الواضح أن مسرد المصطلحات التجارية هو المكان الذي نريده. ونسمح أيضًا بروابط إلى المرادفات في مسرد الأعمال وكذلك ما يمكنك فعله هو أنه يمكنك القول ، فيما يلي ولايتي ، لكن يمكنك أيضًا تحديد ماهية جميع المرادفات لهؤلاء.

الآن الشيء المثير للاهتمام ، بالطبع ، هو عندما تبدأ في النظر إلى هذا المشهد الواسع للبيانات مع كل هذه الأنظمة المختلفة التي حصلت عليها ، لا يمكنك الخروج فقط وتغيير الجداول المقابلة وأنواع الأشياء هذه إلى يتوافق مع معيار التسمية هذا لأنه قد يكون حزمة قمت بشرائها ، لذلك لا يمكنك التحكم في تغيير قاعدة البيانات أو أي شيء على الإطلاق.

ما يمكننا القيام به هناك ، بالإضافة إلى القدرة على ربط تعريفات المسرد ، هو من خلال تلك التعيينات العالمية التي تحدثت عنها ، وما يمكن أن نفعله ، ونوع النهج الموصى به ، هو أن يكون لدينا نموذج منطقي شامل يحدد ما هذه المفاهيم التجارية المختلفة هي التي تتحدث عنها. قم بربط مصطلحات مسرد الأعمال في تلك ، والشيء الجيد الآن هو أنك حصلت على هذا البناء الذي يمثل كيانًا منطقيًا كما كان ، يمكنك بعد ذلك البدء في الارتباط من هذا الكيان المنطقي إلى جميع تطبيقات هذا الكيان المنطقي في النظم المختلفة.

ثم حيث تحتاج إلى ذلك ، يمكنك أن ترى ، أوه ، "الشخص" هنا يسمى "الموظف" في هذا النظام. يسمى "الراتب" هنا "الأجر" هنا في هذا النظام الآخر. لأنك سترى ذلك ، سترى جميع المظاهر المختلفة لتلك لأنك ربطتها معًا.

إريك ليتل: حسنًا ، حسنًا ، لقد حصلت عليه. في هذا المعنى ، هل من الآمن أن نقول إن هذا يشبه بعض النهج الموجهة للكائنات؟

رون هويزنجا: إلى حد ما. إنها أكثر كثافة بقليل مما أعتقد أنه يمكنك القول. أقصد أنه يمكنك اتباع نهج الربط والمتابعة والتفتيش والقيام بكل ذلك يدويًا. الشيء الوحيد الذي لم يكن لدي بالفعل فرصة للحديث عنه - لأنه مرة أخرى ، لدينا الكثير من القدرات - لدينا أيضًا واجهة تلقائية كاملة في أداة Data Architect نفسها. والقدرة الكلية ، والتي هي حقا لغة البرمجة في الأداة. لذلك يمكننا فعلًا القيام بأشياء مثل كتابة وحدات ماكرو ، وإخراجه واستجواب الأشياء وإنشاء روابط لك. نحن نستخدمها لاستيراد وتصدير المعلومات ، ويمكننا استخدامها لتغيير الأشياء أو إضافة سمات ، أو الحدث القائم في النموذج نفسه ، أو يمكننا استخدامه للتشغيل على دفعات للخروج فعلياً واستجواب الأشياء وتعبئة تصميمات مختلفة في الواقع نموذج. لذلك هناك واجهة أتمتة كاملة يمكن للناس الاستفادة منها أيضًا. واستخدام التعيينات العالمية مع تلك سيكون وسيلة قوية للغاية للقيام بذلك.

ريبيكا جوزويك: حسنًا ، شكرًا رون ، وشكر إريك. كانت هذه أسئلة كبيرة. أعلم أننا نجري بعض الوقت على مدار الساعة ، لكنني أود منح مالكولم فرصة لإلقاء بعض الأسئلة على طريقة رون. مالكولم؟

مالكولم تشيشولم: شكرًا ، ريبيكا. لذلك ، رون ، إنه أمر مثير للاهتمام للغاية ، أرى أن هناك الكثير من القدرات هنا. أحد المجالات التي أهتم بها للغاية ، على سبيل المثال ، إذا كان لدينا مشروع تطوير ، فكيف ترى مصمم نماذج البيانات يستخدم هذه القدرات ، وربما يعمل بشكل أكثر تعاونًا مع محللي الأعمال ، مع منشئ بيانات ، مع محلل جودة البيانات ومع الرعاة التجاريين الذين سيكونون في النهاية مسؤولين عن متطلبات المعلومات الفعلية في المشروع. كيف يمكن لمصمم البيانات حقًا ، كما تعلم ، أن يجعل المشروع أكثر فاعلية وكفاءة مع الإمكانيات التي ننظر إليها؟

رون هويزنجا: أعتقد أن أحد الأشياء الأولى التي عليك القيام بها هناك هو مصمم نماذج البيانات - ولا أقصد اختيار بعض المصممين ، لكنني على أي حال - ما زال لدى بعض الناس انطباع بأن مصمم نماذج البيانات هو في الحقيقة نوع من دور حارس البوابة ، ونعرف كيف يعمل ، نحن الحراس الذين نتأكد من أن كل شيء صحيح.

الآن هناك جانب من جوانب ذلك ، وهو أنه يتعين عليك التأكد من أنك تحدد بنية بيانات الصوت وكل شيء آخر. لكن الشيء الأكثر أهمية هو أن مصمم النماذج - ووجدت هذا واضحًا بعض الشيء عندما كنت أستشير - هل يجب أن تصبح وسيطًا ، لذلك عليك أن تجمع هؤلاء الأشخاص معًا.

لن يكون تصميم مقدمًا أو إنشاء أو إنشاء قواعد بيانات بعد الآن - ما عليك أن تكون قادرًا على القيام به هو أنك بحاجة إلى أن تكون قادرًا على العمل مع كل مجموعات أصحاب المصالح المختلفة هذه ، وأن تفعل أشياء مثل الهندسة العكسية ، واستيراد المعلومات ، والحصول على يتعاون أشخاص آخرون ، سواء كان ذلك في المسارد أو الوثائق ، كل شيء من هذا القبيل - وكن ميسرًا لسحب هذا إلى المستودع ، وربط المفاهيم معًا في المستودع ، والعمل مع هؤلاء الأشخاص.

إنها في الواقع أكثر من بيئة تعاونية حيث أنه حتى من خلال تحديد المهام أو حتى سلاسل مناقشة أو هذا النوع من الأشياء التي لدينا في خادم الفريق ، يمكن للأشخاص التعاون فعليًا وطرح الأسئلة والوصول إلى المنتجات النهائية التي يقومون بها الحاجة إلى بنية البيانات الخاصة بهم وتنظيمها. هل هذا النوع من الإجابة؟

مالكولم تشيشولم: نعم ، أوافق. كما تعلمون ، أعتقد أن مهارة التيسير أمر مرغوب فيه للغاية في مصممي البيانات. أوافق على أننا لا نرى ذلك دائمًا ، لكنني أعتقد أن هذا ضروري ، وأقترح أن هناك ميلًا في بعض الأحيان إلى البقاء في الزاوية الخاصة بك للقيام بنمذجة البيانات الخاصة بك ، ولكن عليك حقًا العمل هناك مع مجموعات أصحاب المصلحة الآخرين أو أنك لا تفهم بيئة البيانات التي تتعامل معها ، وأعتقد أن النموذج يعاني نتيجة لذلك. لكن هذا مجرد رأيي.

رون هويزنجا: إنه أمر مثير للاهتمام لأنك ذكرت شيئًا سابقًا في الشريحة الخاصة بك حول تاريخ كيفية تحول الشركات عن تقنية المعلومات لأنها لم تقدم الحلول في الوقت المناسب وتلك الأنواع من الأشياء.

من المثير للاهتمام أنه في ارتباطاتي الاستشارية اللاحقة ، قبل أن أصبح مديرًا للمنتج ، كانت معظم المشاريع التي قمت بها في العامين الماضيين قبل ذلك ، تحت رعاية الأعمال ، حيث كان العمل هو الذي كان يقودها بالفعل ومهندسو البيانات ولم يكن المصممون جزءًا من تقنية المعلومات. كنا جزءًا من مجموعة ترعاها الشركات وكنا هناك كميسرين يعملون مع بقية فرق المشروع.

مالكولم تشيشولم: لذلك أعتقد أن هذه نقطة مثيرة للاهتمام للغاية. أعتقد أننا بدأنا نشهد تحولًا في عالم الأعمال حيث تسأل الأعمال ، أو ربما تفكر ، ليس بقدر ما أقوم به ، مثل العملية ، لكنهم بدأوا أيضًا في التفكير في ما هي البيانات التي أعمل معها ، ما هي احتياجاتي من البيانات ، وما هي البيانات التي أتعامل معها كبيانات ، وإلى أي مدى يمكننا الحصول على منتجات وقدرات IDERA لدعم وجهة النظر هذه ، وأعتقد أن احتياجات العمل ، حتى على الرغم من أنه لا يزال نوعًا ما حديثي الولادة.

رون هويزنجا: أنا أتفق معك وأعتقد أننا نرى أنه يذهب أكثر وأكثر بهذه الطريقة. لقد رأينا صحوة وتطرقت إليها في وقت سابق من حيث أهمية البيانات. لقد رأينا أهمية البيانات في مرحلة مبكرة من تكنولوجيا المعلومات أو في تطور قواعد البيانات ، ثم كما قلت ، دخلنا نوعًا ما في هذه الدورة الكاملة لإدارة العملية - والعملية مهمة للغاية ، لا تخطئني هناك - لكن الآن ما حدث هو عندما حدث ذلك ، ونوع البيانات المفقودة التركيز.

والآن تدرك المنظمات أن البيانات هي حقاً النقطة المحورية. تمثل البيانات كل ما نقوم به في أعمالنا ، لذا نحتاج إلى التأكد من أن لدينا بيانات دقيقة ، وأن نتمكن من العثور على المعلومات الصحيحة التي نحتاجها لاتخاذ قراراتنا. لأنه ليس كل شيء يأتي من عملية محددة. بعض المعلومات هي نتيجة ثانوية لأشياء أخرى ، وما زلنا بحاجة إلى أن نكون قادرين على العثور عليها ومعرفة ما يعنيه ، وأن نكون قادرين على ترجمة البيانات التي نراها هناك في نهاية المطاف إلى معرفة يمكننا استخدامها لدفع أعمالنا بشكل أفضل.

مالكولم تشيشولم: صحيح ، والآن هناك مجال آخر كنت أواجهه وهو ما أسميه دورة حياة البيانات التي ، كما تعلمون ، إذا نظرنا إلى نوع سلسلة إمداد البيانات التي تمر بمؤسسة ، فسنبدأ مع الحصول على البيانات أو التقاط البيانات ، والتي قد تكون إدخال البيانات ولكن قد تكون كذلك ، أحصل على بيانات من خارج المؤسسة من بعض موردي البيانات.

ثم من التقاط البيانات ، نذهب إلى صيانة البيانات حيث أفكر في توحيد هذه البيانات وشحنها إلى الأماكن التي تحتاج إليها. ثم استخدام البيانات ، والنقاط الفعلية حيث توجد البيانات ، ستحصل على قيمة من البيانات.

وفي الأيام الخوالي ، يتم كل ذلك بأسلوب فردي ، ولكن اليوم قد يكون ، كما تعلم ، بيئة تحليلية ، على سبيل المثال ، وبعد ذلك ، أرشيف ، متجر ، حيث نضع البيانات عندما لم نعد في حاجة إليها ، وأخيرا تطهير نوع من العملية. كيف ترى أن نمذجة البيانات تتناسب مع إدارة دورة حياة البيانات بأكملها؟

رون هويزنجا: هذا سؤال جيد للغاية ، وأحد الأشياء التي لم يكن لدي وقت للتفكير فيها اليوم ، على الإطلاق ، هو ما بدأنا بالفعل في الحديث عنه هو سِلة البيانات. إذن ما يمكننا فعله فعلاً هو أن لدينا القدرة على تحديد نسب البيانات في أدواتنا ، وكما أقول ، يمكننا بالفعل استخراج بعضها من أدوات ETL ، لكن يمكنك أيضًا تعيينها فقط عن طريق رسم النسب أيضًا. يمكن لأي من نماذج البيانات أو قواعد البيانات هذه التي قمنا بالتقاطها وإدخالها في النماذج أن نشير إلى الإنشاءات من ذلك في مخطط نسب البيانات لدينا.

ما يمكننا القيام به هو سحب تدفق البيانات ، كما تقول ، من المصدر إلى الهدف ، ومن خلال دورة الحياة الشاملة لكيفية انتقال هذه البيانات عبر الأنظمة المختلفة وما ستكتشفه ، دعنا نأخذ الموظفين 'البيانات - إنها واحدة من الأشياء المفضلة لدي بناءً على مشروع قمت به منذ سنوات. عملت مع مؤسسة لديها بيانات الموظف في 30 نظامًا مختلفًا. ما انتهى بنا الأمر هناك - وبرزت ريبيكا شريحة نسب البيانات - هذه شريحة نسبية بسيطة إلى حد ما هنا ، لكن ما استطعنا فعله هو جلب جميع هياكل البيانات ، والإشارة إليها في الرسم التخطيطي ، ثم يمكن أن تبدأ بالفعل في النظر في ما هي التدفقات بين ، وكيف يتم ربط هذه الكيانات البيانات المختلفة معا في التدفق؟ ويمكننا أن نتجاوز ذلك أيضًا. هذا جزء من مخطط تدفق البيانات أو النسب الذي نراه هنا. إذا كنت ترغب في الذهاب إلى أبعد من ذلك ، فلدينا أيضًا مهندس الأعمال جزء من هذا الجناح وينطبق نفس الشيء هناك.

أي من هياكل البيانات التي قمنا بالتقاطها في بيئة نمذجة البيانات ، يمكن الرجوع إليها في أداة نمذجة الأعمال ، بحيث يمكنك حتى في مخططات نماذج الأعمال أو المخططات الخاصة بعملك ، الرجوع إلى مخازن البيانات الفردية إذا كنت ترغب في الخروج من بيئة نمذجة البيانات ، وأثناء استخدامك لها في المجلدات في نموذج عملية عملك ، يمكنك حتى تحديد CRUD على هؤلاء أيضًا ، حول كيفية استهلاك أو إنتاج تلك المعلومات ، ومن ثم يمكننا البدء في إنشاء أشياء مثل تقارير التأثير والتحليل والرسوم البيانية للخروج من ذلك.

ما نهدف إلى الوصول إليه ، ولدينا الكثير من القدرات بالفعل ، ولكن أحد الأشياء التي لدينا نوعًا من الأهداف التي ننظر إليها ، ونحن نواصل تطوير أدواتنا للمضي قدمًا ، هي القدرة على تحديد نسب البيانات التنظيمية الشاملة ودورة حياة البيانات الكاملة.

مالكولم تشيشولم: حسنًا. ريبيكا ، هل سمح لي أكثر واحد؟

ريبيكا يوزويك: سأسمح لك بمزيد من التقدم ، مالكولم ، للمضي قدمًا.

مالكولم تشيشولم: شكرًا جزيلاً. بالتفكير في إدارة البيانات والتفكير في نمذجة البيانات ، كيف يمكننا أن نجعل هاتين المجموعتين تعملان بفعالية معًا وفهم بعضنا البعض؟

إريك ليتل: حسنًا ، إنه أمر مثير للاهتمام ، وأعتقد أن هذا يعتمد حقًا على المؤسسة ، ويعود إلى مفهومي السابق هو أنه في تلك المنظمات التي كانت فيها المبادرات مدفوعة بالأعمال التي تم ربطنا بها. على سبيل المثال ، كنت أقود بنية بيانات فريق ولكن تم ربطنا بشكل صحيح مع مستخدمي الأعمال وكنا في الواقع نساعدهم على الوقوف في برنامج حوكمة البيانات الخاص بهم. مرة أخرى ، أكثر من نهج استشاري لكنه في الحقيقة أكثر من وظيفة تجارية.

ما تحتاجه حقًا لتكون قادرًا على القيام بذلك هو أنك تحتاج إلى مصممي البيانات والمهندسين المعماريين الذين يفهمون العمل حقًا ، ويمكنهم التواصل مع مستخدمي الأعمال ومن ثم ساعدهم على الوقوف في عمليات الحوكمة من حوله. ترغب الشركة في القيام بذلك ، ولكن بصفة عامة لدينا المعرفة التكنولوجية لتكون قادرًا على مساعدتهم على تمييز هذه الأنواع من البرامج. يجب أن يكون التعاون حقًا ، لكن يجب أن يكون ملكًا للأعمال.

مالكولم تشيشولم: حسنًا ، هذا رائع. شكرا لكم.

الدكتور إريك ليتل: حسنًا.

ريبيكا جوزويك: حسناً ، شكرًا جزيلاً. أيها الحضور ، أخشى أننا لم نتوصل إلى أسئلتك ، لكنني سأحرص على إرسالها إلى الضيف المناسب الذي كان لدينا على الخط اليوم. أود أن أشكركم جزيل الشكر لإريك ومالكولم ورون لكونهم ضيوفنا اليوم. كان هذا أشياء عظيمة ، الناس. وإذا كنت قد استمتعت بالبث عبر الإنترنت IDERA اليوم ، فستكون IDERA أيضًا في برنامج Hot Technologies يوم الأربعاء القادم إذا كنت ترغب في الانضمام ، ومناقشة تحديات الفهرسة و Oracles ، وهذا موضوع رائع آخر.

شكراً جزيلاً لك ، أيها الناس ، اعتني بهم ، وسوف نراكم في المرة القادمة. مع السلامة.

بناء بنية بيانات يحركها العمل