1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 7 Support de cours rédigé par Bernard COFFIN Université.

Présentation au sujet: "1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 7 Support de cours rédigé par Bernard COFFIN Université."— Transcription de la présentation:

1 1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 7 Support de cours rédigé par Bernard COFFIN Université Paris 10 – Nanterre 2007/2008

2 2 Il ne suffit pas de connaître les propriétés des principaux contrôles et de savoir écrire une requête simple en SQL pour faire une BD sous ACCESS Il faut d’abord savoir comment répartir les données à mémoriser entre les différentes tables et définir les liens logiques qui relient ces tables Principe de base : une table permet de mémoriser des occurrences d’une information complexe et cohérente Occurrence : réalisation d’un concept Information complexe : information que l’on peut décomposer en éléments. Les éléments d’informations sont les données (d’où « Base de données »). Une donnée est décrite par un champ de la table Information cohérente : les données ne sont pas placées au hasard, elles décrivent le même concept, participent à un sens (signification) commun Un enregistrement de la table correspond à une occurrence de l’information complexe et cohérente de la définition

3 3 Le sens d’une donnée dépend des autres données qui lui sont associées Autrement dit, placer une donnée dans une table ou dans une autre en modifie la signification Une donnée a une place et une seule : celle qui lui donne la signification souhaitée Pour construire une bonne base de données, il faut d’abord savoir ce qu’on veut représenter (de même que pour construire un bon formulaire, il faut d’abord savoir comment on veut l’utiliser)

4 4 Premièrement : définir les concepts que l’on veut utiliser Exemple vu en TD : on veut enregistrer des informations sur des écrivains et leurs œuvres Que faut-il définir ? un seul concept (l’œuvre et son auteur) ou bien deux concepts séparés a priori, c’est une information complexe et cohérente

5 5 Un seul concept ? Décrire l’auteur (nom, prénom, sexe, années de naissance et de décès) et l’œuvre dans un même enregistrement de la table (unique) Les descriptions risquent de ne pas être cohérentes Ex. Victor Hugo 1803/1885, Les travailleurs de la mer dans un enregistrement et Victor Hugo1804/1900, Les misérables dans un autre Interdit dans une BD bien conçue Règle fondamentale : une information (complexe ou non) ne doit pas être mémorisée plusieurs fois (on parlerait de redondances) Exception : on peut utiliser des redondances à condition qu’elles soient gérées automatiquement

6 6 Deux concepts ? La description d’un auteur est une information complexe et cohérente La description d’une œuvre est une information complexe et cohérente Donc deux concepts séparés… mais associés : ils sont complémentaires Une association de 1 à plusieurs A une occurrence d’auteur correspondent n (plusieurs, 0 possible) occurrences d’œuvre A une occurrence d’œuvre ne correspond qu’une seule occurrence d’auteur (c’est un choix de gestion, pour gérer les œuvres coproduites, il faut faire un autre choix et on aboutit à une autre BD) C’est un lien père/fils (père du côté un et fils du côté plusieurs) Lien réalisé par le couple clef primaire du père = clef externe du fils Ne jamais utiliser un autre moyen !

7 7 Représentation graphique Plusieurs conventions possibles pour représenter schématiquement une BD relationnelle On représente une table par un rectangle tabAuteur CP : N° auteur Sexe Nom auteur Prénom auteur Année naissance Année décès Clef primaire Nom de la table Liste des champs (attributs)

8 8 Représentation graphique Le lien logique est représenté par une flèche allant de la clef externe de la table fils à la clef primaire de la table père CP : N° auteur Sexe Nom auteur Prénom auteur Année naissance Année décès tabAuteurtabŒuvre CP : N° œuvre CE : Référence auteur Titre Clef externe Lien logique

9 9 A partir de quand faut-il deux tables ? Dans un enregistrement, un champ ne peut avoir qu’une seule valeur Si dans l’ensemble des données constituant une information complexe, on peut distinguer deux sous-ensembles tels qu’une occurrence de l’un peut être associé à n occurrences de l’autre, alors il faut deux tables et un lien logique Le premier de ces sous-ensembles correspond à la table père Le second à la table fils

10 10 Deux, c’est plusieurs ? En principe oui Sauf si c’est toujours deux, ni plus, ni moins Dans ce cas-là, on utilise deux champs avec des noms différents Plusieurs, c’est un nombre pouvant varier, d’une occurrence du « père » à l’autre

11 11 Une association de plusieurs à plusieurs Exemple : gestion des commandes dans une entreprise Concepts identifiés sans problème 1.Client – nom, adresse, etc. 2.Produit – nom du produit, description, prix unitaire, etc. 3.Commande – numéro, date, liste des produits commandés avec la quantité commandée pour chacun d’eux Les concepts Client et Produit sont représentés par des tables Le concept Commande doit également être représenté par une table Client / Commande est une association de un à plusieurs (lien logique) Commande / Produit est une association de plusieurs à plusieurs Un lien logique simple ne peut pas décrire cette association Il faut ajouter une table pour gérer cette association

