Les besoins de base de données

I. Exemples classiques d’applications BD  

• Gestion des cours, inscriptions, étudiants, personnels, …. D’une université 
• Gestion des commandes 
• Gestion des comptes clients d’une banque

• Système de réservation 

II. Les besoins de base de données

–Pour décrire les données…

–Pour Mettre à jour les données…

 –Pour interroger les données…

–Pour sécuriser la base de données… 
 

1. Besoins de description 

• Décrire les informations concernant l’application (trains, billets et arrêts) sans mentionner une solution informatique spécifique

– modélisation conceptuelle  
• Module : conception de systèmes d’informations 
• Rédiger une description similaire pour le stockage des informations dans le Système de Gestion de Base de Données (SGBD) sélectionné

– modélisation logique langage de description de données (LDD) 
• Module : base de données 

2. Besoins de création / modification des données 
• Établir la base de données initiale avec les informations représentant le réseau de transport

– langage permettant l’insertion de données 
• Générer progressivement les informations sur les réservations

– Pouvoir modifier (et éventuellement supprimer) toute donnée déjà rentrée 
• langage de manipulation de données (LMD) (insertion, modification, 
suppression)

3. Besoin d’interrogation  
• Répondre à toute requête concernant les informations présentes dans la base de données.  
Par exemple  
a) Mohamed va-t-il une réservation pour aujourd’hui ?

– Si oui, donner les infos sur cette réservation 
b) Quels sont les horaires des trains de Jendouba à Tunis entre 9h et 20 le dimanche ? 
c) Donner les destinations au départ de Tunis sans arrêt intermédiaires. – langage de requête (langage d’interrogation) 
4. Besoins d’exactitude / cohérence 
• Il est nécessaire de formuler toutes les règles qui limitent les valeurs pouvant être enregistrées afin d’éviter toute erreur détectable 
Par exemple : 
• Il ne faut jamais attribuer le même siège dans le même train à deux clients. 
• La date de réservation pour un train doit coïncider avec un jour de circulation de ce train. 
• L’heure de départ d’une gare doit être ultérieure à l’heure d’arrivée à la gare de destination. 
• L’heure d’arrivée à un arrêt doit être après l’heure de départ du précédent arrêt.

– Langage d’expression de contraintes d’intégrité 
5. Besoins de garantie 
• Il ne faut pas que les données (par exemple, les réservations) soient perdues en raison d’un dysfonctionnement quelconque : erreur de programmation, panne système, défaillance de l’ordinateur, coupure de courant, etc. – Garantie de fiabilité 
• Il ne doit pas arriver qu’une action effectuée pour un utilisateur (par exemple, l’enregistrement d’une réservation) soit annulée en raison d’une autre action réalisée simultanément pour un autre utilisateur (réservation du même siège) – Garantie de contrôle de concurrence 
6. Besoins de confidentialité 
• Toute donnée doit être sécurisée contre l’accès de personnes non autorisées. 
– En lecture

– En écriture 
 
Interdire par exemple aux clients de changer les numéros de trains, les horaires ou leurs réservations.

– garantie de confidentialité