Что такое первичный ключ бд какие бывают ключи?

13 ответов на вопрос “Что такое первичный ключ бд какие бывают ключи?”

  1. MrFenomeN Ответить

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

    4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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

    В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
    В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

    Первичные ключи в повседневной жизни
    В базе данных первичные ключи используются для идентификации. В жизни первичные ключи вокруг нас везде. Каждый раз, когда вы сталкиваетесь с уникальным числом это число может служить первичным ключом в базе данных (может, но не обязательно должно использоваться как таковое. Все базы данных способны автоматически генерировать уникальное значение для каждой записи в виде числа, которое автоматически увеличивается и вставляется вместе с каждой новой записью [Т.н. синтетический или суррогатный первичный ключ – прим.перев.]).
    Несколько примеров
    Номер заказа, который вы получаете при покупке в интернет-магазине может быть первичным ключом какой-нибудь таблицы заказов в базе данных этого магазина, т.к. он является уникальным значением.
    Номер социального страхования может быть первичным ключом в какой-нибудь таблице в базе данных государственного учреждения, т.к. она также как и в предыдущем примере уникален.
    Номер счета-фактуры может быть использован в качестве первичного ключа в таблице базы данных, в которой хранятся выданные клиентам счета-фактуры.
    Числовой номер клиента часто используется как первичный ключ в таблице клиентов.
    …
    Что объединяет эти примеры? То, что во всех из них в качестве первичного ключа выбирается уникальное, не повторяющееся значение для каждой записи. Еще раз. Значения поля таблицы базы данных, выбранного в качестве первичного ключа, всегда уникально.
    Что характеризует первичный ключ? Характеристики первичного ключа.
    Первичный ключ служит для идентификации записей.
    Первичный ключ используется для идентификации записей в таблице, для того, чтобы каждая запись стала уникальной. Еще одна аналогия… Когда вы звоните в службу технической поддержки, оператор обычно просит вас назвать какой-либо номер (договора, телефона и пр.), по которому вас можно идентифицировать в системе.
    Если вы забыли свой номер, то оператор службы технической поддержки попросит предоставить вас какую-либо другую информацию, которая поможет уникальным образом идентифицировать вас. Например, комбинация вашего дня рождения и фамилия. Они тоже могут являться первичным ключом, точнее их комбинация.
    Первичный ключ уникален.
    Первичный ключ всегда имеет уникальное значение. Представьте, что его значение не уникально. Тогда его бы нельзя было использовать для того, чтобы идентифицировать данные в таблице. Это значит, что какое-либо значение первичного ключа может встретиться в столбце, который выбран в качестве первичного ключа, только один раз. РСУБД устроены так, что не позволят вам вставить дубликаты в поле первичного ключа, получите ошибку.
    Еще один пример. Представьте, что у вас есть таблица с полями first_name и last_name и есть две записи:
    | first_name | last_name |
    | vasya |pupkin |
    | vasya |pupkin |
    Т.е. есть два Васи. Вы хотите выбрать из таблицы какого-то конкретного Васю. Как это сделать? Записи ничем друг от друга не отличаются. Вот здесь и помогает первичный ключ. Добавляем столбец id (классический вариант синтетического первичного ключа) и…
    Id | first_name | last_name |
    1 | vasya |pupkin |
    2 | vasya |pupkin |
    Теперь каждый Вася уникален.
    Типы первичных ключей.
    Обычно первичный ключ – числовое значение. Но он также может быть и любым другим типом данных. Не является обычной практикой использование строки в качестве первичного ключа (строка – фрагмент текста), но теоретически и практически это возможно.
    Составные первичные ключи.
    Часто первичный ключ состоит из одного поля, но он может быть и комбинацией нескольких столбцов, например, двух (трех, четырех…). Но вы помните, что первичный ключ всегда уникален, а значит нужно, чтобы комбинация n-го количества полей, в данном случае 2-х, была уникальна. Подробнее об этом расскажу позднее.
    Автонумерация.
    Поле первичного ключа часто, но не всегда, обрабатывается самой базой данных. Вы можете, условно говоря, сказать базе данных, чтобы она сама автоматически присваивала уникальное числовое значение каждой записи при ее создании. База данных, обычно, начинает нумерацию с 1 и увеличивает это число для каждой записи на одну единицу. Такой первичный ключ называется автоинкрементным или автонумерованным. Использование автоинкрементных ключей – хороший способ для задания уникальных первичных ключей. Классическое название такого ключа – суррогатный первичный ключ [Как и упоминалось выше. – прим. перев.]. Такой ключ не содержит полезной информации, относящейся к сущности (объекту), информация о которой хранится в таблице, поэтому он и называется суррогатным.

    5. СВЯЗЫВАНИЕ ТАБЛИЦ С ПОМОЩЬЮ ВНЕШНИХ КЛЮЧЕЙ

    Когда я начинал разрабатывать базы данных я часто пытался сохранять информацию, которая казалась родственной, в одной таблице. Я мог, например, хранить информацию о заказах в таблице клиентов. Ведь заказы принадлежат клиентам, верно? Нет. Клиенты и заказы представляют собой отдельные сущности в базе данных. И тому и другому нужна своя собственная таблица. А записи в этих двух таблицах могут быть связаны для того, чтобы установить отношения между ними. Проектирование базы данных – это решение двух вопросов:
    определение того, какие сущности вы хотите хранить в ней
    какие связи между этими сущностями существуют
    Один-ко-многим.
    Клиенты и заказы имеют связь (состоят в отношениях) один-ко-многим потому, что один клиент может иметь много заказов, но каждый конкретный заказ (их множество) оформлен только одним клиентом, т.е. может иметь только одного клиента. Не беспокойтесь, если на данный момент понимание этой связи смутно. Я еще расскажу о связях в следующих частях.
    Одно является важных сейчас – то, что для связи один-ко-многим необходимо две отдельные таблицы. Одна для клиентов, другая для заказов. Давайте немного попрактикуемся, создавая эти две таблицы.
    Какую информацию мы будем хранить? Решаем первый вопрос.
    Для начала мы определимся какую информацию о заказах и о клиентах мы будем хранить. Чтобы это сделать мы должны задать себе вопрос: “Какие единичные блоки информации относятся к клиентам, а какие единичные блоки информации относятся к заказам?”
    Проектируем таблицу клиентов.
    Заказы действительно принадлежат клиентам, но заказ – это это не минимальный блок информации, который относится к клиентам (т.е. этот блок можно разбить на более мелкие: дата заказа, адрес доставки заказа и пр., к примеру).
    Поля ниже – это минимальные блоки информации, которые относятся к клиентам:
    customer_id (primary key) – идентификатор клиента
    first_name — имя
    last_name — отчество
    address — адрес
    zip_code – почтовый индекс
    country — страна
    birth_date – дата рождения
    username – регистрационное имя пользователя (логин)
    password – пароль
    Давайте перейдем к непосредственному созданию этой таблицы в SQLyog (естественно, что вы можете использовать любую другую программу). Ниже приведен пример того, как могла бы выглядеть таблица в программе SQLyog после создания. Все графические приложения для управления базами данных имеют приблизительно одинаковую структуру интерфейса. Вы также можете создать таблицу с помощью командной строки без использования графической утилиты.

    Создание таблицы в SQLyog. Обратите внимание, что выбран флажок первичного ключа (PK) для поля customer_id. Поле customer_id является первичным ключом. Также выбран флажок Auto Incr, что означает, что база данных будет автоматически подставлять уникальное числовое значение, которое, начиная с нуля, будет каждый раз увеличиваться на одну единицу.
    Проектируем таблицу заказов.
    Какие минимальные блоки информации, необходимые нам, относятся к заказу?
    order_id (primary key) – идентификатор заказа
    order_date – дата и время заказа
    customer – клиент, который сделал заказ
    Ниже – пример таблицы в SQLyog.

    Проект таблицы. Поле customer является ссылкой (внешним ключом) для поля customer_id в таблице клиентов.
    Эти две таблицы (клиентов и заказов) связаны потому, что поле customer в таблице заказов ссылается на первичный ключ (customer_id) таблицы клиентов. Такая связь называется связью по внешнему ключу. Вы должны представлять себе внешний ключ как простую копию (копию значения) первичного ключа другой таблицы. В нашем случае значение поля customer_id из таблицы клиентов копируется в таблицу заказов при вставке каждой записи. Таким образом, у нас каждый заказ привязан к клиенту. И заказов у каждого клиента может быть много, как и говорилось выше.
    Создание связи по внешнему ключу.
    Вы можете задаться вопросом: “Каким образом я могу убедиться или как я могу увидеть, что поле customer в таблице заказов ссылается на поле customer_id в таблице клиентов”. Ответ прост – вы не можете сделать этого потому, что я еще не показал вам как создать связь.
    Ниже – окно SQLyog с окном, которое я использовал для создания связи между таблицами.

    Создание связи по внешнему ключу между таблицами заказов и клиентов.
    В окне выше вы можете видеть, как поле customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.
    Теперь, когда вы посмотрите на данные, которые могли бы быть в таблицах, вы увидите, что две таблицы связаны.

    Заказы связаны с клиентами через поле customer, которое ссылается на таблицу клиентов.
    На изображении вы видите, что клиент mary поместила три заказа, клиент pablo поместил один, а клиент john – ни одного.
    Вы можете спросить: “А что же именно заказали все эти люди?” Это хороший вопрос. Вы возможно ожидали увидеть заказанные товары в таблице заказов. Но это плохой пример проектирования. Как бы вы поместили множественные продукты в единственную запись? Товары – это отдельные сущности, которые должны храниться в отдельной таблице. И связь между таблицами заказов и товаров будет являться связью один-ко-многим. Я расскажу об этом далее.

    6. СОЗДАНИЕ ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ

    Ранее вы узнали как записи из разных таблиц связываются друг с другом в реляционных базах данных. Перед созданием и связыванием таблиц важно, чтобы вы подумали о сущностях, которые существуют в вашей системе (для которой вы создаете базу данных) и решили каким образом эти сущности бы связывались друг с другом. В проектировании баз данных сущности и их отношения обычно предоставляются в диаграмме сущность-связь (англ. entity-relationship diagram, ERD). Данная диаграмма является результатом процесса проектирования базы данных.
    Сущности.
    Вы можете задаться вопросом, что же такое сущность. Нуу… это “вещь” в системе. Там. Моя Мама всегда хотела, чтобы я стал учителем потому, что я очень хорошо объясняю различные вещи.
    В контексте проектирования баз данных сущность – это нечто, что заслуживает своей собственной таблицы в модели вашей базы данных. Когда вы проектируете базу данных, вы должны определить эти сущности в системе, для которой вы создаете базу данных. Это скорее вопрос диалога с клиентом или с собой с целью выяснения того, с какими данными будет работать ваша система.
    Давайте возьмем интернет-магазин для примера. Интернет-магазин продает товары. Товар мог бы стать очевидной сущностью в системе интернет-магазина. Товары заказываются клиентами. Вот мы с вами и увидели еще две очевидных сущности: заказы и клиенты.
    Заказ оплачивается клиентом… это интересно. Мы собираемся создавать отдельную таблицу для платежей в базе данных нашего интернет-магазина? Возможно. Но разве платежи – это минимальный блок информации, который относится к заказам? Это тоже возможно.
    Если вы не уверены, то просто подумайте о том, какую информацию о платежах вы хотите хранить. Возможно, вы захотите хранить метод платежа или дату платежа. Но это все еще минимальные блоки информации, которые могли бы относиться к заказу. Можно изменить формулировки. Метод платежа — метод платежа заказа. Дата платежа – дата платежа заказа. Таким образом, я не вижу необходимости выносить платежи в отдельную таблицу, хотя концептуально вы бы могли выделить платежи как сущность, т.к. вы могли бы рассматривать платежи как контейнер информации (метод платежа, дата платежа).
    Давайте не будет слишком академичными.
    Как вы видите, есть разница между сущностью и непосредственно таблицей в базе данных, т.е. это не одно и то же. Специалисты отрасли информационных технологий могут быть ОЧЕНЬ академичными и педантичными в этом вопросе. Я не такой специалист. Эта разница зависит от вашей точки зрения на ваши данные, вашу информацию. Если вы смотрите на моделирование данных с точки зрения программного обеспечения, то вы можете прийти к множеству сущностей, которые нельзя будет перенести напрямую в базу данных. В данном руководстве мы смотрим на данные строго с точки зрения баз данных и в нашем маленьком мире сущность – это таблица.

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

    Диаграмма сущность-связь может быть достаточно большой, если вы работаете над сложным приложением. Некоторые диаграммы могут содержать сотни или даже тысячи таблиц.
    Связи.
    Второй шаг в проектировании баз данных – это выбор того, какие связи существуют между сущностями в вашей системе. Сейчас это может быть немного сложно для понимания, но, повторюсь еще раз, это не ракетостроение. С приобретением некоторого опыта и переосмысления выполненной работы вы будете завершать очередную модель базы данных верным или почти верным образом.
    Итак. Я рассказал вам о связи один-ко-многим и я расскажу вам больше о связях в дальнейших частях этого руководства, поэтому сейчас я больше не буду останавливаться на этом. Просто запомните, что решение о том, какие связи будут иметь ваши сущности – важная часть проектирования баз данных и эти связи отображаются в диаграмме сущность-связь.

  2. Munilas Ответить

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

    Типы данных в базах

    Важно понимать, что можно создавать базы для любых типов данных: текстов, дат, времени, событий, цифр. В зависимости от типа информации реляционные базы данных делят на типы. Каждый тип данных (атрибут) имеет свое обозначение:
    INTEGER- данные из целых чисел;
    FLOAT — данные из дробных чисел, так называемые данные с плавающей точкой;
    CHAR, VARCHAR — текстовые типы данных (символьные);
    LOGICAL — логический тип данных (да/нет);
    DATE/TIME — временные данные.
    Это основные типы данных, которых на самом деле гораздо больше. Причем, каждый язык программирования имеет свой набор системных атрибутов (типов данных).

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

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

    Выше мы вспоминали: каждая строка (запись) БД должна быть уникальна. Именно первичный ключ в виде наборов определенных значений, максимально идентифицируют каждую запись. Можно определить по-другому. Первичный ключ: набор определенных признаков, уникальных для каждой записи. Обозначается первичный ключ, как primary key.
    Primary key (PK) очень важен для каждой таблицы. Поясню почему.
    Primary key не позволяет создавать одинаковых записей (строк) в таблице;
    PK обеспечивают логическую связь между таблицами одной базы данных (для реляционных БД).
    На логической связи между таблицами, стоит остановиться подробнее.

    Ключ внешний

    Foreign key, кратко FK. Обеспечивает однозначную логическую связь, между таблицами одной БД.
    Например, есть две таблицы А и В. В таблице А (обувь), есть первичный ключ: размер, в таблице В (цвет) должна быть колонка с названием размер. В этой таблице «размер» это и будет внешний ключ для логической связи таблиц В и А.
    Более сложный пример.
    Две таблицы данных: Люди и Номера телефонов.
    Таблица: Люди
    primary key
    Имя
    1
    Зайцев
    2
    Белкин
    3
    Волков
    Таблица: Номера телефонов
    primary key
    телефон
    foreign key
    1
    12345
    1
    2
    54321
    1
    3
    678910
    2
    4
    109876
    3
    5
    13579
    3
    В таблице Номера телефонов PK уникален. FK этой таблицы является PK таблицы Люди. Связь между номерами телефонов и людьми обеспечивает FK таблицы телефонов. То есть:
    У Зайцева два телефона;
    У Волкова два телефона;
    У Белкина один телефон.
    первичный ключ и внешний ключ
    В завершении добавлю, что любая СУБД, управляющая базой данных, имеет технические возможности составить первичный ключ.
    ©WebOnTo.ru

    Другие статьи раздела: Базы данных

    PhpMyAdmin на локальном сервере
    Что такое база данных — понятие база данных в информатике
    Функции СУБД обеспечивающие управление базой данных
    Устройство реляционной базы данных

  3. Jekson Go Ответить

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

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

    Вот синтаксис для определения атрибута ID в качестве первичного ключа в таблице Customers.
    CREATE TABLE CUSTOMERS(
    ID INT NOT NULL,
    NAME VARCHAR (20) NOT NULL,
    AGE INT NOT NULL,
    ADDRESS CHAR (25) ,
    SALARY DECIMAL (18, 2),
    PRIMARY KEY (ID)
    );
    Для того, чтобы создать ограничение первичного ключа на столбце «ID», когда таблица CUSTOMERS уже существует, используйте следующий синтаксис SQL:
    ALTER TABLE CUSTOMERS ADD PRIMARY KEY (ID);

  4. Blackworker Ответить

    Каждый вертикальный столбец таблицы представляет совокупность значений конкретного атрибута объекта. Например, в столбце AccountCD содержатся уникальные номера лицевых счетов абонентов. В столбце Phone содержатся номера телефонов абонентов.
    На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей абонента Конюхова В. С., в столбце Fio содержится значение ‘Конюхов В.С.’. В столбце AccountCD той же строки содержится значение ‘015527’, которое является номером лицевого счета абонента с ФИО Конюхов В. С.
    Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце Fio содержатся только слова, а в столбце StreetCD содержатся целые числа, представляющие идентификаторы улиц. В реляционной модели данных общая совокупность значений, из которой берутся действительные значения для определенных атрибутов (столбцов), называется доменом [1]. Доменом столбца Fio, например, является множество фамилий, имен и отчеств (ФИО) абонентов. Каждый столбец всегда определяется на одном домене.
    В реляционных базах данных домен определяется путем задания как минимум некоторого базового типа данных, к которому относятся элементы домена, а часто также и произвольного логического выражения, применяемого к элементам этого типа данных (ограничения домена).
    В учебной базе данных определены следующие домены:
    § Boollean (Логический): SMALLINT. Поля, определяемые на этом домене, могут принимать только целочисленные значения, равные 0 или 1. Это достигается наложением в домене условия проверки (CHECK) на принимаемые этим доменом значения.
    § Money (Деньги): NUMERIC(15,2). Домен предназначен для определения в таблицах полей, хранящих денежные суммы.
    § PKField (Поле ПК): INTEGER. Домен предназначен для определения первичных и внешних ключей таблиц. Ограничение обязательности данных (NOT NULL) на этот домен не наложено. Оно накладывается при объявлении первичного ключа таблицы. Это сделано для того, чтобы можно было определить внешний ключ на этом домене без условия NOT NULL.
    § TMonth (Месяц): SMALLINT. Домен предназначен для определения в таблицах полей, содержащих номера месяцев. Целочисленные значения в таком поле могут находиться в диапазоне 1…12.
    § TYear (Год): SMALLINT. Домен предназначен для определения полей, содержащих номер года. Целочисленные значения могут находиться в диапазоне 1990…2100.
    Поскольку строки в реляционной таблице не упорядочены, то нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно указать в таблице конкретную строку, например строку для абонента с ФИО Аксенов С.А.?
    Ключевым элементом данныхназывается такой элемент, по которому можно определить значения других элементов данных.
    В реляционной базе данных в каждой таблице есть 1 или несколько столбцов, значения в которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы.
    Первичный ключ –это атрибут или группа атрибутов, которые единственным образом идентифицируют каждую строку в таблице.
    Вернемся к рассмотрению таблицы Abonent учебной базы данных (рис. 1.1). На первый взгляд, первичным ключом таблицы Abonent могут служить и столбец AccountCD, и столбец Fio. Однако в случае если будут зарегистрированы 2 абонента с одинаковыми ФИО, то столбец Fio больше не сможет исполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как уникальный номер лицевого счета абонента (AccountCD в таблице Abonent), идентификатор улицы (StreetCD в таблице Street) и т. д.
    Если в таблице нет полей, значения в которых уникальны, для создания первичного ключа в нее обычно вводят дополнительное поле, значениями которого СУБД может распоряжаться по своему усмотрению.
    Если первичный ключ представляет собой комбинацию столбцов, то такой первичный ключ называется составным.
    Вторичные ключи устанавливаются по полям, которые часто используются при поиске или сортировке данных. В отличие от первичных ключей поля для вторичных ключей могут содержать не уникальные значения.

  5. Brasida Ответить

    Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
    Функциональные зависимости.
    Реляционная база данных содержит как структурную, так и семантическую информацию. Структура базы данных определяется числом и видом включенных в нее отношений, и связями типа “один ко многим”, существующими между кортежами этих отношений. Семантическая часть описывает множество функциональных зависимостей, существующих между атрибутами этих отношений. Дадим определение функциональной зависимости.
    19. 1НФ: Основные определения и правила преобразования.
    Для обсуждения первой нормальной формы необходимо дать два определения:
    Простой атрибут – атрибут, значения которого атомарны (неделимы).
    Сложный атрибут – получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах (его также называют вектор или агрегат данных).
    Определение первой нормальной формы:
    отношение находится в 1NF если значения всех его атрибутов атомарны. . В противном случае это вообще не таблица и такие атрибуты необходимо декомпозировать.
    Рассмотрим пример:
    В базе данных отдела кадров предприятия необходимо хранить сведения о служащих, которые можно попытаться представить в отношении
    СЛУЖАЩИЙ(НОМЕР_СЛУЖАЩЕГО, ИМЯ, ДАТА_РОЖДЕНИЯ, ИСТОРИЯ_РАБОТЫ, ДЕТИ).
    Из внимательного рассмотрения этого отношения следует, что атрибуты “история_работы” и “дети” являются сложными, более того, атрибут “история_работы” включает еще один сложный атрибут “история_зарплаты”.
    Данные агрегаты выглядят следующим образом:
     ИСТОРИЯ_РАБОТЫ (ДАТА_ПРИЕМА, НАЗВАНИЕ, ИСТОРИЯ_ЗАРПЛАТЫ),
     ИСТОРИЯ_ЗАРПЛАТЫ (ДАТА_НАЗНАЧЕНИЯ, ЗАРПЛАТА),
     ДЕТИ (ИМЯ_РЕБЕНКА, ГОД_РОЖДЕНИЯ).
    Их связь представлена на рис. 3.3.

    Рис.3.3. Исходное отношение.
    Для приведения исходного отношения СЛУЖАЩИЙ к первой нормальной форме необходимо декомпозировать его на четыре отношения, так как это показано на следующем рисунке:

    Рис.3.4. Нормализованное множество отношений.
    Здесь первичный ключ каждого отношения выделен синей рамкой, названия внешних ключей набраны шрифтом синего цвета. Напомним, что именно внешние ключи служат для представления функциональных зависимостей, существующих в исходном отношении. Эти функциональные зависимости обозначены линиями со стрелками.
    Алгоритм нормализации описан Е.Ф.Коддом следующим образом:
    Начиная с отношения, находящегося на верху дерева (рис. 3.3.), берется его первичный ключ, и каждое непосредственно подчиненное отношение расширяется путем вставки домена или комбинации доменов этого первичного ключа.
    Первичный Ключ каждого расширенного таким образом отношения состоит из Первичного Ключа, который был у этого отношения до расширения и добавленного Первичного Ключа родительского отношения.
    После этого из родительского отношения вычеркиваются все непростые домены, удаляется верхний узел дерева, и эта же процедура повторяется для каждого из оставшихся поддеревьев.
    20. 2НФ: Основные определения и правила преобразования.
    Очень часто первичный ключ отношения включает несколько атрибутов (в таком случае его называют составным) – см., например, отношение ДЕТИ, показанное на рис. 3.4 вопрос 19. При этом вводится понятие полной функциональной зависимости.
    Определение:
    неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов.
    Пример:
    Пусть имеется отношение ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР, ЦЕНА).
    Поставщик может поставлять различные товары, а один и тот же товар может поставляться разными поставщиками. Тогда ключ отношения – “N_поставщика + товар”. Пусть все поставщики поставляют товар по одной и той же цене. Тогда имеем следующие функциональные зависимости:
    N_поставщика, товар -> цена
    товар -> цена
    Неполная функциональная зависимость атрибута “цена” от ключа приводит к следующей аномалии: при изменении цены товара необходим полный просмотр отношения для того, чтобы изменить все записи о его поставщиках. Данная аномалия является следствием того факта, что в одной структуре данных объединены два семантических факта. Следующее разложение дает отношения во 2НФ:
    ПОСТАВКИ (N_ПОСТАВЩИКА, ТОВАР)
    ЦЕНА_ТОВАРА (ТОВАР, ЦЕНА)
    Таким образом, можно дать
    Определение второй нормальной формы: Отношение находится во 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.
    21. 3НФ: Основные определения и правила преобразования.
    Перед обсуждением третьей нормальной формы необходимо ввести понятие: транзитивная функциональная зависимость.
    Определение:
    Пусть X, Y, Z – три атрибута некоторого отношения. При этом X –> Y и Y –> Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.
    Пусть имеется отношение ХРАНЕНИЕ (ФИРМА, СКЛАД, ОБЪЕМ), которое содержит информацию о фирмах, получающих товары со складов, и объемах этих складов. Ключевой атрибут – “фирма”. Если каждая фирма может получать товар только с одного склада, то в данном отношении имеются следующие функциональные зависимости:
    фирма -> склад
    склад -> объем
    При этом возникают аномалии:
    если в данный момент ни одна фирма не получает товар со склада, то в базу данных нельзя ввести данные о его объеме (т.к. не определен ключевой атрибут)
    если объем склада изменяется, необходим просмотр всего отношения и изменение картежей для всех фирм, связанных с данным складом.
    Для устранения этих аномалий необходимо декомпозировать исходное отношение на два:
    ХРАНЕНИЕ (ФИРМА, СКЛАД)
    ОБЪЕМ_СКЛАДА (СКЛАД, ОБЪЕМ)
    Определение третьей нормальной формы:
    Отношение находится в 3НФ, если оно находится во 2НФ и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.

  6. Evgesh@ Ответить

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

    На примере видно, что 2 и 4 строки содержать ФИО студентов, являющихся полными тезками, которые учатся в одной группе. Такая ситуация маловероятна, но возможна. Если один из этих студентов не сдаст экзамены и его отчислят, то по ошибке можно отчислить другого, который не имеет проблем с успеваемостью.
    Чтобы исключить подобные ошибки, потребуется добавить дополнительное свойство, которое потенциально может служить идентификатором: паспортные данные, номер личного дела и т.п.

    На приведенном в качестве примера изображении, столбец «№ дела» однозначно определяет запись и называется первичным ключом. Он является простым, так как состоит из одного столбца.
    В учебной базе данных имеется таблица «Сотрудники_Линии», в которой для каждого оператора определены подключенные телефонные линии.

    Ни один из столбцов не может являться простым первичным ключом, потому что может повторяться (сотруднику подключается несколько линии, и одна линия подключаются разным сотрудникам). В таком случае первичным ключом служит пара столбцов – «Сотрудник» и «Линия». Телефонную линию нельзя подключить несколько раз одному и тому же оператору, что соответствует уникальности записей.
    Первичный ключ, состоящий из нескольких полей, называется составным ключом.
    < Назад Вперёд >

  7. Армейский Мальчик Ответить

    Общие сведения о первичных ключах в Access
    Определение первичного ключа в Access с помощью имеющихся полей
    Удаление первичного ключа
    Изменение первичного ключа в Access
    Дополнительные сведения

    Общие сведения о первичных ключах в Access

    С помощью полей первичных ключей Access быстро связывает данные из нескольких таблиц и объединяет эти данные по заданному принципу. Поля первичного ключа можно использовать в других таблицах для ссылки на таблицу, являющуюся источником первичного ключа. В этих таблицах такие поля называются внешними ключами. Например, поле “ИД клиента” из таблицы “Клиенты” может также использоваться в таблице “Заказы”. В таблице “Клиенты” оно будет первичным ключом, а в таблице “Заказы” — внешним. Проще говоря, внешний ключ — это первичный ключ другой таблицы. Дополнительные сведения см. в статье Основные сведения о создании баз данных.

    1. Первичный ключ
    2. Внешний ключ
    При переносе существующих данных в базу данных в них уже может существовать поле, которое можно использовать как первичный ключ. Часто в роли первичного ключа таблицы выступает уникальный идентификационный номер, например порядковый или инвентарный номер или код. Например, в таблице “Клиенты” для каждого клиента может быть указан уникальный код клиента. Поле кода клиента является первичным ключом.
    Для первичного ключа автоматически создается индекс, ускоряющий выполнение запросов и операций. Кроме того, приложение Access проверяет наличие и уникальность значений в поле первичного ключа.
    При создании таблицы в режиме таблицы Access автоматически создает первичный ключ с именем “Код” и типом данных “Счетчик”.

    Создание приемлемого первичного ключа

    Чтобы правильно выбрать первичный ключ, следует учитывать несколько характеристик.
    Ключ должен однозначно определять каждую строку.
    В нем не должно быть пустых или отсутствующих значений — он всегда содержит значение.
    Ключ крайне редко изменяется (в идеале — никогда).
    Если не удается определить приемлемый ключ, создайте для него поле с типом данных “Счетчик”. Поле “Счетчик” заполняется автоматически созданными значениями при первом сохранении каждой записи. Таким образом, поле “Счетчик” соответствует всем трем характеристикам приемлемого первичного ключа. Дополнительные сведения о добавлении поля “Счетчик” см. в статье Добавление поля счетчика в качестве первичного ключа.

    Поле с типом данных “Счетчик” является хорошим первичным ключом.

    Примеры неудачных первичных ключей

    Любое поле, не имеющее одной или нескольких характеристик подходящего первичного ключа, не следует выбирать в качестве первичного ключа. Ниже представлено несколько примеров полей, которые не годятся на роль первичного ключа в таблице “Контакты”, и пояснения, почему их не следует использовать.
    Неподходящий первичный ключ
    Причина
    Имя
    Может быть не уникальным и может изменяться
    Телефон
    Может изменяться.
    Адрес электронной почты
    Может изменяться.
    Почтовый индекс
    Почтовый индекс может соответствовать нескольким контактным данным
    Сочетание фактов и цифр
    Факты могут изменяться, тем самым усложняя работу. Если фактическая часть повторяется в виде отдельного поля, это может привести к путанице. Например, не следует соединять название города и порядковый номер (например, САМАРА0579), если название города уже указано в отдельном поле.
    Номера социального страхования или ИНН
    Личные сведения запрещено указывать в государственных учреждениях и некоторых организациях.
    Некоторые люди не имеют ИНН
    На одного человека может быть зарегистрировано несколько ИНН на протяжении жизни

    Составные ключи: использование сочетания нескольких полей в качестве первичного ключа

    В некоторых случаях в качестве первичного ключа нужно использовать несколько полей. Например, в таблице “Сведения о заказе”, которая содержит позиции по заказам, первичный ключ может включать два столбца: “Код заказа” и “Код товара”. Если ключ состоит из нескольких полей, он также называется составным ключом.

    Определение первичного ключа в Access с помощью имеющихся полей

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

  8. Ketilar Ответить

    В этой статье я приведу взгляд (отрицательный по большей части) Джоша Беркуса, CEO компании PostgreSQL Experts Inc. на использование суррогатных ключей для таблиц базы данных, тех самых INT NOT NULL AUTO_INCREMENT PRIMARY KEY, к которым мы привыкли. Фактически, это будет вольный, сильно сокращенный перевод его статьи на ittoolbox.
    За статьей последует разбор моих собственных ошибок по этой теме, допущенных в одном старом проекте. Я был молод и глуп, но это меня не извиняет.
    Честно говоря, прочитав эту статью и не заметив, кто автор, я подумал, что он все же преувеличивает и вообще, я без него как-нибудь разберусь, где и какие ключи мне использовать. Потом я еще немного подумал и полез за дампом структуры базы моего старого проекта. Было интересно.
    Если вы опытный DBA, наверное, вам стоит пройти мимо, чтобы не расстраиваться.
    Но обо всем по порядку. Сначала ОЧЕНЬ сокращенный перевод:
    «Суррогатные числовые ключи попали в стандарт SQL89 для сохранения со старыми приложениями, которым требовались номера строк. Впоследствии в разговоре с Джо Селко, Кодд сказал, что жалеет, что допустил это.
    Неопытные разработчики, не понимая, что использование суррогатные ключей является прагматичным компромиссом с соображениями производительности, используют их везде. Даже авторы книг по базам данных советуют обязательно создавать их во всех таблицах в любом случае.
    В теории реляционных баз данных нет понятия первичных ключей. Все ключи базы данных имеют одинаковую значимость. Понятие первичного ключа базируется на представлении, что один и только один ключ определяет порядок кортежей на диске, а реляционная теория говорит нам о том, что как раз это мы должны игнорировать в логической модели наших данных. Так что, первичные ключи вообще – это нарушение реляционной теории.
    Я не говорю о том, что суррогатные ключи нельзя использовать вообще, я говорю о том, что нельзя злоупотреблять их использованием.
    Какие причины могут побудить нас использовать суррогатные ключи?
    Компромисс с многоколоночными ключами. Обычно, довольно убедительна. Синтаксис SQL запросов с использованием многоколоночных ключей и механизм соединений в настоящее время оставляет желать много лучшего, как и производительность запросов такого рода. Как только эти проблемы будут решены, данная причина отпадет.
    У данных нет реального ключа. Очень плохая причина. Ее появление иллюстрирует как плохой дизайн базы данных в целом, таки и то, что разработчик на самом деле не понимает данных, с которыми работает.
    Внешние требования. Обычно убедительна. Как правило, среды разработки и инструменты для работы с базами данных поддерживают только суррогатные ключи. И если вы считаете, что данный инструмент незаменим в проблеме, которую вы решаете, что ж…
    Согласованность данных. Обычно убедительна. Но только в том случае, если вы действительно скрупулезно следуете плану и весь ваш дизайн тщательно спланирован.
    Следование SQL стандарту и принципам хорошего дизайна. Очень плохая причина. Она полностью основана на невежестве. Обычно, ей следуют потому, что где-то услышали, как кто-то прочитал в блоге кого-то, кто учится в УНИВЕРСИТЕТЕ, что использование суррогатных ключей – это стандарт в индустрии. Имейте ввиду, что ни современные стандарты SQL, ни сама реляционная теория не содержит даже упоминания о суррогатных ключах.
    Возможность легкого изменения. Неясно. Действительно, некоторые СУБД не умеют выполнять ON UPDATE CASCADE или делают это слишком неэффективно (кстати, подумайте об этом как о причине смены СУБД). И в этом случае, данная причина может оказаться весомой. Однако иногда разработчики говорят о том, что ключи [первичные] для записи меняться не должны и должны оставаться одинаковыми на всей протяженности жизненного цикла записи. Имейте ввиду, что это утверждение яйца выеденного не стоит и уж, разумеется, полностью отсутствует в реляционной теории.
    Производительность. Обычно плохая причина. Да, действительно, могут возникать ситуации, в которых использование естественных ключей сильно замедляет работу системы по сравнению с суррогатными. Но в 80% случаев за этим утверждением не стоят реальные тесты и подобное утверждение остается безосновательным. Предварительная оптимизация – корень многих бед в дизайне баз данных.
    Для баз данных мега-объема результирующий размер таблицы также может иметь значение. Но для этого база должна быть уж очень большой.
    Производительность соединений или сортировки также имеет значение на большом количестве данных, в зависимости от типа первичного ключа и числа его компонентов. Однако мой опыт показывает, что когда называют эту причину, за ней очень редко стоят реальные расчеты или замеры производительности. Например, http://www.bricolage.cc использует 14-байтовые числовые первичные ключи для своих таблиц много лет. Однако и в этом случае, после появления пользователя с трехмиллионной записью в истории, когда встал вопрос об изменении первичных ключей ради производительности, эта проблема была решена переписыванием запросов. Было достигнуто примерно 10-кратное увеличение производительности.
    Обратите внимание, что проблемы причиняет не использование суррогатных ключей, а злоупотребление ими».
    Конец моего ОЧЕНЬ СОКРАЩЕННОГО перевода. Оригинал тут (Primary Keyvil называется): it.toolbox.com/home/search.aspx?r=%22Primary+kevill%22&community=1&contentType=5
    Если я упустил что-то важное в переводе, пожалуйста, скажите мне об этом. Добавлю.

    Теперь немного о том, что я сам думаю.

    Все же статья показалось мне немного драматизирующей проблему. Мне кажется, что суррогатные ключи выбираются все чаще всего именно из-за того, чтобы избежать проблем с производительностью впоследствии и в последнее время все так к ним привыкли, что они насаждаются на уровне самих СУБД. Например, InnoDB, если вы не создадите первичный ключ, просто создаст его сама. Кстати, в случае с InnoDB выбор первичного ключа имеет серьезные последствия с точки зрения производительности, поскольку по нему производится кластеризация (соответственно, выбор естественного ключа может как улучшить, так и ухудшить ситуацию).
    Несмотря на то, что статья звучит так, будто суррогатные ключи суть воплощенное зло, автор несколько раз подчеркивает, что проблему несет не их использование, а злоупотребление ими.
    Эта статья открыла мне глаза в том плане, что я всегда считал естественным не искать себе особых кандидатов в первичные ключи, а просто создать INT NOT NULL AUTO_INCREMENT PRIMARY KEY поле и сидеть спокойно. Разумеется, я знал о том, что в качестве первичного ключа можно выбрать любой уникальный ключ, но я никогда на этом не акцентировался. Я никогда особо не задумывался о том, что вообще по-настоящему делает данную строку базы данных уникальной и почему это важно. Как выяснилось, зря.
    В качестве примера я хочу вам привести свой небольшой старый проект. Там всего несколько таблиц. Вначале я хотел выбрать что-то побольше, но думаю, что это лишнее. Только напрасно отниму у вас время. Пусть каждый сам откроет какой-нибудь свой старый проект и посмотрит на него с точки зрения описанной позиции. Я там на самом деле добавил одну ошибку сейчас справедливости ради. Я бы ее все равно сделал. Меня спасла только случайность.
    Проект представляет собой некоторый закрытый торрент-трекер. Я прошу вас не обращать сейчас внимание на проблемы с нормализацией и всякие другие. Если бы я писал его сейчас, может быть, кое-что я бы сделал по-другому. Давайте сосредоточимся на суррогатных ключах.

    Структура базы данных


    pastebin.com/LstH8Xfx
    Первая таблица, о которой я бы хотел поговорить, это таблица логов. Вообще, именно этот случай меня немного ошарашил что ли, поскольку я неожиданно увидел ошибку. Совсем небольшую, не стоящую особого внимания, но, тем не менее, это ошибка, которой я не замечал много-много лет. Совсем не замечал. Отвлекитесь сейчас от текста и вернитесь к структуре этой таблицы. Видите? Я не видел.
    В этой таблице хранится простая информация. IP, ID пользователя, дата возникновения события и его текст. Да, конечно, текст можно было заменить кодом и сделать много еще чего, но речь сейчас не об этом. После прочтения статьи, я посмотрел на эту таблицу и подумал, что, вот я создал суррогатный ключ. Но каков реальный ключ данных? Что делает конкретную строку таблицы уникальной?
    Ответ очень простой. Комбинация из ID пользователя и времени возникновения события. И вот тут я неожиданно увидел ситуацию с другой стороны. Практически во всех моих старых проектах поле DATETIME используется для хранения времени в логах. Просто потому, что это удобно. Да, я знал, что оно хранится с точностью до секунды и меня это полностью устраивало. Сейчас, когда я начал искать естественные ключи, мне неожиданно пришло в голову, какие последствия это несет. Торрент-трекер, о котором идет речь, нагружен очень сильно и в течение секунды многое может произойти. Фактически, если в логе с этим чертовым суррогатным ключом окажется несколько событий с одним и тем же временем и они произошли друг за другом очень быстро, я смогу сказать, какое из них произошло первым, а какое последним только ориентируясь по автоинкременту суррогатного ключа. Само поле информации о дате, которое создано именно затем, чтобы сообщать такие вещи, мне ничем не поможет. А точно выяснить интервал между событиями я не смогу вообще.
    В целом, это, конечно, неважно. Вероятность того, что мне потребуется выяснить интервал между двумя событиями, который в любом случае составляет менее секунды, весьма невелика. Но все свои проекты, и старые и новые, я всегда рассматриваю как учебные. Проект мог быть немного другим, и это могло стать важным.
    Я хочу сказать, что рассмотрение проблемы с точки зрения поиска естественного ключа – это взгляд несколько с другой стороны. Попробуйте взглянуть на дизайн вашего проекта таким образом и посмотрите, что обнаружится.
    Похоже, что мое объяснение получилось сумбурным. Надеюсь, все же, мне удалось донести до вас мою мысль.
    Теперь таблица peer. У нее уже есть уникальный ключ, который просто просится на роль первичного. В таблицу peer производятся многие сотни вставок/удалений в секунду и держать там лишний индекс в виде первичного ключа просто накладно. Вот я его и ликвидировал.
    Таблица session. По некоторой причине я не полагался на сессии PHP полностью, а частично реализовал свои. В качестве первичного ключа этой таблицы выступает случайное значение. Мало того, что это просто глупо использовать 40-символьные случайные последовательности, так оно тут вообще не очень нужно. Что выступает в качестве естественного ключа для записей в этой таблице? В этом проекте пользователю не позволялось быть залогиненым с нескольких компов одновременно. Гм. user_id? Все остальное по отношению к данному значению вторично. Я не буду сейчас анализировать, что вытекает из этого простого утверждения. Много чего вплоть до удаления таблицы сессий и реализации другого механизма. Вариантов тут много.
    Перейдем к таблице torrent.
    Небольшое отступление для того, чтобы вы представляли себе предмет обсуждения. Торрент-трекер, который я разрабатывал, одновременно являлся и первым сидом для файлов, которые раздавались. В таблице torrent хранилась информация о файлах, которые сидировались. Эти файлы лежали в файловой системе сервера, для них создавались соответствующие .torrent файлы по схеме один файл = один торрент, которые и скачивались пользователями. Каждый торрент имеет так называемый info_hash, который его уникальным образом идентифицирует.
    Это поле в таблице peer называется peer_info_hash. А в таблице torrent это поле torrent_info_hash. torrent_id там лишний. Совсем. Обратите внимание, что в таблице peer torrent_id тоже есть. Непонятно зачем.
    Ну и таблица user. Казалось бы, тут я просто не мог сделать ошибки. Ошибался.
    В системе авторизации, торрент-трекеров используется GET параметр с уникальным для пользователя значением. В таблице это значение user_torrent_uid. Вот спросите меня, кто мешал использовать это значение в качестве естественного ключа в том или ином варианте? Да, оно может измениться. В очень редком случае. Ну и что? Если 8 байт – слишком длинно, можно было взять обычный случайный INT и конвертировать его в текст, как на Flickr делают умные люди. Можно было… Да много чего можно было.
    Вот так. Все очевидно, не так ли? 🙂

  10. VideoAnswer Ответить

Добавить ответ

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