Что такое ключи в копирайтинге, для чего нужны и как их вписывать

SQL FOREIGN KEY в CREATE TABLE

Следующий SQL создает внешний ключ в столбце «PersonID» при создании таблицы «Orders»:

MySQL:

CREATE TABLE Orders
(
   
OrderID int NOT NULL,
   
OrderNumber int NOT NULL,
   
PersonID int,
   
PRIMARY KEY (OrderID),
   
FOREIGN KEY (PersonID) REFERENCES Persons(PersonID)
);

SQL Server / Oracle / MS Access:

CREATE TABLE Orders
(
   
OrderID int NOT NULL PRIMARY KEY,
   
OrderNumber int NOT NULL,
   
PersonID int FOREIGN KEY REFERENCES Persons(PersonID)
);

Чтобы разрешить именование ограничения внешнего ключа и определить ограничение внешнего ключа для нескольких столбцов, используйте следующий синтаксис SQL:

MySQL / SQL Server / Oracle / MS Access:

CREATE TABLE Orders
(
   
OrderID int NOT NULL,
   
OrderNumber int NOT NULL,
   
PersonID int,
   
PRIMARY KEY (OrderID),
   
CONSTRAINT FK_PersonOrder FOREIGN KEY (PersonID)
   
REFERENCES Persons(PersonID)
);

Как домофон определяет, подходит ли ключ?

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

Когда вы подносите ключ к домофону, он считывает код и сравнивает его со значениями из своей памяти. Если значение ключа там есть, дверь открывается.

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

Вот так переустановят домофон у вас в подъезде, а ключи менять не придётся. Хотя, конечно, установщик домофона вполне может попытаться заработать на этом.

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

Когда мастер «из ларька» клонирует такой ключ, он копирует только заводской код, но не код домофона. В результате домофон может отвергнуть такой ключ – сработает система защиты от клонов. Скопировать заводской код сможет лишь обслуживающая компания.

Код сущности

В листинге 1 приведен класс Java, названный .
Этот класс моделирует платежный адрес лица или организации. Само составление счета связано с другим классом Java, названным . Здесь нет ничего особенного — сначала размещается заказ на покупку, затем следует составление счета.

Листинг 1. Класс

import javax.persistence.*;
import java.io.Serializable;

@Embeddable
public class BillingAddress implements Serializable {

    private String street;
    private String city;

    BillingAddress() {}

    public BillingAddress(String street, String city) {
        this.street = street;
        this.city = city;
    }

    public String getStreet() {
        return street;
    }

    private void setStreet(String street) {
        this.street = street;
    }

    public String getCity() {
        return city;
    }

    private void setCity(String city) {
        this.city = city;
    }
}

Обратите внимание на один важный момент: этот класс реализует Java-интерфейс. Обратим также внимание на строку с аннотацией

Эта аннотация является первой деталью головоломки составного ключа. Java-класс с аннотацией сам может быть подкомпонентом другого класса. Это только звучит сложно, на самом деле все просто. В качестве примера в листинге 2 приводится класс , использующий класс из листинга 1.

Листинг 2. Класс

import javax.persistence.*;

@Entity
@Table(name = "PURCHASE_ORDERS")
@IdClass(BillingAddress.class)
public class PurchaseOrder {

	PurchaseOrder() {}

	PurchaseOrder(BillingAddress billingAddress) {
	street = billingAddress.getStreet();
	city = billingAddress.getCity();
	}

	@Id
	@AttributeOverrides({
	@AttributeOverride(name = "street",
	column = @Column(name="STREET")),
	@AttributeOverride(name = "city",
	column = @Column(name="CITY"))
	})

	private String street;
	private String city;
	private String itemName;

	public String getItemName() {
	return itemName;
	}

	public void setItemName(String itemName) {
	this.itemName = itemName;
	}
}

Мне всегда казалось, что аннотации трудны для чтения, и листинг 2 не является исключением, поэтому я разбил его на удобные для просмотра фрагменты. Первая аннотация —, она показывает, что этот класс является объектом базы данных (то есть, он будет частью ORM-решения). Обычно с ожидается соответствующая таблица базы данных, и на неё указывает следующая аннотация — а именно . Мне кажется, что когда процесс разбивают таким образом, его проще понять.

Следующей в листинге 2 идет аннотация , которая определяет ссылку на класс составного ключа. Возможно, вы заметили, что эта аннотация ссылается на класс из листинга 1

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

Эти аннотации используются для определения столбцов составного ключа: «STREET» и «CITY» соответственно.

