OpenOffice Base
1-Introduction
Avant de commencer, regardons quelques-uns des avantages d'une base de données relationnelle.
- Accès rapide et facile à l'information.
- Toute l'information est centralisée dans la base de données.
- Recherche Ad hoc facile.
- Suivi de l'information.
- Gestion des données facile.
- Analyse des données aisée.
- Automatisation de certaines tâches répétitives.
2-Intéret d'une base de données relationnelles ?
Un système de gestion de base de données relationnel (SGBDR) utilise beaucoup moins d'espace qu'une base de données simple sous forme de liste parce qu'elle réduit au minimum les redondances ou les répétitions des données.
Pour mieux comprendre le concept et l'avantage d'un SGBDR, utilisons un exemple de factures.
Regardons quelques-unes des données que l'on retrouve normalement sur une facture.
| No. Facture | Client | Produit | Description | Prix Unitaire | Qté |
|---|---|---|---|---|---|
| 001 | Client1 | 123 | Produit1 | 22,02 | 14 |
| 002 | Client1 | 456 | Produit2 | 30,07 | 18 |
| 003 | Client2 | 123 | Produit1 | 22,02 | 30 |
L'idée d'une base de données relationnelle est de répartir les données dans plusieurs BD ou tables et de créer des relations entre chacune d'elles.
| Facture | Client | Vendeur | Stock |
|---|---|---|---|
| N° Facture | N° Client | N° Vendeur | N° Produit |
| N° Produit | Adresse | Nom | Description |
| Qté vendue | Code Postal | Prénom | Prix unitaire |
| N° Vendeur | N° téléphone | N° Secsoc. | Qté disponible |
| N° Client | Personne autorisée | Date d'embauche | Qté commandée |
Dans le tableau précédent, la table FACTURE va chercher les informations sur le client de la table CLIENT par le champ commun N° CLIENT. Il est inutile de réécrire les données du client plusieurs fois.
Nous pouvons chercher l'information grâce à une relation entre ces deux tables : le champ N° Client.
Il en va de même pour les informations des tables VENDEUR et Article reliées à la table FACTURE par leurs champs communs respectifs N° VENDEUR et N° PRODUIT .
Nous économisons une réécriture des données. Cela permet également de conserver de l'espace pour d'autres données.
Pour les trois factures de l'exemple, nous économisons de l'espace et du temps à ne pas avoir à réécrire les informations sur le Client1 ni la description et le prix unitaire du produit 123.
3-Définitions
Il est important de bien maîtriser le vocabulaire lié à l'utilisation d'une base de données. Ces nouveaux termes seront utilisés tout au long des pages concernant OpenOffice Base.
| Champ | Information nécessaire sur une personne, une chose ou un événement. Ex : nom, prénom, adresses, téléphone, description, commentaires, etc. |
|---|---|
| Enregistrement | Regroupement de champs qui décrivent une personne, une chose ou un événement. Ex : nom, prénom, date de naissance, numéro de sécurité sociale, adresse, téléphone, télécopieur, etc. |
| Table | Regroupement d'enregistrements sur un thème commun. Ex : employés, inventaire, client, fournisseurs, véhicules, contacts etc. |
| Base de données | Regroupement de tables, de requêtes, de formulaires, de rapports qui constituent un système complet. Ex : gestion de la facturation, gestion de l'inventaire, carnet de contacts, réservations etc. |
| Structure d'une table | Caractéristiques des différents champs de la tables. Ex : nom, type de données, propriétés. |
| Relations | Liens entre les tables. Ils peuvent être de type un à un, un à plusieurs ou plusieurs à plusieurs. |
| Clé primaire | Champ ou combinaisons de champs déterminant de manière unique un enregistrement. |
| Feuille de données | Présentation des enregistrements sous forme d'un tableau. Chaque champ est placé dans une colonne. |
| Formulaire | Présentation à l'écran d'une ou plusieurs tables sous une forme conviviale. |
| Requête | Interrogation de la SGBDR permettant d'extraire des informations. |
| Rapport | Présentation d'une partie ou de l'ensemble des données sous un format imprimable. |
La définition d'une base de données prend maintenant un sens plus large qu'auparavant. Ce n'est plus juste un fichier qui contient de l'information utile pour l'utilisateur. Il contient aussi les requêtes, les formulaires, les rapports, les macros et les modules pour développer une "application" ou un "système" qui répond aux besoins spécifiques de l'utilisateur.
4-Quelles sont les composantes d'OpenOffice Base ?
Contient les champs recueillant les informations. C'est l'objet fondamental de la base de données.
Recherche d'information qui répond à certains critères déterminés par l'utilisateur.
Présentation de l'information à l'écran d'une manière conviviale pour l'utilisateur.
Présentation imprimable de l'information.
5-Création d'une base de données
Pour vous aider à comprendre la création d'une base de données, nous allons montrer les étapes à suivre. Afin d'éviter des répétitions, vous serez amenés à lire d'autres parties du cours, notamment sur les tables et les relations. L'exercice va consister à créer une base de données pour la gestion d'un commerce.
La première étape de la création d'une base de données est l'analyse. C'est d'ailleurs probablement l'étape la plus importante. Si vous passez trop rapidement sur cette étape, vous allez ensuite perdre beaucoup de temps et d'efforts à refaire ce qui aurait dû être accompli auparavant.
Avant de créer votre base de données, il faut avoir une idée claire des informations dont vous aurez besoin.
Une des techniques que vous pouvez utiliser consiste à partir des formulaires et des rapports dont vous aurez besoin. Connaissant les résultats, vous découvrirez quels sont les champs nécessaires pour obtenir ceux-ci.
Vous pouvez également partir de la base de données et déterminer les informations qui sont nécessaires pour les requêtes, les formulaires et les rapports.
Pour les besoins de l'exercice, prenez quelques instants et écrivez sur une feuille les champs que l'on peut retrouver sur une facture. Essayez de trouver autant de champs que vous pouvez.
5.1-Liste des champs
Voici la liste de champs que l'on peut retrouver une facture.
Date, Numéro de facture, Numéro de client, Adresse de facturation du client, Ville, Numéro de téléphone, Numéro de télécopieur, Adresse de courriel, Adresse de livraison, Personne contact, Conditions de paiement, Numéro de produit, Description du produit, Prix unitaire du produit, Quantité achetée, Total pour l'item, Sous total, TVA, Escompte, Bon de commande, Numéro du vendeur, Nom du vendeur, ...
Ouf ! C'est peut être un peu plus que ce à quoi vous vous attendiez.
5.2-Regrouper les informations dans des tables.
Il faut ensuite regrouper toutes ces informations (champs) en entités dans une table ou un "thème" en commun.
Nous allons voir une technique de regroupement des champs dans les tables et ensuite déterminer les relations entre ces tables.
La technique est un peu simpliste mais demande un peu d'expérience.
Le concept est de distribuer les champs dans le plus grand nombre de tables possibles. Cependant certaines règles sont à respecter :
- Regrouper les champs dans les tables qui peuvent être reliées.
- Pas de dédoublement de champs, sauf pour les champs en commun.
- Pas de dédoublement d'entrée d'information.
- Pas de champs calculables dont on peut avoir le résultat avec les informations des autres champs des tables.
Pour pouvoir regrouper les champs dans des tables, il faut se poser un certain nombre de questions :
Quels sont les champs que l'on peut regrouper ensemble ? Quelles sont les opérations accomplies ? Qui utilise quelle information ?
Pour la facture, on retrouve des éléments qui distinguent la facture, le client, les produits et le vendeur. Ce sont les quatre tables qui seront utilisées.
Il faut également s'assurer que les champs sont dans les bonnes tables, qu'il n'y a pas de tables cachées à l'intérieur des autres.
À l'exception des champs en commun qui servent à "relier" les tables, un champ ne devrait pas se retrouver dans plusieurs tables.
5.3-Déterminer les clés primaires
Une clé primaire est un champ (ou une série de champs) qui permet de différencier un enregistrement des autres.
Une clé primaire n'est pas obligatoire pour une table. Elle le devient lorsque vous voulez relier deux tables.
Essayez de déterminer le champ approprié pour une clé primaire pour la table Employe.
Certainement pas le champ sexe. À moins qu'il y ait seulement un homme et une femme dans l'entreprise. Cela limite un peu la croissance de l'entreprise !
Il serait possible d'utiliser le champ Nom de famille tant que deux personnes dans l'entreprise n’ont pas le même nom. Pour régler le problème, il est possible de créer une clé primaire composé de deux champs : Nom de famille et emp_prenom.
Cette clé va fonctionner correctement jusqu'à ce que deux employés aient le même prénom et le même nom. Pour régler ce problème, il est possible de créer une clé primaire composée du nom de famille, du prénom et de la date de naissance. Cette clé primaire va fonctionner correctement jusqu'à ce que ... Cela peut continuer longtemps.
Pour simplifier, vous verrez qu'il est préférable d'avoir un champ nommé Numéro d'employé ou Numéro de sécurité sociale pour distinguer chacun des enregistrements de la table.
Prenez quelques instants pour essayer de déterminer quels champs dans la table seraient appropriés pour être la clé primaire ou être dans la clé primaire. L'explication pour appliquer la clé primaire sur un ou plusieurs champs de la table se trouve dans le cours suivant sur les tables.
5.4-Déterminer les relations entre les tables
Pour qu'une relation soit possible entre deux tables (ou requêtes ou une combinaison des deux), il faut :
- Un champ commun aux deux tables.
- Le même type de champ (Texte avec texte, numérique avec numérique... sauf exception de Interger [INTEGER] avec numérique).
- La même longueur (Pas un champ long de 15 caractères avec un autre long de 50 caractères !).
- Le même genre d'information (Ex : Code d'inventaire avec des codes d'inventaires, Titre avec Titre, ...).
Vous n'êtes pas obligé de relier toutes les tables les unes aux autres. Il est possible d'accéder à une information d'une des tables si les tables sont reliées soit directement, soit indirectement entre elles. Vous trouverez plus de détails sur la page des relations.
5.5-Déterminer les types de relations (cardinalité)
Il existe trois types de relations : un à un, un à plusieurs et plusieurs à plusieurs.
Pour déterminer le type de relation et comment créer des relations vous trouverez de plus amples explications dans le cours sur les relations.
Dans le cas d'une facturation, nous pourrions relier les tables de la façon suivante :
L'image ci-dessus montre la liste des tables avec les champs qui les composent. Les lignes indiquent le type de relation entre les tables.
La relation de types plusieurs à plusieurs requiert une table intermédiaire composée, au minimum de la clé primaire des deux tables à relier. C'est la raison d'être de la table Transition_Fact-Stock.
6-La normalisation et les formes normales
L'avantage d'une base de données relationnelle est d'éviter au maximum les répétitions ou les redondances d'information.
La normalisation sert à séparer la liste des champs en plusieurs tables pour avoir une base de données plus efficace.
Il s'agit de retirer progressivement les quelques problèmes que l'on retrouve dans les bases de données pour pouvoir afficher la base de données sous différentes formes normales (1ère, 2ème, 3ème ...).
Pour le moment, nous allons seulement regarder les trois premières formes normales.
6.1-Première forme normale : répétition des données
Pour atteindre la première forme normale, il faut éliminer les groupes répétitifs en les séparant en plusieurs tables. Le travail à accomplir est d'éviter complètement les répétitions d'entrée de données.
| ID_Facture | ID_Produit |
|---|---|
| 1 | 1, 3, 5 |
Nous pouvons avoir plusieurs numéros de produits pour une même facture. Ce qui implique une redondance de saisie de données et cela ne correspond pas à une forme appropriée de conservation d'informations dans une base de données relationnelle.
En effet, si nous devions modifier un numéro de produit, nous devrions répercuter cette modification sur l'ensemble des enregistrements de toutes les factures dans la table Facture. Vous convenez que ce travail est fastidieux et peut être source d’erreurs. Nous devons donc placer le champ ID_Produit dans une table autre que Facture.
Le test de la deuxième forme normale va s'assurer que les champs sont à la bonne place.
Il faut donc s'assurer que l'utilisateur ne saisisse pas plusieurs fois la même information.
En effet, nous devons saisir les informations sur le client pour chaque facture du client. Pas vraiment efficient ! C'est pour cette raison que nous devons "séparer" la liste des champs dont nous avons besoin dans plusieurs tables pour avoir une saisie simplifiée des données.
La même situation se répète pour les informations sur le vendeur. Nous devrions donc avoir les tables composées de la manière suivantes
- Facture: ID_Facture, date, bon de commande, escompte.
- Client: ID_Client, adresse de facturation, ville, numéro de téléphone, numéro de télécopieur, adresse de courriel, adresse de livraison, personne contact, escompte, conditions de paiement.
- Employe: ID_Vendeur, nom, prénom, poste, bureau, salaire, commission, embauche.
- Stock: ID_Produit, description, prix unitaire, quantité disponible.
Nous devons ensuite déterminer la clé primaire pour chaque table. Cela est nécessaire pour la seconde forme normale. Une clé primaire est un champ (ou une série de champs) qui permet de distinguer un enregistrement des autres. Pour la table Facture, la clé primaire sera le champ ID_Facture.
En effet, le contenu de tous les autres champs de la table peut se répéter, ce qui serait contraire à la définition d'une clé primaire.
6.2-Deuxième forme normale: Dépendance directe à la clé primaire
Pour passer à la deuxième forme normale, nous devons préalablement avoir passé le test de la première forme normale. Nous devons maintenant éliminer les dépendances partielles. Cela veut dire que nous devons nous assurer que tous les champs de la table dépendent de la clé primaire de la table. Sinon, nous devrons créer une nouvelle table ou déplacer le champ.
Le problème à ce niveau est le champ Quantité achetée. Il dépend en même temps du numéro de facture et du numéro de produit. Une facture peut avoir plusieurs produits. Mais un produit peut aussi se retrouver sur plusieurs factures. Il y a donc une relation de plusieurs à plusieurs entre ces deux tables.
Ce qui nous amène aux tables composées de la manière suivante :
- Facture: ID_Facture, Date, bon de commande, escompte.
- Client: ID_Client, adresse de facturation, ville, numéro de téléphone, numéro de télécopieur, adresse de courriel, adresse de livraison, personne contact, escompte, conditions de paiement.
- Employe: ID_Vendeur, nom, prénom, poste, bureau, salaire, commission, embauche.
- Stock: ID_Produit, description, prix unitaire, quantité disponible.
- Transition_Fact-Stock: ID_Facture, ID_Produit, quantité achetée.
Vous remarquez que la clé primaire de cette table est composé de deux champs : fact_id et Numéro de produit. Ce sont aussi les clés primaires des tables Facture et Stock.
| ID_Facture | ID_Produit | Quantité achetée |
|---|---|---|
| 1 | 1 | 10 |
| 1 | 2 | 25 |
| 2 | 1 | 50 |
| 2 | 2 | 100 |
Dans cette table, un même numéro de facture et un même numéro de produit peuvent être utilisé plusieurs fois.
6.3-Troisième forme normale: Dépendances partielles de la clé
Pour la troisième forme normale, il s'agit d'éliminer les dépendances transitives. C’est-à-dire qu'il faut s'assurer qu'il n'y ait pas de tables qui soient cachées parmi les autres.
De cette manière, les tables ne devraient jamais contenir de champs calculés.
Il est possible d'avoir le "Sous total" en multipliant les "Quantité vendue" par les "art_pu".
Donc, il est inutile de le saisir dans les tables.
La troisième étape consiste à déterminer les relations entre les différentes tables. Nous devons réfléchir à quelles sont les relations possibles entre les entités.
Pour pouvoir relier deux tables, celles-ci doivent avoir au moins un champ en commun. Nous pouvons relier une facture à un client par le champ "N° Client". Ou encore, relier un produit à une facture par le champ "N° Produit" etc.
Vous devriez, dans ce cas, vous apercevoir que certains champs seraient mieux placés dans une autre table.
Une fois que vous avez réalisé les regroupements et déterminé les relations, vous avez votre base pour la création des tables.
Maintenant que vous avez les entités et les champs qui les composent, imaginez à quoi devrait ressembler vos formulaires et vos rapports. Est-ce que les champs que vous avez choisis répondent à tous vos besoins ?
Prenez tout le temps nécessaire pour l'analyse. Il vous coûtera beaucoup plus de temps et d'effort si vous passez trop rapidement à la création et oubliez des éléments importants.
Maintenant que vous avez créé la base de données, il ne reste qu'a créer les tables, saisir les données, créer les requêtes, les formulaires, les rapports, les macros et les modules pour votre base de données.