Model design guidelines

Use Lucid Chart to document your model design

The “model design” consists of the entities and relationships between them.

LucidChart is a free plugin for Google Docs. Once installed, you can click on the “More Shapes” button, then check “Entity Relationships” to enable: (a) special Entity boxes, and (b) new line ending shapes corresponding to Crow’s Foot relationship diagrams.

Generally, a very simple ER diagram just showing the entities and relationships is enough to establish how the Java model classes will look. For example:

Use crow’s foot notation

There are many different ways to represent the relationships between entities. For this class, please use crow’s foot notation (which, conveniently, is what Lucid Charts provides).

Crow’s foot notation consists of a pair of icons at each end of a line. The “outer” icon represents the “maximum” value, and the “inner” icon represents the “minimum” value:

This indicates that a specific garden instance can have zero or more plant species in it (because some gardens might be “brand new” and consist only of dirt). However, every instance of a plant species (for example, Digitalis Purpurea) is associated with at least one garden (i.e. we don’t create a plant species in the database unless there’s a garden instance that uses it).

Note that Lucid Charts also provides a one-to-one and one-to-many relationship notation that does not specify the minimum cardinality:

Do not use the above notations in your diagrams! Instead, use the notations that include the minimum cardinalities as well, as this provides more information to the reader:

Now you can see that a Prescription instance cannot exist without being associated with a Person instance, but a Person instance can exist without any associated Prescription instances.

Heuristics for entity identification

Entities should be:

Entities should not:

Heuristics for relationship identification

One to one relationships

The major issue you will have with one-to-one relationships is whether to actually specify the relationship at all, or else simply provide the data as fields within the entity instance. For example, consider an entity type Person where each Person instance has an address consisting of a street, city, state, and zip code. Should you specify the address data as fields in the Person entity, or should you create a separate Address entity type?

There is no single answer to this question: the right choice depends upon how you intend to use the data. For example, it would be better to specify the Address as its own entity type if: