Создание первичных ключейcreate primary keys

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

Скрыть рекламу в статье

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

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

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

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

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

<pkukconstraint> = {PRIMARY KEY |

UNIQUE}

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

CREATE TABLE pkuk(

pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*первичный ключ*/

ukl VARCHAR(SO) NOT NULL UNIQUE,/*уникальный ключ */

uk2 INTEGER NOT NULL UNIQUE /* еще уникальный ключ */);

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

<pkuktconstraint> = {PRIMARY KEY |

UNIQUE) ( col )

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

CREATE TABLE pkuk2(

Number1 INTEGER NOT NULL,

Namel VARCHAR(SO) NOT NULL,

Kol INTEGER NOT NULL,

Stoim NUMERIC(15,4) NOT NULL,

CONSTRAINT pkt PRIMARY KEY (Numberl, Namel), /*первичный ключ pkt на

основе двух полей*/

CONSTRAINT uktl UNIQUE (kol, Stoim) ); /*уникальный ключ uktl на основе

двух полей*/

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

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

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

ALTER TABLE tablename

ADD {PRIMARY KEY | UNIQUE) ( col )

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

CREATE TABLE pkalter(

ID1 INTEGER NOT NULL,

ID2 INTEGER NOT NULL,

UID VARCHAR(24));

Затем добавляем ключи. Сначала первичный:

ALTER TABLE pkalter

ADD CONSTRAINT pkall PRIMARY KEY (idl, id2);

Затем уникальный ключ:

ALTER TABLE pkalter

ADD CONSTRAINT ukal UNIQUE (uid) ;

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

4).

Оглавление книги

лМБУУЙЖЙЛБГЙС

рТПУФЩЕ Й УПУФБЧОЩЕ ЛМАЮЙ

рЕТЧЙЮОЩК ЛМАЮ НПЦЕФ УПУФПСФШ ЙЪ ЕДЙОУФЧЕООПЗП РПМС ФБВМЙГЩ, ЪОБЮЕОЙС ЛПФПТПЗП ХОЙЛБМШОЩ ДМС ЛБЦДПК ЪБРЙУЙ. фБЛ, ОБРТЙНЕТ, ОБ РТЕДРТЙСФЙЙ ОЕ НПЦЕФ ВЩФШ ДЧХИ ТБВПФОЙЛПЧ У ПДЙОБЛПЧЩНЙ ФБВЕМШОЩНЙ ОПНЕТБНЙ, РПЬФПНХ Ч ФБВМЙГЕ, УПДЕТЦБЭЕК ЪБРЙУЙ П ТБВПФОЙЛБИ, ФБВЕМШОЩК ОПНЕТ НПЦЕФ ВЩФШ РЕТЧЙЮОЩН ЛМАЮПН. фБЛПК РЕТЧЙЮОЩК ЛМАЮ ОБЪЩЧБАФ РТПУФЩН ЛМАЮПН.

еУМЙ ФБВМЙГБ ОЕ ЙНЕЕФ ЕДЙОУФЧЕООПЗП ХОЙЛБМШОПЗП РПМС, РЕТЧЙЮОЩК ЛМАЮ НПЦЕФ ВЩФШ УПУФБЧМЕО ЙЪ ОЕУЛПМШЛЙИ РПМЕК, УПЧПЛХРОПУФШ ЪОБЮЕОЙК ЛПФПТЩИ ЗБТБОФЙТХЕФ ХОЙЛБМШОПУФШ. фБЛ, ЙНС, ЖБНЙМЙС, ПФЮЕУФЧП, ОПНЕТ РБУРПТФБ, УЕТЙС РБУРПТФБ ОЕ НПЗХФ ВЩФШ РЕТЧЙЮОЩНЙ ЛМАЮБНЙ РП ПФДЕМШОПУФЙ, ФБЛ ЛБЛ НПЗХФ ПЛБЪБФШУС ПДЙОБЛПЧЩНЙ Х ДЧХИ Й ВПМЕЕ МАДЕК. оП ОЕ ВЩЧБЕФ ДЧХИ МЙЮОЩИ ДПЛХНЕОФПЧ ПДОПЗП ФЙРБ У ПДЙОБЛПЧЩНЙ УЕТЙЕК Й ОПНЕТПН. рПЬФПНХ Ч ФБВМЙГЕ, УПДЕТЦБЭЕК ЪБРЙУЙ П МАДСИ, РЕТЧЙЮОЩН ЛМАЮПН НПЦЕФ ВЩФШ ОБВПТ РПМЕК, УПУФПСЭЙК ЙЪ ФЙРБ МЙЮОПЗП ДПЛХНЕОФБ, ЕЗП УЕТЙЙ Й ОПНЕТБ. фБЛПК РЕТЧЙЮОЩК ЛМАЮ ОБЪЩЧБАФ УПУФБЧОЩН ЛМАЮПН (БОЗМ. compound key, composite key, concatenated key).

еУФЕУФЧЕООЩЕ Й УХТТПЗБФОЩЕ ЛМАЮЙ

рЕТЧЙЮОЩК ЛМАЮ НПЦЕФ УПУФПСФШ ЙЪ ЙОЖПТНБГЙПООЩИ РПМЕК ФБВМЙГЩ (ФП ЕУФШ РПМЕК, УПДЕТЦБЭЙИ РПМЕЪОХА ЙОЖПТНБГЙА ПВ ПРЙУЩЧБЕНЩИ ПВЯЕЛФБИ). фБЛПК РЕТЧЙЮОЩК ЛМАЮ ОБЪЩЧБАФ ЕУФЕУФЧЕООЩН ЛМАЮПН. фЕПТЕФЙЮЕУЛЙ, ЕУФЕУФЧЕООЩК ЛМАЮ ЧУЕЗДБ НПЦОП УЖПТНЙТПЧБФШ, Ч ЬФПН УМХЮБЕ НЩ РПМХЮЙН Ф. О. ЙОФЕММЕЛФХБМШОЩК ЛМАЮ. оБ РТБЛФЙЛЕ, ПДОБЛП, ЙУРПМШЪПЧБОЙЕ ЕУФЕУФЧЕООЩИ ЛМАЮЕК ОБФБМЛЙЧБЕФУС ОБ ПРТЕДЕМЈООЩЕ УМПЦОПУФЙ:

• оЙЪЛБС ЬЖЖЕЛФЙЧОПУФШ — еУФЕУФЧЕООЩК ЛМАЮ НПЦЕФ ВЩФШ ЧЕМЙЛ РП ТБЪНЕТХ (ПУПВЕООП ЛПЗДБ ПО УПУФБЧОПК), Й ЕЗП ЙУРПМШЪПЧБОЙЕ ПЛБЦЕФУС ФЕИОЙЮЕУЛЙ ОЕЬЖЖЕЛФЙЧОЩН (ЧЕДШ ЧП ЧУЕИ ФБВМЙГБИ, УЧСЪБООЩИ У ДБООПК, РПОБДПВЙФУС УПЪДБФШ РПМЕ ФПЗП ЦЕ ТБЪНЕТБ, ЮФПВЩ ИТБОЙФШ УУЩМЛЙ).
• оЕПВИПДЙНПУФШ ЛБУЛБДОЩИ ЙЪНЕОЕОЙК — рТЙ ЙЪНЕОЕОЙЙ ЪОБЮЕОЙС РПМС, ЧИПДСЭЕЗП Ч ЕУФЕУФЧЕООЩК ЛМАЮ, ПЛБЪЩЧБЕФУС ОЕПВИПДЙНЩН ЙЪНЕОЙФШ ЪОБЮЕОЙЕ РПМС ОЕ ФПМШЛП Ч ДБООПК ФБВМЙГЕ, ОП Й ЧП ЧУЕИ ФБВМЙГБИ, УЧСЪБООЩИ У ДБООПК, Ч РТПФЙЧОПН УМХЮБЕ ЧУЕ УУЩМЛЙ ОБ ДБООХА ЪБРЙУШ ПЛБЦХФУС ОЕЛПТТЕЛФОЩНЙ. ч УМПЦОЩИ ВБЪБИ ДБООЩИ ФБЛЙИ УЧСЪБООЩИ ФБВМЙГ НПЦЕФ ВЩФШ ПЮЕОШ НОПЗП, Й ЧУЕЗДБ ПУФБЈФУС ПРБУОПУФШ ХРХУФЙФШ ЙЪ ЧЙДХ ЛБЛХА-ФП ЙЪ ОЙИ. рТЙ ДПВБЧМЕОЙЙ ОПЧЩИ УЧСЪБООЩИ ФБВМЙГ РТЙИПДЙФУС ДПВБЧМСФШ УПЗМБУХАЭЙЕ ЙЪНЕОЕОЙС ЧП ЧУЕ НЕУФБ РТПЗТБНН, ЗДЕ РТБЧЙФУС ЙУИПДОБС ФБВМЙГБ.
• оЕУППФЧЕФУФЧЙЕ ТЕБМШОПУФЙ — хОЙЛБМШОПУФШ ЕУФЕУФЧЕООПЗП РЕТЧЙЮОПЗП ЛМАЮБ Ч ТЕБМШОЩИ вд ОЕ ЧУЕЗДБ УПВМАДБЕФУС. дПРХУФЙН, ОБРТЙНЕТ, ЮФП РЕТЧЙЮОЩК ЛМАЮ Ч ФБВМЙГЕ — ДБООЩЕ МЙЮОПЗП ДПЛХНЕОФБ. ч ФБЛХА ФБВМЙГХ ПЛБЦЕФУС ОЕЧПЪНПЦОЩН ЧОЕУФЙ ЮЕМПЧЕЛБ, П ДПЛХНЕОФБИ ЛПФПТПЗП ОЕФ ЙОЖПТНБГЙЙ Ч НПНЕОФ ДПВБЧМЕОЙС ЪБРЙУЙ, Б ОБ РТБЛФЙЛЕ ФБЛБС ОЕПВИПДЙНПУФШ НПЦЕФ ЧПЪОЙЛОХФШ.

