Файл: Базы данных САПР_УП.pdf

36

4)

Nulls – не заполняем, что означает запрет на пустые значения; 

5)

Rule (задается при помощи окна диалога «Managing Rules», в области 
«Description» вводим: 

Create RULE valid_id 

AS@id>0

And @id <100000 

Правило – ограничение  значений,  принимаемых  полем,  сформулиро-

ванное в виде условного выражения. 

@id – заменяется действительным значением столбца везде, где этот тип 

данных используется в определении поля. 

В  общем  случае,  при  создании  правила  после AS может  стоять  любое 

выражение, допустимое в условии WHERE языка SQL, не содержащее подза-
проса  и  не  ссылающиеся  на  другие  поля.  Его  единственный  параметр  иден-
тифицируется символом @. 

То есть мы создали пользовательский тип с ограничениями; 
id_type под таким именем запомним → ПОЛЬЗОВАТЕЛЬСКИЙ ТИП на 

базе системного «int». 

 
7.1.2.

Определение отдельных таблиц  

 
Определяется также в окне «Enterprise Manager» (Таблицы). 
Существует следующий порядок: 
1.

 В таблице, расположенной ниже наименования  таблица база данных 

определяются поля новой таблицы (поля таблиц и их описание в одну стро-
ку). 

 
Имя таблицы базы данных заносится в окно. 
 

 Table 

 
2.

Каждая определяющая поле строка состоит из столбцов 

Column Name (Имя столбца) 
Data type (Тип данных) 
Length (Длина) 
И индикаторы возможных ограничений: 
Nulls (Пустые значения) (если может содержать, то ставим флажок) 
Default (Значение по умолчанию) 
Rule (Правило) 
3.

 Определяя  таблицу,  задаются  все  поля,  присваивается  имя,  выполня-

ется команда Create Table. 

Например, 

37

Поле <<skill_type>> (тип_специальный) – имеет  символьный  тип,               

‘длина 10’ и  для  него надо определить  и  значение  по  умолчанию  и правило; 
оно будет автоматически помещаться в столбец, если пользователь не вводит 
значение. 

Например,  если  не  вводим  телефон  служащего,  то  система  может  вво-

дить номер центрального коммутатора. 

Значение по умолчанию – это значение, которое автоматически вводит-

ся  системой,  если  пользователь  опускает  значение. (Причем,  ввод  в  столбец 
Nulls аннулируется любым вводом в столбец Default). 

Значение по умолчанию определяется в окне <<Managing Rulles>> 
CREATE DEFAULT skill_deflt  AS. 
‘Плотник’ – теперь в окне определения таблицы в столбце  Default стро-

ки skill_type мы вводим: «skill_deflt» - значение по умолчанию должно быть 
константой,  т.е.  оно  не  может  содержать  переменных,  имен  таблиц  или 
столбцов, а только постоянные значения, возможно, соединенные арифмети-
ческими операциями. 

Правила (Rule) – ограничивают вводимые значения пользователем. 
CREATE RULE valid_skill_type AS 
@ skill_type in (‘Электрик’, ‘Штукатур’, ‘Плотник’, ‘Кровельщик’). 
 
7.1.3.

Определение первичных и вторичных ключей  

 
Для  того  чтобы  СУБД  автоматически  поддерживала  правила  целостно-

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

Oracle. 
В Oracle первичные  ключи  определяются  в  контексте  определения  таб-

лицы, например, в таблице  WORKER. 

CREAT TABLE worker 
(worker_id id_type CONSTRAINT pk_wid PRIMARY KEY), … 
Мы выделили определение  worker_id как первичного ключа; 
CONSTRAINT  означает,  что  далее  следует  ограничительное  условие  на 

поле pk_wid – имя, которое присвоено ограничению. 

Если  делается  попытка  нарушить  ограничительное  условие,  то  система 

выдает сообщение об ошибке, указав имя ограничения. 

PRIMARY KEY – означает, что поле worker_id будет внешним ключом. 

Это означает, что его значение в таблице worker 

1)

не должно повторяться; 

2)

не может содержать пустое значение. 

Такое  ограничение  называется  ограничение  на  поле – является  ча-

стью определения поля. 

38

Например, в таблице assignment первичный ключ состоит из двух полей: 

worker_id и bldg_id поэтому он не может быть определен как ограничение на 
поле. Его нужно определять как ограничение на таблицу. Это также опреде-
ляется в контексте определения таблицы: 

CREATE TABLE assignment 

