запутаться в концепции первичного ключа и номализации

Question

Давайте рассмотрим пример таблицы login со столбцами: id (первичный ключ), username, password, status.

id - это первичный ключ, ноТем не менее, мы аутентифицируем пользователя путем поиска в таблице через username + passwordРазве это не нарушает правило нормализации?

Другой пример: предположим, у нас есть две таблицы: employer и job

employer идентификатор таблицы используется в таблице job как внешняяключ, но job сама таблица имеет свой собственный id

job table
---------
id (primary key) || employer_id (foreign key) || etc etc

Теперь, когда мы будем искать работу, опубликованную работодателем, мы используем employer_id, но у этой таблицы есть первичный ключ?

Answer 1

Я предлагаю вам прочитать какое-то учебное пособие, но, вкратце ... первичный ключ - это уникальный идентификатор, который не является нулевым и идентифицирует запись в вашей таблице.Внешний ключ - это ссылка на идентификатор в другой таблице.Как вы сказали, сотрудник и рабочие столы.Идентификатор в большинстве случаев генерируется последовательностью, вы не знаете его значение до вставки записи.Обычно вы выполняете поиск по имени пользователя, имени, ... данным, которые известны пользователю.В вашем случае, когда вы ищете работу, вы, вероятно, будете выполнять присоединение.Объединение - это отношение (и есть больше типов) между таблицами.В вашем случае вы будете делать

select *
from employer emp inner join job jjj on emp.id = jjj.employer _id

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

Answer 2

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

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

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

В первом примере username - это бизнес-ключ, а id - технический ключ. Это одна из причин, почему у нас должно быть две модели данных. Логическая модель данных имеет сущность с именем user с ключом-кандидатом username. Физическая модель данных имеет таблицу с именем user с первичным ключом id и уникальным ключом username.

Для вашего второго примера, кажется, вы моделируете доску вакансий ситуаций. Отношения между Работодателем и Работой одно к многим, то есть работодатель может рекламировать множество вакансий. Таким образом, таблица Job имеет свой собственный первичный ключ id плюс внешний ключ employer_id, который ссылается на первичный ключ таблицы Employer. Это означает, что мы можем найти все рабочие места для конкретного работодателя. Но поскольку таблица job имеет свой собственный первичный ключ, мы можем идентифицировать каждую работу, чтобы мы могли отличить работу Дворник на Фармацевтические препараты Harrisons от работы Дворник в Ravi's Cash'n'Carry . (Что, кстати, показывает, зачем нам нужны технические ключи: представьте, если внешний ключ employer_id представлял собой строку varchar2(128) для каждой строки в таблице Job.)

В логической модели данных employer_id будет означать , подразумеваемое для сущности job по ссылке на сущность employee, но будет отображаться (на самом деле это может быть, это зависит от инструмента ). В физической модели столбец должен быть добавлен в зависимую таблицу, потому что ограничения базы данных (и соединения!) Физически нуждаются в столбце для работы.

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

Answer 3

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

Пытаясь получить записи, вы будете использовать первичный ключ как связь между различными таблицами. Например, у вас есть работодатели и работники. Поиск может выглядеть так: « Получите мне всех сотрудников для этого работодателя ». Теперь работодатель является основным субъектом, и мы ищем связанные с ним записи сотрудников. Здесь идентификатор работодателя поможет нам получить соответствующие записи. Запрос для того же может выглядеть примерно так:

SELECT [COLUMN NAMES HERE]
FROM EMPLOYER INNER JOIN EMPLOYEE ON
     EMPLOYER.ID = EMPLOYEE.EMPLOYERID