Essentially, it is a CRUD based application, which means that you have a number of tables and then you have the ability to make changes. Like I mentioned in the requirements video, the main element I wanted you to focus on is the concept of breaking out tables into smaller tables, because when it comes to building an enterprise-level application, you really want to make sure that you're building well-structured relationships.

The Parts and MaintenanceParts classes are a great example. You can see that this could be accomplished in a few different ways. Technically, MaintenanceParts is a type of Part, so this could be subclassed, but just because you have the ability to use inheritance does not necessarily mean that you should or that you need to. It just comes down to personal preference.

The main type of behavior that I like to model inside a class diagram is my database. This is where I can set up my associations and break my tables up into as many pieces as I need. For example, could we have connected Parts directly with the ServiceList? Technically yes. However, what happens if the fleet management system does really well and they want to start adding the parts that they use when they're going out to perform their work. If we ever needed to start adding in the list of parts from the inventory for their other services, that would not fit inside of MaintenanceParts. We would have to go back and create another class for their other types of parts. By separating this out what we can do is allow our system to be more scalable in the future.

There's only one other element that I want to focus on in this diagram because we haven't really seen it too much: a one-to-one relationship. I've personally worked on a number of projects where this type of construct of having a one-to-one relationship was one of the most helpful things in regards to how I set up the system. The reason for that is navigability. For example, we can call a Vehicle object and then just ask, "What car model are you?" I can just call a Vehicle and it's a direct navigation point to the CarModel class.

There are many times where I've seen students who thought that every relationship had to be either a one-to-many or a many-to-many relationship, and I think part of that is because it's probably the most common kind of set up. However, there are many times where you do not need to have a one-to-many relationship. Because of that, you can clean up your entire codebase because it's much easier for one object to communicate with another object.