Сразу поcле аннотаций в листинге 2 повторяются две строки из листинга 1. Повторяющийся код — это, конечно, два скрытых члена класса: street и city. Это дублирование нужно для создания составного ключа.

Виды ключей для домофонов

Существует несколько семейств домофонных ключей.

1. «Таблетки». Официально стандарт называется Touch memory (ТМ) или iButton, это контактные ключи в корпусе MicroCAN. В «таблетках» используется протокол 1-Wire, но форматы бывают разные.

В РФ это в основном ключи модели Dallas, с которыми работают домофоны Vizit, Eltis, Z-5R, С2000-2 и т.д., Cyfral (ключи DC2000А и Цифрал-КП1 и др.), «Метаком».

Довольно редко встречаются резистивные «таблетки» – у них считывается сопротивление.

2. «Капельки». RFID-метки в пластиковом корпусе круглой, овальной или каплеобразной формы. Иногда их выпускают в виде браслетов или карт.

Внутри – RFID-метка, как и в картах метро, «пищалках» на товарах в супермаркетах и других подобных штуках. В основном «капельки» могут быть ближнего действия (Proximity, считываться на расстоянии до 10-15 см), так как более «дальнобойные» метки Vicinity, которые работают на расстоянии до 1 м, небезопасны в данном случае.

В РФ чаще всего используют Proximity-ключи EM-Marin, но встречаются также и более старые HID-метки или более новые MiFare, как в картах метро.

3. Оптические. Настоящие динозавры. Где-то в провинциях ещё сохранились. Такой ключ – это металлическая пластина, в которой в определенном порядке насверлены отверстия.

Внутри домофона есть фотоэлемент, который распознает, в том ли порядке насверлены дыры.

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

Схема базы данных

Мы рассмотрели техническую сторону вопроса. Теперь посмотрим, как это выразится на практике, создав схему базы данных. В листинге 3 приведена схема базы данных простейшего ORM-проекта.

Листинг 3. Схема базы данных

drop table PURCHASE_ORDERS if exists;

create table PURCHASE_ORDERS (
        street varchar(255) not null,
        city varchar(255) not null,
        itemName varchar(255),
        primary key (street, city)
);

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

В листинге 4 приведен фрагмент программы, создающий объекты ранее определенных классов.

Листинг 4. Код ORM-клиента

        // Start EntityManagerFactory
        EntityManagerFactory emf =
                Persistence.createEntityManagerFactory("helloworld");

        // First unit of work
        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        PurchaseOrder purchaseOrder = 
          new PurchaseOrder(new BillingAddress("Broad Street", "Boston"));
        purchaseOrder.setItemName("My new computer");
        em.persist(purchaseOrder);

        tx.commit();
        em.close();

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

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

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

Обратите внимание на вызовы и

Важно помнить, что в базе данных не произойдёт никаких изменений, пока не будут выполнены оба этих вызова. Это простая модель Java Persistence API (JPA)

Это простая модель Java Persistence API (JPA).

Чтобы завершить обзор ORM, посмотрим, как выглядит база данных после выполнения программы из листинга 4 (рисунок 1). Программа была протестирована с использованием HSQLDB, базы данных в памяти, куда также входит простая графическая утилита. Состояние базы данных HSQLDB показано на рисунке 1. Можно видеть, что был запущен SQL-запрос по таблице PURCHASE_ORDERS. Эта таблица была создана из схемы, которая, в свою очередь, была создана из программы на Java в предыдущих листингах.

Рисунок 1. Заполненная база данных

На рисунке 1 можно видеть результат выполнения строки из листинга 4: . Вызов setter-метода заполнил соответствующий столбец в строке базы данных строковыми данными: «My new computer». С точки зрения рабочего процесса можно представить себе работу всей программы как создание заказа на покупку нового компьютера, за которым следует процесс составления счета. Все шаги рабочего процесса неявно сохраняются в базе данных.

Руководство по проектированию реляционных баз данных. Каскадное удаление данных

Введение.

Если отталкиваться от обывательской позиции человека, который разрабатывает базы данных, то внешние ключи – это удобно и упрощает жизнь (в большинстве случаев, всегда есть исключения.). Даже будучи невеждой в реляционной теории баз данных, к осознанной необходимости использования внешних ключей, на определенном этапе своего развития, приходит практически любой практик (утверждение — более относится к начинающим), который не стоит на месте в своем развитии и продолжает мыслить. Даже если он еще не знает, что то, что ему нужно называется связью по внешнему ключу, он начинает самостоятельно организовывать данные определенным образом, разбивать на отдельные таблицы и связывать их между собой. Настолько это становится очевидным.
Но при использовании внешних ключей, даже если не знать такого определения, возникает необходимость следить за связываемыми данными. Рассматриваемым объектом данной статьи является, если так можно сказать, своеобразный спутник, который следует за такой организацией данных. И в данном случае уже гораздо полезнее знать теорию, т.к. это может значительно упростить жизнь в процессе работы с базой данных.

