Traduction des associations

Dans cet exercice, si le contraire n'est pas spécifié, il faut supposer que la stratégie de traduction de l'héritage "une seule table par hiérarchie d'héritage" a été choisie.

Association les classes Facture et LigneFacture

Association 1-N traduite par une clé étrangère du côté N, c'est-à-dire du côté table ligne1 (lignes de la facture).

Il faut donc ajouter un attribut "numero_facture" dans la table ligne1 avec une contrainte de référence (avec la clause on delete cascade car une ligne de facture n'a pas de sens sans facture) :

numero_facture integer not null
  constraint fk_ligne1_facture1 references facture1 on delete cascade

Association entre les classes Lot et Article

Association M-N traduite par une table association :

create table lot_article1 (
  -- La référence vers le lot.
  -- Pas de moyen de vérifier à ce niveau que l'on référence bien un lot...
  ref_lot integer constraint fk_lot_article1_lot references article1,
  -- La référence vers l'article qui est un composant du lot.
  ref_article varchar(8) constraint fk_lot_article1_article references article1,
  nb_article integer,
  constraint pk_lot1_article1 primary key(reference_lot, reference_article)
)

Association entre les classes LigneFacture et Article

Association 1-N traduite par une clé étrangère du côté N, c'est-à-dire du côté de la table ligne1.

Il faut donc ajouter un attribut "reference_article" dans la table ligne1 :

ref_article varchar(8) not null
  constraint fk_ligne_article1 references article1

Association entre les classes LigneFacture et Article avec la stratégie "une table par classe concrète"

Toujours évidemment une association 1-N traduite par une clé étrangère du côté N, c'est-à-dire du côté de la table LigneFacture. Mais cette fois-ci on ne peut donner de contrainte de référence puisqu'il n'y a pas de table que l'on peut référencer ! C'est un des problèmes de la stratégie "une table par classe concrète".

ref_article varchar(8) not null