Что такое внешний ключ базы данных? учебник для новичков

Содержание:

Базы данных «ключ — значение»

В последние годы появились базы данных нового типа, получившие название «ключ — значение» (англ. «key-value» database), которые хорошо показали себя в распределённых системах с большой нагрузкой, в том числе в поисковых системах Интернета.

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

СУБД поддерживает только добавление записи, поиск значения по ключу, а также изменение и удаление найденной таким образом записи. Никакие связи между значениями в явном виде не поддерживаются. Хотя объект может содержать ссылки на другие объекты (их ключи), СУБД не проверяет их правильность. Обеспечение надёжности и целостности данных возлагается не на СУБД, а на прикладную программу, которая работает с базой данных.

Ключи — это хэш-коды хранящихся данных (значений). Ключи объединяются в группы так, что все данные, связанные с ключами одной группы, хранятся на одном сервере. Таким образом, по ключу можно сразу определить нужный сервер и напрямую получить от него данные. За счет этого обеспечивается масштабируемость — если один сервер не справляется с нагрузкой, нужно добавить ещё один и разделить данную группу ключей на две части.

Многие базы типа «ключ — значение» хранят документы — объекты, которые имеют произвольный набор полей-свойств, например:

Важно, что другие документы могут иметь совершенно другой набор полей. Такие базы данных называют документоориентированными.. Итак, базы данных «ключ — значение» обладают достоинствами, которые принципиально важны в некоторых задачах:• масштабируемость — возможность наращивания мощности распределенной системы простым добавлением новых серверов;
• простота представления данных, близость к человеческому восприятию

Итак, базы данных «ключ — значение» обладают достоинствами, которые принципиально важны в некоторых задачах:• масштабируемость — возможность наращивания мощности распределенной системы простым добавлением новых серверов;
• простота представления данных, близость к человеческому восприятию.

В то же время у них есть и недостатки:• СУБД не поддерживают связи между данными, не обеспечивает целостность данных;
• нет стандарта на язык описания и управления данными (для реляционных БД таким стандартом стал язык SQL);
• основной вид запросов — поиск значения по ключу, поэтому очень сложно, например, выполнить сортировку данных.

Кроме того, есть бесплатные СУБД этого класса, например MongoDB (www.mongodb.org) или CouchDB (couchdb.apache.org).

Следующая страница Вопросы и задания

Cкачать материалы урока

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 Комментарии

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

Создание главной кнопочной формы базы данных access

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

      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

Как хранится информация в БД

Внешний nfc модуль: что это такое и как установить

В основе всей структуры хранения лежат три понятия:

База данных;
Таблица;
Запись.

База данных

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц. Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц). Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога. Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов. Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel). Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация. В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

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

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

Создадим для сайта новую БД и дадим ей название «weather_diary».
Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
- Город (тип: текст);
- День (тип: дата);
- Температура (тип: число);
- Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
- Были ли осадки (тип: истина или ложь);
- Комментарий (тип: текст).
При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение. А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой. Что это за связи? Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации. В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными. Но можно поступить иначе:

Создать новую таблицу с именем „cities“.
Все города в России известны, поэтому их все можно добавить в одну таблицу.
Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

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

Это интересно: Трудовая книжка

SQL PRIMARY KEY в CREATE TABLE

Следующий SQL создает первичный ключ о «ID» в столбик, когда таблица «Persons» создается:

MySQL:

CREATE TABLE Persons
(
    ID int NOT NULL,

LastName varchar(255) NOT NULL,

FirstName varchar(255),

Age int,

PRIMARY KEY (ID)
);

SQL Server / Oracle / MS Access:

CREATE TABLE Persons
(
    ID int NOT NULL PRIMARY KEY,

LastName varchar(255) NOT NULL,

FirstName varchar(255),

Age int
);

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

MySQL / SQL Server / Oracle / MS Access:

CREATE TABLE Persons
(
    ID int NOT NULL,

LastName varchar(255) NOT NULL,

FirstName varchar(255),

Age int,

CONSTRAINT PK_Person PRIMARY KEY (ID,LastName)
);

Примечание: В приведенном выше примере существует только один первичный ключ (PK_Person).
Однако значение первичного ключа состоит из двух столбцов (ID + LastName).

Практическое применение

