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

Что такое первичный ключ в БД

В базе данных первичный ключ таблицы – это один из ее столбцов (Primary key). Разберемся на примере, как это выглядит. Представим простое отношение студентов университета (назовем его «Студенты»).

Фамилия	Имя	Год рождения	Факультет	Курс	Средний балл
Иванов	Иван	1999	Экономический	3	3,8
Кузнецов	Петр	2000	Журналистики	2	4,1
Михайлов	Сергей	2000	Технологический	2	4,0
Козлов	Евгений	1998	Технологический	4	4,5
Иванов	Антон	2000	Юридический	2	3,6

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

Загрузка стандартных приложений из магазина

Каждая из стандартных игрушек была переработана и усовершенствована в плане игрового процесса и дизайна.

1. Откройте окно магазина приложений;
2. Введите в строке поиска слово «Microsoft», чтобы увидеть все приложения, которые выпускает компания. В их числе будут и стандартные. Результаты поиска будут как на рисунке ниже;

№11 – результат поиска по запросу пользователя

Откройте вкладку игр, чтобы получить список всех разработок компании «Майкрософт».

№12 – вкладка игр

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

Рекомендовать

АЛЕКСИЯ AliExpress for women Полезные и интересные товары с Алиэкспресс для жещин. Купоны и скидки

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

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

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

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

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

Требования второй нормальной формы (2NF)

Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:

• Таблица должна находиться в первой нормальной форме
• Таблица должна иметь ключ
• Все неключевые столбцы таблицы должны зависеть от полного ключа (в случае если он составной)

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

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

Главное правило второй нормальной формы (2NF) звучит следующим образом

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

Первичные ключи определены в помощью ограничения PRIMARY KEY. Синтаксис для добавления такого ограничения к существующей таблице определен в SQL: 2003 следующим образом:

ALTER TABLE <table identifier> 
    ADD  CONSTRAINT <constraint identifier>  
    PRIMARY KEY ( <column name>  {, <column name> }...  )

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

Обратите внимание, что некоторые СУБД требуют явной пометки столбцов первичного ключа как .

CREATE TABLE table_name (
   
   ...
)

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

CREATE TABLE table_name (
   id_col  INT  PRIMARY KEY,
   col2    CHARACTER VARYING(20),
   ...
)

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

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

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

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

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

Простой и составной первичный ключ

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

Ф. И. О.	Дата рождения	Серия паспорта	Номер паспорта
Иванов П.А.	12.05.1996	75	0553009
Сергеев В.Т.	14.07.1958	71	4100654
Краснов Л.В.	22.01.2001	73	1265165

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

При помощи Microsoft Equation 3.0

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

Для начала необходимо открыть интерфейс самой утилиты, для этого:

1. Перейдите во вкладку “Вставка”.
2. В группе инструментов “Текст” нажмите по кнопке “Объекты”.
3. В появившемся окне выберите “Microsoft Equation 3.0”, который находится в списке “Тип объекта”.
4. Нажмите кнопку “ОК”.

После этого в месте где был установлен курсор, появится форма для заполнения

Обратите внимание также на то, что внешний вид “Ворда” довольно сильно поменяется

Для вставки знака корня вам необходимо в окне инструментов “Формула” нажать на кнопку “Шаблоны дробей и радикалов”. Ее расположение вы можете наблюдать на изображении ниже.

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

Удалить первичный ключ

В SQL вы можете удалить первичный ключ, используя оператор ALTER TABLE.

Синтаксис

Синтаксис для удаления первичного ключа в SQL.

ALTER TABLE table_name DROP PRIMARY KEY;

table_name

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

Пример

Давайте посмотрим, как удалять первичный ключ с помощью оператора ALTER TABLE в SQL.

PgSQL

ALTER TABLE suppliers
DROP PRIMARY KEY;

1 2	ALTERTABLEsuppliers DROPPRIMARYKEY;

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

Создание таблиц

Последнее обновление: 26.06.2017

Ключевым объектом в базе данных являются таблицы. Таблицы состоят из строк и столбцов. Столбцы определяют тип информации, которая хранится, а строки содержат
значения для этих столбцов.

