Funcionarios
1.0.0
نظام إدارة موظفي الشركة.
تم تطوير المشروع باستخدام ASP.NET لتطوير التطبيق وخادم SQL كقاعدة بيانات تخزين. تم تسجيل تسجيل للموظفين (شخص + شحن) حيث من الممكن اتخاذ الإجراءات الأربعة لمعايير CRUD. قراءة ، إنشاء ، تحرير وحذف. بالإضافة إلى ذلك ، تم تنفيذ خيار إعادة حساب الرواتب أيضًا ، حيث تجعل قاعدة البيانات العلاقة مرة أخرى بين الشخص والمكتب ، وملء جدول person_salary الذي تم إملائه في وصف الاختبار.
في المسؤولين/ النسخ الاحتياطي/ يحتوي على ملف نسخ احتياطي لخادم SQL الذي استخدمته مع جميع الإجراءات المستخدمة والبيانات التي تم إدخالها بالفعل. لذلك ، تحتاج فقط إلى استعادة البنك.
ملاحظة : بعد القيام بالاستعادة ، تحتاج إلى تغيير سلسلة الاتصال الموجودة في فئة الموظفين ضمن ملف الموظف. aspx.cs. التغيير بواسطة سلسلة اتصال من جهازك.
بعد تكوين قاعدة البيانات ، افتح الحل لبعض محرر التعليمات البرمجية من اختيارك (استخدمت Visual Studio) وقم بتشغيل التطبيق.
لتسهيل عرض الإجراءات المستخدمة في التطبيق ، وضعت ملفات الإنشاء الخاصة بهم في الموظفين/SQLS/.
أثناء التطوير ، وجدت بعض الأشياء الغريبة حول الهندسة المعمارية المقترحة. أساسا فيما يتعلق بقاعدة البيانات.
يقال في وصف الاختبار هو إنشاء جدول يسمى pessoa_salario من شأنه أن يجعل اتصال جدول الشخص مع وضع. ومع ذلك ، فإن وجود هذا الجدول ليس ضروريًا. للحاجة إلى إنشاء جدول متوسط ضروري فقط عندما تكون هناك علاقة للكثيرين بالنسبة للكثيرين بين الجدولين الذين تم تحليلهم. وهذا ليس هو الحال بين الشخص والمكتب. بعد كل شيء يمكن أن يكون شخص واحد في وضع واحد في وقت واحد ، وبالتالي هناك حقل واحد يسمى الموضع _id شخصيًا. ومن هذا الأمر ، فإن الطريقة الفريدة لجدول الموضع موجودة بالفعل ، وبالتالي من الممكن بالفعل الوصول إلى موقف هذا الشخص وراتب ذلك ، دون الحاجة إلى إنشاء جدول للقيام بذلك.
الطريقة التي تم وصفها في الاختبار ، هناك مشكلة مكررة في البنك. إلى جانب كونها خاطئة من الناحية المعمارية ، حيث يمكن أن تولد عدم الاتساق في هذه البيانات في مرحلة ما ، كان هناك حاجة أيضًا إلى "تصحيح" لهذا في التطبيق الذي كان إنشاء زر إعادة حساب الرواتب. بعد كل شيء إذا تم تغيير قيمة راتب المتدرب في المستقبل ، على سبيل المثال ، فإن جدول الموضع سيحدث القيمة ، ولكن لا يزال لدى جدول بيع Sanal القيمة القديمة (مشكلة عدم تناسق البيانات) وسيكون من الضروري الذهاب يدويًا على شاشة الموظف وتشغيل إجراء إعادة حساب الرواتب. لا يلزم القيام به إذا لم يكن هناك جدول لشخص ، لأنه إلى جانب وجود هذه البيانات فقط في مكان واحد ، ومنع التناقضات ، فإن الاستشارة ستأخذ القيمة بشكل صحيح. سواء قبل تعديل مبلغ الراتب وبعد.
دليل على ذلك هو تحليل المشاورات التي تولدها البنية.
هذه هي الاستشارة لإرجاع جميع بيانات الشخص والشحن والشخصية المستخدمة في الإدراج من قبل مقترحات العمارة:
SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, ps . Salario FROM Pessoa as p
INNER JOIN Pessoa_Salario as ps on p . ID = ps . Pessoa_ID
INNER JOIN Cargo as c on p . Cargo_ID = c . IDوهذا له نفس الوظيفة مثل الاستشارة المذكورة أعلاه ، ولكن لا يشمل سوى الشخص والمكتب ويعيد نفس البيانات تمامًا بطريقة أبسط وأكثر تحسينًا:
SELECT p . ID , p . Nome as Pessoa, Cidade, Email, CEP, Endereco, Pais, Usuario, Telefone, Data_Nascimento, c . Nome as Cargo, c . Salario FROM Pessoa as p
INNER JOIN Cargo as c on p . Cargo_ID = c . IDملاحظة : تم تطوير مقترحات الحل الخاصة بي باستخدام الهندسة المعمارية المقترحة. كان هذا التعليق فقط لإظهار الطريقة التي وجدت أنها أكثر إثارة للاهتمام وتحسينها من قبل الهندسة المعمارية.
