Первичный ключ и внешний ключ таблиц реляционных баз данных

Представление в модели предметной области

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

      public
      class Story
{
  publicint    Id      { get; set; }
  publicstring Title   { get; set; }
  publicstring Url     { get; set; }
  publicstring Content { get; set; }
}

Приведённый класс не содержит информации об дополнительных ключах, но при реализации методов Equals() и GetHashCode() для операций поиска и сравнения объектов программист повторяет логику работы дополнительного ключа:

      public
      class Story
{
  // Свойства пропущены…// Перегрузка object.Equalspublicoverridebool Equals(object obj)
  {
    if (obj == null || GetType() != obj.GetType())
      returnfalse;

    var anotherStory = (Story)obj;

    return Title == anotherStory.Title && Url == anotherStory.Url;
  }

  // Перегрузка object.GetHashCodepublicoverrideint GetHashCode()
  {
    var hashCode = 1;

    if (Title != null)
 hashCode = (hashCode * 397) ^ Title.GetHashCode();

    if (Url != null)
 hashCode = (hashCode * 397) ^ Url.GetHashCode();

    return hashCode;
  }
}

Обратите внимание на то, что для используемых полей допускается значение null. Это сделано потому, что мы можем вызвать описанные методы для только что созданного объекта (не инициализированного конкретными значениями)

Подобный код может быть автоматически сгенерирован на основании анализа дополнительных ключей в БД. В следующем разделе приведен пример практической реализации данной идеи на основе ORM BLToolkit

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, а на поля, которые должны быть уникальными установлено ограничение уникальности. Что выбрать? Зависит от конкретной задачи и от того, с чем вам удобнее работать.

Важная информация по безопасности

Для доступа к объектам, защищенным главным ключом службы, необходима учетная запись службы SQL Server , которая использовалась для создания ключа, или учетная запись компьютера. Т. е. учетная запись компьютера привязана к системе, в которой был создан ключ. Можно изменить учетную запись службы SQL Serverили учетную запись компьютера, не теряя доступа к ключу. Однако если изменить обе учетные записи, доступ к главному ключу службы будет потерян. Если доступ к главному ключу службы будет потерян без одного из этих элементов, то не удастся расшифровать данные и объекты, зашифрованные с помощью первоначального ключа.

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

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

Внимание!

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

SQL CREATE TABLE с PRIMARY KEY CONSTRAINT для большего количества столбцов

В следующем разделе мы обсудим использование SQL PRIMARY KEY CONSTRAINT вместе с оператором CREATE TABLE для двух или более столбцов.

Пример:

В следующем примере создается таблица. Таблица должна содержать ПЕРВИЧНЫЙ КЛЮЧ с комбинацией двух столбцов ‘cust_code’ и ‘cust_city’. Вот имя поля и типы данных:

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

Выход:

Создание файла базы данных

При запуске Access открывается диалоговое окно — Окно запуска, в котором предлагается создать новую БД, запустить Мастера БД или открыть существую­щую БД.

В Access поддерживаются два способа создания БД. Можно создать пустой файл БД, а затем разрабатывать таблицы, формы, отчеты и другие объекты, добав­ляя их в БД. Такой способ является профессиональным и наиболее гибким, но тре­бует отдельного определения каждого элемента БД. При выборе такого способа создания БД надо в окне запуска установить флажок Новая база данных. В рас­крывшемся окне Файл новой базы данных следует выбрать каталог и задать имя создаваемой БД. Раскроется Окно базы данных.

Вниманию студентов! Студенческие БД должны создаваться в директории StudentGRNNN.

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

Флажок Открыть базу данных окна запуска позволяет открыть ранее

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

• АлтГТУ 419
• АлтГУ 113
• АмПГУ 296
• АГТУ 266
• БИТТУ 794
• БГТУ «Военмех» 1191
• БГМУ 172
• БГТУ 602
• БГУ 153
• БГУИР 391
• БелГУТ 4908
• БГЭУ 962
• БНТУ 1070
• БТЭУ ПК 689
• БрГУ 179
• ВНТУ 119
• ВГУЭС 426
• ВлГУ 645
• ВМедА 611
• ВолгГТУ 235
• ВНУ им. Даля 166
• ВЗФЭИ 245
• ВятГСХА 101
• ВятГГУ 139
• ВятГУ 559
• ГГДСК 171
• ГомГМК 501
• ГГМУ 1967
• ГГТУ им. Сухого 4467
• ГГУ им. Скорины 1590
• ГМА им. Макарова 300
• ДГПУ 159
• ДальГАУ 279
• ДВГГУ 134
• ДВГМУ 409
• ДВГТУ 936
• ДВГУПС 305
• ДВФУ 949
• ДонГТУ 497
• ДИТМ МНТУ 109
• ИвГМА 488
• ИГХТУ 130
• ИжГТУ 143
• КемГППК 171
• КемГУ 507
• КГМТУ 269
• КировАТ 147
• КГКСЭП 407
• КГТА им. Дегтярева 174
• КнАГТУ 2909
• КрасГАУ 370
• КрасГМУ 630
• КГПУ им. Астафьева 133
• КГТУ (СФУ) 567
• КГТЭИ (СФУ) 112
• КПК №2 177
• КубГТУ 139
• КубГУ 107
• КузГПА 182
• КузГТУ 789
• МГТУ им. Носова 367
• МГЭУ им. Сахарова 232
• МГЭК 249
• МГПУ 165
• МАИ 144
• МАДИ 151
• МГИУ 1179
• МГОУ 121
• МГСУ 330
• МГУ 273
• МГУКИ 101
• МГУПИ 225
• МГУПС (МИИТ) 636
• МГУТУ 122
• МТУСИ 179
• ХАИ 656
• ТПУ 454
• НИУ МЭИ 641
• НМСУ «Горный» 1701
• ХПИ 1534
• НТУУ «КПИ» 212
• НУК им. Макарова 542
• НВ 777
• НГАВТ 362
• НГАУ 411
• НГАСУ 817
• НГМУ 665
• НГПУ 214
• НГТУ 4610
• НГУ 1992
• НГУЭУ 499
• НИИ 201
• ОмГТУ 301
• ОмГУПС 230
• СПбПК №4 115
• ПГУПС 2489
• ПГПУ им. Короленко 296
• ПНТУ им. Кондратюка 119
• РАНХиГС 186
• РОАТ МИИТ 608
• РТА 243
• РГГМУ 118
• РГПУ им. Герцена 124
• РГППУ 142
• РГСУ 162
• «МАТИ» — РГТУ 121
• РГУНиГ 260
• РЭУ им. Плеханова 122
• РГАТУ им. Соловьёва 219
• РязГМУ 125
• РГРТУ 666
• СамГТУ 130
• СПбГАСУ 318
• ИНЖЭКОН 328
• СПбГИПСР 136
• СПбГЛТУ им. Кирова 227
• СПбГМТУ 143
• СПбГПМУ 147
• СПбГПУ 1598
• СПбГТИ (ТУ) 292
• СПбГТУРП 235
• СПбГУ 582
• ГУАП 524
• СПбГУНиПТ 291
• СПбГУПТД 438
• СПбГУСЭ 226
• СПбГУТ 193
• СПГУТД 151
• СПбГУЭФ 145
• СПбГЭТУ «ЛЭТИ» 380
• ПИМаш 247
• НИУ ИТМО 531
• СГТУ им. Гагарина 114
• СахГУ 278
• СЗТУ 484
• СибАГС 249
• СибГАУ 462
• СибГИУ 1655
• СибГТУ 946
• СГУПС 1513
• СибГУТИ 2083
• СибУПК 377
• СФУ 2423
• СНАУ 567
• СумГУ 768
• ТРТУ 149
• ТОГУ 551
• ТГЭУ 325
• ТГУ (Томск) 276
• ТГПУ 181
• ТулГУ 553
• УкрГАЖТ 234
• УлГТУ 536
• УИПКПРО 123
• УрГПУ 195
• УГТУ-УПИ 758
• УГНТУ 570
• УГТУ 134
• ХГАЭП 138
• ХГАФК 110
• ХНАГХ 407
• ХНУВД 512
• ХНУ им. Каразина 305
• ХНУРЭ 324
• ХНЭУ 495
• ЦПУ 157
• ЧитГУ 220
• ЮУрГУ 306

