Составные первичные ключи в jpa

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

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

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

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

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

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

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

значение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Синтаксис

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

ALTER TABLE table_name
ADD CONSTRAINT constraint_name
PRIMARY KEY (column1, column2, … column_n);

table_name

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

constraint_name

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

column1, column2, … column_n

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

Пример

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

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id);

1 2 3

ALTERTABLEsuppliers ADDCONSTRAINTsuppliers_pk PRIMARYKEY(supplier_id);

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

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id, supplier_name);

1 2 3

ALTERTABLEsuppliers ADDCONSTRAINTsuppliers_pk PRIMARYKEY(supplier_id,supplier_name);

Этот пример создал бы первичный ключ с именем supplier_pk, который состоит из комбинации столбцов supplier_id и supplier_name.

Тестирование

этой ссылке

• Всего три серии тестов с длиной текстового поля в записи 80, 800 и 8000 байт соответственно (количество символов в тестовой программе будет в два раза меньше в каждом из случаев, так как один символ в NVARCHAR занимает два байта).
• В каждой из серий — по 5 запусков, каждый из которых добавляет по 10000 записей в каждую из таблиц. По результатам каждого из запусков можно будет проследить зависимость времени вставки от количества строк, уже находящихся в таблице.
• Перед началом каждой из серий таблицы полностью очищаются.

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

Определение связей между сущностями

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

Один-к-одному

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

Один-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

Многие-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако и каждой записи второй сущности может соответствовать несколько записей из первой сущности. Например, есть две сущности: Автор и Книга. Один автор может написать много книг. Но у книги может быть несколько авторов.
По критерию обязательности отношения делятся на обязательные и необязательные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение первичных ключей в 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),
   ...
)

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

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

Составной ключ (composite key)

Что касается составного ключа — это несколько первичных ключей в таблице. Таким образом, создав composite key, уникальность записи будет проверяться по полям, которые объединенные в этот ключ.

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

create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

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

Это все, что касается ключей в SQL. Это небольшое пособие — подготовка к статье связи sql где мы подробно рассмотрим как объединять таблицы, чтобы они составляли единую базу данных.

Связанные задачи

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

Задача	Раздел
Описывает, как создать первичный ключ.	Создание первичных ключей
Описывает, как удалить первичный ключ.	Удаление первичных ключей
Описывает, как изменить первичный ключ.	Изменение первичных ключей
Описывается создание связей внешнего ключа	Создание связей по внешнему ключу
Описывает, как изменить связи внешнего ключа.	Изменение связей по внешнему ключу
Описывает, как удалить связи внешнего ключа.	Удаление связей по внешнему ключу
Описывает, как просматривать свойства внешнего ключа.	Просмотр свойств внешнего ключа
Описывает, как отключить ограничения внешнего ключа для репликации.	Отключение ограничений внешнего ключа для репликации
Описывает, как отключить ограничения внешнего ключа на время выполнения инструкций INSERT и UPDATE.	Отключение ограничений внешнего ключа для инструкций INSERT и UPDATE

SQL Справочник

SQL Ключевые слова
ADD
ADD CONSTRAINT
ALTER
ALTER COLUMN
ALTER TABLE
ALL
AND
ANY
AS
ASC
BACKUP DATABASE
BETWEEN
CASE
CHECK
COLUMN
CONSTRAINT
CREATE
CREATE DATABASE
CREATE INDEX
CREATE OR REPLACE VIEW
CREATE TABLE
CREATE PROCEDURE
CREATE UNIQUE INDEX
CREATE VIEW
DATABASE
DEFAULT
DELETE
DESC
DISTINCT
DROP
DROP COLUMN
DROP CONSTRAINT
DROP DATABASE
DROP DEFAULT
DROP INDEX
DROP TABLE
DROP VIEW
EXEC
EXISTS
FOREIGN KEY
FROM
FULL OUTER JOIN
GROUP BY
HAVING
IN
INDEX
INNER JOIN
INSERT INTO
INSERT INTO SELECT
IS NULL
IS NOT NULL
JOIN
LEFT JOIN
LIKE
LIMIT
NOT
NOT NULL
OR
ORDER BY
OUTER JOIN
PRIMARY KEY
PROCEDURE
RIGHT JOIN
ROWNUM
SELECT
SELECT DISTINCT
SELECT INTO
SELECT TOP
SET
TABLE
TOP
TRUNCATE TABLE
UNION
UNION ALL
UNIQUE
UPDATE
VALUES
VIEW
WHERE

