Галерея
7757 8119 8300 8698 8817 9504 9722 9937
Интересные записи
Топовые новости
Новое

Внешний ключ

Внешний ключВернемся к примеру с базой данных заказов. Теперь понятно, почему в качестве первичного ключа было выбрано поле CUST ID N — идентификационный код компании (ОКПО) уникален по определению, и ни одна фирма не может иметь два таких кода. Чтобы отслеживать товары, приобретаемые конкретными клиентами, требовалось обеспечение некоторой связки между клиентами и их заказами. Таблица заголовков заказов ORDER HEADER имеет собственный первичный ключ — ORDH — DR ID N, уникально идентифицирующий заказы. Дополнительно в ней определен и внешний ключ ORDHDR CUSTID FN. Идентификаторы клиентов в этом поле соответствуют содержащимся в поле CUST ID N таблицы CUSTOMER. При этом следует отметить, что в отличие от первичного ключа для значений внешнего уникальность не требуется — один клиент может разместить несколько заказов.

Теперь, просматривая таблицу ORDER HEADER, можно определить, какие клиенты выполнили конкретные заказы. Эта таблица посредством внешнего ключа связана с таблицей CUSTOMER. Теперь найти клиентов по заказам или наоборот совсем не сложно. Для этого не нужно знать структуру базы или порядок в ней записей. Также отпала необходимость в изучении массы узкоспециализированных языков программирования, чтобы извлечь нужные данные. Достаточно сформулировать запрос на стандартном, интуитивно понятном языке SQL. В свете очевидных преимуществ реляционной модели баз данных потребовалось совсем немного времени на переход к ним. Одна из главных причин была связана с аппаратными требованиями. Логическая прозрачность модели доказала свое право на внедрение, даже несмотря на повышенные требования к объему памяти и мощности процессора.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *