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

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

Однократное сохранение информации уменьшает шанс ошибки

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

Таблицы Customer хранит единичную информацию об адресе

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

Предотвращение удаления значимой информации

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

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

NoteСовет

Такая стратегия деления информации в разные таблицы представляет собой взгляд на индивидуальные факты и определяет, что каждый факт представляет собой. Например, в форме заказа Tasmanian Traders адрес потребителя не говорит о продаже; а говорит только о потребителе. Это приводит к выводу, что вам необходима отдельная таблица для потребителей. В отчете Products On Order номер телефона поставщика не говорит о наличии продукта на складе; это информация только о поставщике. То есть, вам нужна отдельная таблица для поставщиков.

Смотрите также