Полный список ВУЗов

Чтобы распечатать файл, скачайте его (в формате Word).

SQL Учебник

SQL ГлавнаяSQL ВведениеSQL СинтаксисSQL SELECTSQL SELECT DISTINCTSQL WHERESQL AND, OR, NOTSQL ORDER BYSQL INSERT INTOSQL Значение NullSQL Инструкция UPDATESQL Инструкция DELETESQL SELECT TOPSQL MIN() и MAX()SQL COUNT(), AVG() и …SQL Оператор LIKESQL ПодстановочныйSQL Оператор INSQL Оператор BETWEENSQL ПсевдонимыSQL JOINSQL JOIN ВнутриSQL JOIN СлеваSQL JOIN СправаSQL JOIN ПолноеSQL JOIN СамSQL Оператор UNIONSQL GROUP BYSQL HAVINGSQL Оператор ExistsSQL Операторы Any, AllSQL SELECT INTOSQL INSERT INTO SELECTSQL Инструкция CASESQL Функции NULLSQL ХранимаяSQL Комментарии

Ключи

Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Аннотация IdClass

Допустим, у нас есть таблица с именем Account и в ней есть два столбца – AccountNumber, AccountType– , которые образуют составной ключ. Теперь мы должны нанести его на карту в JPA.

В соответствии со спецификацией JPA давайте создадим класс Account Id с этими полями первичного ключа:

public class AccountId implements Serializable {
    private String accountNumber;

    private String accountType;

    // default constructor

    public AccountId(String accountNumber, String accountType) {
        this.accountNumber = accountNumber;
        this.accountType = accountType;
    }

    // equals() and hashCode()
}

Далее давайте свяжем Идентификатор учетной записи класс с сущностью Учетная запись .

Для этого нам нужно аннотировать объект с помощью аннотации @IdClass . Мы также должны объявить поля из класса AccountId в сущности Account и аннотировать их с помощью @Id :

@Entity
@IdClass(AccountId.class)
public class Account {
    @Id
    private String accountNumber;

    @Id
    private String accountType;

    // other fields, getters and setters
}

Аннотация EmbeddedId

@EmbeddedId является альтернативой аннотации @IdClass .

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

В этом случае класс первичного ключа BookID должен быть аннотирован с помощью @Embeddable :

@Embeddable
public class BookId implements Serializable {
    private String title;
    private String language;

    // default constructor

    public BookId(String title, String language) {
        this.title = title;
        this.language = language;
    }

    // getters, equals() and hashCode() methods
}

Затем нам нужно встроить этот класс в сущность B ook , используя @EmbeddedId :

@Entity
public class Book {
    @EmbeddedId
    private BookId bookId;

    // constructors, other fields, getters and setters
}

Ссылочная целостность

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

Как при этом не допустить появления \»болтающихся в воздухе\» строк дочерней таблицы? Для этого существуют правила ссылочной целостности ON UPDATE и ON DELETE, которые, по стандарту SQL 92, могут содержать следующие инструкции:

Более интересные моменты возникают, когда мы удаляем или изменяем строки родительской таблицы. Как при этом не допустить появления \»болтающихся в воздухе\» строк дочерней таблицы? Для этого существуют правила ссылочной целостности ON UPDATE и ON DELETE, которые, по стандарту SQL 92, могут содержать следующие инструкции:

• CASCADE — обеспечивает автоматическое выполнение в дочерней таблице тех же изменений, которые были сделаны в родительском ключе. Если родительский ключ был изменен — ON UPDATE CASCADE обеспечит точно такие же изменения внешнего ключа в дочерней таблице. Если строка родительской таблицы была удалена, ON DELETE CASCADE обеспечит удаление всех соответствующих строк дочерней таблицы.
• SET NULL — при удалении строки родительской таблицы ON DELETE SET NULL установит значение NULL во всех столбцах вторичного ключа в соответствующих строках дочерней таблицы. При изменении родительского ключа ON UPDATE SET NULL установит значение NULL в соответствующих столбцах соответствующих строк (о как:) дочерней таблицы.
• SET DEFAULT — работает аналогично SET NULL, только записывает в соответствующие ячейки не NULL, а значения, установленные по умолчанию.
• NO ACTION (установлено по умолчанию) — при изменении родительского ключа никаких действий с внешним ключом в дочерней таблице не производится. Но если изменение значений родительского ключа приводит к нарушению ссылочной целосности (т.е. к появлению «висящих в воздухе» строк дочерней таблицы), то СУБД не даст произвести такие изменения родительской таблицы.

Ну а сейчас — от общего к частному.

Создать первичный ключ (оператор ALTER TABLE)

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

Синтаксис

Синтаксис для создания первичного ключа с помощью оператора ALTER TABLE в SQL.

ALTER TABLE table_name
ADD CONSTRAINT constraint_name
PRIMARY KEY (column1, column2, … column_n);

table_name

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

constraint_name

Название первичного ключа

column1, column2, … column_n

Столбцы, составляющие первичный ключ

Пример

Давайте посмотрим, как создать первичный ключ с помощью оператора ALTER TABLE в SQL. Скажем так, у нас уже есть таблица suppliers, созданная в нашей базе данных. Мы могли бы добавить первичный ключ к таблице suppliers с помощью следующего оператора ALTER TABLE.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id);

В этом примере мы создали первичный ключ для существующей таблицы suppliers, который называется sources_pk. Он состоит из столбца supplier_id.
Мы также могли бы создать первичный ключ с более чем одним полем, как показано ниже.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id, supplier_name);

Этот пример создал бы первичный ключ с именем supplier_pk, который состоит из комбинации столбцов supplier_id и supplier_name.

Отношение один к одному

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

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

 
CREATE TABLE Names
(
 idName uniqueidentifier DEFAULT NEWID(), 
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (idName)
)

CREATE TABLE Phones
(
 idPhone uniqueidentifier DEFAULT NEWID(),
 vcPhone varchar(10), 
 CONSTRAINT PK_idPhone PRIMARY KEY (idPhone),
 CONSTRAINT FK_idPhone FOREIGN KEY (idPhone)
   REFERENCES Names (idName)
)

Внешний ключ нужен только у одной из таблиц. Так как связь идет один к одному, то не имеет значения, в какой таблице создать его.

Проектирование базы данных

   Основой любой реляционной БД являются
таблицы. Разработка таблиц яв­ляется одним из наиболее сложных этапов в
проектировании БД. Грамотно спро­ектированные таблицы являются основой для
создания работоспособной и эффек­тивной БД.

   Понятие таблицы в Access полностью соответствует аналогичному
понятию реляционной модели данных. Любая таблица реляционной БД состоит из строк
(называемых также записями) и столбцов (называемых
также полями).

  Строки таблицы содержат сведения об
однотипных объектах — документах, людях, предметах. На пересечении столбца и
строки находится конкретное значе­ние, характеризующее объект.

   Можно сформулировать ряд основных
требований, которым должны удов­летворять таблицы.

    1. Информация в таблице не должна
дублироваться, т.е. в таблице не должно существовать двух записей с полностью
совпадающим набором значений ее по­лей.

    2. На пересечении любого столбца и
любой строки должно находиться одно

значение.

    3.  Не рекомендуется включать в
таблицу данные, которые являются резуль­татом вычислений.

    4.  Значения данных в одном и том же
столбце должны принадлежать к од­ному и тому же типу, доступному для
использования в данной СУБД.

    5. Каждое поле должно иметь уникальное
имя.

    6. Каждая таблица должна иметь
первичный ключ.

    7. Таблицы БД должны быть связаны
через внешние ключи.

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

   В Access можно выделить три типа ключевых полей: простой ключ, состав­ной
