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

بواسطة Techopedia Staff ، 16 نوفمبر 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إريك كافانا: هذا منطقي تمامًا. كان لدينا بضعة أشخاص آخرين يسألون أسئلة محددة حول كيفية ربط كل هذا بالأداة. I know you spent some time going through examples and you've been showing some screenshots about how you actually roll some of this stuff out. In terms of this whole sprint process, how often do you see that in play in organizations versus how often do you see more traditional processes where things just, kind of, plod along and take more time? How prevalent is the sprint-style approach from your perspective?

Ron Huizenga: I think we're seeing it more and more. I know that, I would say, probably in the last 15 years in particular, I've seen much more of an adoption of people recognizing that they really need to embrace quicker delivery. So I've seen more and more organizations jump on the agile bandwagon. Not necessarily entirely; they may start out with a couple of pilot projects to prove out that it works, but there are some that are still very traditional and they do stick with the waterfall method. Now, the good news is, of course, that the tools work very fine in those organizations as well for those type of methodologies, but we have the adaptability in the tool so that those who do jump on board have the tools in the toolbox at their fingertips. Things like the compare and merge, things like the reverse-engineering capabilities, so they can see what the existing data sources are, so they can actually compare and generate out the incremental DDL scripts very quickly. And as they start to embrace that and see that they can have the productivity, their inclination to embrace agile even more increases.

Eric Kavanagh: Well, this is great stuff, folks. I just posted a link to the slides there in the chat window, so check that out; it's a little bit of a Bitly in there for you. We do have all these webcasts for later viewing. Feel free to share them with your friends and colleagues. And Ron, thank you very much for your time today, you're always pleasant to have on the show – a real expert in the field and it's obvious that you know your stuff. So, thanks to you and thanks to IDERA and, of course, to Dez and our very own Robin Bloor.

And with that we're going to bid you farewell, folks. شكرا مرة أخرى على وقتك والاهتمام. We appreciate you sticking around for 75 minutes, that's a pretty good sign. Good show guys, we'll talk to you next time. مع السلامة.