Мы могли бы закончить на этом, но у некоторых читателей, вероятно, возникнет вопрос: зачем такое усложнение для системы объектно-реляционного отображения, которая не управляет состоянием объектов? И они отчасти правы. Число сценариев, где можно применить изложенные концепции для BLToolkit, крайне мало по сравнению с такими системами объектно-реляционного отображения как NHibernate и Entity Framework. Однако мне хотелось бы привести пример одного из таких сценариев.

Предположим, что нам необходимо реализовать просмотр и добавление новых историй с помощью веб-сайта на платформе ASP.NET MVC. Пример:

publicclass HomeController : Controller
{
  privatereadonly StoryRepository repository = new StoryRepository();
  privateconstint PageSize = 10;

  // Просмотр последних 10 историй.public ActionResult Index(int? page)
  {
    var stories = repository.GetStories(page ?? 0, PageSize);

    return View(stories);
  }

  // Предложение добавить новую историю.public ActionResult Add()
  {
    return View(new Story());
  }

  // Добавление новой истории.
  
  public ActionResult Add(string title, string url, string content)
  {
    var story = new Story
    {
      Title   = title,
      Url     = url,
      Content = content
    };

    Validate(story);

    if (ModelState.IsValid)
    {
      try
      {
        repository.SaveStory(story);
        return RedirectToAction("Index");
      }
      catch (Exception ex)
      {
        ModelState.AddModelError("Saving error", ex);
      }
    }

    return View(story);
  }

  // Валидацию сделаем для простоты вручнуюprivatevoid Validate(Story story)
  {
    if (string.IsNullOrWhiteSpace(story.Title))
      ModelState.AddModelError("Validation error", "The title is empty");

    if (string.IsNullOrWhiteSpace(story.Url))
      ModelState.AddModelError("Validation error", "The url is empty");

    if (string.IsNullOrWhiteSpace(story.Content))
      ModelState.AddModelError("Validation error", "The content is empty");
  }
}

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

ПРИМЕЧАНИЕ

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

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

ПРИМЕЧАНИЕ

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

По этим причинам мы перед добавлением проанализируем результаты в кэше.

publicclass HomeController : Controller
{
  // Показаны только изменения в объекте контроллера!privateconststring CacheId = "LastStories";

  public ActionResult Index(int? page)
  {
    var stories = (IEnumerable<Story>)HttpRuntime.Cache.Get(CacheId);

    if (stories == null)
    {
      stories = repository.GetStories(page ?? 0, PageSize);
      
      // В реальности рекомендуется устанавливать зависимость// объектов от таблицы в базе данных.
      HttpRuntime.Cache.Insert(CacheId, stories);
    }

    return View(stories);
  }

  
  public ActionResult Add(string title, string url, string content)
  {
    var story = new Story
    {
      Title   = title,
      Url     = url,
      Content = content
    };

    Validate(story);

    if (ModelState.IsValid)
    {
      var stories = (IEnumerable<Story>)HttpRuntime.Cache.Get(CacheId);

      if (stories != null)
      {
        // Используем поддержку дополнительных ключей, т.к.// объект сравнения неперсистентен.if (!stories.Contains(story))
        {
          // Сбрасываем вручную кеш.
          HttpRuntime.Cache.Remove(CacheId);
        }
        else
        {
          ModelState.AddModelError(
            "Saving error",
            "Sorry, your story already exist on our site.");
        }
      }

      try
      {
        if (ModelState.IsValid)
        {
          repository.SaveStory(story);
          return RedirectToAction("Index");
        }
      }
      catch (Exception ex)
      {
        ModelState.AddModelError("Saving error", ex);
      }
    }

    return View(story);
  }
}

Определение ключевых полей

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

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

Для создания ключевого поля типа Счетчик необходимо в режиме Конструктора таблиц:

Включить в таблицу поле счетчика.
Задать для него автоматическое увеличение на 1.
Указать это поле в качестве ключевого путем нажатия на кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).

Если до сохранения созданной таблицы ключевые поля не были определены, то при сохранении будет выдано сообщение о создании ключевого поля. При нажатии кнопки Да (Yes) будет создано ключевое поле счетчика с именем Код (ID) и типом данных Счетчик (AutoNumber).

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

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

Открыть таблицу в режиме Конструктора.
Выделить поля, которые необходимо определить как ключевые.
Нажать кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).

