Defining Entities and Attributes in Data Modeling

Previously in this course, we explored Introduction to Database Design: Schema Basics for SaaS and learned how to perform Requirements Gathering for SaaS: Identifying Core Entities to extract the nouns that drive our business. Now, we move from identifying these concepts to defining their technical shape.

In this lesson, we will formalize those "nouns" into entities and flesh them out with attributes, ensuring every piece of data has a clear purpose and a defined type.

From Concepts to Data Modeling

In data modeling, an entity is a person, place, object, or event about which we want to store data. If your SaaS project involves users signing up and paying for a service, "User" and "Subscription" are your primary entities.

Attributes are the specific details that describe an entity. If "User" is the entity, its attributes might be email, first_name, and created_at. Think of the entity as the table and the attributes as the columns in a spreadsheet or database.

Categorizing Attributes by Data Type

Before we write a single line of SQL, we must decide what kind of data each attribute holds. Choosing the right data type is the difference between a performant database and one that crashes under pressure.

Worked Example: Modeling the SaaS User

Let’s apply this to our running project. We need to store information about our SaaS users. Based on our requirements, here is how we define the User entity and its attributes:

• Entity: User
• Attributes:
  • user_id: Unique identifier (Numeric)
  • email: User's login address (String)
  • password_hash: Securely stored password (String)
  • is_active: Status flag (Boolean)
  • created_at: Date/time of account creation (Temporal)

Practice Exercise

Take the "Subscription" entity from your own project requirements. List at least four attributes for it, assign them a logical data type, and explain why you chose that type.

Example:

• plan_name (String): To store descriptive names like "Pro" or "Enterprise."
• monthly_price (Decimal): To handle currency accurately without rounding errors common in floats.

Common Pitfalls in Schema Design

Even experienced engineers fall into these traps when defining attributes:

1. Over-normalizing or "Under-typing": Storing everything as a TEXT string is a lazy habit that prevents the database from performing math or date-based filtering efficiently.
2. Mixing Concerns: Including attributes that don't belong to the entity. For example, putting shipping_address in the User table is a mistake if a user might have multiple addresses; that should be a separate entity.
3. Ignoring Precision: Using FLOAT for financial data. Always use DECIMAL or NUMERIC to avoid floating-point math errors that cause pennies to vanish from your billing reports.

FAQ: Entity and Attribute Best Practices

Q: Should I use abbreviations for attribute names? A: Keep names descriptive and readable. user_email is better than ue. Consistency is more important than brevity.

Q: How do I handle optional data? A: If an attribute isn't mandatory (e.g., middle_name), it simply becomes a "nullable" attribute during the physical design phase.

Q: Can an attribute be an entity itself? A: If an attribute starts to require its own attributes (like an address that needs street, city, and zip), it is often a sign that it should be promoted to its own entity linked by a relationship.

Recap

We have moved from abstract business requirements to concrete entity definitions. We now know that entities represent our core objects, while attributes define the specific details we track. By categorizing these attributes into numeric, string, temporal, or boolean types, we prepare ourselves to build a schema that is both performant and accurate.

Up next: Understanding Relationships — we will learn how to connect these entities to make your data model truly relational.