Как делают копию ключа?

Обычно для этого берут болванку – пустую заготовку без кода. Затем мастер считывает код с вашего ключа и записывает его же на болванку.

В результате вы получаете два одинаковых ключа. А так как код оригинального ключа уже сохранен в домофоне, то и его клон позволит открыть дверь.

Болванки бывают перезаписываемые и неперезаписываемые. Если вы помните слово «финализация» при прожиге дисков, возьмите с полки пирожок, то здесь оно тоже применяется.

Технически вы сами можете собрать дубликатор (программатор) ключей на основе Arduino или Raspberry Pi, а затем наделать копий ключа на все случаи жизни. Инструкций в интернете полно, как и предложений купить дубликатор за тысячу-другую рублей.

Главное – не промахнуться с типом домофона и ключа.

Так, одни ключи рассчитаны на частоту 125 КГц, другие на 13,56 МГц и так далее. К тому же они могут быть разного типа. Помните о защите от клонов, которая может поддерживаться вашим домофоном.

Типы связей и их реализация. Ссылочная целостность и ее обеспечение.

Более
правильным вариантом является вынесение
сведений об издателях в отдельную
таблицу «Издатели». При этом таблица
«Книги» будет содержать ссылки на
записи таблицы «Издатели».

Чтобы
сохранить синхронизацию, следует
обеспечить целостность данных между
таблицами «Книги» и «Издатели».
Связи с обеспечением целостности данных
позволяют следить за тем, чтобы данные
в одной таблице соответствовали данным
в другой. Например, каждая книга в таблице
«Книги» связана с определенным
издателем в таблице «Издатели».
Добавить в таблицу книгу для издателя,
отсутствующего в базе данных, невозможно.

Виды
связей между таблицами

Связь
осуществляется путем сопоставления
данных в ключевых столбцах; обычно это
столбцы, имеющие в обеих таблицах
одинаковые названия. В большинстве
случаев сопоставляются первичный ключ
одной таблицы, содержащий для каждой
из строк уникальный идентификатор, и
внешний ключ другой таблицы. Например,
с каждым из изданий, находящихся в
продаже, можно связать объемы его продаж
путем создания столбца «ИД_издания»
в таблице «Книги» (первичный ключ)
и столбца «ИД_издания» в таблице
«Продажи» (внешний ключ).

Существует
три вида связей между таблицами. Вид
создаваемой связи зависит от того, как
заданы связанные столбцы.

Связи
«один ко многим»

Связь
«один ко многим» — наиболее
распространенный вид связи. При такой
связи каждой строке таблицы А может
соответствовать множество строк таблицы
Б, однако каждой строке таблицы Б может
соответствовать только одна строка
таблицы А. Например, между таблицами
«Издатели» и «Книги» установлена
связь «один ко многим»: каждый из
издателей может опубликовать множество
книг, однако каждая книга публикуется
лишь одним издателем.

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

В
Microsoft Access сторона связи «один ко
многим», которой соответствует
первичный ключ, обозначается символом
ключа. Сторона связи, которой соответствует
внешний ключ, обозначается символом
бесконечности.

Связи
«многие ко многим«

При
установлении связи «многие ко многим»
каждой строке таблицы А может
соответствовать множество строк таблицы
Б и наоборот. Такая связь создается при
помощи третьей таблицы, называемой
соединительной, первичный ключ которой
состоит из внешних ключей, связанных с
таблицами А и Б. Например, между таблицами
«Авторы» и «Книги» установлена
связь вида «многие ко многим»,
задаваемая с помощью связей вида «один
ко многим» между каждой из этих таблиц
и таблицей «АвторыКниг». Первичный
ключ таблицы «АвторыКниг» — это
сочетание столбцов «ИД_автора»
(первичного ключа таблицы авторов) и
«ИД_книги» (первичного ключа таблицы
заголовков).

Связи
«один к одному»

При
установлении связи «один к одному»
каждой строке таблицы А может
соответствовать только одна строка
таблицы Б и наоборот. Связь «один к
одному» создается в том случае, когда
оба связанные столбца являются первичными
ключами или на них наложены ограничения
уникальности.

Этот
вид связи используется редко, поскольку
в такой ситуации связываемые данные
обычно можно хранить в одной таблице.
Использовать связь вида «один к
одному» можно в указанных ниже случаях.