12 12 Représentation graphique d’une association n/n tabCommande CP : N° Commande CE : Réf Client Date commande tabLien_Cde_Pdt CP : ? CE : Réf Commande CE : Réf Produit tabClient CP : N° client Nom client Adresse tabProduit CP : Code produit Nom produit Description Prix Unitaire Quelle clef primaire pour cette table ?

13 13 tabCommande CP : N° Commande CE : Réf Client Date commande tabLien_Cde_Pdt CP CE : Réf Commande CE : Réf Produit tabClient CP : N° client Nom client Adresse tabProduit CP : Code produit Nom produit Description Prix Unitaire Si une occurrence de Produit ne peut être associée qu’une seule fois à une occurrence de Commande, on utilise une clef composée des deux clefs externes

14 14 tabCommande CP : N° Commande CE : Réf Client Date commande tabLien_Cde_Pdt CP : N° ligne cde CE : Réf Commande CE : Réf Produit tabClient CP : N° client Nom client Adresse tabProduit CP : Code produit Nom produit Description Prix Unitaire Si une occurrence de Produit peut être associée plusieurs fois à une occurrence de Commande, on utilise une clef autonome

15 15 Où placer le champ correspondant à la donnée Quantité commandée ? Règle : pour placer un champ dans une table, il faut qu’il dépende entièrement de sa clef primaire La valeur de la quantité commandée dépend à la fois de la commande et du produit concerné Il faut placer le champ dans la table qui décrit l’association Commande / Produit

16 16 tabCommande CP : N° Commande CE : Réf Client Date commande tabLien_Cde_Pdt CP CE : Réf Commande CE : Réf Produit Quantité commandée tabClient CP : N° client Nom client Adresse tabProduit CP : Code produit Nom produit Description Prix Unitaire

17 17 tabCommande CP : N° Commande CE : Réf Client Date commande Taux2 tabLien_Cde_Pdt CP CE : Réf Commande CE : Réf Produit Quantité commandée Taux3 tabClient CP : N° client Nom client Adresse Taux1 tabProduit CP : Code produit Nom produit Description Prix Unitaire Le sens et la place Trois taux de remises dans trois tables différentes, quels sont leurs sens respectifs ? Pour placer un champ dans une table, il faut qu’il dépende entièrement de sa clef primaire Taux de remise permanente Taux de remise exceptionnelle Taux de remise valable uniquement pour le produit et la commande concernés

18 18 Association ternaire (entre trois tables) Exemple : gestion des commandes dans une entreprise Nouveaux choix de gestion 1.Un client peut avoir plusieurs adresses de livraisons 2.Dans une commande, le client indique pour chaque produit à laquelle de ses adresse il doit être livré La pluralité des adresses nécessite une nouvelle table L’association Commande / Produit concerne aussi l’adresse ; elle devient ternaire La table représentant l’association est liée aux trois autres par des liens logiques La clef primaire est composée des trois clefs externes

19 19 tabCommande CP : N° Commande CE : Réf Client Date commande tabLigne_commande CP CE : Réf Commande CE : Réf adresse livraison CE : Réf Produit Quantité commandée tabClient CP : N° client Nom client Prénom client Adresse client tabProduit CP : Code produit Nom produit Description Prix Unitaire tabAdresse CP : N° adresse CE : Client concerné Adresse livraison

20 20 Un formulaire simple pour la saisie des commandes Formulaire lié ; sa source est : SELECT * FROM tabCommande; Sous-formulaire sfLigne_commande Source: SELECT * FROM tabLigne_commande ORDER BY Réf_adresse, Réf_produit; Champs père / fils : [N° commande] / Réf_commande

21 21 Un formulaire simple pour la saisie des commandes Zone de liste Choix_client Contrôle source : Réf_client Contenu : SELECT [N° client], [Nom client] & " " & [Prénom client] & " à " & [Adresse client] FROM tabClient ORDER BY [Nom client], [Prénom client], [Adresse client]; Colonne liée 1 / Nombre colonne : 2 / Largeurs colonnes : 0 cm; 6 cm Zone de liste : Choix_adresse Contrôle source : Réf_adresse_livraison Contenu :SELECT [N° adresse], [Adresse livraison] FROM tabAdresse WHERE Client_concerné=forms!Saisie_Commande!Choix_client.Value; Colonne liée 1 / Nombre colonne : 2 / Largeurs colonnes : 0 cm; 6 cm Zone de liste : Choix_produit Select [N° produit], [Nom produit], [Prix unitaire] etc. Procédure événementielle : Private Sub Choix_client_AfterUpdate() sfLigne_commande!Choix_adresse.Requery End Sub

22 22 Un formulaire simple pour la saisie des commandes Étiquette dont la légende permet d’afficher le prix unitaire Procédures événementielles gérant l’affichage : Private Sub Choix_produit_AfterUpdate() etPrix.Caption = Choix_produit.Column(2) & "€" End Sub Private Sub Form_Current() If Not IsNull(Choix_produit.Column(2)) Then etPrix.Caption = Choix_produit.Column(2) & "€" Else etPrix.Caption = "" End If End Sub