Создание объектов для хранения данных. Работа с ограничениями

Задание ограничений NOT NULL на значения колонок

При определении спецификаций колонок таблиц проектировщик базы данных должен рассмотреть ограничения, которые могут быть наложены на значения колонок. В реляционных СУБД этих ограничений предусмотрено достаточно много. Здесь мы остановимся на одном из главных ограничений такого рода - это обязательность присутствия значения в колонке. Такое ограничение на значение колонки называется NOT NULL ограничением.

Предопределенное значение колонки, равное NULL, означает, что в данный конкретный момент для данной конкретной строки (экземпляра сущности предметной области) значение не определено, или не известно, или отсутствует. Проектировщику базы данных необходимо идентифицировать возможность колонки принимать NULL -значения, т.к. пользователи могут иметь проблемы при использовании таких колонок. Примером этой проблемы может служить ситуация, в которой пользователю требуется выполнить соединение двух таблиц по колонкам, имеющим NULL -значения. При выполнении таких соединений любые строки, которые содержат NULL -значения в колонках соединения в любой из таблиц, не будут показаны в результирующей выборке для запроса. Подобная потеря данных может привести к тому, что пользователь получит неправильную выборку на запрос, особенно если ему необходимо видеть все строки хотя бы одной из таблиц.

Примечание. Одним из способов решения определенной выше проблемы является использование внешних соединений.

При назначении NULL -значений колонкам проектировщику базы данных необходимо принимать во внимание следующие факторы.

• Колонки, являющиеся частью составного первичного ключа, всегда должны иметь ограничение NOT NULL, т.к. согласно реляционной теории значения колонок первичного ключа должны быть определены и уникальны для каждого кортежа.
• Внешние ключи должны также определяться как NOT NULL, поскольку дочерняя таблица зависит от родительской и внешний ключ родительской не может иметь NULL-значения. Это следует из того, что существование строки дочерней таблицы без соответствующей строки родительской таблицы нарушает правило зависимости связи. (О внешних ключах, родительских и дочерних таблицах см. далее.)
• Только внешние ключи для таблицы с опциональной связью могут рассматриваться как кандидаты на наличие NULL -значений, чтобы показать, что для данной комбинации родительской и дочерних строк в этих таблицах связи нет.
• Внешние ключи с правилом удаления SET NULL должны определяться со спецификацией NULL.
• Используйте спецификацию NOT NULL WITH DEFAULT для колонок с типами данных DATE или TIME, чтобы сохранять текущие даты и текущее время автоматически.
• Разрешайте использовать NULL -значения только для тех колонок, которые действительно могут иметь неопределенные значения.
• Используйте NOT NULL WITH DEFAULT для всех колонок, которые не подпадают под перечисленные выше правила.

Пример. Как можно увидеть ниже, проектировщик базы данных определил, что:

1. дата поступления служащего в организацию HIREDATE определена со спецификацией NOT NULL WITH DEFAULT, которая означает, что если на вводе значение колонки не определено, то по умолчанию подставляется текущая дата;
2. номер подразделения DEPNO, номер служащего EMPNO и номер проекта PROJNO имеют спецификацию NOT NULL как первичные ключи таблиц;
3. для остальных полей базовых таблиц проектировщик базы данных принял решение разрешить наличие в них NULL -значений.

CREATE TABLE DEPARTAMENT 
( 
	DEPNO 	integer NOT NULL, 
	DNAME 	char(20),
	LOC  		char(20),
	MANAGER 	char(20),
	PHONE  	char(15),
	PRIMARY KEY (DEPNO)  определение первичного ключа
);
 
CREATE TABLE EMPLOYEE
(
	EMPNO  	integer NOT NULL,
	ENAME  	char(25),
	LNAME  	char(10),
	DEPNO  	int,
	SSECNO  	char(10),
	PROJNO  	char(8),
	JOB  		char(25),
	AGE  		date,
	HIREDATE 	date NOT NULL WITH DEFAULT,
	SAL  		dec(9,2),
	COMM  	dec(9,2),
	FINE 		dec(9,2),
	PRIMARY KEY (EMPNO)
);

CREATE TABLE PROJECT 
(
	PROJNO  	char(8) NOT NULL,
	PNAME  	char(25),
	BUDGET  	dec(9,2),
	PRIMARY KEY (PROJNO)
);