MySQL Функции
Функции строк
ASCII
CHAR_LENGTH
CHARACTER_LENGTH
CONCAT
CONCAT_WS
FIELD
FIND_IN_SET
FORMAT
INSERT
INSTR
LCASE
LEFT
LENGTH
LOCATE
LOWER
LPAD
LTRIM
MID
POSITION
REPEAT
REPLACE
REVERSE
RIGHT
RPAD
RTRIM
SPACE
STRCMP
SUBSTR
SUBSTRING
SUBSTRING_INDEX
TRIM
UCASE
UPPER
Функции чисел
ABS
ACOS
ASIN
ATAN
ATAN2
AVG
CEIL
CEILING
COS
COT
COUNT
DEGREES
DIV
EXP
FLOOR
GREATEST
LEAST
LN
LOG
LOG10
LOG2
MAX
MIN
MOD
PI
POW
POWER
RADIANS
RAND
ROUND
SIGN
SIN
SQRT
SUM
TAN
TRUNCATE
Функции дат
ADDDATE
ADDTIME
CURDATE
CURRENT_DATE
CURRENT_TIME
CURRENT_TIMESTAMP
CURTIME
DATE
DATEDIFF
DATE_ADD
DATE_FORMAT
DATE_SUB
DAY
DAYNAME
DAYOFMONTH
DAYOFWEEK
DAYOFYEAR
EXTRACT
FROM_DAYS
HOUR
LAST_DAY
LOCALTIME
LOCALTIMESTAMP
MAKEDATE
MAKETIME
MICROSECOND
MINUTE
MONTH
MONTHNAME
NOW
PERIOD_ADD
PERIOD_DIFF
QUARTER
SECOND
SEC_TO_TIME
STR_TO_DATE
SUBDATE
SUBTIME
SYSDATE
TIME
TIME_FORMAT
TIME_TO_SEC
TIMEDIFF
TIMESTAMP
TO_DAYS
WEEK
WEEKDAY
WEEKOFYEAR
YEAR
YEARWEEK
Функции расширений
BIN
BINARY
CASE
CAST
COALESCE
CONNECTION_ID
CONV
CONVERT
CURRENT_USER
DATABASE
IF
IFNULL
ISNULL
LAST_INSERT_ID
NULLIF
SESSION_USER
SYSTEM_USER
USER
VERSION

SQL Server функции
Функции строк
ASCII
CHAR
CHARINDEX
CONCAT
Concat with +
CONCAT_WS
DATALENGTH
DIFFERENCE
FORMAT
LEFT
LEN
LOWER
LTRIM
NCHAR
PATINDEX
QUOTENAME
REPLACE
REPLICATE
REVERSE
RIGHT
RTRIM
SOUNDEX
SPACE
STR
STUFF
SUBSTRING
TRANSLATE
TRIM
UNICODE
UPPER
Функции чисел
ABS
ACOS
ASIN
ATAN
ATN2
AVG
CEILING
COUNT
COS
COT
DEGREES
EXP
FLOOR
LOG
LOG10
MAX
MIN
PI
POWER
RADIANS
RAND
ROUND
SIGN
SIN
SQRT
SQUARE
SUM
TAN
Функции дат
CURRENT_TIMESTAMP
DATEADD
DATEDIFF
DATEFROMPARTS
DATENAME
DATEPART
DAY
GETDATE
GETUTCDATE
ISDATE
MONTH
SYSDATETIME
YEAR
Функции расширений
CAST
COALESCE
CONVERT
CURRENT_USER
IIF
ISNULL
ISNUMERIC
NULLIF
SESSION_USER
SESSIONPROPERTY
SYSTEM_USER
USER_NAME

