Реляционная база данных будет содержать множество таблиц, аналогичных таблице patient_info (рис. 7). Таблицы связаны друг с другом с помощью ключевых полей. Как вы видите на рисунке, таблица patient_info содержит поля, являющиеся первичным ключом и внешним ключом. Каждая таблица в реляционной базе данных должна содержать первичный ключ. Первичный ключ — это уникальный идентификатор записи в таблице. Первичный ключ каждой записи должен быть уникальным и не должен быть нулевым (пустым). Обратите внимание на поле PatientID в таблице patient_info. Поскольку это поле используется как первичный ключ, у каждой записи в таблице значение данного поля должно быть уникально. Иными словами, никакие две записи не могут иметь один и тот же PatientID.
Хотя первичный ключ (в данном случае PatientID) должен быть уникальным, другие поля могут содержать данные, повторяющиеся более чем в одной записи. Рассмотрим поле PrimaryCareDoctorID. Например, если Dr. Waynewright, ID 106547 (см. первую строку рис. 7), лечит нескольких пациентов из базы данных, то его имя и идентификатор могут встречаться в нескольких записях таблицы.
Примечание
В реляционной базе данных таблицы часто называют «связями», так как они содержат набор записей (строк), связанных с различными полями (столбцами). Однако в этой книге мы будем использовать термин «таблица». См. рис. 5 — «Основная терминология».
Внешний ключ — это поле в таблице, значение которого соответствует первичному ключу в другой таблице. Предположим, что в дополнение к нашей таблице patient_info в базе данных существует еще одна таблица с именем primary_care_doctors, в которой в качестве первичного ключа используется поле PrimaryCareDoctorID. В таблице primary_care_doctors строка Dr. Waynewright с ID 106547 появится только в одной записи. Именно совпадение различных ключевых полей в разных таблицах обеспечивает исключительно важную взаимосвязь в реляционной базе данных. Как правило, эти связи отображаются в виде схемы базы данных, также известной как диаграмма «сущность — связь» (ERD, Entity Relationship Diagram), которая служит своего рода эскизом для базы данных.
Рис. 7
Рис. 8
Пока не беспокойтесь, что означают символы 1 и ∞. Очень скоро мы к ним вернемся. А сейчас рассмотрим схему и ее взаимосвязи. В данной схеме всего четыре таблицы, и таблицы связаны друг с другом посредством одного или нескольких общих полей. Поле PatientID — это первичный ключ для таблицы patient_info и одновременно внешний ключ для таблицы lab_orders. Точно так же поле HospitalId — первичный ключ для таблицы hospitals, но это внешний ключ для таблицы primary_care_doctors. Очень просто, правда? Давайте рассмотрим другую схему.
Схема на рис. 9 описывает базу данных для обработки заказов и доставки товаров клиентам. И здесь пора поговорить о символах 1 и ∞, которые находятся на схеме на концах соединительных линий. Эти символы описывают связи между таблицами. Когда на одном конце соединительной линии находится символ 1, а на другом — символ ∞, это означает связь между полями таблиц «один-ко-многим».
Рассмотрим подробнее таблицу products (рис. 10). В ней представлены данные о различных товарах и их атрибутах.
Рис. 9
Рис. 10
Поле ProductId — первичный ключ для этой таблицы (обозначено значком ключа). Каждая запись в таблице будет содержать уникальный идентификационный номер товара. Фактически основная цель этой таблицы — каталогизировать атрибуты различных товаров базы данных. Теперь давайте проанализируем связи между таблицами products и suppliers.
Рис. 11
Рис. 12
Между таблицами suppliers и products существует связь «один-ко-многим», основанная на данных поля SupplierId. В таблице suppliers каждая запись будет иметь уникальный идентификационный номер для каждого поставщика. В таблице products может быть несколько записей с одним и тем же идентификационным номером поставщика.
Значок ключа, расположенный рядом с полем SupplierId в таблице suppliers, означает, что SupplierId — это первичный ключ для этой таблицы. В базе данных, безусловно, может содержаться большое количество разных товаров (каждый будет иметь уникальный идентификационный номер), поступающих от одного поставщика и каталогизированных в таблице products. Взгляните на таблицу suppliers, где должен быть только один уникальный идентификационный номер поставщика для каждой записи.