Funcionarios
1.0.0
ระบบการจัดการพนักงานของ บริษัท
โครงการได้รับการพัฒนาโดยใช้ ASP.NET สำหรับการพัฒนาแอปพลิเคชันและ SQL Server เป็นฐานข้อมูลการจัดเก็บ การลงทะเบียนของพนักงาน (บุคคล + สินค้า) ถูกสร้างขึ้นในที่ที่เป็นไปได้ที่จะทำการกระทำ 4 ของมาตรฐาน CRUD อ่านสร้างแก้ไขและลบ นอกจากนี้ยังมีการใช้ตัวเลือกการคำนวณเงินเดือนใหม่ซึ่งฐานข้อมูลทำให้ความสัมพันธ์ระหว่างบุคคลและสำนักงานอีกครั้งโดยมีการเติมตารางของ Person_salary ในคำอธิบายการทดสอบ
ในเจ้าหน้าที่/ สำรองข้อมูล/ มีไฟล์สำรอง SQL Server ที่ฉันใช้กับขั้นตอนทั้งหมดที่ใช้และข้อมูลที่ป้อนแล้ว ดังนั้นคุณเพียงแค่ต้องทำการกู้คืนธนาคาร
หมายเหตุ : หลังจากทำการกู้คืนคุณต้องเปลี่ยนสตริงการเชื่อมต่อที่มีอยู่ในชั้นเรียนพนักงานภายใน file.aspx.cs เปลี่ยนโดยสตริงการเชื่อมต่อของเครื่องของคุณ
หลังจากกำหนดค่าฐานข้อมูลให้เปิดโซลูชันไปยังโปรแกรมแก้ไขรหัสที่คุณเลือก (ฉันใช้ Visual Studio) และเรียกใช้แอปพลิเคชัน
เพื่อให้ง่ายต่อการดูขั้นตอนที่ใช้ในแอปพลิเคชันฉันวางไฟล์การสร้างไว้ในพนักงาน/SQLS/
ในระหว่างการพัฒนาฉันพบสิ่งแปลก ๆ เกี่ยวกับสถาปัตยกรรมที่เสนอ ส่วนใหญ่เกี่ยวกับฐานข้อมูล
มีการกล่าวในคำอธิบายการทดสอบว่าการสร้างตารางที่เรียกว่า pessoa_salario ซึ่งจะทำให้การเชื่อมต่อของตารางบุคคลกับตำแหน่ง อย่างไรก็ตามการมีอยู่ของตารางนี้ไม่จำเป็น สำหรับความจำเป็นในการสร้างตารางกลางเป็นสิ่งจำเป็นเฉพาะเมื่อมีความสัมพันธ์ของคนจำนวนมากสำหรับหลาย ๆ คนระหว่างสองตารางที่วิเคราะห์ ซึ่งไม่ใช่กรณีระหว่างบุคคลและสำนักงาน หลังจากคน ๆ หนึ่งคนสามารถอยู่ในตำแหน่งได้ครั้งละและดังนั้นจึงมีหนึ่งฟิลด์ที่เรียกว่า position_id ด้วยตนเอง และจากนี้วิธีที่ไม่ซ้ำกันของตารางตำแหน่งมีอยู่แล้วและดังนั้นจึงเป็นไปได้ที่จะเข้าถึงตำแหน่งและเงินเดือนของบุคคลนั้นโดยไม่จำเป็นต้องสร้างตารางเพื่อทำสิ่งนี้
วิธีที่คุณอธิบายไว้ในการทดสอบมีปัญหาที่ซ้ำกันในธนาคาร ซึ่งนอกเหนือจากการเป็นสถาปัตยกรรมที่ไม่ถูกต้องเนื่องจากสามารถสร้างความไม่สอดคล้องกันในข้อมูลเหล่านี้ในบางจุด "การแก้ไข" ของสิ่งนี้ก็จำเป็นในแอปพลิเคชันที่เป็นการสร้างปุ่มการคำนวณเงินเดือนใหม่ หลังจากทั้งหมดหากมูลค่าของเงินเดือนของผู้ฝึกงานในอนาคตตัวอย่างเช่นการเปลี่ยนแปลงตารางตำแหน่งจะมีการอัปเดตมูลค่า แต่ตารางการขาย sanal จะยังคงมีค่าเก่า (ปัญหาความไม่สอดคล้องกันของข้อมูล) และจำเป็นต้องไปด้วยตนเองบนหน้าจอพนักงานและกระตุ้นการดำเนินการคำนวณใหม่ ซึ่งไม่จำเป็นต้องทำหากไม่มีโต๊ะของบุคคลเพราะนอกจากมีเพียงข้อมูลนี้ในสถานที่เดียวเพื่อป้องกันความไม่สอดคล้องกันการปรึกษาหารือจะได้รับค่าอย่างถูกต้อง ทั้งสองก่อนแก้ไขจำนวนเงินเดือนและหลัง
หลักฐานนี้คือการวิเคราะห์การปรึกษาหารือที่สถาปัตยกรรมทั้งสองสร้างขึ้น
นี่คือการให้คำปรึกษาเพื่อส่งคืนข้อมูลทั้งหมดของบุคคลการขนส่งสินค้าและ person_salary ที่ใช้ในรายการโดยข้อเสนอสถาปัตยกรรม:
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หมายเหตุ : ข้อเสนอโซลูชันของฉันได้รับการพัฒนาโดยใช้สถาปัตยกรรมที่เสนอ ความคิดเห็นนี้เป็นเพียงการแสดงวิธีที่ฉันพบว่ามันน่าสนใจและปรับให้เหมาะสมที่สุดโดยสถาปัตยกรรม
