Lab 2 Modifying A Database Design In Visio Week 4 And Word

Lab 2 Modifying A Database Design In Visiodue Week 4 And Worth 75 Poi

This assignment contains two (2) Sections: Visio Diagram and Design Summary. You must submit both sections as separate files in order to complete this assignment. Use “Appendix A: Designing Databases with Visio Professional: A Tutorial,” to help you complete Section 1: Visio Database Design. (Note: This tutorial focuses on the use of Microsoft Visio. Open source applications are not covered in Appendix A; however, the use of open source applications within labs is permitted.) Click here to download Appendix A.

After reviewing your database design from Lab 1: Creating a Database Design in Visio, the college has provided more information for the database that they want developed: For each student, the college needs to track the student ID, student names, addresses, start date, phone numbers and types (such as mobile, home, work), email addresses and types (such as personal, school, work), gender, and birth date.

For each course, the college needs to track the course ID, course name, department, quarters offered, sections, and instructor teaching each course. For each instructor, the college needs to track the instructor ID, name, address, phone numbers and types (such as mobile, home, work), email addresses and types (such as personal, school, work), gender, birth date, and the courses that each instructor is qualified to teach. Additionally, the college needs to track the final grades for each student after each course has completed.

Section 1: Modified Visio Diagram

1. Use Microsoft Visio (or open source equivalent) in which you:

• Modify the database diagram from Lab 1 with the entities and attributes that the scenario identified (i.e., a college tracking students, courses, and instructors).
• Create the appropriate relationships between each entity within the diagram.

Section 1 of your assignment must follow these formatting requirements: Submit the Visio diagram as a Visio file.

Section 2: Design Summary

1. Write a one to two (1-2) page paper in which you:

• Discuss the degree to which you believe the Visio diagram reflects the database design.
• Describe any assumptions that you had to make about the business rules to in order to create the Visio diagram and the associated relationships.

Section 2 of your assignment must follow these formatting requirements: Submit the design summary as a Microsoft Word file. This course requires use of Strayer Writing Standards (SWS). The format is different than other Strayer University courses.

Please take a moment to review the SWS documentation for details. Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page is not included in the required assignment page length.

Paper For Above instruction

The project at hand focuses on developing and refining a university’s database design to accurately reflect its operational needs. Based on the guidelines provided, the primary goal is to create a comprehensive Entity-Relationship Diagram (ERD) using Microsoft Visio that encapsulates all specified entities, their attributes, and the relationships among them, followed by a reflective narrative discussing the design's validity and underlying assumptions.

Developing the Visio Diagram

In constructing the ERD, the entities identified include Students, Courses, and Instructors. Each entity requires detailed attributes as provided: Students possess identifiers such as Student ID, along with personal data including name, address, gender, birth date, and contact information with associated types for phones and emails. Courses are characterized by Course ID, name, department, quarters offered, and sections, with an emphasis on the instructor who teaches these courses. Instructors are distinguished by Instructor ID, name, address, contact info similar to students, gender, birth date, and a set of courses they are qualified to teach.

The relationships among these entities are critical. A Student can enroll in multiple Courses, and a Course can have many Students—a many-to-many relationship that necessitates an associative entity, such as Enrollments, to track each student's performance via final grades after course completion. Instructors are associated with Courses through a teaching relationship, which may be one-to-many, considering that an instructor can teach multiple courses, but each course typically has a single instructor per section.

This structured approach ensures clarity and supports data normalization principles by minimizing redundancy while maintaining referential integrity. Attributes like phone numbers and email addresses are modeled as separate related entities or multi-valued attributes to represent multiple contact options effectively.

Reflections on the Database Design

The design reflects a logical and normalized structure suitable for the college's operational requirements. It captures essential data points for students, courses, and instructors while establishing relationships that mirror real-world associations. The inclusion of an associative entity for enrollments allows for flexibility in tracking multiple courses per student and associated grades, aligning with typical academic record-keeping practices.

However, some assumptions were necessary to streamline the design. For example, we assumed that each course section is taught by a single instructor and that an instructor's expertise is limited to the courses they are qualified to teach, which is modeled through a qualification attribute or related table. Communication contact information for students and instructors is modeled to handle multiple entries, assuming that contact types are discrete and mutually exclusive.

Assumptions and Limitations

In making this design, a key assumption was that the college's data encompasses multiple contact methods per individual, which influenced the modeling of phone numbers and email addresses as separate multi-valued attributes or related entities. Additionally, the design presumes that course offerings are repeated across multiple quarters, necessitating the inclusion of a quarters offered attribute. The model assumes a straightforward reporting structure for final grades, linked to the enrollment entity, simplifying the grading process to a single grade per student per course.

Limitations of the current design include potential oversimplification of instructor qualifications and course scheduling nuances, which could be expanded with additional attributes or entities in a more detailed model. Despite these limitations, the design provides a solid foundation for managing core college data and can be extended as needed.

Conclusion

The overall design effectively captures the core data requirements of the college, transforming the initial specifications into a structured ERD that supports data integrity and future scalability. The assumptions made were necessary to bridge gaps in the scenario description and to facilitate a logical, normalized database schema that aligns with best practices in data modeling. Future iterations could explore more complex scheduling, role-based access control, and additional business rules to enhance functionality.

References

• Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377-387.