В прошлой теме была создана база данных university. Теперь определим в ней первую таблицу. Опять же для создания таблицы в SQL Server Management Studio
можно применить скрипт на языке SQL, либо воспользоваться графическим дизайнером. В данном случае выберем второе.

Для этого раскроем узел базы данных university в SQL Server Management Studio, нажмем на его подузел Tables
правой кнопкой мыши и далее в контексто меню выберем New -> Table…:

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

• Column Name: имя столбца

• Data Type: тип данных столбца. Тип данных определяет, какие данные могут храниться
  в этом столбце. Например, если столбец представляет числовой тип, то он может хранить только числа.

• Allow Nulls: может ли отсутствовать значение у столбца, то есть может ли он быть пустым

Допустим, нам надо создать таблицу с данными учащихся в учебном заведении. Для этого в дизайнере таблицы четыре столбца: Id, FirstName, LastName и Year, которые будут представлять
соответственно уникальный идентификатор пользователя, его имя, фамилию и год рождения. У первого и четвертого столбца надо указать тип int (то есть целочисленный), а у столбцов FirstName и LastName — тип nvarchar(50)
(строковый).

Затем в окне Properties, которая содержит свойства таблицы, в поле Name надо ввести имя таблицы — Students, а в
поле Identity ввести Id, то есть тем самым указывая, что столбец Id будет идентификатором.

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

И в конце нам надо отметить, что столбец Id будет выполнять роль первичного ключа (primary key).
Первичный ключ уникально идентифицирует каждую строку. В роли первичного ключа может выступать один столбец, а может и несколько.

Для установки первичного ключа нажмем на столбец Id правой кнопкой мыши и в появившемся меню выберем пункт Set Primary Key.

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

И после сохранения в базе данных university появится таблица Students:

Мы можем заметить, что название таблицы на самом деле начинается с префикса dbo. Этот префикс представляет схему.
Схема определяет контейнер, который хранит объекты. То есть схема логически разграничивает базы данных. Если схема явным образом не указывается при создании объекта, то объект принадлежит
схеме по умолчанию — схеме dbo.

Нажмем правой кнопкой мыши на название таблицы, и нам отобразится контекстное меню с опциями:

С помощью этих опций можно управлять таблицей. Так, опция Delete позволяет удалить таблицу. Опция Design откроет окно дизайнера таблицы,
где мы можем при необходимости внести изменения в ее структуру.

Для добавления начальных данных можно выбрать опцию Edit Top 200 Rows. Она открывает в виде таблицы 200 первых строк и
позволяет их изменить. Но так как у нас таблица только создана, то естественно в ней будет никаких данных. Введем пару строк — пару студентов, указав
необходимые данные для столбцов:

В данном случае я добавил две строки.

Затем опять же по клику на таблицу правой кнопкой мыши мы можем выбрать в контекстном меню пункт Select To 1000 Rows,
и будет запущен скрипт, который отобразит первые 1000 строк из таблицы:

НазадВперед

Перед началомBefore You Begin

ОграниченияLimitations and Restrictions

• В таблице возможно наличие только одного ограничения по первичному ключу.A table can contain only one PRIMARY KEY constraint.

• Все столбцы с ограничением PRIMARY KEY должны иметь признак NOT NULL.All columns defined within a PRIMARY KEY constraint must be defined as NOT NULL. Если допустимость значения NULL не указана, то для всех столбцов c ограничением PRIMARY KEY устанавливается признак NOT NULL.If nullability is not specified, all columns participating in a PRIMARY KEY constraint have their nullability set to NOT NULL.

PermissionsPermissions

Создание новой таблицы с первичным ключом требует разрешения CREATE TABLE в базе данных и разрешения ALTER на схему, в которой создается таблица.Creating a new table with a primary key requires CREATE TABLE permission in the database and ALTER permission on the schema in which the table is being created.

Создание первичного ключа в существующей таблице требует разрешения ALTER на таблицу.Creating a primary key in an existing table requires ALTER permission on the table.

Ссылочные действия

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

КАСКАД

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

ОГРАНИЧЕНИЕ

Значение нельзя обновить или удалить, если в ссылочной или дочерней таблице существует строка, которая ссылается на значение в ссылочной таблице.

