In this article we continue our simple data modelling example.  We have named our database table, and now we need columns to store the information about each pot.

Naming columns is another minefield, just like naming tables. All sorts of logic can be applied to avoid naming conflicts and ensure consistency. We will ignore this also, for the time being.

Let us simply say that this is our database, only we will be looking at it, and other people’s opinions do not matter! I choose to use column names entirely in capital letters and to give them names that suit me – as shown in the table below.

Simple Data Modelling Example

Column Name Description 
TYPE
 Type of pot. 
SIZE
 Size of pot. 
AVAILABLE
 Is pot available for use? 
DIRTY
 Is pot dirty?
(Hmmm. If so, is it AVAILABLE too?)

This is our first cut at modelling our pots and pans.

Items in the cupboard

Let’s look at some examples of the things you might find in your cupboard.

Saucepan



Hahn 16cm Saucepan
www.cooksandkitchens.co.uk CC-BY-2.0

Column Name Value 
TYPE
 Saucepan 
SIZE
 16cm 
AVAILABLE
 Yes 
DIRTY
 No

Egg Poacher



Metallic single egg poacher
© Marie-Lan Nguyen / Wikimedia Commons / CC-BY 2.5

Column Name Value 
TYPE
 Poacher 
SIZE
 1 egg 
AVAILABLE
 Yes 
DIRTY
 No

Frying pan


pan
Frying pan

Column Name Value 
TYPE
 Frying pan 
SIZE
 20cm (base) 
AVAILABLE
 Yes 
DIRTY
 No

Would our modelling be useful?

All of the pots and pans in our cupboard can be recorded in this way. One database row for each pot or pan.

We could use our data to see what would be the best pot or pan for what we are about to cook. Once we tried to use it in this way, we would start to realise immediately that we are missing some of the information we need. Imagine we want to make some fried eggs. How do we decide which pot or pan to use?

We can look through all the pots and pans in our database. This is little different from looking through our cupboard. It depends on us knowing exactly what we want to do, and what the equipment can do.

Alternatively, we can search for ‘fried’, but none of our fields includes this text. We would need some better way of searching.

Probably the best way to proceed is to extend our model. We need to know what each pot can be used for. Frying, BBQing, boiling, blanching, etc.

Some modelling questions to think about

The above examples show a simple model of cooking pots and pans with a few specific types of pots and the values that could be used. However, not everything is always obvious, so here are some questions to think about.

  • What if each pot/pan is a different TYPE? With no duplicate values, how useful is searching?
  • What data type should be used for the TYPE column?
  • Problem with AVAILABLE and DIRTY? How do they interact?
  • What data types should we use for AVAILABLE and DIRTY?
  • What data type should be used for SIZE and what does it really store?

When a pot is DIRTY, it may well depend on just how dirty it is whether you would consider it AVAILABLE or not, or it may depend on what has been cooked in it whether you want to re-use it without some specific cleaning first. In short, what can seem like a simple question does not always end up simple. Jewish laws about food can seem complex to those of us who are not Jewish, but let’s look at some as examples of unexpected interactions. For example, if a dead lizard ended up in a pot, the pot was unclean and must be washed, but it could not be used again until evening (Leviticus chapter 11 verses 29-33). So your pot might be DIRTY, but not AVAILABLE because of the lizard. Interactions between fields can make modelling difficult. Another example from the same law is that if the pot was made of earthenware, then not only was it unclean, but it must be destroyed. One fewer pot in your cupboard. Maybe you would need to have a MATERIAL column, not just TYPE. This is another challenge of data modelling.