чУМЕДУФЧЙЕ ЬФЙИ Й ДТХЗЙИ УППВТБЦЕОЙК Ч РТБЛФЙЛЕ РТПЕЛФЙТПЧБОЙС вд ЮБЭЕ ЙУРПМШЪХАФ Ф. О. УЙОФЕФЙЮЕУЛЙЕ (УХТТПЗБФОЩЕ) ЛМАЮЙ — ЙУЛХУУФЧЕООП УПЪДБООЩЕ ФЕИОЙЮЕУЛЙЕ ЛМАЮЕЧЩЕ РПМС, ОЕ ОЕУХЭЙЕ ЙОЖПТНБГЙЙ ПВ ПВЯЕЛФБИ.

нБФЕТЙБМ ЙЪ ЧЙЛЙРЕДЙЙ — УЧПВПДОПК ЬОГЙЛМПРЕДЙЙ
тБЪДЕМ: фЕПТЕФЙЮЕУЛЙЕ ПУОПЧЩ ВБЪ ДБООЩИ • ухвд

Завершение первичного проекта

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

Может случиться так, что каждый продукт будет иметь несколько штрих-кодов, потому что если производитель вносит значительные из­менения в упаковку продукта, он также часто меняет и штрих-код. Например, все наверняка видели упаковки с надписью «+20% бес­платно», стоимость такой (например) бутылки лимонада не меняется, но зато благодаря этой рекламной акции лимонада вы получаете боль­ше. Обычно в таких случаях производители изменяют штрих-код, но сам продукт, по существу, не меняется. Возникает отношение: мно­жество штрих-кодов для одного продукта. Добавляем таблицу для хранения штрих-кодов (рис. 5):

Рис. 5. Добавление в базу данных таблицы BARCODE

Заметьте, что стрелка идет в направлении от таблицы BARCODE к табли­це ITEM, потому что именно штрих-кодов может быть несколько для од­ного товара

Обратите внимание на то, что barcode_ean является пер­вичным ключом, т. к

для каждого штрих-кода должна существовать уникальная строка и (хотя один продукт и может иметь несколько штрих-кодов) ни один штрих-код не может принадлежать более чем одному продукту.

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

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

