نمذجة البيانات في بيئة رشيقة

فيديو: Data Modeling in an Agile Environment

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

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

إريك كافانا: حسنا ، سيداتي وسادتي. أهلا بكم من جديد يوم الأربعاء الساعة 4:00 بتوقيت شرق الولايات المتحدة. وهذا يعني أن الوقت قد حان لتقنيات Hot. نعم فعلا اسمي إريك كافانا ، سأكون مضيفك.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أعتقد أن هذا ما قلته بما فيه الكفاية. سأذهب إلى Dez Blanchfield ، يقول كل شيء آخر تمامًا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

وهذا كل شيء! من هنا سنتخذ المزيد من الأسئلة.

إريك كافانا: حسنًا ، حسنًا ، اسمح لي برميه أولاً. ثم ، Dez ، أنا متأكد من أن لديك سؤالين. خذها بعيدا ، روبن.

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

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

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

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

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

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

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

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

على أي حال ، سأنتقل إلى Dez لأنني اعتقدت أن لديّ وقتي المخصص. ديز؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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