Trop de normalisation

Rappelez-vous la définition de la table loan.

CREATE TABLE loan (
    borrower_id INTEGER REFERENCES borrower(id),
    bank_id INTEGER REFERENCES bank(id),
    approval_date DATE NOT NULL DEFAULT CURRENT_DATE,
    gross_approval DECIMAL(9, 2) NOT NULL,
    term_in_months SMALLINT NOT NULL,
    revolver_status BOOLEAN NOT NULL DEFAULT FALSE,
    initial_interest_rate DECIMAL(4, 2) NOT NULL
);

Un nouveau modèle pour cette table a été proposé afin de satisfaire la 1NF. La définition révisée remplace approval_date par approval_month, approval_day et approval_year :

CREATE TABLE loan (
    ...
    approval_month SMALLINT,
    approval_day SMALLINT,
    approval_year SMALLINT,
    ...
);

Cet exercice montre comment une normalisation excessive peut permettre l’insertion de données invalides.

Cet exercice fait partie du cours

<cours>Créer des bases de données PostgreSQL</cours>

Voir le cours

Instructions de l’exercice

Supprimez l’instruction INSERT INTO qui, si elle était exécutée, entraînerait l’insertion de données invalides dans la table.

Exercice interactif pratique

Essayez cet exercice en complétant ce code d’exemple.

INSERT INTO loan (
  	borrower_id, bank_id, approval_month, approval_day,
  	approval_year, gross_approval, term_in_months,
  	revolver_status, initial_interest_rate
) VALUES (12, 14, 12, 1, 2013, 421115, 120, false, 4.42);

INSERT INTO loan (
  	borrower_id, bank_id, approval_month, approval_day,
  	approval_year, gross_approval, term_in_months,
  	revolver_status, initial_interest_rate
) VALUES (3, 201, 6, 42, 2017, 30015, 60, true, 3.25);

INSERT INTO loan (
  	borrower_id, bank_id, approval_month, approval_day,
  	approval_year, gross_approval, term_in_months,
  	revolver_status, initial_interest_rate
) VALUES (19, 5, 8, 19, 2018, 200000, 120, false, 6.3);

Modifier et exécuter le code