Запутался в сущностях моста и сущностях с несколькими атрибутами

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

Определение таблицы для ассоциативной таблицы может выглядеть примерно так:

CREATE TABLE buys
( prod_id  NUMBER(5,0) NOT NULL COMMENT 'composite PK, FK ref products.prod_id'
, cus_id   NUMBER(5,0) NOT NULL COMMENT 'composite PK, FK ref customers.cus_id'
, PRIMARY KEY (prod_id, cus_id) 
, UNIQUE KEY buys_UX1 (cus_id, prod_id)
, CONSTRAINT FK_buys_products FOREIGN KEY (prod_id) REFERENCES products (prod_id) 
  ON DELETE CASCADE ON UPDATE CASCADE     
, CONSTRAINT FK_buys_customers FOREIGN KEY (cus_id) REFERENCES customers (cus_id) 
  ON DELETE CASCADE ON UPDATE CASCADE     
) ENGINE=InnoDB
;

Примечание. Я не верю, что NUMBER(5,0) является допустимым типом данных MySQL. Для столбцов первичного ключа я обычно использую целочисленный тип данных, INT или BIGINT. Но столбцы внешнего ключа должны ТОЧНО соответствовать типу данных ссылочных первичных столбцов, поэтому я использовал NUMBER(5,0) как копию типа данных ссылочных столбцов.

Многозначный атрибут может быть реализован как дочерняя таблица с отношением «один ко многим». Но я не вижу никаких указаний на многозначный атрибут в модели.

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

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

 cus_name_title
 cus_name_last
 cus_name_first
 cus_name_suffix

Аналогично для атрибута "почтовый адрес"

cus_addr_street
cus_addr_line2
cus_addr_city
cus_addr_state
cus_addr_postal_code

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

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

СЛЕДОВАТЬ ЗА

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

Мы можем создать таблицу с внешним ключом, ссылаясь на cus_id в customers.

 CREATE TABLE cus_phone_numbers 
 ( id            INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY COMMENT 'PK'
 , cus_id        NUMBER(5,0) NOT NULL COMMENT 'FK ref customers.cus_id'
 , phone_type    VARCHAR(80)  COMMENT 'e.g. main, mobile, office, fax'
 , phone_number  VARCHAR(80)
 , CONSTRAINT FK_cus_phone_numbers_customers 
   FOREIGN KEY (cus_id) REFERENCES customers (cus_id)
   ON DELETE CASCADE ON UPDATE CASCADE
 ) ENGINE=InnoDB 
 ;

Например, у клиента с тремя телефонными номерами будет три строки в таблице телефонных номеров. У клиента без номера телефона в таблице будет ноль строк.

  cus_id   phone_type    phone_number
  ------   ----------    ---------------
      42   main 1        xxx-xxx-1111
      42   office        xxx-xxx-1212
      42   fax           xxx-xxx-3333
     112   service       xxx-xxx-7701
     112   delivery      xxx-xxx-7702

Это атрибуты многозначный ... и атрибут объекта, который может иметь ноль, одно или несколько значений.

Атрибут составной состоит из нескольких атрибутов компонентов. Например, атрибут «имя» клиента может быть комбинацией нескольких простых атрибутов:

 title/salutation        'Major'
 first name              'Charles'
 middle name             'Emerson'
 last name               'Winchester'
 suffix                  'III'
 nickname                ''

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

Рассмотрим атрибут «номер телефона». Это можно смоделировать как составной атрибут:

country code        +1
area code           888
exchange number     467
line number         4355