• Чтобы
разделить таблицу, содержащую слишком
много столбцов.

• Чтобы
изолировать часть таблицы по соображениям
безопасности.

• Для
хранения данных кратковременного
использования, удалить которые проще
всего путем очистки таблицы.

• Для
хранения данных, имеющих отношение
только к подмножеству основной таблицы.

В
Microsoft Access сторона связи «один к одному»,
которой соответствует первичный ключ,
обозначается символом ключа. Сторона
связи, которой соответствует внешний
ключ, также обозначается символом ключа.

Создание
связей между таблицами

При
установлении связи между таблицами
связанные поля не обязательно должны
иметь одинаковые названия. При этом у
них должен быть один и тот же тип данных,
если только поле, являющееся первичным
ключом, не относится к типу «Счетчик».
Поле типа «Счетчик» можно связать
с полем типа «Числовой» только в
том случае, если для свойства FieldSize
(размер поля) каждого из них задано одно
и то же значение. Например, можно связать
столбцы типов «Счетчик» и «Числовой»,
если для свойства FieldSize каждого из них
установлено значение «Длинное целое».
Даже если оба связываемых столбца
относятся к типу «Числовой», значение
свойства FieldSize для обоих полей должно
быть одинаковым.

Задача нормализации

Ранее мы встретились
с чисто механическим переходом от
иерархической структуры к реляционной
и назвали этот процесс нормализацией.

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

В качестве неудачно
спроектированной рассмотрим таблицу
ZAKAZ. Что неправильно? В
нее включено поле «Реквизиты»
заказчика, значение которого зависит
от значения кода заказчика, но не зависит
от ключа таблицы — номера заказа.
Появляется возможность потери информации-
при удалении заказа (обычная операция)
будутутраченыи сведения о реквизитах
заказчика (если это единственный заказ
этого заказчика). Если у одного заказчика
заказов много, то нужно как-то избежатьповторногоих ввода.

Выход — в удалении
поля «Банк_рек» и включении его, с
добавлением кода заказчика в качестве
ключа в таблицу- словарь SLZAK.
Получится, что одно поле в словаре будет
обслуживать много полей в основной
таблице. Кроме этого, словарь можно
использовать и с другими таблицами, в
которых есть поле «Код_зак».

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

Если применить
этот принцип снова к тому же примеру —
обнаружим еще поле «Цена» — его значение
является функцией поля «Код_прод»,
поэтому следует поступить аналогично
«Реквизитам» — сделать словарем.

Последнее поле
«Стоимость» также является лишним,
поскольку его значение- вычислимои равно произведению цены на объем,
поэтому его не нужно хранить в БД.

Таким образом,
после вынесения третьего и седьмого
полей в словари мы получим
оптимально-компромиссное решение.
Компромисс заключается, с одной стороны,
в полноте нормализации, с другой — в
минимизации числа таблиц.

Выводы:

Практические
правила нормализации, связанные с
выбором полей и главного ключа следующие:

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

2. Если главный ключ
   не просматривается — подумать, правильно
   ли подобран состав полей.

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

Можно ли обмануть домофон?

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

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

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

Часто можно услышать, что домофон можно вывести из строя электрошокером. Да, тонкая электроника серьёзный заряд действительно не перенесет. У механического удара на 10-15 см ниже панели домофона те же последствия. Но это порча имущества и статья УК РФ.

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

Некоторые домофоны под ключ-«таблетку» могут открываться с помощью батарейки «крона». Способ гуманный и безопасный для домофона, но срабатывает редко.

Создание связи по внешнему ключу в конструкторе таблицCreate a foreign key relationship in Table Designer

Использование среды SQL Server Management StudioUsing SQL Server Management Studio

1. В обозревателе объектов щелкните правой кнопкой мыши таблицу, которая будет содержать внешний ключ для связи, и выберите пункт Конструктор.In Object Explorer, right-click the table that will be on the foreign-key side of the relationship and click Design.

   Таблица откроется в окне Конструктор таблиц.The table opens in Table Designer.

2. В меню конструктора таблиц выберите пункт Связи.From the Table Designer menu, click Relationships.

3. В диалоговом окне Связи внешнего ключа щелкните Добавить.In the Foreign-key Relationships dialog box, click Add.

   Связь появится в списке Выбранные связи с именем, установленным системой, в формате format FK_<tablename><tablename>, где tablename (имя таблицы) является именем внешнего ключа.The relationship appears in the Selected Relationship list with a system-provided name in the format FK<tablename>_<tablename>, where tablename is the name of the foreign key table.

