This week we were lucky to have a relatively simple set of WODs which focused on data design and generating Entity Relationship Diagrams. Although simple, this topic is extremely important and necessary for next weeks lesson, Data Design Implementation. Since I’ve studied this material in the past, this was a great (and very much needed) review.
WOD 1: Library Data Model
In our first WOD, we were tasked with designing a data model for the typical library system. In this system, the library holds multiple copies of books. Patrons, who are either students or faculty members, can borrow and reserve up to 5 books. This system must be designed to meet the following requirements:
- Check whether a recently returned book has been reserved
- Check which borrower has a specific book on loan
- Check which books are currently with a specific borrower
- Check the status of a particular book (borrowed/not borrowed)
- Check which reservation should receive a recently returned book
- Retrieve the loan and reservation history for a book
Since I’ve studied data design in previous classes and I’ve worked with Lucid Charts before, I found this WOD fairly easy to accomplish. I finished my first and only attempt in Av time of 15 minutes and 38 seconds. Here is the Entity-Relationship Diagram I drafted for this problem which, I believe, meets the required specifications:
WOD 2: Car Rental Data Model
The Second WOD was similar to the first but a bit more challenging. We were instructed to create an ERD for a car rental company. The company has a number of offices in various cities and locations. Each location has a set of vehicles, each vehicle can be categorized into one of five vehicle types (i.e. Economy, Standard, Van, Box Truck, Cargo Van). Customers can reserve a vehicle at a specific location for a set date and time. When the vehicle is returned, the car rental clerk records the date, time, odometer reading and gas level.
Like the previous WOD, I was able to finish my first and only attempt in AV time of 14 minutes and 35 seconds. While my solution varies slightly from that presented by the professor, I believe that it provides a satisfactory design for this data model. Here is my ERD:
Conclusion
The exercises this week were fairly simple to accomplish but we can easily see how models can quickly get complicated as the data and relationships become more complex. In the application that I am building for the final project, I already know that I am going to have at least 4 different entities: Users; News subscriptions; Commute subscriptions; and Blog subscriptions, however, this number may change. Representing my data model as an ERD will undoubtedly be helpful and provide direction when I eventually take on the task of implementing the backend database.
Rob Namahoe 