MS Access функции
Функции строк
Asc
Chr
Concat with &
CurDir
Format
InStr
InstrRev
LCase
Left
Len
LTrim
Mid
Replace
Right
RTrim
Space
Split
Str
StrComp
StrConv
StrReverse
Trim
UCase
Функции чисел
Abs
Atn
Avg
Cos
Count
Exp
Fix
Format
Int
Max
Min
Randomize
Rnd
Round
Sgn
Sqr
Sum
Val
Функции дат
Date
DateAdd
DateDiff
DatePart
DateSerial
DateValue
Day
Format
Hour
Minute
Month
MonthName
Now
Second
Time
TimeSerial
TimeValue
Weekday
WeekdayName
Year
Другие функции
CurrentUser
Environ
IsDate
IsNull
IsNumeric

SQL ОператорыSQL Типы данныхSQL Краткий справочник

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

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

Пример:

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

Так что не стоит создавать PRIMARY KEY для ‘agent_name’. ‘Agent_code’ может быть единственным и исключительным выбором для PRIMARY KEY для этой таблицы.

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ	скованность
agent_code	голец	6		нет	ОСНОВНОЙ КЛЮЧ
имя агента	голец	40		нет
рабочая область	голец	35		да
комиссия	десятичный	10	2	да
номер телефона	голец	17		да

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

Ограничение первичного ключа на уровне столбца:

Код SQL:

Ограничение первичного ключа на уровне таблицы:

Код SQL:

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

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

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

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

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

1 Анализ предметной области

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

1. репертуар и расписание проката кинотеатра должен кто-то вносить в систему — соответствующую роль назовем «Менеджер»;
2. посетитель и кассир должны иметь возможность просматривать расписание, при этом интересно расписание, начиная с некоторого момента времени (например, текущего времени). Составлять оно может по-разному:
   1. расписание показа всех фильмов, упорядоченное по времени;
   2. расписание прокатов в отдельных залах кинотеатра;
   3. расписание проката определенного фильма.

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

Несмотря на то, что мы не будет разрабатывать интерфейс информационной системы и текстовые описания прецедентов, дальше нас будут интересовать данные, необходимые для выполнения того или иного прецедента, а для этого надо выделить и описать сущности. Иначе, невозможно определить «какие данные должен вводить менеджер при добавлении фильма». Основные сущности, данные которых потребуются во время работы, показаны на рисунке, при этом используется нотация диаграммы классов UML. Каждый прямоугольник соответствует одной сущности, внутри записаны поля и типы данных.

Каждая сущность, кроме hall_row содержит поле id, которое идентифицирует объект. У сущности hall_row поле id не нужно, так как в одном и том же зале кинотеатра (id_hall) не могут повторяться номера рядов (number).

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

Создать первичный ключ (оператор 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.

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

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

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

Как показано на следующем рисунке, столбцы ProductID и VendorID в таблице Purchasing.ProductVendor формируют составное ограничение первичного ключа для данной таблицы. При этом гарантируется, что каждая строка в таблице ProductVendor имеет уникальное сочетание значений ProductID и VendorID. Это предотвращает вставку повторяющихся строк.

• В таблице возможно наличие только одного ограничения по первичному ключу.

• Первичный ключ не может включать больше 16 столбцов, а общая длина ключа не может превышать 900 байт.

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

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

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

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

Теория

Первичный ключ таблицы БД может быть естественным или суррогатным.

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

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

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

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

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

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

На основании дополнительных ключей можно автоматически генерировать код проверки объектов на эквивалентность.