Но может быть и так, что у нас множество товаров, при этом чаще все­го лишь какие-то из них присутствуют на складе, а объем инфор­мации, которую приходится хранить для товаров, находящихся на складе, весьма велик. Например, для склада необходимо хранить ин­формацию о размещении, номерах партий и сроках годности. Если в картотеке имеется 500 000 товаров, а на складе есть только 1000, то хранение данных по всем товарам будет просто расточительством. У этой проблемы есть стандартное решение — дополнительная таблица.

Следует создать новую таблицу, в которой хранилась бы «дополни­тельная информация» (например, сведения о хранении на складе), а затем создать только нужные строки — для продуктов, имеющихся в наличии на складе. Эти данные будут ссылаться на основную таблицу. На самом деле все гораздо проще, чем может показаться из этого объ­яснения. Окончательный проект первого варианта нашей базы дан­ных, с которым мы будем работать далее, представлен на рис. 2.19:

Рис. 2.19. Добавление в базу данных таблицы stock

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

ствующим товаром в таблице item используется . Стрелка ука­зывает на таблицу item, потому что это главная таблица, хотя в данном случае и нет отношения «многие-к-одному».

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

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

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

Первичный ключ может быть создан при выполнении оператора CREATE TABLE в SQL.

Синтаксис

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

CREATE TABLE table_name
(
column1 datatype ,
column2 datatype ,
…

CONSTRAINT constraint_name PRIMARY KEY (pk_col1, pk_col2, … pk_col_n)
);

Или

CREATE TABLE table_name
(
column1 datatype CONSTRAINT constraint_name PRIMARY KEY,
column2 datatype ,
…
);

table_name

Имя таблицы, которую вы хотите создать

column1, column2

Столбцы, которые вы хотите создать в таблице

constraint_name

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

pk_col1, pk_col2, … pk_col_n

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

Пример

Давайте посмотрим, как создать первичный ключ с помощью оператора CREATE TABLE в SQL. Мы начнем с очень простого, где наш первичный ключ состоит всего из одного столбца.
Например:

PgSQL

CREATE TABLE suppliers
( supplier_id int NOT NULL,
supplier_name char(50) NOT NULL,
contact_name char(50),
CONSTRAINT suppliers_pk PRIMARY KEY (supplier_id)
);

1 2 3 4 5 6

CREATETABLEsuppliers (supplier_idintNOT NULL, supplier_namechar(50)NOT NULL, contact_namechar(50), CONSTRAINTsuppliers_pkPRIMARYKEY(supplier_id) );

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

PgSQL

CREATE TABLE suppliers
( supplier_id int CONSTRAINT suppliers_pk PRIMARY KEY,
supplier_name char(50) NOT NULL,
contact_name char(50)
);

1 2 3 4 5

CREATETABLEsuppliers (supplier_idintCONSTRAINTsuppliers_pkPRIMARYKEY, supplier_namechar(50)NOT NULL, contact_namechar(50) );

Оба эти синтаксиса действительны при создании первичного ключа только с одним полем.
Если вы создаете первичный ключ, который состоит из 2-х или более столбцов, вы ограничены использованием только первого синтаксиса, в котором первичный ключ определен в конце оператора CREATE TABLE.
Например:

PgSQL

CREATE TABLE contacts
( last_name VARCHAR(30) NOT NULL,
first_name VARCHAR(25) NOT NULL,
birthday DATE,
CONSTRAINT contacts_pk PRIMARY KEY (last_name, first_name)
);

1 2 3 4 5 6

CREATETABLEcontacts (last_nameVARCHAR(30)NOT NULL, first_nameVARCHAR(25)NOT NULL, birthdayDATE, CONSTRAINTcontacts_pkPRIMARYKEY(last_name,first_name) );

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

Что представляет собой БД?

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

База данных Access — это хранилище объектов. В одной такой базе данных может содержаться более одной таблицы. Представьте систему отслеживания складских запасов с тремя таблицами — это будет одна база данных, а не 3.

Что касается БД Access, то в ней все таблицы сохраняются в одном файле совместно с другими объектами (формами, отчётами, модулями, макросами).

Для файлов БД, созданных в формате Access 2007 (он совместим с Access 2010, Access 2013 и Access 2016), применяется расширение ACCDB, а для БД, которые созданы в более ранних версиях, — MDB. При этом посредством Access 2007, Access 2013, Access 2010 и Access 2016 вы сможете, при необходимости, создавать файлы и в форматах более ранних версий (Access 2000, Access 2002–2003).

