Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tc_info:2024_cm_modeles [2024/12/18 23:04] – [4. Normalisation d'un schéma] edauce
+++ tc_info:2024_cm_modeles [2024/12/20 08:58] (Version actuelle) – [4.2. Dépendances fonctionnelles] edauce
@@ Ligne 1: / Ligne 1: @@
 ====== Données et modélisation ==
-===== 1. Données numériques ===
+===== 1. Données persistantes ===
 <note tip>
 Les données numériques sont une des composantes essentielles des programmes informatiques.
@@ Ligne 444: / Ligne 444: @@
 <note>
-**Rappels d’algèbre de base:**
+**Rappels d’algèbre élémentaire:**
   * **Relation binaire** : une relation binaire  $r$  portant sur deux domaines  $\text{dom}(A)$  et  $\text{dom}(B)$ :
@@ Ligne 542: / Ligne 542: @@
 ==== 4.3 Clé d'une relation====
-=== 4.1 Définitions ===
+=== Définitions ===
   * Soit un schéma  $R(A_1, ..., A_m)$ .
 <note important>
@@ Ligne 582: / Ligne 582: @@
 </note>
-=== 4.2 Axiomes d'Amstrong ===
+=== Axiomes d'Amstrong ===
 Soit  $K$  une clé candidate. On démontre que  $K \rightarrow R$  à l'aide des //axiomes d'Amstrong// à partir d'un ensemble de DF connues:
@@ Ligne 647: / Ligne 647: @@
 </note>
-==== 5. Formes Normales =====
+=== Formes Normales ====
 **__Les Formes normales__**
   * Restreignent les dépendances admises dans un schéma relationnel
@@ Ligne 655: / Ligne 655: @@
     * en plusieurs schémas //liés entre eux//:
-=== 5.1 2ème forme normale (2FN) ===
+=== 2ème forme normale (2FN) ===
 <note important>
 **Dépendance fonctionnelle élémentaire (DFE) **
@@ Ligne 682: / Ligne 682: @@
 </note>
-=== 5.2 Normalisation 2FN ===
+=== Normalisation 2FN ===
   * Lorsqu’un schéma relationnel n’est pas en deuxième forme normale, __il doit être **normalisé**__:
@@ Ligne 725: / Ligne 725: @@
 </note>
-=== 5.3 3ème forme normale (3FN) ===
+=== 3ème forme normale (3FN) ===
 <note important>
@@ Ligne 753: / Ligne 753: @@
-=== 5.4 Normalisation 3FN ===
+=== Normalisation 3FN ===
 * Lorsqu’un schéma relationnel n’est pas en troisième forme normale, __il doit être **normalisé**__:
@@ Ligne 791: / Ligne 791: @@
 L’attribut nom_f est maintenant clé primaire de la table Client et clé étrangère de la table Commande.
-</note>
-==== 6. Modèle ensembliste ====
-<note tip>
-Pour leur conception, les bases de données sont ici vues comme des ensembles constitués de plusieurs populations d'objets //en interaction//, participant au bon fonctionnement d'un certain //système//. Établir un schéma de base de données consiste à décrire ces différentes populations d'objets, mais surtout et principalement à décrire les dépendances et les interactions entre ces populations.
-</note>
-Une base de donnée est constituée de plusieurs ensembles d'objets et d'opérateurs participant au bon fonctionnement d'un système:
-__Exemple 1 :__
-  * Ensembles d'employés
-  * Ensembles de commandes
-  * Ensembles d'articles
-  * Ensembles de clients
-__Exemple 2 :__
-  * Ensembles d'étudiants
-  * Ensembles de séances
-  * Ensembles de cours
-  * Ensembles de copies
-On parle plus généralement d'**ensembles d'entités**.
-<note tip>
-** Le modèle entité/association **
-Le modèle entité/associations est une méthode de description des relations entre ensembles d’entités. Il s’appuie sur le prédicat selon lequel tous les éléments des ensembles d’entités sont discernables.
-Le modèle entités/associations repose sur un langage graphique de description des données, indépendant du support et de la mise en œuvre informatique.
-</note>
-=== Généralités ===
-Une **entité**  $x$
-    * est une représentation d'un objet du monde réel,
-    * appartenant au système/à l'organisation modélisée.
-  * Une entité est décrite par une ou plusieurs valeurs caractéristiques, appelées **attributs**.
-Les informations conservées au sujet des entités d'un ensemble sont les **attributs**.
-  * Chaque **attribut** :
-    * a un **nom** unique dans le contexte de cet ensemble d'entités :  $A$ ,  $B$ ,  $C$ ,  $A_1$ ,  $A_2$ , ...,  $A_m$ , ...
-      * Exemples de noms concrets : //couleur//, //nom//, //horaire//, //salaire//.
-    * prend ses valeurs dans un domaine bien spécifié,
-      * également appelé le **type** de l'attribut.
-      * Le domaine d'un attribut est noté  $\text{dom}(Aj)= Dj$ .
-        * Exemples :
-          *  $\text{dom}(couleur)={rouge, vert, bleu, jaune}$ ,
-          *  $\text{dom}(nom) =$ ensemble des chaînes de caractères,
-          *  $\text{dom}(salaire) =$  entiers naturels
-          * etc...
-<note important>
-    * Un attribut  $A_j$  est une fonction à valeur sur  $D_j$  :
- $A_j :  E  \rightarrow D_j$
- $x \mapsto   A_j(x)$
-</note>
-<note tip>
-    * Un attribut peut être :
-      * simple ou composé.
-        * Exemple :  une //adresse// peut être décrite par une simple chaîne de caractères, ou peut être décomposée en //rue// , //no//, //boîte//, //ville//, //code postal//, //pays//.
-      * obligatoire ou facultatif ( $D_j$  peut ou non contenir la valeur ø ).
-      * atomique ou non (Un attribut peut posséder 0, 1 voire plusieurs valeurs...)
-</note>
-Un **ensemble d'entités** est un ensemble fini d'éléments :
- $E = \{x_1,…,x_n\}$
-Il regroupe (ou associe) plusieurs entités ayant des caractéristiques communes (descriptibles à l'aide du même ensemble d'attributs).
-<note tip>
-**Exemples** :
-  * les employés d'une firme,
-  * les cours de Centrale Méditerranée,
-  * une collection de disques,
-  * etc…
-</note>
-  * Les éléments d’un ensemble d’entités sont //partiellement discernables// à travers les valeurs de leurs attributs :
-    * les attributs  $(A_1,...,A_m)$  servent à décrire les éléments de l’ensemble.
-    * Le schéma  $R$  de l’ensemble  $E$  est une //application// de l'ensemble d'entités vers l'ensemble des tuples de schéma  $R$
-      * Soit :
- $R : \mathcal{X} \rightarrow D_1 \times ... \times D_m$
- $x_i \mapsto (A_1(x_i),…, A_m(x_i))$
-<note tip>
-** représentation graphique ** :
-{{public:std-3:cm1:s7-entite-0.png}}
-</note>
-<note>
-** Exemples **:
-{{public:std-3:cm1:s7-entite-01.png}}
-</note>
-=== Définitions ===
-Modéliser une base de données, c'est :
-  * Identifier les différents ensembles en interaction
-  * Identifier les liens de dépendance entre les différents ensembles
-<note>
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-01.png?500}}
-</note>
-<note>
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-02.png}}
-</note>
-<note>
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-03.png}}
-</note>
-<note tip>
-Les liens entre les différents ensembles sont  appelés des **associations**
-</note>
-=== Association ===
-<note important>
-Une association exprime des relations de dépendance entre deux ou plusieurs ensembles d’entités.
-**Définition** : Une **association** entre les ensembles  $E_1$ , ...,  $E_k$  est un sous-ensemble du produit  $E_1 \times ... \times E_k$ .
-Il s'agit donc d'un ensemble de k-uplets  $\{..., (x_1,…,x_k), …\}$   t.q.  $x_1 \in E_1,…, x_k \in E_k$ .
-où  $k$  est le degré de l'association :
-  * k=2 : association binaire
-  * k=3 : association ternaire
-  * etc…
-</note>
-=== Rôles des associations ===
-  * //**Attribution**// : propriété, réservation, participation, supervision, auteur, rôle, pilote, ...
-  * //**Événements**// :  achat, vente, séance, épreuve,  appel, consultation, réunion, transaction, transport ...
-  * //**Aggrégation/Composition**// : tout/parties, contenant/contenu, supérieur/subordonné, pays/région, ...
-  * //**Relations entre membres**// : parenté, collaboration, cercle d'amis, ...
-  * ...
-=== Contraintes de cardinalité ===
-<note tip>
-Pour chaque ensemble participant à une association, on précise dans combien d'instances de l'association chaque entité peut apparaître.
-On donne en général un intervalle  $[b_\text{inf},b_\text{sup}]$  qui définit le nombre d'apparitions autorisées pour chaque rôle de l'association
-</note>
-=== Représentation graphique ===
-**Associations binaires**
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-04.png?600}}|
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-05.png?600}}|
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-06.png?600}}|
-**Associations ternaires**
-| {{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-07.png}}|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-08.png}}|
-=== Types d'associations ===
-**Associations de 1 à plusieurs (fonctionnelle)**
-Relation non symétrique entre les deux ensembles : […,1] d'un côté, […,N] de l'autre.
-Relation de type contenant/contenu, propriétaire/objet possédé, occupant/occupé, actif/passif etc...
-Il s'agit du type d'association le plus "courant".
-<note tip>
-On dit parfois que l’ensemble dont la participation est unique est dit “à gauche” de l’association fonctionnelle, et celui dont la participation est multiple est “à droite”, autrement dit la pointe de la flèche désigne l’ensemble de “droite”:
-“à gauche” → “à droite”
-</note>
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-09.png?600}}|
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-08.png?400}}|
-**Associations de plusieurs à plusieurs (croisée)**
-Dans une association “croisée”, les tous les lien de l’association sont de cardinalité multiple […,N]
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-04.png?600}}|
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-07.png?500}}|
-=== Modèles Entité Associations valués ===
-<note important>
-Dans le cadre du modèle entité/association :
-  * les attributs des ensembles d'entités sont des //mesures//:
-    * Soit  $A$  un attribut de l'ensemble d'entités  $\mathcal{E}$
- $A : \mathcal{E} \rightarrow \text{dom}(A)$
-  * les attributs des associations sont des //opérateurs// :
-    * Soit  $B$  un attribut de l'association sur  $\mathcal{E} \times \mathcal{F}$
- $B : \mathcal{E}\times \mathcal{F}\rightarrow \text{dom}(B)$
-</note>
-** Mesures **
-  * Les mesures sont les données saisies sur les éléments d'un ensemble. Chaque mesure est associée à un attribut.
-  * Le schéma de l'ensemble est l'ensemble des attributs servant à caractériser ses éléments
-  * Les éléments de l'ensemble sont //discernables// ssi il existe un jeu de mesures différent pour chaque élément de l'ensemble
-  * Une //clé// est un ensemble d'attributs //minimal// (permettant de distinguer les objets) appartenant au schéma
-<note tip> **TODO**
-Ensembles discernables / non discernables
-</note>
-** Opérateurs **
-  * On s’intéresse ici aux associations qui représentent une “opération” (inscription, achat, embauche, affectation…).
-  * Lors d’une mise à jour de la base, certains événements tels que l’emprunt ou le retour d’un ouvrage, l’affectation d’un employé à un poste,  ou la liste des anciens clients disparaissent.
-  * Il est possible de garder une trace des événements passés en mettant un (ou plusieurs) attributs sur une association.
-  * Ainsi, certaines associations peuvent être "datées", c'est à dire
-    * avoir lieu à une date
-    * ou prendre place sur une durée précise (prêt,accès temporaire, statut temporaire…)
-  * On peut ainsi mémoriser :
-    * "Monsieur Dupont a été employé au département logistique de tant à tant."…
-    * "L'étudiant X a été élève Centrale Méditerranée de telle année à telle année"…
-<note tip>
-**Exemple**
-"Monsieur Dupont a été employé au département logistique de tant à tant."…
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-10.png?600}}|
-</note>
-<note tip>
-**Exemple**
-  * Chaque coureur est décrit par ses nom, prénom, nationalité et numéro de maillot.
-  * Chaque coureur appartient à une équipe qui possède un numéro, un sponsor associé.
-  * Chaque coureur participe à une ou plusieurs étapes. Une étape se caractérise par son numéro, son type (contre la montre/étape simple), ses points de départ et d'arrivée, sa date.
-  * A chaque étape est associée un classement d'arrivée pour chaque coureur, avec la durée totale de course.
-|{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-11.png?800}}|
-</note>
-==== 7. Traduction vers le modèle relationnel ====
-Il est possible de traduire un modèle entité/association vers un modèle relationnel (en perdant quelques propriétés).
-<note tip>
-Lors de la réalisation d'une base de données, on passe  en général par les étapes suivantes:
-  - Conception de la base sous forme d'un modèle entité/association.
-  - Traduction sous la forme d'un modèle relationnel.
-  - Normalisation (voir [[https://wiki.centrale-marseille.fr/informatique/tc_info:cm5#normalisation_d_un_schema|Normalisation d'un schéma]])
-  - Mise en œuvre informatique.
-</note>
-Un petit nombre de règles permettent de traduire un modèle entité/association vers un modèle relationnel.
-  * Selon ces règles, à la fois les ensembles d'entités et les associations sont transformés en schémas relationnels.
-  * Les liaisons et dépendances entre schémas de relation sont assurés par la définition des **clés étrangères** (attributs communs à plusieurs tables).
-=== Schéma de base et clé étrangère ===
-<note important>
-  * Un schéma (ou modèle) de bases de données est un ensemble fini de schémas de relation.
-  * Une base de données est un ensemble fini de relations.
-  * Les liens et associations entre relations entre s’expriment sous la forme de **clés étrangères**
-</note>
-<note tip>
-**Définition**
-  * Au sein d'un schéma relationnel  $R$ , Une clé étrangère est un attribut (ou un groupe d'attributs) qui constitue la clé primaire d'un schéma  $S$  distinct de  $R$ .
-  * La présence d'une clé étrangère au sein d'une relation  $r$  de schéma  $R$  introduit une contrainte d'intégrité sur les données :
-    * la valeur des attributs de la clé étrangère d'un tuple de  $r$  doit être trouvée dans la table s correspondante.
-  * On indique la présence d'une clé étrangère à l'aide de pointillés : {…, __C__l__é__ __é__t__r__a__n__g__è__r__e__, …}
-</note>
-**Exemple **
-<note>
-**Schéma de base relationnelle** :
-  * **Clients** ( __nom_client__, adresse_client, solde)
-  * **Commandes** ( __num_Commande__, __n__o__m__ __c__l__i__e__n__t, composant, quantité)
-  * **Fournisseurs** ( __nom_fournisseur__, adresse_fournisseur)
-  * **Catalogue** ( __nom_fournisseur, composant__, prix )
-</note>
-=== Traduction des associations de plusieurs à plusieurs ===
-Une association croisée ne contient que des contraintes de cardinalité de type [..,N]. Soit  $R$  une telle association et  $E_1$ , ...,  $E_k$  les ensembles participant à l'association.
-<note important>
-**Règle de traduction :**
-  * Chaque ensemble  $E_i$  est traduit par un schéma relationnel (contenant les mêmes attributs)
-  * L'association  $R$  est traduite sous la forme d'un schéma relationnel contenant:
-    * les clés primaires des ensembles participant à l’association
-    * (éventuellement) les attributs propres à l'association,
-</note>
-<note tip>
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-12.png}}
-** Traduction :**
-  * **Pays** (__nom_pays__, superficie, population, PIB )
-  * **Matière_première** ( __nom_matière__, unité, prix )
-  * **Exportation** (__n__o__m__ __p__a__y__s, __n__o__m__ __m__a__t__i__è__r__e__, quantité)
-</note>
-<note tip>
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-16.png}}
-**Traduction** :
-  * **Appareil** (__code_appareil__, type, marque, modèle)
-  * **Séance** (__date, heure, local__)
-  * **Réservation** (__c__o__d__e __a__p__p__a__r__e__i__l,__d__a__t__e, __h__e__u__r__e__, __l__o__c__a__l__)
-</note>
-=== Traduction des associations de un à plusieurs ===
-Soit une association fonctionnelle  $R$ . On suppose qu'il existe au moins un ensemble  $A$  de cardinalité unique [1,1] participant l’association.
-<note important>
-**Règle de traduction**
-  * Chaque ensemble participant est traduit sous forme de schéma relationnel
-  * L'association  $R$  est traduite sous forme de **clé étrangère** : l'ensemble  $A$  reçoit la clé primaire du (ou des) ensemble(s) dont la participation est multiple.
-</note>
-<note tip>
-**Exemple** :
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-13.png}}
-</note>
-<note tip>
-**Remarque** : lorsque l’association est valuée, les attributs de l’association sont également injectés dans la table représentant l’ensemble de gauche.
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-14.png}}
-</note>
-<note tip>
-**Exemple**
-{{public:std-3:cm2:conception_de_bases_de_donnees:3.1.1_modele_ensembliste:s7-cm2-15.png}}
-**Traduction** :
-  * **Groupe_TD**( __num_groupe__, LV1, LV2)
-  * **Entreprise** ( __nom_entreprise__, Adresse)
-  * **Etudiant** ( __num_etudiant__, Nom, Prénom, Date_naiss, __n__u__m__ __g__r__o__u__p__e, intitulé, date, durée, __n__o__m__ __e__n__t__r__e__p__r__i__s__e)
-</note>
-=== Exemple complet ===
-<note>
-**Schéma de base relationnelle** :
-  * **Clients** ( __nom_client__, adresse_client, solde)
-  * **Commandes** ( __num_Commande__, __n__o__m__ __c__l__i__e__n__t, composant, quantité, montant)
-  * **Fournisseurs** ( __nom_fournisseur__, adresse_fournisseur)
-  * **Catalogue** ( __nom_fournisseur, composant__, prix )
-</note>
-<note>
-** Réalisation ** :
-**Clients** :
-^__nom_client__^adresse_client^solde^
-|Durand|7, rue des Lilas|335,00|
-|Dubois|44, av. du Maréchal Louis|744,00|
-|Duval|5, place du marché|33,00|
-**Commandes** :
-^__num_Commande__^ __n__o__m__ __c__l__i__e__n__t^ composant^ quantité^
-|6674|Dubois|micro controller|55|
-|6637|Dubois|radio tuner|2|
-|6524|Durand|transistor|4|
-|6443|Duval|micro controller|7|
-**Fournisseurs** :
-^__nom_fournisseur__^ adresse_fournisseur^
-|Sage|33, College street, London|
-|MoxCom|77 Ashley square,Mumbay|
-**Catalogue** :
-^__nom_fournisseur__^ __composant__^ prix^
-|Sage|transistor|4,4|
-|MoxCom|micro controller|3,7|
-|MoxCom|radio tuner|7,0|
 </note>