4.3.3. Триггер ссылочной целостности

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

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

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

Для редактирования триггера следует (находясь в физической мо­дели) щелкнуть правой кнопкой мыши по таблице и выбрать во всплы­вающем меню пункт [название целевой СУБД] Trigger (рис. 4.4).

Рис. 4.4. Позиция меню для редактирования триггера

Поскольку не все СУБД поддерживают механизм триггеров, то соответствующая позиция меню активна не всегда: она не активна для настольных СУБД и активна для корпоративных систем.

На это следует обратить внимание

• Обеспечение целостности базы данных является важнейшей за­дачей при проектировании и эксплуатации БД.

• При проектировании БД необходимо выявить все ограничения целостности, которые обусловлены как особенностями предметной области, так и спецификой используемого программного и техничес­кого обеспечения.

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

Контрольные вопросы

1. Что такое «ограничения целостности»?

2. В чем важность задания ограничений целостности?

3. Какие виды ограничений целостности вы знаете? Приведите при­меры ограничений целостности каждого вида.

4. Какие способы задания ограничений целостности вы знаете? В чем преимущества и недостатки каждого из них?

5. В чем суть применения триггеров для контроля целостности данных?

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

7. Что такое ограничение целостности связи?

8. Если задано ограничение целостности связи, но не задано каскад­ное удаление связанных записей, повлияет ли заданное ограничение це­лостности на процесс удаления записи из основного файла?

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

10. В чем суть ограничения целостности по существованию? В чем его отличие от ограничения целостности связи?

11. Какие виды диапазонов вы знаете? В чем особенности их за­дания?

12. Что такое «домен»? Как можно реализовывать ограничения цело­стности на «домен»?

13. Что такое «транзакция»? С каким видом ограничений целостно­сти обычно связаны транзакции?

14. Какие ограничения связи непосредственно отображены в ER-модели?

15. Какие ограничения целостности и каким образом могут быть заданы в ERWin?

Глава 5 создание и ведение баз данных

5.1. Описание структуры баз данных. Общие сведения

Спроектированная структура базы данных должна быть описана на языке описания данных или с использованием соответствующих операторов интегрированного языка. Язык описания данных может быть различным: аналитическим, табличным, смешанным. Описания данных могут храниться отдельно от данных или вместе с ними. В СУБД предшествующего поколения (к которым относятся иерархи­ческие и сетевые системы) обычно использовалось раздельное хра­нение данных и их описаний. В большинстве современных настоль­ных реляционных СУБД описания БД хранятся вместе с данными.

В связи с тем, что наибольшее развитие в настоящее время имеют реляционные СУБД, рассмотрим вопросы создания БД на их примере.

Для описания логической структуры данных в настольных реля­ционных СУБД обычно используется простой табличный язык опи­сания данных, физические параметры практически не указываются. Загрузка данных в базу данных заключается либо во вводе данных с клавиатуры, либо в переносе их из других файлов. Наблюдается упро­щение технологического процесса, связанного с созданием баз данных.

Наиболее часто используемым способом создания файла/табли­цы базы данных является выбор из соответствующего меню позиции «создать новый файл базы данных/таблицу». Возможно и использо­вание соответствующего оператора языка описания данных. В тех системах, в которых наряду с понятием «файл базы данных/таблица» поддерживается и понятие «база данных», нужно сначала определить базу данных, а затем - таблицы, входящие в нее.

Как указывалось выше, обычно описание структуры таблиц само представляется в табличной форме. Каждая строка этой таблицы опи­сания соответствует одному полю таблицы. Каждое поле должно иметь уникальное имя в пределах таблицы. Максимальная длина этого имени и символы, допустимые при его задании, зависят от используемой операционной среды и СУБД.

Каждое поле имеет определенный тип (Field Type). Современные СУБД обычно позволяют при описании поля просмотреть список допустимых типов полей и выбрать нужный. Кроме того, во многих СУБД задать нужный тип поля можно, указав первую букву названия выбираемого типа.

Допустимые типы полей различаются от системы к системе. На­блюдается тенденция к расширению списка поддерживаемых типов данных. Многие современные СУБД наряду с традиционными типа­ми полей (Character - символьное, Numeric - числовое, Floating - с плавающей запятой, Date - дата, Logical - логическое, Memo - поле памяти) поддерживают и такие экзотические до недавнего времени типы полей, как двоичные, рисунки и др. Наиболее развитые систе­мы (например, Огас1е7) позволяют в единой базе данных интегриро­вание хранить не только структурированные данные, но и неструкту­рированные, такие, как поточная аудио- и видеоинформация, простран­ственные многомерные данные.

Для массовых применений наиболее часто используются типы Character, Numeric, Logical и Date. Тип поля Floating в основном при­меняется для математических расчетов, тип Memo - для хранения данных, длина которых резко отличается от записи к записи, а также при хранении длинных полей. Этот тип поля называют также полем примечания, а иногда и просто текстовым.