(worker_id id_type, 

bldg_id id_type, 

…… 

CONSTRAINT pk_’ wkblid PRIMARY KEY (worker_id, bldg_id) 

Аналогично, значения пары полей worker_id и bldg_in  не должно повто-

ряться в таблице и никакое из полей не должно иметь пустых значений. 

Внешние ключи.  
Например,  
CREATE TABLE assignment 
(work_id id_type REFERENCES worker, 
bldg_id id_type REFERENCES building, 
……………. 
(Таблица assignment ссылается на поле из таблицы worker и building). 
REFERENCES – обозначает  определение  ВНЕШНЕГО  КЛЮЧА.  Стол-

бец  является  внешним  ключом,  ссылающимся  на  таблицу,  стоящую  после 
слова REFERENCES. 

Это означает: его значение должно соответствовать ключевому значению 

в таблице, на которую внешний ключ ссылается. 

Например,  в  таблице assignment есть  кортеж: {1235,515, ….}, то  обяза-

тельно  есть worker_id=1235 и bldg_id=515; которые  стоят  в  ключевом  поле  
некоторого кортежа одноименной таблицы.  

Если такие кортежи не существуют в момент ввода строки значения, то-

гда СУБД не позволит добавить такую строку в таблице assignment. 

Если строка успешно введена, но позднее соответствующий кортеж таб-

лицы worker удаляется. 

В этом случае удаление кортежа worker будет запрещено до тех пор, по-

ка не будут удалены  все ссылающиеся на него строки таблицы assignment.  

DELETE RESTRICT – она устанавливается по умолчанию. 
(удаление  ограничивать) 
ON DELETE CASCADE – при удалении строки другой таблицы, на  
(удаление каскадное)  

которую ссылается кортеж таблицы assignment 

– он будет автоматически удален. 

Например, 
CREATE TABLE assignment 
(work_id id_type REFERENCES worker ON DELETE CASCADE, 
bldg_id id_type REFERENCES building ON DELETE CASCADE, 
……………. 

39

То есть в Oracle, все внешние и первичные ключи определяются ЯВНО и 

СУБД Oracle автоматически  поддерживает  их. (То  есть  при  вводе  данных 
СУБД проверяет, что первичные ключи не пусты и не повторяются, а значе-
ниям  внешних  ключей соответствуют  значения первичных  ключей, на  кото-
рые они ссылаются). 

Внешний  ключ  –  набор  атрибутов  в  одной  реляционной  таблице,  со-

ставляющих ключ другой реляционной таблицы (или возможно той же самой 
таблице);  применяется  для  задания  логических  связей  между  реляционными 
таблицами. 

Первичный ключ – потенциальный ключ, выбранный в качестве основ-

ного средства однозначного определения строк реляционной таблицы. 

В SQL-Server(e) поддержка первичных и вторичных ключей выполняется 

с помощью триггеров – программа, которая автоматически исполняется, ко-
гда предпринимается попытка обновления определенного типа заданной таб-
лицы. 

CHEK – 

ограничения

 
CHEK – ограничения – общее ограничение на поле и таблицу, сформу-

лированное в виде условного выражения. 

1)

 CHEK  –  ограничения,  как  правило,  используются  для  задания  общих 

правил формирования данных. 

Например,  таблица employee (emp_id, emp_name, emp_adress, salary, bo-

nus). 

Пусть политика компании такова, что размер премии не должен превы-

шать 10% от зарплаты: 

(*) CHEK (bonus<=.10 * salary)/ 
2)

 CHEK  –  ограничения  могут  быть  частью  определения  поля  или  таб-

личным ограничениям. 

3)

 CHEK – ограничения могут влиять на любое поле таблицы, а не толь-

ко на то, частью определения  которого оно является. 

4)

 Часто  это  ограничение  является  табличным,  так  как  обычно  касается 

целого кортежа, а не поля. 

5)

 CHEK – ограничения Oracle, аналогичны правилам в SQL Server; 

CREAT RULE Valid_skill_type AS 
@skill_type IN (‘Электрик’, ‘Штукатур’, ‘Плотник’, ‘Кровельщик’)  в 

Oracle тоже самое: 

СНЕСК (skill_type IN (‘Электрик’, ‘Штукатур’, ‘Плотник’, ‘Кровель-

щик’)) 

СHECK – ограничения дают больше возможностей, чем правило (RULE), 

так как применяются сразу к нескольким столбцам, но в отличие от триггеров 
CHECK  не  может  содержать  подзапрос,  ссылающийся  на  значения  других 
кортежей той же таблицы или кортежи любой другой таблицы. 

40

То  есть  ограничение (*) всегда будет  сравнивать  только  значение  атри-

бута bonus кортежа со значением атрибута salary того же кортежа. 

7.2. 

Создание

триггеров

Триггер – программа, которая автоматически выполняется при по-

пытке изменения содержимого заданной таблицы. 

Существует три типа триггеров: 
-

ввода; 

-

добавления; 

-

удаления. 

Предположим мы хотим поддерживать  в базе данных столбец, получен-

ный в результате вычислений над другими столбцами. 

Например,  имея  почасовую  ставку  работника  и  полагая  рабочий  день 

восьмичасовым,  мы  можем  подсчитать  зарплату  работника  за  определенное 
количество дней. 

Тогда в таблице Worker, появится поле «comulative_pay». 
 
Технология работы триггеров. 
1.

 Когда  над  таблицей  выполняются  операции  добавления,  изменения 

или удаления данных, создаются новые версии управляемых системой триг-
герных таблиц. 

2.

 Эти  триггерные  таблицы  называются    inserted  (введено)  и deleted 

(удалено). 

-

Если в таблице введены строки, то они помещаются в таблицу inserted, 

а таблица deleted остается пустой. 

-

Если  из  таблицы  удаляются  строки,  то  они  помещаются  в  таблице 

deleted, а таблица inserted остается пустой. 

-

Если таблица обновляется, то deleted состоит из старых версий строк, а 

таблица inserted состоит из новых версий тех же строк. 

-

SQL  сервер  запускает  триггер  после  того,  как  обновление  файла  про-

изошло.  Таким  образом,  когда  триггер  запускается,  файлы inserted и deleted 
уже существуют. 

 
Например: 
предположим, что таблица worker была расширена: в нее включено поле 

«comulative_pay». 

1.

 Worker (Worker_id, worker name, hrly_rate, skill_type, supv_id, comula-

tive_pay). 

2.

Формула подсчета comulative_pay: 

 comulative_pay = total_name_days*8* hrly_rate) 
total_name_days вычисляется по таблице.