OpenOffice Base

Introduction

Avant de commencer, regardons quelques-uns des avantages d'une base de données relationnelle.

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.

Ex : Date, Numéro de facture, Numéro du vendeur, Numéro du produit, Quantité vendue, Prix unitaire, Description du produit, Sous total, Taxes, Total ...
Voici quelques-unes de ces données dans une BD simple.
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.

Les données pourraient être divisées dans une BD relationnelle.
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.

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.

Quelles sont les composantes d'OpenOffice Base ?

bouton tablesContient les champs recueillant les informations. C'est l'objet fondamental de la base de données.

bouton requêtesRecherche d'information qui répond à certains critères déterminés par l'utilisateur.

bouton formulairesPrésentation de l'information à l'écran d'une manière conviviale pour l'utilisateur.

bouton rapportsPrésentation imprimable de l'information.

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.

Ex : informations sur mes clients, sur mes fournisseurs, sur mon inventaire, sur mon personnel, etc.

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.

Ex : il faut connaître les quantités vendues et à quel prix unitaire avant de connaître le total des ventes.

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.

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.

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.

Ex : est-ce que le champ "Escompte" ou "Conditions de paiement" ira dans l'entité (table) "Facture" ou "Client" ?

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 :

Ex : Total = Qté * Prix unitaire

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.

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.

Ex : bien qu'il puisse y avoir plusieurs factures avec la même date, la même quantité achetée, le même client ou le même vendeur, il n'y aura pas deux factures avec le même numéro de facture.

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.

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 :

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.

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 :

relations entre toutes les tables

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.

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.

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.

Ex : une facture peut contenir plusieurs produits.
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.

Ex : cela ne serait pas efficace d'avoir une table "Facture" qui contienne également les champs "Nom du client", "Adresse de livraison", "personne contact".

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

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.

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 :

Ex : la table Transition_Fact-Stock joue le rôle d'intermédiaire entre les tables Facture et Stock pour éviter une saisie redondante et surtout permettre une relation entre les clés primaires des deux tables.

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.

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.

Ex : les champs "Sous-total", "Total" ou "TVA" ne devraient pas apparaître dans les tables puisqu'il est possible de les calculer à partir des données qui sont déjà dans les tables.
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'à 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.

Dernière modification : 31/07/2024 14:53:21