nsa10124,
When we talk about entity-relationship models, we are talking about building a logical / mathematical model of your business as a dynamic flow of data from beginning to end with many potential steps along the way.
Each type of "thing" you work on will be an ENTITY in the model. A table represents a list of entities of the same type. The idea is that if you treat two "things" the same way, even if they are different things, they are the same entity in the model. So if you treat trucks and SUVs exactly the same, then despite minor differences in their description, they are the same entity. And if you treat them radically differently, they are different entities. Although what I really think is that ALL vehicles have enough in common to be treated as the same entity but they might have a list of potential maintenance actions that depend on vehicle type as described in a secondary child table or reference table.
Here is an off-the-cuff example:
You have people who perform the maintenance. You might call them "mechanics" and have a table of mechanics. They are different people but the same entity.
You have vehicles to be maintained. You might call them "vehicles" and have a table of vehicles. They are different vehicles but the same entity - and different from the entity called "mechanics" because you do different things with mechanics vs. vehicles. Differences in treatment are the key to knowing they are different entities.
You have equipment that might be assigned to the use of individual mechanics. So you would have an equipment table representing a third type of entity. And, because you assign the equipment to mechanics, there is a natural relationship between members of the mechanics table and elements of the equipment table.
You might have a maintenance job where you assign a vehicle to a mechanic. This job table would be a trackable, if somewhat less physical, entity. You track it because you want to keep records of maintenance. So this job table would have relationships (plural) - to the vehicle being maintained and the mechanic who maintained it. (This is also an example of what Access calls a Junction table, which you can look up on this forum.) The job table would also have a status such as "Scheduled" or "Assigned" or "In Work" or "In Inspection" or "Maintenance Complete" ... as need for each job.
When I mentioned "data flow" issues, the data flow for your problem starts with your vehicle inventory, equipment inventory, and mechanic employees. The "flow" is based on the "job" order that brings mechanic (and his/her equipment) together with a vehicle.
Read over this and see if it suddenly snaps into focus as a logical description - at a very high level - of what your business does. It will get a lot more complicated, but remember the example of Julius Caesar - divide and conquer. Break it all down into simple steps.
Understand that I just planted seeds, but YOU have to build the garden. And, like any other gardener, you'll occasionally encounter a pile of poop to be managed. (How do you think gardens stay green?)