Для составного ключа существенным может оказаться порядок образующих ключ полей. Сортировка записей осуществляется в соответствии с порядком ключевых полей в окне Конструктора таблицы. Если необходимо указать другой порядок сортировки без изменения порядка ключевых полей, то сначала нужно определить ключ, а затем нажать кнопку Индексы (Indexes) на панели инструментов Конструктор таблиц (Table Design). Затем в появившемся окне Индексы (Indexes) нужно указать другой порядок полей для индекса с именем Ключевое поле (Primary Key).

Рассмотрим в качестве примера применения составного ключа таблицу «Заказано» (OrderDetails) базы данных (Northwind) (рис. 2.23).

В данном случае в качестве составного ключа используются поля «Код заказа» (OrderlD) и «КодТовара» (ProductID), т. к. ни одно из этих полей в отдельности не гарантирует уникальность записи. При этом в таблице выводится не код товара, а наименование товара, т. к. поле «КодТовара» (ProductID) данной таблицы содержит подстановку из таблицы «Товары» (Products), а значения полей «КодТовара» (ProductID) этих таблиц связаны отношением «один-ко-многим» (одной записи таблицы «Товары» (Products) может соответствовать несколько записей таблицы «Заказано» (OrderDetails)). Оба поля могут содержать повторяющиеся значения. Так, один заказ может включать в себя несколько товаров, а в разные заказы могут включаться одинаковые товары. В то же время сочетание полей «КодЗаказа» (OrderlD) и «КодТовара» (ProductID) однозначно определяет каждую запись таблицы «Заказы» (OrderDetails).

Чтобы изменить ключ, необходимо:

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

Чтобы удалить ключ, необходимо:

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

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

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

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

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

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

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

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

значение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Столбец, который в базе данных должен быть уникальным помечают первичным ключом. Первичный ключ или primary key означает, что в таблице значение колонки primary key не может повторяться. Таким образом данный ключ позволяет однозначно идентифицировать запись в таблице не боясь при этом, что значение столбца повториться. Сразу пример: допустим у Вас есть таблица пользователей. В данной таблице есть поля: ФИО, год рождения, телефон. Как идентифицировать пользователя? Таким параметрам как ФИО и телефон доверять нельзя. Ведь у нас может быть несколько пользователей не только с одинаковой фамилией, но и с именем. Телефон может меняться со временем и пользователь с номером телефона может оказаться не тем кто у нас в базе данных.

Вот для этого и придумали первичный ключ. Один раз присвоили уникальный идентификатор и все. В mySql на примере которой мы выполняем все примеры из цикла статей по SQL поле AUTO_INCREMENT нельзя задать если не указать, что это первичный ключ.

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

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

NoSQL как альтернатива традиционным БД

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

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

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

ОСНОВНЫЕ ОТЛИЧИЯ

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

Основной ключ

Определение первичного ключа

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

Совместный первичный ключ

Характеристики первичного ключа

Необходимость первичного ключа

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

Бессмысленность первичного ключа

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

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

Основной принцип выбора первичного ключа: не используйте в качестве первичного ключа какие-либо бизнес-поля.

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

Выбор первичного ключа

Автоинкрементный целочисленный тип: база данных автоматически присваивает автоинкрементное целое число каждой записи при вставке данных, поэтому нам вообще не нужно беспокоиться о дублировании первичного ключа и нам не нужно предварительно генерировать первичные ключи самостоятельно;
Глобально уникальный тип GUID: используйте глобально уникальную строку в качестве первичного ключа, аналогично. Алгоритм GUID гарантирует, что строки, сгенерированные любым компьютером в любое время, различны через MAC-адрес сетевой карты, метку времени и случайное число. Большинство языков программирования имеют встроенный алгоритм GUID, который позволяет вам самостоятельно определять бюджет первичного ключа.

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

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

5
11
Голоса

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

Foreign Key Constraints

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

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

Максимальное количество таблиц и столбцов, на которые может ссылаться таблица в качестве внешних ключей (исходящих ссылок), равно 253. SQL Server 2016 (13.x); увеличивает ограничение на количество других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящие ссылки), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Увеличение имеет следующие ограничения:

Превышение 253 ссылок на внешние ключи поддерживается только для операций DML DELETE. Операции UPDATE и MERGE не поддерживаются.
Таблица со ссылкой внешнего ключа на саму себя по-прежнему ограничена 253 ссылками на внешние ключи.
Превышение 253 ссылок на внешние ключи в настоящее время недоступно для индексов columnstore, оптимизированных для памяти таблиц, базы данных Stretch или секционированных таблиц внешнего ключа.