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