Основные принципы проектирования базы данных

Свойства полей

Для каждого поля таблицы можно задать значение Свойств (Properties), список которых зависит от выбранного типа данных (Data Type) и размера поля (Field Size).

В табл. 8.3. приведено описание некоторых свойств полей таблицы.

Установления соответствия между объектами и таблицами базы данных

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

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

Таблица 8.3. Свойства полей данных таблицы

Свойство	Описание
Field Size (Размер поля)	Определяет максимальный размер величин типов Text или Memo либо особенности значений типа Number
Format (Формат)	Позволяет указать, как следует отображать поле в отчете или форме. Это свойство наиболее полезно при работе с типами данных Number или Currensy
Input Mask (Маска ввода)	Определяет строку символов, которые используются для проверки правильности ввода данных
Default Value (Значение по умолчанию)	Определяет строку, которая отображается в форме или отчете не месте имени поля
Validation Rule (Условие назначения)	Позволяет проверять допустимость нового значения поля
Validation Text (Сообщение об ошибке)	Определяет сообщение, которое выводится, если новое значение поля является недопустимым, т.е. нарушает правило Validation Rule
Required (Обязательное поле)	Обозначает, что пользователь должен заполнить поле до того, как запись будет добавлена к базе данных. Это свойство также называется Not Null (Не ноль)
Allow Zero Length (Пустые строки)	Обозначает, что ввод в поле типа Text или Memo значений без каких-либо символов допускается
Indexed (Индексированное поле)	Когда это свойство установлено в Yes (Да), то на основе этого поля автоматически создается и поддерживается индекс, что ускоряет поиск информации. Ускорение процесса поиска записи обычно замедляет процессы добавления и изменения записи

В реляционной СУБД класса Microsoft Access, каждую базу данных следует строить на основе некоторого набора задач или функций. Например, одна база данных, предназначенная для обработки заказов, может содержать данные о каждом клиенте, предлагаемые товары, заказы, статистические данные о продаже товаров в прошлом. Другая же будет предназначена для учета кадров. В нее войдет информация о подразделениях организации и подробные данные о сотрудниках - ФИО, должность, анкетные сведения и т. п.

Здесь мы сталкиваемся с самым сложным вопросом в процессе проектирования: как в ориентированной на конкретные задачи базе данных организовать хранение данных, используя преимущества реляционной модели и избежав лишних затрат? Если мы следовали изложенным выше этапам определения задач и объектов базы данных, то уже немало сделали для создания логичного и гибкого проекта приложения. А если мы начали создавать таблицы данных, не проанализировав задачи и объекты? Важным моментом является рассмотрение принципов, применение которых поможет избежать некоторых проблем и создать надежное и эффективное приложение.

Дата добавления: 2014-01-05