Применение БД Access позволяет:
• добавлять новые данные в БД (допустим, новый артикул складских запасов);
• менять информацию, находящуюся в базе (перемещать артикул);
• удалять данные (например, когда артикул продан либо утилизирован);
• упорядочивать и просматривать данные разными методами;
• обмениваться информацией с другими людьми посредством отчётов, сообщений, эл. почты, глобальной или внутренней сети.

Типы соединений между таблицами (Join)

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

Создание связи по внешнему ключу в конструкторе таблицCreate a foreign key relationship in Table Designer

Использование среды SQL Server Management StudioUsing SQL Server Management Studio

1. В обозревателе объектов щелкните правой кнопкой мыши таблицу, которая будет содержать внешний ключ для связи, и выберите пункт Конструктор.In Object Explorer, right-click the table that will be on the foreign-key side of the relationship and click Design.

   Таблица откроется в окне Конструктор таблиц.The table opens in Table Designer.

2. В меню конструктора таблиц выберите пункт Связи.From the Table Designer menu, click Relationships.

3. В диалоговом окне Связи внешнего ключа щелкните Добавить.In the Foreign-key Relationships dialog box, click Add.

   Связь появится в списке Выбранные связи с именем, установленным системой, в формате format FK_<tablename><tablename>, где tablename (имя таблицы) является именем внешнего ключа.The relationship appears in the Selected Relationship list with a system-provided name in the format FK<tablename>_<tablename>, where tablename is the name of the foreign key table.

4. Щелкните нужную связь в списке Выбранные связи .Click the relationship in the Selected Relationship list.

5. Щелкните Спецификация таблиц и столбцов в сетке справа и нажмите кнопку с многоточием ( … ) справа от свойства.Click Tables and Columns Specification in the grid to the right and click the ellipses (…) to the right of the property.

6. В диалоговом окне Таблицы и столбы в раскрывающемся списке Первичный ключ выберите таблицу, которая будет находиться на стороне первичного ключа связи.In the Tables and Columns dialog box, in the Primary Key drop-down list, choose the table that will be on the primary-key side of the relationship.

7. В сетке внизу выберите столбцы, составляющие первичный ключ таблицы.In the grid beneath, choose the columns contributing to the table’s primary key. В соседней ячейке сетки справа от каждого столбца выберите соответствующий столбец внешнего ключа таблицы внешнего ключа.In the adjacent grid cell to the right of each column, choose the corresponding foreign-key column of the foreign-key table.

   Конструктор таблиц автоматически предлагает имя для связи.Table Designer suggests a name for the relationship. Чтобы его изменить, отредактируйте содержимое текстового поля Имя связи .To change this name, edit the contents of the Relationship Name text box.

8. Нажмите кнопку OК , чтобы создать связь.Choose OK to create the relationship.

9. Закройте окно конструктора таблиц и сохраните внесенные изменения, чтобы изменения связи внешнего ключа вступили в силу.Close the table designer window and save your changes for the foreign key relationship change to take effect.

Языки манипулирования данными

Основное средство для общения с реляционными базами данных — язык структурированных запросов SQL.

Это декларативный язык. То есть инструкции в нём не идут одна за другой (не как в императивных языках). Каждый оператор SQL описывает только необходимое действие, а СУБД сама принимает решение, как его выполнить.

Например, чтобы выбрать все данные из таблицы Messages за 10.11.2020, делается запрос:

SELECT * FROM messages WHERE date = ‘10.11.2020’

Язык структурированных запросов делится на несколько частей (группы операторов) и позволяет:

• определять данные (DDL),
• манипулировать ими (DML),
• контролировать доступ к данным (DCL)
• и управлять транзакциями (TCL).

В SQL изначально нет средств для создания печатных отчётов, экранных форм и других инструментов для разработки программ. Хотя SQL сам по себе не является полноценным (Тьюринг-полным) языком программирования, но его стандарт позволяет создавать процедурные расширения. Они доводят его функциональность до полноценного языка программирования.