Точно так же нельзя удалить строку, если на нее есть ссылка из ссылающейся или дочерней таблицы.

Чтобы лучше понять RESTRICT (и CASCADE), может быть полезно заметить следующую разницу, которая может быть не сразу очевидна. Ссылочное действие CASCADE изменяет «поведение» самой (дочерней) таблицы, в которой используется слово CASCADE. Например, ON DELETE CASCADE эффективно говорит: «Когда указанная строка удаляется из другой таблицы (главной таблицы), удалить также и из меня ». Однако ссылочное действие RESTRICT изменяет «поведение» главной таблицы, а не дочерней таблицы, хотя слово RESTRICT появляется в дочерней таблице, а не в главной таблице! Итак, ON DELETE RESTRICT эффективно говорит: «Когда кто-то пытается удалить строку из другой таблицы (главной таблицы), предотвращайте удаление из этой другой таблицы (и, конечно, также не удаляйте из меня, но это не главное. Вот).»

RESTRICT не поддерживается в Microsoft SQL 2012 и более ранних версиях.

БЕЗДЕЙСТВИЕ

ОТСУТСТВИЕ ДЕЙСТВИЙ и ОГРАНИЧЕНИЕ очень похожи. Основное различие между NO ACTION и RESTRICT состоит в том, что при NO ACTION проверка ссылочной целостности выполняется после попытки изменить таблицу. RESTRICT выполняет проверку перед попыткой выполнения оператора UPDATE или DELETE . Оба ссылочных действия действуют одинаково, если проверка ссылочной целостности не удалась: оператор UPDATE или DELETE приведет к ошибке.

Другими словами, когда оператор UPDATE или DELETE выполняется для указанной таблицы с использованием ссылочного действия NO ACTION, СУБД проверяет в конце выполнения оператора, что ни одно из ссылочных отношений не нарушено. Это отличается от RESTRICT, который изначально предполагает, что операция нарушит ограничение. При использовании NO ACTION триггеры или семантика самого оператора могут привести к конечному состоянию, в котором никакие отношения внешнего ключа не нарушаются к моменту окончательной проверки ограничения, что позволяет успешно завершить выполнение инструкции.

УСТАНОВИТЬ ПО УМОЛЧАНИЮ, УСТАНОВИТЬ NULL

В общем, действие, предпринимаемое СУБД для SET NULL или SET DEFAULT, одинаково как для ON DELETE, так и для ON UPDATE: значение затронутых ссылочных атрибутов изменяется на NULL для SET NULL и на указанное значение по умолчанию для SET DEFAULT. .

Триггеры

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

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

CREATE TABLE account (acct_num INT, amount DECIMAL(10,2));

CREATE TRIGGER ins_sum BEFORE INSERT ON account
     FOR EACH ROW SET @sum = @sum + NEW.amount;

Пример приведения таблицы ко второй нормальной форме

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

Таблица сотрудников в первой нормальной форме.

ФИО	Должность	Подразделение	Описание подразделения
Иванов И.И.	Программист	Отдел разработки	Разработка и сопровождение приложений и сайтов
Сергеев С.С.	Бухгалтер	Бухгалтерия	Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности
John Smith	Продавец	Отдел реализации	Организация сбыта продукции

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

Теперь мы можем начать процесс нормализации этой таблицы до второй нормальной формы.

Что для этого нам нужно сделать? Нам нужно внедрить первичный ключ.

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

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

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

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

Табельный номер	ФИО	Должность	Подразделение	Описание подразделения
1	Иванов И.И.	Программист	Отдел разработки	Разработка и сопровождение приложений и сайтов
2	Сергеев С.С.	Бухгалтер	Бухгалтерия	Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности
3	John Smith	Продавец	Отдел реализации	Организация сбыта продукции

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

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

Пример приведения таблицы ко второй нормальной форме (первичный ключ составной)

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

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

Для хранения таких данных мы создали следующую таблицу.

Таблица проектов организации в первой нормальной форме.

Название проекта	Участник	Должность	Срок проекта (мес.)
Внедрение приложения	Иванов И.И.	Программист	8
Внедрение приложения	Сергеев С.С.	Бухгалтер	8
Внедрение приложения	John Smith	Менеджер	8
Открытие нового магазина	Сергеев С.С.	Бухгалтер	12
Открытие нового магазина	John Smith	Менеджер	12

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

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

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

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

