++ CBDR

class: titlepage

.title[
      ++ de CBDR
]

.subtitle[
  V pour Validation
]


.footnote[
      'V' Matthias Lapu 
]

---
layout: true
class: animated fadeIn middle numbers

---
# Table des matières
1. Diagrammes de classes
  1. Classe et clé 
  2. Associations et cardinalité
  3. Héritage
2. Modèle relationnel 
3. Correction du partiel 2022-2023
      1. Texte -> UML (Exercice 1) **~35%**
      2. UML -> Relationnel (Exercice 2) **~35%**
      3. Rétroconception (Exercice 3) **~20%**
      4. Formes Normales (Exercice 4) **~10%**
4. Outils pour réviser (Mes fiches Anki)

.footnote[
  V pour Validation
]
---
# Rappel de cours 

Les bases de données, c'est énormément de diagrammes de classes.

--

L'informatique c'est énormément de diagramme de classe, pour des raisons que vous verrez bientôt.

![](image/UML.jpeg)

.footnote[
  V pour Validation
]

---
# Classe, attribut, clé et méthodes
## Classe et attribut

Une classe est élément , avec des **attributs** et des **méthodes**.

**Les attributs ont des types** (c'est mieux de savoir avec quoi on travaille).

|      Voiture      | 
|:-----------------:|
|     #plaque       |
|  nbPorte: int     |
|  modèle : String  |
|  âge : age        |
|kilométrage : float|

.footnote[
  V pour Validation
]

---

# Classe, attribut, clé et méthodes
## Clé
Une clé est un attribut qui identifie une classe. **Une clé est unique.**

|  Voiture  | 
|:---------:|
|**#plaque**|
|  nbPorte  |
|  modèle   |
|  âge      |
|kilométrage|

.footnote[
  V pour Validation
]

---

## Clé artificielle

Il est possible pour différentes raisons qu'il n'y ait **pas de clé primaire qui nous convienne** (trop de cas qui match ou encore collision si suppresion d'un compte).

Ou encore que les clés candidates nécessite trop d'opération pour avoir ce que l'on cherche.

--

La solution, c'est les clés artificielles et vous avez l'habitude.

|  IIENS        | 
|:-------------:|
|    **#id**    |
|  nom          |
|  prénom       |
|  pseudo       |
|montantComptBar|


**Un id c'est une clé artificielle**, car le nom, le prénom etc. ne suffise pas, ce ne sont pas des clés primaires.
---

# Classe, attribut, clé et méthodes

## Méthode

Une méthode représente un comportement spécifique à une classe . C'est l'équivalent d'une fonction en C par exemple.
On peut se servir de méthode pour faire des **attributs dérivés**.

--

|               Voiture                       | 
|:-------------------------------------------:|
|**#plaque**                                  |
|    ...                                      |
|  consommationEssence(modèle,age)            |

.footnote[
  V pour Validation
]

---

# Associations et cardinalité

## Les associations 

Les associations, c'est ce qui définit les liens entre les objets de ces classes.

![](image/nocardinal.png)

De manière générale, on se limite aux associations binaires, c'est amplement suffisant.

.footnote[
  V pour Validation
]

---

# Associations et cardinalité

## Cardinalité

Il manque les cardinalités ! 

C'est ce qui permet de savoir le nombre minimum et maximum d'instance dans la relation.

| Cardinalité | Signification        |
|:-----------:|:--------------------:|
|   0..1      | Optionnel (0 ou 1)   |
|   1..1      | Obligatoire (1 seul) |
|   0..*      | Optionnel (0 à n)    |
|   1..*      | Obligatoire (1 à n)  |

.footnote[
  V pour Validation
]

---

# Associations et cardinalité
## Cardinalité

![](image/cardinality.png)

Pour ceux qui ont du mal avec les couleurs, 
      si A<->B alors A lis la cardinalité collé à B et vis-versa.

.footnote[
  V pour Validation
]

---

# Associations et cardinalité

## La composition

C'est une relation ou il y a une **dépendance** entre un objet, la classe composite, et un autre
        la classe dépendante. Le mot clé, c'est **contient** ou les équivalents.
- Composition non partageable
- La classe dépendante n'a pas de sens sans son composite

** En plus du losange, c'est toujours 1 --- 1.* **

![](image/composition.png)

.footnote[
  V pour Validation
]

---

# Associations et cardinalité

## La composition

![](image/longLive.jpg)

.footnote[
  V pour Validation
]

---

# Associations et cardinalité
## L'aggrégation 

Permet de définir une relation de type "ensemble/élement". 

Les éléments peuvent survivre indépendemment.


![](image/aggregation.png)

.footnote[
  V pour Validation
]
---

# Associations et cardinalité
## L'association n-aire

Très similaire aux binaires que l'on à vu plus haut. 
**TROIS C'EST LE MAX.**
Si vous pensez que c'est plus de trois, relisez d'habord bien le sujet avant.

- Moins lisible
- Plus compliqué 

![](image/nAire.png)

**à ne pas faire ! **

.footnote[
  V pour Validation
]
---
#Héritage

L'Héritage, c'est une association entre 2 classes qui permet d'exprimer une généralistaion ou encore une spécialisation. 

![](image/heritage.png)

.footnote[
  V pour Validation
]
---

#Héritage

L'Héritage, c'est une association entre 2 classes qui permet d'exprimer une généralistaion ou encore une spécialisation. 
 
On dit qu'une classe "hérite" de l'autre car c'est comme une copie de la classe mais avec des attributs en plus.


|  IIENS        | 
|:-------------:|
|    **#id**    |
|  nom          |
|  prénom       |
|  pseudo       |
|montantComptBar|


.footnote[
  V pour Validation
]
---

#Héritage

## Classe abstraite

C'est un "template". Cette classe ne sera jamais utilisé comme tel, 
        mais sera hérité pour crée d'autre classes.
Car elle n'est pas instancié elle n'a **aucune relation sauf l'héritage.**

![](image/abstraite.png)

--

Remarque : En plus , c'est un héritage **abstrait** car ses enfants n'ont aucun attribut.

.footnote[
  V pour Validation
]
---

#Héritage

Il y a d'autre type d'héritage (exclusif), ainsi que des contraites d'associations. 

Je vous invite à voir mes fiches Anki, ou le cours.

.footnote[
  V pour Validation
]
---
        
# Fin de la partie 1 

## Questions ? 

.footnote[
  V pour Validation
]
---

# Modèle relationnel

Le modèle relationnel c'est ce qui formalise les diagrammes UML.

Ce n'est qu'une **traduction** qui décrit ce qui est fait en diagramme. 

Si vous avez compris l'un, l'autre sera simple alors.

Il est important de savoir passé du diagramme au modèle relationnel et vis-versa.

.footnote[
  V pour Validation
]

--

![](image/umlVSrelationnel.jpg)

.footnote[
  V pour Validation
]

---

# Modèle relationnel

## Clé étrangère

Une clé étrangère, c'est un groupe d'attribut d'une classe qui **apparait dans l'autre**.

![](image/etrangere1.png)

.footnote[
  V pour Validation
]

---

# Clé étrangère 


![](image/etrangere1.png)

|  ID           |  NOM          |  Prenom       |  **PC**                      | 
|:-------------:|:-------------:|:-------------:|:----------------------------:|
|     1         |    Parker     |    Peter      |Spider-computer               |
|     2         |    Wayne      |    Bruce      |Bat-computer1,Bat-computer2   |
|     3         |    Banner     |    Bruce      |NULL(Broken-computer)         |

.footnote[
  V pour Validation
]


---

# Modèle relationnel

Comme je l'ai dit plus haut, c'est une traduction, donc traduisons : 


|  IIENS              | 
|:-------------------:|
|    **#id : int**    |
|  pseudo : String    |
|  age : int          |


--

IIENS(**#id : int** , pseudo : String, age : int)

.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 

![](image/cleEtrangere.png)

.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

![](image/cleEtrangere.png)

Quand il y a une associations simple, on peut commencer par traduire les clés et les attributs sans vraiment réfléchir.

IIENS(#id_IIENS, nom, ?? 

PC(#id_PC, marque , ??
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Pour la traduction quand il y a des associations avec un **1** ou encore un **0..1**, il y a forcément une clé étrangère.

![](image/cleEtrangere.png)


IIENS(#id_IIENS, nom, ?? 

PC(#id_PC, marque , ??
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Pour la traduction quand il y a des associations avec un **1** ou encore un **0..1**, il y a forcément une clé étrangère.

Dans ce cas-la la clé est unique du coté d'IIENS. 

Donc **pour IIENS, il peut y avoir plusieurs pc, ce n'est pas unique**

![](image/cleEtrangere.png)

IIENS(#id_IIENS, nom)

PC(#id_PC,marque , ???
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Donc **pour PC, il peut y avoir 0 ou 1 IIENS, c'est unique.**

IIENS est la clé étrangère de PC dans cette association.

![](image/cleEtrangere.png)

IIENS(#id_IIENS,nom)

PC(#id_PC, marque , **id_IIENS => IIENS**)
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Changeons les cardinalités !

![](image/cleEtrangere2.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS)
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Quand on a un **1..1**, ça implique qu'on ne peut pas être NULL

Donc **pour PC, il peut y avoir qu'1 IIENS, c'est unique et il est forcément présent.**

![](image/cleEtrangere2.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS)          

**id_IIENS NOT NULL**
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Changeons encore de cardinalité !

![](image/cleEtrangere3.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS)          
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Associations 1 : n

Là, un IIENS à forcément 1 pc **au minimum.**

Si on pense en terme de table, ça veut donc dire que tous les IIENS sont **forcéments** dans la table des PC
(car tous les PC sont posséder par un 1 IIENS).

![](image/cleEtrangere3.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS)          
        
**IIENS in PC**
.footnote[
  V pour Validation
]
---

# Modèle relationnel

![](image/readPLS.jpeg)

---

# Pause

## Questions ? (car c'est la base pour ce qui suit)
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Les classes d'associations

Ce qui a été fait fonctionne sans aucune modification majeures quand il y a des classes d'associations.

**Il suffit d'ajouter les attributs de la classes d'associations dans la même classe ou l'on a ajouter les clés étrangères.**
        
![](image/cleEtrangere4.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS, **date**)          
        
**IIENS in PC**

.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Les associations n : n

![](image/asso_N_N.png)
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Les associations n : n

Si la logique est comprises, on garde exactement la même, sauf que l'**on crée une relation pour l'association**.

![](image/asso_N_N.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque)

--

R_IIENS-PC(**#(id_IIENS=>IIENS, id_PC=>PC)**)
.footnote[
  V pour Validation
]
---

# Modèle relationnel

## Les associations n : n

![](image/asso_N_1N.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque)

R_IIENS-PC(**#(id_IIENS=>IIENS, id_PC=>PC)**)

**PC in R_IIENS-PC**

.footnote[
  V pour Validation
]
---

![](image/rules.jpeg)

---


# Clé locale 

Dans les associations, il est possible d'y avoir des clé local.

Dans ce cas la on la met dans la relation, **avec les autres clés étrangères**.

![](image/local.png)
.footnote[
  V pour Validation
]
---

# Composition

On garde la même logique que pour les 1:n que l'on avait fait auparavant du point de vue des clés étrangère.
C'est tellement similaire que l'on peut commencer par le traiter comme une relation classique.

![](image/composition2.png)

IIENS(#id_IIENS,nom)

PC(#id_PC,marque, id_IIENS => IIENS)

IIENS in PC

**id_IIENS NOT NULL** n'est plus nécessaire car c'est une composition, si IIENS est nul PC est mort.

.footnote[
  V pour Validation
]
---

# Composition


** La clé étrangère est pour la classe dépendante **

![](image/composition2.png)

IIENS(#id_IIENS,nom)

PC(**#(id_PC, id_IIENS => IIENS)** , marque)

IIENS in PC 
.footnote[
  V pour Validation
]
---

# Héritage relationnel

**S'il y a des vues, il y a héritage. On utilise tout le temps l'héritage par référence**

Il y a donc **3 possibilités** de traduction en fonction de la classe mère.

**Il faut savoir, en lisant le relationnel, quel type d'héritage il y a (rétroconception).**

|  Traduction   |  Heritage Exclusif (XOR) |  Classe mère abstraite       | 
|:-------------:|:------------------------:|:----------------------------:|
|**référence**  |    Non                   |Non                           |
|   classe fille|    Oui                   |Oui                           |
|    classe mère|   **sans spécificité**   |Non                           |


Il va falloir apprendre les étapes, voir la syntaxe des traductions en fonction de s'il y a rétroconception ou traduction d'uml.


.footnote[
  V pour Validation
]
---

# Traduction par référence 

1. Ecriture de la classe mère 
2. Ecriture des relation mère fille avec comme **clé principale la clé de la mère**
3. Jointure (qui permet de "faire la copie", passer les arguments de la mère à la fille)

![](image/reference.png)
.footnote[
  V pour Validation
]
---

# Traduction par référence 

Etape 1 : Ecriture de la classe mère 

![](image/reference.png)

R_Véhicule(#plaque , anneeFabrication)
.footnote[
  V pour Validation
]
---

# Traduction par référence 

Etape 2 : Ecriture des relation mère fille avec comme **clé principale la clé de la mère**

![](image/reference.png)

R_Voiture(#id_voiture=> R_Véhicule, id_voiture, crit'Air, **cle(id_voiture)**)

R_Avion(#id_avion=>R_Véhicule, id_avion, hauteurDeVol, **cle(id_avion)**)

.footnote[
  V pour Validation
]
---

# Traduction par référence 

Etape 3 : Jointure 

![](image/reference.png)

V_Voiture = join(R_Véhicule, R_Voiture, plaque=id_voiture)

V_Avion = join(R_Véhicule, R_Avion , plaque = id_avion)
.footnote[
  V pour Validation
]
---


# Traduction par classe fille

La classe mère **n'apparait pas** (elle est abstraite), on **copie ses arguments** dans la classe.

![](image/classeFille.png)

R_Avion(**#plaque , anneeFabrication** , id_avion , hauteurDeVol, **cle(id_avion**))

.footnote[
  V pour Validation
]
---

# Traduction par classe mère

Tout passe par la classe mère et se gère à l'aide de restriction (aled). Il y a donc une seule et unique relation auquel on applique plein de restriction.
Les classes filles sont accessible par le biais de "vue".

![](image/reference.png)

.footnote[
  V pour Validation
]
---

# Traduction par classe mère

![](image/reference.png)

R_VéVoAv(#plaque,anneeFabrication,id_voiture,...,id_avion,...
        **type:{Vé,Vo,Av}**
        )

le type c'est ce qui va permettre de faire la discrimination dans la relation.

.footnote[
  V pour Validation
]

---

# Traduction par classe mère

![](image/reference.png)

Ensuite on crée les vues : 

.footnote[
  V pour Validation
]

---

# Traduction par classe mère

![](image/reference.png)

Vue_Véhicule = restriction(R_VéVoAv, type="Vé")

Vue_Voiture = restriction(R_VéVoAv, type="Vo **| VoAv**")

Vue_Avion = restriction(R_VéVoAv, type="Av **| VoAv**")

.footnote[
  V pour Validation
]
---

# Traduction par classe mère VS par référence

Si la classe mère n'est pas abstraite les 2 se valent.

![](image/refVSmere.jpeg)
.footnote[
  V pour Validation
]
---
# Association 1:1

![](image/asso_1_1.jpeg)

ça dépend énormément de l'énoncé et de la compréhension du texte, ce n'est pas tombé l'année dernière, je prend le pari que ça ne tomberas pas ou que ça ne sera pas bloquant.
.footnote[
  V pour Validation
]
.footnote[
  V pour Validation
]
---
# Forme normale (FN)

|   Forme Normale (FN)    |          Description                                |
|:-----------------------:|:---------------------------------------------------:|
|   1FN (Première FN)     |   Élimination des valeurs NULL et non atomiques     |
|   2FN (Deuxième FN)     |   1FN + Élimination des dépendances partielles      |
|   3FN (Troisième FN)    |   2FN + Élimination des dépendances transitives     |
|   BCNF (Boyce-Codd FN)  |   3FN + Satisfaction de la contrainte de Boyce-Codd |

.footnote[
  V pour Validation
]
---
# 1 FN


|   Forme Normale (FN)    |          Description            |
|:-----------------------:|:-------------------------------:|
|   1FN (Première FN)     |   Élimination des valeurs NULL et non atomiques.       |

**S'il y a des valeurs nulle ou avec plusieurs valeurs dedans ce n'est pas une 1FN.**

Pour effectuer le passage en 1FN, il faut enlever les valeurs non atomiques

Remarque : Si rien n'est précisé, c'est au moins en 1FN.
.footnote[
  V pour Validation
]
---

# 2 FN

|   Forme Normale (FN)    |          Description            |
|:-----------------------:|:-------------------------------:|
|   1FN (Première FN)     |   Élimination des valeurs NULL et atomiques       |
|   2FN (Deuxième FN)     |   1FN + Élimination des dépendances partielles        |

**Si tous les éléments ne dépendent pas fonctionnelement des clés ce n'est pas en 2FN.**

|application(#nom, #version, date_lancement, developpeur )|
|:-------------------------------------------------------:|
|Clé = { nom, version }|
|DF :  **nom, version** → date_lancement |
|DF :  **nom, version** → developpeur|
|DF : version → date_lancement |
|version -> date_lancement(dépendance partielle)|
|⇒ Pas en 2FN|
.footnote[
  V pour Validation
]
---
# 2 FN

Pour faire le passage en 2FN, on sort les dépendance fonctionnel qui empêche cela.

|application(#nom, #version, developpeur )|
|:-------------------------------------------------------:|
|Clé = { nom, version }|
|⇒ 2FN|

R1(#version,date_lancement)
.footnote[
  V pour Validation
]
---

# 3 FN

|   Forme Normale (FN)    |          Description            |
|:-----------------------:|:-------------------------------:|
|   1FN (Première FN)     |   Élimination des valeurs NULL et atomiques       |
|   2FN (Deuxième FN)     |   1FN + Élimination des dépendances partielles        |
|   3FN (Troisième FN)    |   2FN + Élimination des dépendances transitives        |
        
Il suffit de mettre des couleurs sur les clés et voir s'il y a **transitivité**.

|voiture(#n_véhicule, type, marque, puissance, couleur)|
|:-------------------------------------------------:|
|DF : { n véhicule → type, type → marque, n_véhicule → puissance, n véhicule → couleur }|
|Clé = n véhicule|
|n_véhicule -> type , type -> marque (pas bon)|
|⇒ Pas en 3FN|
.footnote[
  V pour Validation
]
---
# 3 FN

|   Forme Normale (FN)    |          Description            |
|:-----------------------:|:-------------------------------:|
|   3FN (Troisième FN)    |   2FN + Élimination des dépendances transitives        |
        
On décompose de nouveau. On isole la relation transitive.

|voiture(#n_véhicule, type, puissance, couleur)|
|:-------------------------------------------------:|
|DF : { n véhicule → type, n_véhicule → puissance, n véhicule → couleur }|
|Clé = n véhicule|
|⇒ 3FN|

R1(type, marque)
.footnote[
  V pour Validation
]
---


# BCNF 

|   Forme Normale (FN)    |          Description            |
|:-----------------------:|:-------------------------------:|
|   1FN (Première FN)     |   Élimination des valeurs NULL et atomiques       |
|   2FN (Deuxième FN)     |   1FN + Élimination des dépendances partielles        |
|   3FN (Troisième FN)    |   2FN + Élimination des dépendances transitives        |
|   BCNF (Boyce-Codd FN)  |   3FN + Satisfaction de la contrainte de Boyce-Codd      |

**Chaque DF commence par une superclé .**


Remarque : Ce sont des DF non triviales mais les DF triviales sont rarement voir non mises car de la forme a -> a.
.footnote[
  V pour Validation
]

---

# Correction du Partiel 

Rappel du plan du DS de l'année dernière : 

1. Texte -> UML (Exercice 1) **~35%**
2. UML -> Relationnel (Exercice 2) **~35%**
3. Rétroconception (Exercice 3) **~20%**
4. Formes Normales (Exercice 4) **~10%**

.footnote[
  V pour Validation
]

---

# Correction du Partiel 

## Exercice 3 : Rétroconception **~20%**

![](image/exercice3.png)

.footnote[
  V pour Validation
]

---

# Exercice 3 : Rétroconception ~20%


En lisant, on se rend compte qu'il y a :

![](image/exercice3.png)
.footnote[
  V pour Validation
]

---

# Exercice 3 : Rétroconception ~20%
- 6 classes 

![](image/exercice3.png)

.footnote[
  V pour Validation
]
---

# Exercice 3 : Rétroconception ~20%
- 2 clé local (représenté par le mot clé  : **clé()**)

![](image/exercice3.png)

.footnote[
  V pour Validation
]
---

# Exercice 3 : Rétroconception ~20%
- 1 héritage (traduction par référence = vue par **projection**)

![](image/exercice3.png)

.footnote[
  V pour Validation
]
---

# Exercice 3 : Rétroconception ~20%
- Des conditions sur les cardinalités forçant l'existence (NOT NULL)
- Des conditions sur les relations qui indique des clés étrangère (et donc l'existence de relation)

![](image/exercice3.png)

.footnote[
  V pour Validation
]
---

# Exercice 3 : Rétroconception ~20%

## Si on résume 

- 6 classes 
- 2 clé local (représenté par le mot clé  : **clé()**)
- 1 héritage (traduction par référence = vue par **projection**)
- Des conditions sur les cardinalités forçant l'existence (**NOT NULL**)
- Des conditions sur les relations qui indique des clés étrangère (et donc l'existence de relation)

.footnote[
  V pour Validation
]
---

# Exercice 3 : Rétroconception ~20%

## Ma correction (copie de DS 2022)

![](image/correctionExercice3.png)

.footnote[
  V pour Validation
]
---

# Correction du Partiel 

## Exercice 1 : Texte -> UML **~35%**

(aussi appelée l'exo lecture + stabilo)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

- Traduisez le modèle conceptuel de la figure en modèle relationnel. Justifiez la traduction de l'héritage. 

- Enumérer l'ensemble des contraintes à respecter sur les attributs et/ou les relations.

.footnote[
  V pour Validation
]
---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

On commence par ce qui est simple, classe mère, classe composite.
.footnote[
  V pour Validation
]
---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Quete(#Q_nom, description, difficulte :{1,...,5}, r=>Roi)

.footnote[
  V pour Validation
]
---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Quete(#Q_nom, description, difficulte :{1,...,5}, r=>Roi)

**r NOT NULL**

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Recompense(#(R_numero, Q_nom => Quete),description , type, valeur)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Territoire(#nom , blason, tradition, monnaie)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Territoire(#nom , blason, tradition, monnaie)

Territoire IN Gouverner

Territoire IN Chevalier


.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Chevalier(#C_nom, prenom, annee_naissance, t=>Territoire)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Roi(#C_nom1 => Chevalier)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Roi(#C_nom1 => Chevalier)

Roi IN Quete

Roi in Gouverner (max : 4)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Roi(#C_nom1 => Chevalier)

V_Roi = join(Chevalier, Roi , C_nom = C_nom 1)

.footnote[
  V pour Validation
]

---

# Exercice 2 : UML -> Relationnel ~35%

![](image/exercice2.png)

Gouverner(#(t=>Territoire, r=>Roi), periode : [debut,fin])

.footnote[
  V pour Validation
]

---

# Exercice 1 : Texte -> UML ~35%

## C'est de la lecture, bonne chance.

.footnote[
  V pour Validation
]

---

# Exercice 4 : Formes normales ~10%

![](image/formeNormaleExo.png)

4.2 Identifiez et décrivez au moins un problème visible sur l'instance E.

.footnote[
  V pour Validation
]

---

# Exercice 4 : Formes normales ~10%

![](image/formeNormaleExo.png)

Redondance des informations car la relation à une dépendance par transitivité.

ex : Mr Graw-Hill | USA 

.footnote[
  V pour Validation
]

---

# Exercice 4 : Formes normales ~10%

![](image/formeNormaleExo.png)

En quelle forme normale (NF) est l'instance E ? 

.footnote[
  V pour Validation
]

---

# Exercice 4 : Formes normales ~10%

![](image/formeNormaleExo.png)

![](image/resume41.png)

.footnote[
  V pour Validation
]

---

# Exercice 4 : Formes normales ~10%

![](image/formeNormaleExo.png)

La forme normale est en 2NF , car atomique et pas de dépendance partielle.

Il y a par contre dépendance transitive donc pas 3NF.

---

# Outils pour réviser (mes fiches) 

![](image/ficheAnki.jpg)

Disponible sur mon perso : lapu.iiens.net

Ainsi que sur le discord de votre promo.

.footnote[
  V pour Validation
]

---

# Good Luck et Road To Valider 


![](image/thatsAllFolks.png)

.footnote[
  V pour "Valider moi cette matière !" Bonne chance
]