# 15.00 - Taking the “Partial Nothing” Argument To Its Logical Extreme - Teradata Database

## Teradata Database Design

prodname
vrm_release
15.00
category
User Guide
featnum
B035-1094-015K

### Taking the “Partial Nothing” Argument To Its Logical Extreme

Consider the following classic case study: an employee table that records the salary of each employee currently working for the enterprise. It is not uncommon for salaries to be unknown at a given point, so an employee row might contain a null to hold the place of the true salary of that employee. At the time the rows is inserted into the table, the salary value is missing information.

At a given instant, this employee table might look like this:

 employee emp_num emp_name dept_num hire_date salary PK 214 Smith 32 09-12-1989 56150 447 Lau 15 05-30-1993 ? 103 Hossein 09 09-13-1984 29775 500 Nakamura 11 06-09-1997 84932 713 Schroeder 24 10-29-2001 ?

New hire Schroeder has not yet been assigned a salary and Lau has just been promoted, but her new salary has not yet been determined.

Pascal argues that in reality, this “partial nothing” information is no more useful than the following “partial nothing” table, for which only the primary key values known for each row.

 employee emp_num emp_name dept_num hire_date salary PK 214 ? ? ? ? 447 ? ? ? ? 103 ? ? ? ? 500 ? ? ? ? 713 ? ? ? ?

Pascal argues that the problem with the “partial nothing” table is that its semantics are perceived as something other than what they truly are. The intended meaning of the nulls in the salary column derives from the true proposition that all employees receive a salary. The formal semantics of the table, however, assert only that a salary amount exists for each employee.

As a result, the table actually represents a mix of two different categories of assertion:

• Those rows with nulls that apply to all employees (“a salary amount exists for all employees”).
• Those rows that describe only those employees whose salaries are known (“all employees receive a salary”).
• Another way of saying this is that multiple, inconsistent, informal predicates are being mapped (incorrectly!) into a single formal predicate. In this particular case, some rows (those containing nulls as place holders for the salary value) apply to all employees, while others (those that contain values for employee salaries) apply to a subset of that population. No single predicate can possibly apply to both situations.