Таблица проектов организации. Внедрен составной первичный ключ.

Название проекта	Участник	Должность	Срок проекта (мес.)
Внедрение приложения	Иванов И.И.	Программист	8
Внедрение приложения	Сергеев С.С.	Бухгалтер	8
Внедрение приложения	John Smith	Менеджер	8
Открытие нового магазина	Сергеев С.С.	Бухгалтер	12
Открытие нового магазина	John Smith	Менеджер	12

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

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

Чтобы это проверить, мы можем задать себе несколько вопросов.

Можем ли мы определить «Должность», зная только название проекта? Нет. Для этого нам необходимо знать и участника. Значит, пока все хорошо, по этой части ключа мы не можем четко определить значение неключевого столбца. Идем дальше и проверяем другую часть ключа.

Можем ли мы определить «Должность» зная только участника? Да, можем. Значит наш первичный ключ плохой, и требование второй нормальной формы не выполняется.

Что делать в этом случае?

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

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

Проекты.

Идентификатор проекта	Название проекта	Срок проекта (мес.)
1	Внедрение приложения	8
2	Открытие нового магазина	12

Участники.

Идентификатор участника	Участник	Должность
1	Иванов И.И.	Программист
2	Сергеев С.С.	Бухгалтер
3	John Smith	Менеджер

Связь проектов и участников этих проектов.

Идентификатор проекта	Идентификатор участника
1	1
1	2
1	3
2	2
2	3

Мы создали 3 таблицы:

1. Проекты, в нее мы добавили искусственный первичный ключ
2. Участники, в нее мы также добавили искусственный первичный ключ
3. Связь между проектами и участниками, она нужна для реализации связи «Многие ко многим», так как между этими таблицами связь именно такая

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

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Нравится12Не нравится

Естественный и суррогатный ключ

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

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

Столбец первичного ключа в таблице помогает идентифицировать каждую строку или запись в таблице. Содержит уникальные значения. Столбец первичного ключа не может иметь значения Null. Таблица может иметь один первичный ключ. В таблице Student, student_id является первичным ключом. В таблице Patient_Details, Patient_id является первичным ключом. Для первичного ключа необязательно иметь одно поле. Это также может быть комбинация нескольких полей. Когда первичный ключ состоит из нескольких полей, он называется составным ключом. Например, первичный ключ таблицы Student может быть комбинацией student_id и name.

Назовите четыре основных типа соединения в SQL

Чтобы объединить две таблицы в одну, следует использовать оператор . Соединение таблиц может быть внутренним () или внешним (), причём внешнее соединение может быть левым (), правым () или полным ().

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

Рассмотрим пример соединения SQL таблиц с использованием . Следующий запрос выбирает все заказы с информацией о клиенте:

9

6.1.Понятие реляционной базы данных

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

Таблица
2

№№	ИМЯ ПОЛЯ	ТИП ПОЛЯ
1	Фамилия	Текстовый
2	Имя	Текстовый
3	Отчество	Текстовый
4	Почтовый индекс	Текстовый
5	Страна	Текстовый
6	Город	Текстовый
7	Адрес	Текстовый
8	Кредит	Денежный
9	Примечание	МЕМО или OLE
10	Категория товара	Текстовый
11	Наименование товара	Текстовый
12	Фирма-производитель	Текстовый
13	Цена	Денежный
14	Дата заказа	Дата/Время
15	Заказано	Числовой
16	Дата продажи	Дата/Время
17	Продано	Числовой

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

Поэтому
целесообразно разбить эту таблицу
на четыре таблицы “КЛИЕНТЫ”, “ЗАКАЗЫ
И ПРОДАЖИ”, “ТОВАРЫ” и «ПОСТАВЩИКИ»,
установив связи между ними, например,
так, как показано на рис. 6.1.

Рис.
6.1. Схема данных в реляционной БД

Реляционная
база данных
– совокупность некоторых таблиц с
данными, взаимосвязанных между собой
определёнными логическими соотношениями
(relation).