The Relational Model1 Nulls A dilemma

The Relational Model2 The Real World Situation A common situation “Date of birth not given” “Present whereabouts unknown” “Date to be announced” We must handle them!

The Relational Model3 A Design Temptation Common “shortcut” Typical scenario entities A and B differ only in that A has an attribute X which B lacks create one table C, make X null for all Bs The DB is not supporting a good model code will be required in many places Tables and joins are “cheap” code is expensive (not least due to bugs)

The Relational Model4 The Theoretical Situation Nulls have challenging mathematical properties Authorities disagree on them Kroenke largely ignores them but is positive Date talks a lot about them and is violently opposed to them There is theory for them

The Relational Model5 What are Nulls - characteristics Null is not a value avoid “null value” It is the explicit absence of a value may have several real-world interpretations Different from zero bank balance example Different from “blank” defendant's reply example

The Relational Model6 Where can we have them? We will know from our requirements specification some values we must have DBMS have ways of identifying attributes like this SQL has “NOT NULL” Access has “Required”

The Relational Model7 In candidate keys? Makes no sense in real world terms Cannot uniquely identify tuple because NULL  NULL Traditionally disallowed System prevents it Compare two nulls: both attributes have real values we don’t know them can’t say they are equal

The Relational Model8 In Foreign Keys? Are traditionally allowed Can handle the employee/supervisor case CEO’s supervisor attribute is null Access allows it by default can make the attribute(s) “Required”

The Relational Model9 Left, Right and Outer Joins Explicitly generate nulls Causes some theoretical problems can cause real problems of interpretation Can be in a generated primary key

The Relational Model10 Default values Some suggest these are the better way Date Give it a “silly” value if you don’t know the real one ******! (c.f. Millenium bug) A silly value is not automatically distinguishable from a proper one Null can be properly detected others must be checked in application code must be done every time

The Relational Model11 3-valued logic The way null is often handled Scalar attribute A > B TRUE or FALSE If A or B or both are null, the answer is “UNKNOWN” ( or “UNDEFINED”) Applies to all comparison operators

The Relational Model12 Maybe We need a Maybe “all suppliers (known to be) in Singapore” + “all suppliers (known to be) not in Singapore”  “all suppliers” what about “all suppliers who may be in Singapore” ? Two-valued logic not applicable

The Relational Model13 So when should I allow them? 1) When the enterprise model has unknowns 2) When only one meaning is implied, and two-valued logic is not implicitly used

The Relational Model14 When should I disallow Nulls? Avoid NULLs when trying to represent several states, e.g. Missing value Below detection limit Value out of range Not applicable case NULLs in foreign keys? Legal, but (pto) Date is right – NULLs don’t fit into the relational model without introducing complications and inconsistencies

The Relational Model15 NULLs in foreign keys Can represent optional relationships by introducing new tables, rather than through mandatory relationships with nulls During the optimisation stage, it may be decided to relax this rule, and introduce nulls (typically when missing values occur very infrequently). “Null means no relationship” i.e. one specific meaning

The Relational Model16 Indicator Attributes The user can “extend” a domain (e.g. telephone number) to include an extra ‘Indicator’ or ‘Status’ attribute, and regard (Telephone#, Status) as a single value. Both attributes will be assigned values, always, thereby avoiding nulls. In an actual query, first test that the Status is ‘valid’ before extracting an actual telephone number.

The Relational Model17 Indicator Value Example TelStatus Valid 0000Unknown 0000Ex-directory Valid 0000No_phone Only number with Status=Valid are true phone numbers Other entries are arbitrary, but never null Status is never null