Entities, attributes and relationships

Data modelling starts by identifying the things your system needs to remember, what you need to know about each, and how they relate.

Entities

An entity is a kind of thing with its own identity that the business cares about. A useful technique is to read requirements and underline the nouns. From the clinic platform brief:

"Clinics list their practitioners and the services they offer. Patients book appointments for a service with a practitioner at a clinic. Patients pay for appointments, and may leave a review after a completed appointment."

Candidate entities: clinic, practitioner, service, patient, appointment, payment, review.

Not every noun is an entity. Some are attributes of something else. "Price" is a property of a service, not a thing with its own identity. Ask: does it have its own life cycle, its own identity and several attributes? If yes, it is probably an entity.

Attributes

Attributes are the facts you store about an entity. For a patient: name, date of birth, email, phone. For a service: name, duration in minutes, price.

Good attributes are atomic: they store one fact. A single "address" field mixing street, city and postcode makes it hard to search by city or validate postcodes. Whether to split depends on how you use the data. If you never search or validate by city, one field might be fine. Decide deliberately.

Watch for attributes that are really relationships. "Clinic name" stored on a practitioner is a hint that practitioner relates to clinic.

Relationships

A relationship describes how entities connect, ideally with a verb:

• A clinic employs practitioners.
• A clinic offers services.
• A patient books appointments.
• An appointment is for a service, with a practitioner, at a clinic.
• A payment settles an appointment.
• A review is written about an appointment.

Writing relationships as sentences surfaces questions. Does a clinic employ practitioners, or can independent practitioners work at several clinics? Our domain expert says practitioners can work at several clinics, which changes the relationship from one to many into many to many.

Identifying the hidden entities

Many to many relationships often hide an entity. "Practitioners work at clinics" becomes a clinic membership with its own attributes: start date, role, which days they work there. Recognising these hidden entities is one of the most valuable modelling skills.

Write it down

Create a simple list with each entity, its key attributes and its relationships in sentence form. Review it with someone who knows the domain before drawing any diagram. Mistakes caught here cost minutes; caught after launch, they cost weeks.