4. Щелкните нужную связь в списке Выбранные связи .Click the relationship in the Selected Relationship list.

5. Щелкните Спецификация таблиц и столбцов в сетке справа и нажмите кнопку с многоточием ( … ) справа от свойства.Click Tables and Columns Specification in the grid to the right and click the ellipses (…) to the right of the property.

6. В диалоговом окне Таблицы и столбы в раскрывающемся списке Первичный ключ выберите таблицу, которая будет находиться на стороне первичного ключа связи.In the Tables and Columns dialog box, in the Primary Key drop-down list, choose the table that will be on the primary-key side of the relationship.

7. В сетке внизу выберите столбцы, составляющие первичный ключ таблицы.In the grid beneath, choose the columns contributing to the table’s primary key. В соседней ячейке сетки справа от каждого столбца выберите соответствующий столбец внешнего ключа таблицы внешнего ключа.In the adjacent grid cell to the right of each column, choose the corresponding foreign-key column of the foreign-key table.

   Конструктор таблиц автоматически предлагает имя для связи.Table Designer suggests a name for the relationship. Чтобы его изменить, отредактируйте содержимое текстового поля Имя связи .To change this name, edit the contents of the Relationship Name text box.

8. Нажмите кнопку OК , чтобы создать связь.Choose OK to create the relationship.

9. Закройте окно конструктора таблиц и сохраните внесенные изменения, чтобы изменения связи внешнего ключа вступили в силу.Close the table designer window and save your changes for the foreign key relationship change to take effect.

1.2.5. Первичный ключ

Мы уже достаточно много говорили про ключевые поля, но ни разу их не использовали. Самое интересное, что все работало. Это преимущество, а может недостаток базы данных Microsoft SQL Server и MS Access. В таблицах Paradox такой трюк не пройдет и без наличия ключевого поля таблица будет доступна только для чтения.

В какой-то степени ключи являются ограничениями, и их можно было рассматривать вместе с оператором CHECK, потому что объявление происходит схожим образом и даже используется оператор CONSTRAINT. Давайте посмотрим на этот процесс на примере. Для этого создадим таблицу из двух полей «guid» и «vcName». При этом поле «guid» устанавливается как первичный ключ:

CREATE TABLE Globally_Unique_Data
(
 guid uniqueidentifier DEFAULT NEWID(),
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (Guid)
)

Самое вкусное здесь это строка CONSTRAINT. Как мы знаем, после этого ключевого слова идет название ограничения, и объявления ключа не является исключением. Для именования первичного ключа, я рекомендую использовать именование типа PK_имя, где имя – это имя поля, которое должно стать главным ключом. Сокращение PK происходит от Primary Key (первичный ключ).

После этого, вместо ключевого слова CHECK, которое мы использовали в ограничениях, стоит оператор PRIMARY KEY, Именно это указывает на то, что нам необходима не проверка, а первичный ключ. В скобках указывается одно, или несколько полей, которые будут составлять ключ.

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

В данном примере, в качестве первичного ключа выступает поле типа uniqueidentifier (GUID). Значение по умолчанию для этого поля – результат выполнения серверной процедуры NEWID.

Внимание

Только один первичный ключ может быть создан для таблицы

Для простоты примеров, в качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше, если он будет типа «autoincrement» (автоматически увеличивающееся/уменьшающееся число). В MS SQL Server таким полем является IDENTITY, а в MS Access это поле типа «счетчик».

Следующий пример показывает, как создать таблицу товаров, в которой в качестве первичного ключа выступает целочисленное поле с автоматическим увеличением:

CREATE TABLE Товары
(
  id int IDENTITY(1, 1),
  товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY (id)
)

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

Первичный ключ может состоять из более, чем одной колонки. Следующий пример создает таблицу, в которой поля «id» и «Товар» образуют первичный ключ, а значит, будет создан индекс уникальности на оба поля:

CREATE TABLE Товары1
(
  id int IDENTITY(1, 1),
  Товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY 
         (id, )
)

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

Единственный недостаток первичного ключа из нескольких колонок – проблемы создания связей. Тут приходиться выкручиваться различными методами, но проблема все же решаема. Достаточно только ввести поле типа uniqueidentifier и производить связь по нему. Да, в этом случае у нас получаются уникальными первичный ключ и поле типа uniqueidentifier, но эта избыточность в результате не будет больше, чем та же таблица, где первичный ключ uniqueidentifier, а на поля, которые должны быть уникальными установлено ограничение уникальности. Что выбрать? Зависит от конкретной задачи и от того, с чем вам удобнее работать.