✍️
Team FitBob
  • Introduction and Foreword
  • Motivation
  • Features
  • Tech Stack
  • Software Engineering Practices
    • Requirements
    • Software Design Patterns
      • Model View Controller (MVC)
      • Abstraction Occurrence Pattern
  • Deployments
    • Trying Our App
  • Activity diagram
  • Frontend
    • Login
    • User Registration
    • Client Screens
      • Client Dashboard
      • Client Profile
      • Eating History
      • Meals
    • Personal Trainer screens
      • Personal Trainer Profile
      • Personal Trainer Dashboard
        • Clients
        • Meal plans
        • Meals
    • Recipe screens
    • Search screen
    • Searching for Restaurants
    • Notes on BeautifulSoup and Flask
    • Request/Success/Failure Cycle
  • Backend
    • Notes on Django
    • API
    • Entity relationship diagram
  • Testing
    • User Testing
    • Backend
  • Project Limitations and Constraints
  • Closing Thoughts.
  • Project log
  • Poster
Powered by GitBook
On this page
  • One to One relationship
  • Many to One relationship
  • Many to Many relationship

Was this helpful?

  1. Backend

Entity relationship diagram

ERD for freshie's database

PreviousAPINextTesting

Last updated 3 years ago

Was this helpful?

The entity relationship diagram is a structural diagram that shows how the database is designed. The boxes in the relationship depict the model and its fields, and the lines depict how they are related to another model.

To begin, we can look at the User model. We extended the AbstractUser model that Django provides, which can be seen by the arrow pointing towards the AbstractUser model. We added an extra field to the User model, which is the isPersonalTrainer field.

One to One relationship

Many to One relationship

Many to Many relationship

As we have gone through all the relationships in our ERD and what they signify, we feel that being able to visualise the database in such a way helps us to understand and hence effectively use the relationships between the models to obtain the data we need without needing extra steps or tables.

Focusing on the different types of users, we can see two lines extending from the top left corner of the user model. Each of these lines depict the relationship between the user model and thePersonalTrainer/Client model. Take note that the lines do not have any arrow or a circle at the end as they have a . This means a user can only either be a PersonalTrainer/Client.

There is also a relationship between the Client model and the PersonalTrainer model. They are connected by a line with a circle at the end. This line represents the . This means that a client can only have one personal trainer, but a personal trainer can have many clients.

Lastly, there are also lines which have circles on both ends of the line. These lines signify the . To explain what this relationship is, we should look at the relationship between themealPlan and Recipe model. A meal plan is a plan that can consist of one or more recipes, therefore it would make sense that a meal plan has many recipes. On the other hand, meal plans may consist of different recipes, but it is possible that 2 meal plans share the one or two of the same recipes. In that case, a recipe will also be required to belong to many meal plans. Hence, the Many to Many relationship is use to relate the two models.

One to One relationship
Many to One relationship
Many to Many relationship
generated using djanog-extensions and graphviz