После указания типа поля обычно указывается его длина. Для не­которых типов полей длина предопределена и устанавливается систе­мой автоматически. Так, например, для полей типа даты автоматиче­ски устанавливается длина, равная 8 символам, для логического типа - 1 символу. Для других типов полей проектировщик при описании фай­ла должен задать длину поля. В некоторых случаях эта величина может быть составной. Так, например, если это поле типа Numeric, то указы­вается общая длина поля, включая десятичную точку и знаки после нее, а также задается число знаков после десятичной точки.

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

Многие реляционные системы позволяют при описании структу­ры файла БД указать и признаки индексирования по отдельным по­лям или по совокупности полей (составной индекс). Соответствую­щие колонки таблицы описания структуры файла БД/таблицы в раз­ных системах называются по-разному (Index, Tag). В некоторых СУБД (например, Access) индексирование задается как свойство поля.

Индексация представляет собой способ логической упорядочен­ности файлов. Если при создании файла для какого-то поля в графе индексирования установлено значение «да», то для этого поля созда­ется специальный индексный файл, который содержит значения это­го поля и номер записи в индексируемом файле, содержащей такое значение поля. Индексный файл является упорядоченным (обычно организован как двоичное дерево сортировки). Многие системы по­зволяют также при описании файла указывать и вид упорядочения (по возрастанию, по убыванию).

Если значение «да» в графе признака индексации установлено для нескольких полей, то для каждого из них создается аналогичный файл (в зависимости от реализации хранения индексов в конкретных СУБД все эти индексные файлы могут объединяться в один мультииндексный файл или храниться как самостоятельные отдельные файлы).

Кроме индексации по одному полю можно проводить индекса­цию по совокупности полей (составной индекс) или по более слож­ному выражению. Нужно быть внимательными при задании индекса­ции по сложному выражению, в котором участвуют поля разных типов, поскольку некоторые СУБД самостоятельно проводят необхо­димые преобразования типов, а некоторые - нет (при этом в лучшем случае может быть выдано предупреждающее сообщение, а в худ­шем - можно получить не тот результат, на который рассчитывали, и не сразу догадаться об этом).

После того как описано одно поле, переходят к описанию следу­ющего, и так до тех пор, пока не будут определены все поля данного файла БД.

Реляционные СУБД должны поддерживать концепцию ключа. Некоторые СУБД требуют, чтобы при описании таблицы обязательно был указан ее ключ, другие - предоставляют такую возможность, но не требуют, чтобы в каждой таблице ключ был обязательно задан, третьи - вообще не предоставляют возможности идентифицировать ключ. Те системы, которые поддерживают концепцию ключа, обыч­но не только обеспечивают проверку на его уникальность, но и авто­матически проводят индексацию по ключевому полю. (В Access, например, таблица, для которой определен ключ, так и называется ин­дексированной.) Некоторые СУБД, например та же Access, при со­хранении новой таблицы, для которой не задан ключ, предлагают определить ключ автоматически и в случае положительного ответа формируют дополнительное поле-счетчик с именем «Код», которое будет содержать уникальное значение для каждой записи. Такое ре­шение можно принять, когда запись таблицы не содержала естествен­ного ключа или когда естественный ключ слишком длинный.

В некоторых системах при описании файлов БД можно задать и ограничения целостности. Тенденции развития СУБД таковы, что даже настольные системы включают все более развитые возможности кон­троля целостности.

Кроме рассмотренных выше свойств полей СУБД позволяют оп­ределять и другие свойства, такие, как подпись поля (название поля, которое будет использоваться при выводе информации), формат поля и др.

Многие СУБД предоставляют возможность использовать и иные способы создания таблиц, не предполагающие непосредственного описания каждого поля проектировщиком.

Так, при создании новой таблицы можно воспользоваться образ­цами, которые обычно включаются в состав СУБД. Но это не осво­бождает от понимания основ проектирования БД, так как следует вни­мательно оценить, насколько предлагаемое в качестве образца решение соответствует вашим потребностям, и при необходимости изменить предлагаемую структуру БД.

Кроме того, имеются возможности полного или выборочного ко­пирования структуры имеющегося файла при создании нового файла.

Имеются и другие способы создания таблиц БД. Так, многие СУБД позволяют проводить импорт файлов/таблиц, созданных в других при­ложениях, в создаваемую БД. При этом описание включенной в БД таким образом таблицы будет сформировано автоматически.

При завершении описания Структуры файла БД необходимо дать имя этому файлу (таблице).

Следует обратить внимание на то, что база данных представляет собой не просто совокупность отдельных файлов, а единое взаимо­связанное хранилище данных. Поэтому описание БД не ограничива­ется описанием отдельных ее файлов (таблиц). В СУБД, поддерживаю­щих нереляционные структурированные модели данных (иерархиче­ские, сетевые), описание связей между информационными единицами является неотъемлемой частью описания БД. В реляционных СУБД (в силу специфики модели БД) описание связей в схеме БД не являет­ся обязательным. Однако многие СУБД позволяют описывать связи при описании БД; это прежде всего служит цели задания ограниче­ний целостности.