При этом синтаксис SQL в разных СУБД может различаться. Кое-где даже используются его отдельные диалекты, например:

• T-SQL — для работы с Microsoft SQL Server;
• на PL / SQL пишут хранимые процедуры и функции в Oracle;
• на PL / pgSQL — в PostgreSQL.

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

Новые таблицы добавляются в существующую базу данных с помощью оператора CREATE TABLE SQL. За оператором CREATE TABLE следует имя создаваемой таблицы, а далее через запятые список имен и определений каждого столбца таблицы:

CREATE TABLE имя_таблицы ( определение имени_столбца, определение имени_таблицы …, PRIMARY KEY= (имя_столбца) ) ENGINE= тип_движка;

В определении столбца ​​задается тип данных, может ли столбец быть NULL, AUTO_INCREMENT. Оператор CREATE TABLE также позволяет указать столбец (или группу столбцов) в качестве первичного ключа. Прежде чем будет создавать таблицу, нужно выбрать базу данных. Это делается с помощью оператора SQL USE:

USE MySampleDB;

Создадим таблицу, состоящую из трех столбцов: customer_id, customer_name и customer_address. Столбцы customer_id и customer_name не должны быть пустыми (то есть NOT NULL). customer_id содержит целочисленное значение, которое будет автоматически увеличиваться при добавлении новых строк. Остальные столбцы будут содержать строки длиной до 20 символов. Первичный ключ определяется как customer_id.

CREATE TABLE customer 
( 
customer_id int NOT NULL AUTO_INCREMENT, 
customer_name char(20) NOT NULL, 
customer_address char(20) NULL, 
PRIMARY KEY (customer_id) 
) ENGINE=InnoDB;

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

йУРПМШЪПЧБОЙЕ

рЕТЧЙЮОЩК ЛМАЮ Ч ФБВМЙГЕ СЧМСЕФУС ВБЪПЧЩН ХОЙЛБМШОЩН ЙДЕОФЙЖЙЛБФПТПН ДМС ЪБРЙУЕК. ъОБЮЕОЙЕ РЕТЧЙЮОПЗП ЛМАЮБ ЙУРПМШЪХЕФУС ЧЕЪДЕ, ЗДЕ ОХЦОП ХЛБЪБФШ ОБ ЛПОЛТЕФОХА ЪБРЙУШ. оБ ЙУРПМШЪПЧБОЙЙ РЕТЧЙЮОЩИ ЛМАЮЕК ПУОПЧБОБ ПТЗБОЙЪБГЙС УЧСЪЕК НЕЦДХ ФБВМЙГБНЙ ТЕМСГЙПООПК вд. юФПВЩ ПТЗБОЙЪПЧБФШ НЕЦДХ ДЧХНС ФБВМЙГБНЙ УЧСЪШ ФЙРБ «ПДЙО Л ПДОПНХ» ЙМЙ «ПДЙО ЛП НОПЗЙН» Ч ПДОХ ЙЪ УЧСЪЩЧБЕНЩИ ФБВМЙГ ДПВБЧМСАФ РПМЕ (РПМС), УПДЕТЦБЭЕЕ(ЙЕ) ЪОБЮЕОЙЕ РЕТЧЙЮОПЗП ЛМАЮБ ЪБРЙУЙ Ч УЧСЪБООПК ФБВМЙГЕ (ФБЛПЕ РПМЕ ОБЪЩЧБАФ ЧОЕЫОЙН ЛМАЮПН). дМС ПТЗБОЙЪБГЙЙ УЧСЪЙ ФЙРБ «НОПЗЙЕ ЛП НОПЗЙН» УПЪДБАФ ПФДЕМШОХА ФБВМЙГХ (ФБЛ ОБЪЩЧБЕНХА «ФБВМЙГХ УЧСЪЙ» ЙМЙ «ФБВМЙГХ БУУПГЙБГЙЙ»), ЛБЦДБС ЪБРЙУШ ЛПФПТПК УПДЕТЦЙФ РЕТЧЙЮОЩЕ ЛМАЮЙ ДЧХИ УЧСЪБООЩИ ЪБРЙУЕК Ч ТБЪОЩИ ФБВМЙГБИ.