Data Modelling Do’s and Don’ts

Some Do’s and Don’ts of Data

Modelling and Database Development

Some Examples
Data Modelling Do’s and Don’ts

No Cyclic/Transitive Dependencies
• Cyclic Dependencies can cause data duplication leading to
error Appointment Client

Specialist

CLIENT SPECIALIST APPOINTMENT

client_no name spec_no name app_id client* specialist*
C1 Fred S1 Judy Appt01 C1 S1
C2 Jane S2 Trevor Appt02 C1 S2
Appt03 C2 S1
• So we do not need the relationship between client and
specialist
• Otherwise we will duplicate information and introduce the
potential for integrity errors
Data Modelling Do’s and Don’ts

Singular Entity Names

• Use Singular Entity names where possible
• Otherwise you will probably get the cardinality of your
relationships wrong
Appointments Clients

Specialists

• e.g. this nonsensically says “clients make many

appointments and each appointment is with one
specialists, and each appointments is with one
clients”?????
Data Modelling Do’s and Don’ts

Get your cardinality and optionality

right
• Booking must have a customer, but may have a
therapist
customer booking therapist

‘Mandatory

‘Optional’,
‘null’ keyword
not necessary
Data Modelling Do’s and Don’ts

Some Do’s and Don’ts of Data

Modelling and Database Development

Part Two
Data Modelling Do’s and Don’ts

Data Dictionary
• How many errors can you find with this table?

TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
id NUMBER 3 Not Null PK
client_id VARCHAR 3 Not Null
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
address VARCHAR 30 Not Null
dob VARCHAR 10
telephone_no NUMBER 13
gender VARCHAR 10 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Data Dictionary
1. Always choose a natural primary key
• There is no need to create a separate id attribute when
client_id is a suitable primary key
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 3 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
address VARCHAR 30 Not Null
dob VARCHAR 10
telephone_no NUMBER 13
gender VARCHAR 10 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Data Dictionary
2. Think about data sizes
– 3 digits for client id means ‘999’ clients maximum, is
that enough?
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 5 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
address VARCHAR 30 Not Null
dob VARCHAR 10
telephone_no NUMBER 13
gender VARCHAR 10 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Data Dictionary
2. Think about data sizes
• Why do we need 10 digits to store ‘M’ or ‘F’ for the
gender?
• We should use data type CHAR for fixed length strings,
and VARCHAR for variable length strings
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 5 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
address VARCHAR 30 Not Null
dob VARCHAR 10
telephone_no NUMBER 13
gender CHAR 1 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

CHAR or …… VARCHAR?

 
Data Modelling Do’s and Don’ts

Data Dictionary
3. Split data such as addresses into separate fields to
aid searching
• And certainly more than 30 characters to store an
address!
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 5 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
street VARCHAR 30 Not Null And think about
town VARCHAR 20
use of Null/Not
postcode VARCHAR 8 Not Null
null
dob VARCHAR 10
telephone_no NUMBER 13
gender CHAR 1 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Addresses….
• This is wrong…

Query returns no data unless we use

pattern matching within the string
• This is better

This allows us to return the

correct matching data
Data Modelling Do’s and Don’ts

To Null or not…?
• Use null/not null appropriately
– enforces a constraint which can reduce efficiency
– but increases integrity
– Remember can also enforce optionality
Data Modelling Do’s and Don’ts

Some Do’s and Don’ts of Data

Modelling and Database Development

Part Three
Data Modelling Do’s and Don’ts

Data Dictionary
4. Some numeric data needs to be VARCHAR
• Telephone, account numbers, etc., can start with 0
• And put it in quotes when inserting in SQL, ‘01234…’
• Otherwise you still lose the leading ‘0’
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 5 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
street VARCHAR 30 Not Null
town VARCHAR 20
postcode VARCHAR 8 Not Null
dob VARCHAR 10
telephone_no VARCHAR 13
gender CHAR 1 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Data Dictionary
5. Some numeric data needs to be VARCHAR
• Telephone numbers, etc. can start with 0
• And put it in quotes when inserting in SQL, ‘01234…’
• Otherwise you still lose the leading ‘0’, e.g.

The 0 has disappeared

from the start of the
telephone number
Data Modelling Do’s and Don’ts

Data Dictionary
6. Think carefully about data types, and what is
available in your DBMS
• Oracle and most DBMSs provide a DATE type (which
may or may not include time – if it does then there is no
need for a separate attribute)
TABLE Client
Format/
Attribute Name Data Type Size Null/Not Null PK/FK Constraints
client_id VARCHAR 5 Not Null PK
firstname VARCHAR 20 Not Null
lastname VARCHAR 30
street VARCHAR 30 Not Null
town VARCHAR 20
postcode VARCHAR 8 Not Null
dob DATE
telephone_no VARCHAR 13
gender CHAR 1 ‘M’ or ‘F’
Data Modelling Do’s and Don’ts

Data Dictionary
7. And be careful with data sizes and the use of real
numbers for numeric data
• 10 digits is £9,999,999,999, i.e. 10 billion pounds
• VARCHAR is for strings, not numbers
• And we need to specify if we want decimal digits, e.g.
NUMBER(5,2)
TABLE Client
Attribute Name Data Type Size Null/Not Null PK/FK
OrderNo VARCHAR 8 Not Null PK
ItemCode VARCHAR 5 Not Null FK (Item.ItemCode)
Quantity VARCHAR 3 Not Null
TotalCost NUMBER 10 Not Null
Data Modelling Do’s and Don’ts

• Notice the rounding error….

Data Modelling Do’s and Don’ts

Currency
8. And we don’t need to store the currency symbol
• It will stop us doing calculations
• And we can always include it in a query
Data Modelling Do’s and Don’ts

Some Do’s and Don’ts of Data

Modelling and Database Development

Part Four
Data Modelling Do’s and Don’ts

Duplicate Data

• Don’t duplicate data across tables – leads to

integrity errors
Cust First Last Booking Booking Cust First Last
No Name Name No Date No* Name Name

C01 Fred Smith B001 02/10/2022 C01 Fred Smith

B002 03/10/2022 C01 Jane Smith
Data Modelling Do’s and Don’ts

Dropping your objects…

• Always drop tables/views, etc. in reverse order to
how you created them – even if you use cascade
constraints it’s still more efficient
Data Modelling Do’s and Don’ts

To Like or not To Like

• Use of LIKE is for pattern matching where you
are matching against an incomplete string, e.g.
– WHERE town LIKE 'Tyne%'

• Don’t use LIKE for complete strings

– e.g. WHERE town NOT LIKE 'Tynemouth’ 
– It’s less efficient and not good practice
– Use normal comparison operators instead, e.g. = or <>
– e.g. WHERE town <> 'Tynemouth’ 
Data Modelling Do’s and Don’ts

Don’t forget to Join…

SELECT b.branch_no, b.br_street, SELECT b.branch_no, b.br_street,
s.branch_no, s.staff_no, s.branch_no, s.staff_no,
s.staff_forenames, s.staff_surname
s.staff_forenames, s.staff_surname
FROM branch b, staff s
FROM branch b, staff s;
WHERE b.branch_no = s.branch_no;
Data Modelling Do’s and Don’ts

And finally…

• There will be many others which will be added in

the future!