THEORIQUE GESTION DE BASE DE DONNEES

## Objectifs et prérequis À la fin de ce chapitre, l’élève sera capable de : - Définir précisément une donnée, en indiquer sa valeur et choisir son format (type, longueur). - Élaborer un dictionnaire des données adapté à un besoin professionnel. - Définir une entité (individu), lister ses attributs et choisir un identifiant approprié. - Établir un lien entre deux entités en justifiant le type de codification utilisé. - Décrire une base de données relationnelle, concevoir la structure d’une table et représenter les relations sous forme de Modèle Conceptuel de Données (MCD). - Interpréter un MCD, définir une requête, distinguer les différents types de requêtes et expliquer leur fonction. - Définir formulaire, sous‑formulaire et contrôle dans un environnement de gestion sur ordinateur. **Prérequis** : notions de base de l’informatique (système d’exploitation, traitement de texte, tableur), capacité à lire et à rédiger des consignes simples en français, maîtrise des opérations arithmétiques élémentaires. --- ## Introduction contextualisée Dans les entreprises camerounaises, qu’il s’agisse d’une agence de micro‑finance à Yaoundé, d’un service de suivi des projets agricoles dans la région du Littoral ou d’un bureau de douane au port de Douala, la gestion de l’information repose sur la capacité à collecter, organiser et exploiter des données de façon fiable. Le traitement manuel des fichiers papier entraîne des erreurs de saisie, des pertes de temps et des difficultés de partage. L’approche par compétences du programme MINESEC/IGE vise donc à former les apprenants à concevoir des bases de données structurées, à les interroger et à les présenter sous forme de formulaires adaptés aux besoins réels du milieu professionnel. Ce chapitre fournit les fondements théoriques nécessaires avant la mise en pratique sur des logiciels tels que Microsoft Access ou LibreOffice Base. --- ## I. Leçon 4 : Les données ### Définir une donnée > **Une donnée est une représentation symbolique d’un fait ou d’une caractéristique mesurable, pouvant être traitée par un ordinateur.** Elle peut être quantitative (nombre, mesure) ou qualitative (texte, code). ### Donner la valeur d’une donnée La valeur est l’instance concrète que prend la donnée pour un individu ou un événement donné. Exemple : pour la donnée « âge », la valeur peut être 23 ans pour un apprenant spécifique. ### Choisir un format d’une donnée (type, longueur) Le format précise le **type** (entier, réel, chaîne de caractères, date, booléen) et la **longueur maximale** lorsqu’il s’agit de chaînes. - **Entier** : valeurs sans décimale, ex. 42 (stockage sur 2 ou 4 octets). - **Réel** : valeurs avec décimale, ex. 12,5 (stockage en virgule flottante). - **Chaîne** : séquence de caractères, ex. « CAMEROUN » (longueur définie, ex. 20 caractères). - **Date** : format jj/mm/aaaa ou aaaa-mm-jj. - **Booléen** : vrai/faux. ### Établir un dictionnaire des données Le dictionnaire recense, pour chaque donnée du système, son nom, sa description, son type, sa longueur, son unité éventuelle et les règles de gestion (valeurs autorisées, valeurs nulles, valeurs par défaut). | Nom de la donnée | Description | Type | Longueur | Unité | Règle de gestion | |------------------|---------------------------|--------|----------|-------|---------------------------------| | NumClient | Numéro du client | Entier | 6 | – | Valeur unique, non nulle | | NomClient | Nom complet du client | Chaîne | 30 | – | Obligatoire | | DateNaissance | Date de naissance du client| Date | 10 | – | Doit être antérieure à aujourd’hui | | Solde | Solde du compte | Réel | 8 | FCFA | ≥ 0 | > **Le dictionnaire des données constitue la référence commune pour les développeurs, les analystes et les utilisateurs finaux.** --- ## II. Leçon 5 : Entité ou individu ### Définir une entité (individu) > **Une entité est un objet du monde réel distinguable et pouvant être décrit par un ensemble de propriétés.** Dans un contexte de gestion, une entité peut être un client, un fournisseur, un produit, un employé, etc. ### Donner les propriétés ou attributs d’une entité Les attributs sont les caractéristiques qui décrivent l’entité. Chaque attribut correspond à une donnée du dictionnaire. Exemple pour l’entité **Client** : - NumClient (identifiant) - NomClient - PrénomClient - DateNaissance - Téléphone - AdresseEmail ### Définir Identifiant ou clé d’identification d’une entité > **L’identifiant (ou clé) est un attribut ou un groupe d’attributs qui permet d’identifier de façon unique chaque instance de l’entité.** Il doit être **non nul**, **unique** et **stable** dans le temps. ### Citer les différents types d’identifiant - **Identifiant simple** : un seul attribut (ex. NumClient). - **Identifiant composé** : plusieurs attributs combinés (ex. CodeProduit + CodeSite). - **Identifiant artificiel** : valeur générée par le système (ex. numéro auto‑incrémenté). - **Identifiant naturel** : attribut issu du monde réel ayant déjà une valeur unique (ex. NUMERO DE CARTE D’IDENTITÉ). ### Choisir un type de codification La codification transforme la valeur de l’identifiant en une représentation normalisée facilitant le stockage et la recherche. - **Codification numérique** : séquence de chiffres (ex. 00123). - **Codification alphanumérique** : mélange de lettres et de chiffres (ex. CLT‑2023‑045). - **Codification hiérarchique** : reflète une classification (ex. REG‑DEP‑COM). Le choix dépend de la lisibilité souhaitée, de la longueur maximale autorisée et des règles de l’entreprise. ### Établir un lien entre deux entités Un lien (ou relation) associe des instances de deux entités selon une règle de correspondance. - **Relation 1 : 1** : une instance de A est liée à au plus une instance de B. - **Relation 1 : N** : une instance de A peut être liée à plusieurs instances de B, mais chaque B à une seule A. - **Relation N : M** : plusieurs instances de A peuvent être liées à plusieurs instances de B (nécessite une table d’association). Exemple professionnel : une **Facture** (entité A) est liée à plusieurs **Lignes de facture** (entité B) → relation 1 : N. La clé étrangère de la table LignesFacture référence la clé primaire de la table Facture. > **La clé étrangère garantit l’intégrité référentielle : elle ne peut prendre que des valeurs présentes dans la clé primaire de la table parente ou rester nulle si la relation est optionnelle.** --- ## III. Leçon 6 : Base de données relationnelle ### Définir base de données relationnelle > **Une base de données relationnelle (BDR) organise l’information sous forme de tables (relations) où chaque ligne représente un enregistrement et chaque colonne un attribut.** Le modèle repose sur les principes d’intégrité d’entité, d’intégrité référentielle et d’indépendance logique. ### Définir table Une **table** est un ensemble de lignes (enregistrements) partageant la même structure (les mêmes attributs). Exemple : table **Clients** avec les colonnes NumClient, NomClient, PrénomClient, DateNaissance, Téléphone. ### Concevoir la structure d’une table Étapes : 1. Lister les attributs nécessaires (d’après le dictionnaire). 2. Déterminer la clé primaire (identifiant unique). 3. Préciser le type et la longueur de chaque attribut. 4. Indiquer les contraintes (NOT NULL, UNIQUE, CHECK, DEFAULT). 5. Ajouter les clés étrangères si la table participe à une relation. ### Représenter les relations entre les tables (MCD) Le **Modèle Conceptuel de Données (MCD)** utilise des boîtes pour les entités, des losanges pour les relations et des lignes pour les attributs. - Cardinalité notée sous la forme (min, max) près de chaque extrémité de la ligne. Exemple simplifié : ``` [Client] 1 --< (0,N) [Facture] >-- 1 [Paiement] ``` Interprétation : un client peut avoir zéro ou plusieurs factures ; chaque facture est liée à exactement un client ; une facture peut générer zéro ou un paiement ; chaque paiement appartient à une seule facture. ### Interpréter les données figurant sur un MCD Lire le MCD permet de déduire : - Quelles tables créer. - Quelles clés primaires et étrangères définir. - Quelles contraintes de cardinalité appliquer (ex. empêcher une facture sans client). ### Définir requête > **Une requête est une instruction formulée en langage d’interrogation (SQL) qui extrait, met à jour ou manipule des données présentes dans une ou plusieurs tables.** ### Énumérer les différents types de requête et donner leur fonction | Type de requête | Fonction principale | Exemple SQL simplifié | |-----------------|--------------------------------------------------|--------------------------------------| | SELECT | Lire des données | SELECT NomClient FROM Clients WHERE NomClient='Kamga'; | | INSERT | Ajouter de nouveaux enregistrements | INSERT INTO Clients VALUES (101,'Kamga','Marie','1995-04-12','690123456'); | | UPDATE | Modifier des enregistrements existants | UPDATE Clients SET Téléphone='699876543' WHERE NumClient=101; | | DELETE | Supprimer des enregistrements | DELETE FROM Clients WHERE NumClient=101; | | JOIN (INNER/LEFT…) | Combiner des données de plusieurs tables | SELECT * FROM Clients C JOIN Facture F ON C.NumClient=F.NumClient; | | AGRÉGATION (COUNT, SUM, AVG…) | Calculer des totaux ou moyennes | SELECT COUNT(*) FROM Factures WHERE DateFacture BETWEEN '2023-01-01' AND '2023-12-31'; | ### Définir formulaire Un **formulaire** est une interface utilisateur qui permet de saisir, consulter ou modifier les données d’une table (ou d’une requête) de façon guidée. Il regroupe des contrôles associés à chaque champ. ### Définir sous‑formulaire Un **sous‑formulaire** est un formulaire imbriqué dans un autre, généralement utilisé pour afficher les enregistrements d’une relation 1 : N (ex. les lignes d’une facture dans le formulaire de la facture). ### Définir contrôle Un **contrôle** est l’élément graphique d’un formulaire (zone de texte, liste déroulante, case à cocher, bouton) lié à un champ de la table ou à une expression calculée. > **Un bon formulaire respecte les principes d’ergonomie : champs obligatoires clairement indiqués, ordre de tabulation logique, validation en temps réel.** --- ## Synthèse du chapitre - **Donnée** : symbole d’un fait, valeur concrète, format (type, longueur). - **Dictionnaire des données** : référentiel décrivant chaque donnée (nom, type, longueur, règles). - **Entité** : objet du monde réel décrit par des attributs ; identifiant unique obligatoire. - **Lien entre entités** : relation 1 : 1, 1 : N ou N : M, mise en œuvre via clés primaires/étrangères. - **Base de données relationnelle** : organisation en tables, respect de l’intégrité d’entité et référentielle. - **MCD** : représentation graphique des entités, relations et cardinalités. - **Requête** : instruction SQL (SELECT, INSERT, UPDATE, DELETE, JOIN, agrégations). - **Formulaire** : interface de saisie/consultation, composé de contrôles ; sous‑formulaire pour les relations 1 : N. --- ## Glossaire (15 termes) - **Donnée** : représentation symbolique d’un fait mesurable. - **Valeur** : instance concrète prise par une donnée pour un enregistrement donné. - **Type de donnée** : catégorie (entier, réel, chaîne, date, booléen) définissant les opérations possibles. - **Longueur** : nombre maximal de caractères ou d’octets autorisés pour une donnée. - **Dictionnaire des données** : document décrivant nom, description, type, longueur, règles de chaque donnée. - **Entité** : objet du réel distinguable, décrit par un ensemble d’attributs. - **Attribut (propriété)** : caractéristique d’une entité correspondant à une donnée du dictionnaire. - **Identifiant (clé)** : attribut ou groupe d’attributs assurant l’unicité des instances d’une entité. - **Clé primaire** : identifiant choisi comme référence principale d’une table. - **Clé étrangère** : attribut d’une table faisant référence à la clé primaire d’une autre table (intégrité référentielle). - **Modèle Conceptuel de Données (MCD)** : schéma graphique représentant entités, relations et cardinalités. - **Requête SQL** : instruction permettant de lire, insérer, mettre à jour ou supprimer des données dans une BDR. - **Formulaire** : interface utilisateur pour interagir avec une table ou une requête. - **Sous‑formulaire** : formulaire imbriqué permettant d’afficher les enregistrements d’une relation 1 : N. - **Contrôle** : élément graphique d’un formulaire lié à un champ (zone de texte, liste, case à cocher, bouton). --- ## Exercices d'application corrigés ### Exercice 1 – Création d’un dictionnaire **Situation** : Vous êtes chargé de concevoir la base de données d’une coopérative agricole qui enregistre les producteurs, leurs parcelles et les récoltes. **Consigne** : Établir le dictionnaire des données pour les trois entités suivantes : Producteur, Parcelle, Récolte. Indiquer pour chaque donnée : nom, description, type, longueur, unité éventuelle et règle de gestion. **Corrigé** : | Entité | Nom de la donnée | Description | Type | Longueur | Unité | Règle de gestion | |----------|--------------------|------------------------------------------|---------|----------|-------|--------------------------------------| | Producteur | NumProd | Numéro du producteur | Entier | 6 | – | Unique, non nul | | | NomProd | Nom du producteur | Chaîne | 30 | – | Obligatoire | | | ContactProd | Téléphone du producteur | Chaîne | 15 | – | Format : +237xxxxxxxxx | | Parcelle | IdParc | Identifiant de la parcelle | Entier | 6 | – | Unique, non nul | | | NumProd (FK) | Numéro du propriétaire | Entier | 6 | – | Doit exister dans Producteur | | | Surface | Surface cultivée | Réel | 8 | ha | > 0 | | | Culture | Type de culture principale | Chaîne | 20 | – | Valeur parmi liste prédéfinie | | Récolte | IdRec | Numéro de la récolte | Entier | 6 | – | Unique, non nul | | | IdParc (FK) | Identifiant de la parcelle concernée | Entier | 6 | – | Doit exister dans Parcelle | | | DateRec | Date de la récolte | Date | 10 | – | ≤ date du jour | | | Quantite | Quantité récoltée | Réel | 8 | kg | ≥ 0 | | | PrixUnitaire | Prix de vente unitaire | Réel | 8 | FCFA/kg | ≥ 0 | ### Exercice 2 – Conception d’une table et d’une clé étrangère **Situation** : Toujours pour la coopérative, vous devez créer la table **Récolte** dans un SGBD relationnel. **Consigne** : 1. Écrire l’instruction SQL de création de la table Récolte en incluant la clé primaire, la clé étrangère vers Parcelle et les contraintes de vérification (CHECK) pour la quantité et le prix unitaire. 2. Insérer un exemple de récolte : IdRec = 2001, IdParc = 50, DateRec = 15/09/2024, Quantite = 1200, PrixUnitaire = 250. **Corrigé** : ```sql CREATE TABLE Recolte ( IdRec INT PRIMARY KEY, IdParc INT NOT NULL, DateRec DATE NOT NULL CHECK (DateRec <= CURDATE()), Quantite DECIMAL(10,2) NOT NULL CHECK (Quantite >= 0), PrixUnitaire DECIMAL(10,2) NOT NULL CHECK (PrixUnitaire >= 0), FOREIGN KEY (IdParc) REFERENCES Parcelle(IdParc) ); ``` Insertion : ```sql INSERT INTO Recolte (IdRec, IdParc, DateRec, Quantite, PrixUnitaire) VALUES (2001, 50, '2024-09-15', 1200.00, 250.00); ``` ### Exercice 3 – Lecture d’un MCD et écriture d’une requête **Situation** : Le MCD suivant décrit les relations entre les tables **Fournisseur**, **BonCommande** et **Livraison**. ``` [Fournisseur] 1 --< (0,N) [BonCommande] >-- 1 [Livraison] ``` **Consigne** : a) Décrire en mots la signification de cette relation. b) Écrire une requête SQL qui retourne le nom du fournisseur, la date de la commande et la quantité livrée pour toutes les livraisons effectuées en 2023. **Corrigé** : a) Chaque fournisseur peut passer zéro ou plusieurs bons de commande. Chaque bon de commande est lié à exactement un fournisseur. Chaque bon de commande peut donner lieu à zéro ou une livraison ; chaque livraison est associée à exactement un bon de commande. b) En supposant les colonnes suivantes : - Fournisseur (NomFourn, IdFourn) - BonCommande (DateCmd, IdFourn, IdCmd) - Livraison (QteLiv, DateLiv, IdCmd) ```sql SELECT F.NomFourn, B.DateCmd, L.QteLiv FROM Fournisseur F JOIN BonCommande B ON F.IdFourn = B.IdFourn JOIN Livraison L ON B.IdCmd = L.IdCmd WHERE YEAR(L.DateLiv) = 2023; ``` --- ## Erreurs fréquentes et règles de sécurité | # | Erreur fréquente | Conséquence | Règle de prévention / bonne pratique | |---|------------------|-------------|--------------------------------------| | 1 | Oublier de déclarer une clé primaire | Duplication d’enregistrements, perte d’intégrité d’entité | Toujours définir une clé primaire (simple ou composée) lors de la création d’une table. | | 2 | Utiliser un type de donnée inadapté (ex. entier pour un téléphone avec le signe +) | Truncation ou rejet de la saisie | Choisir le type qui accepte tous les caractères nécessaires (chaîne pour téléphone, code postal, etc.). | | 3 | Négliger la contrainte NOT NULL sur un champ obligatoire | Enregistrements avec valeurs manquantes, rapports erronés | Identifier les champs obligatoires lors de l’élaboration du dictionnaire et appliquer NOT NULL. | | 4 | Créer une clé étrangère qui référence une colonne non indexée | Performances dégradées lors des jointures | S’assurer que la colonne référencée est la clé primaire (ou possède un index unique). | | 5 | Effectuer une mise à jour sans clause WHERE | Modification accidentelle de toutes les lignes d’une table | Toujours vérifier la présence d’une clause WHERE ; tester d’abord en SELECT. | | 6 | Ignorer la validation des données à l’entrée (ex. date future pour une date de naissance) | Données incohérentes, difficultés d’exploitation | Mettre en place des contrôles CHECK ou des vérifications dans le formulaire (plage de valeurs, format). | > **Rappel de sécurité** : Lors de la conception d’une base de données, appliquer le principe du moindre privilège : chaque utilisateur ne doit disposer que des droits strictement nécessaires à ses tâches (lecture, insertion, mise à jour, suppression). --- *Fin du cours.*