Projects People Resources Semesters Blog About
Projects
Projects
💽

Data Design

Last Updated: 31 January, 2023

Slides 🖼️

Data Design was last presented during Hack Session 2 in Spring 2023 by

Why 🤔

Designing your data in a smart way makes programming much easier! It will save you time and prevent you from having to sovle unncessary, complex problems. This is because you would have already thought about many of the tough technical questions on how to create your project and model it’s data.

What 💽

Think about what needs to be stored and how each property of each data type needs to interact. For example, if you were creating a social app where users could share invites to events you might break down your data like this:

  • Users
    • UUID: String
      • The unique identifier for the user.
    • Name: String
      • The name of the user.
    • Email: String
      • The email address of the user. Important for ensuring each user is unique, and there is a way to contact users to notify them.
    • Events Hosted: [List-of UUID]
      • List of the Events (by UUID) which the user is the host of.
    • Events Attended: [List-of UUID]
      • List of the Events (by UUID) which the user has attended.
  • Events
    • UUID: String
      • The unique identifier for the event.
    • Title: String
      • The title of the event.
    • Location: Address
      • Where the event is taking place. Custom data type that needs to be defined. Will be stored in the database as JSON.
    • Time: Int
      • When the event is taking place. Will be stored in the database as Time Interval (in seconds) since Jan. 1, 1970.
    • Host: UUID
      • The UUID of the host user.
    • Guests: [List-of UUID]
      • List of UUID’s of each of the guest’s UUID’s.

How 🪛

You can represent your data design in a variety of ways. One common method is to convert the list above into a UML Class Diagram. Class Diagrams showcase Facts, Constraints, and Relationships.

  • Facts: What is everything?
    • Different attributes for each entity, their types, and their titles are all examples of facts.
  • Constraints: Are there limitations?
    • “There can only be 1 CEO”, “ID’s must be 7 digits”, and “A project must have at least one task” are all examples of constraints.
  • Relationships: How does each Entity relate?
    • A CEO manages a Project, controls a Report, and assigns things to Employees. These are all examples of relationships.

Rules of Thumb 👍

  • Model data as it is in real life.
    • Going against real-world representations can create needless complexity. To simplify, think about what elements of real life you actually need to include. Often, we add far too many fields to our structures when only a select few are necessary.
  • To model is to simply— you don’t need everything
    • The goal of modeling is to simplify the real world. Model relationships and constraints as they benefit your project— not just to perfectly replicate every small detail of the real world.
  • If you don’t have a reason for it, you don’t need it (yet)
    • You can always add attributes to entities. You want small, reusable components to start with.
  • Naming is hard! Take your time; be deliberate.
    • If your names don’t quite mean what you think they do, it can make it harder to solve problems becuase the real-world meaning will get mixed up with the project’s meaning.