ключ и поле счетчика.

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

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

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

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

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

   Сила реляционных баз данных, таких как
БД Microsoft Access, заключается в том, что они могут быстро найти и связать данные
из разных таблиц при помощи запросов, форм и отчетов. Таблицы реляционных БД
связываются через одинако­вые значения одноименных полей, содержащихся в
связываемых таблицах. Такие поля называются внешним ключом для
этих таблиц. Все таблицы БД Access должны
быть связаны с помощью внешних ключей.

Составной ключ (composite key)

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

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

create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

В примере выше два поля объединенные в составной ключ и в таблице не будет записей с этими одинаковыми полями.

Это все, что касается ключей в SQL. Это небольшое пособие — подготовка к статье связи sql где мы подробно рассмотрим как объединять таблицы, чтобы они составляли единую базу данных.

Что такое внешний ключ

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

Рисунок 1: Первичный и Внешний ключ

Например, предположим, что есть база данных продаж. Имеются таблицы клиентов и продуктов. Таблица customer содержит столбцы customer_id, name, address и contact_no. Первичный ключ таблицы клиента — customer_id. Товар имеет столбцы product_id, name, quality. Первичный ключ таблицы продукта — product_id. Размещение product_id в таблице клиентов создаст связь между двумя таблицами. Product_id в таблице product является первичным ключом, но это внешний ключ в customer_table. Аналогично, можно соединять таблицы в базе данных, используя внешний ключ.

ОСНОВНОЙ КЛЮЧ

SQL PRIMARY KEY — это столбец в таблице, который должен содержать уникальное значение, которое можно использовать для уникальной идентификации каждой строки таблицы.

Тем не менее, SQL поддерживает первичные ключи напрямую с ограничением PRIMARY KEY.

Функционально это то же самое, что и ограничение UNIQUE, за исключением того, что для данной таблицы можно определить только один PRIMARY KEY. PRIMARY KEY не допускает значения NULL.

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

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

Первичные ключи могут быть указаны во время CREATING TABLE или во время изменения структуры существующей таблицы с помощью инструкции ALTER TABLE.

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

Синтаксис:

 CREATE TABLE <имя_таблицы>
column1 data_type  NOT NULL PRIMARY KEY,
column2 data_type ,
...);

Параметры:

Денормализация

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

5
10
Голоса

Рейтинг статьи

Разница между первичным ключом и внешним ключом

Определение

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

Количество связанных таблиц

Первичный ключ связан с одной таблицей, а внешний ключ связан с двумя таблицами. Таким образом, вытекает из базовой концепции, это еще одно различие между первичным ключом и внешним ключом.

Повторяющиеся значения

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

Количество ключей

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

использование

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

Заключение

Первичный ключ и внешний ключ — это два типа ключей, используемых в СУБД. Разница между первичным ключом и внешним ключом заключается в том, что первичный ключ используется для уникальной идентификации записей в таблице, а внешний ключ используется для соединения двух таблиц вместе.   

Ключи и ссылочная целостность в MySQL и Oracle

Oracle поддерживает первичные, уникальные, внешние ключи в полном объеме. Oracle поддерживает следующие правила ссылочной целостности:

• NO ACTION (устанавливается по умолчанию) в более жестком, чем по стандарту SQL 92, варианте: запрещается изменение и удаление строк родительской таблицы, для которых имеются связанные строки в дочерних таблицах.
• ON DELETE CASCADE.

Более сложные правила ссылочной целостности в Oracle можно реализовать через механизм триггеров.

MySQL версии 4.1 (последняя на момент написания статьи стабильная версия) позволяет в командах CREATE / ALTER TABLE задавать фразы REFERENCES / FOREIGN KEY, но в работе никак их не учитывает и реально внешние ключи не создает. Соответственно правила ссылочной целостности, реализуемые через внешние ключи, в MySQL не поддерживаются. И все заботы по обеспечению целостности и непротиворечивости информации в базе MySQL ложатся на плечи разработчиков клиентских приложений.