Système Ďinformation Et Bases de Données

Système d’Information
et Bases de Données
Sara AREZKI
Année universitaire 2017/2018

Objectifs du cours
 Comprendre les différents concepts liés à la notion des systèmes
d’information
 Identifier dans un contexte donné les différents acteurs et leurs tâches
 Maitriser les principales étapes de conception d’une base de données
relationnelle
 Connaître les progiciels permettant la conception et la gestion d’une base de
données relationnelles
 Connaître les principales étapes de conception, de développement et de
réalisation d’un système d’information
Prérequis:
 Accès à un atelier de génie logiciel
× Pas de compétences particulières
SI et BD - Sara AREZKI 2
Partie 1
Les Systèmes d’Information
Sommaire
1. Notion d’information
2. Notion de système d’information
3. Rôles du SI
4. Analyse et conception d’un SI
5. Méthodologie
6. Cycle d’abstraction
Notion d’information
 Une information, c’est une donnée qui a un sens pour celui qui en a
besoin.
1234 AA 56
Le modèle est inconnu,

le sens est plus difficile à
percevoir ou incomplet
Le modèle est connu,

l’interprétation donne
du sens aux données
L’information est un facteur de production
presque comme les autres
 L’information a une valeur, variable selon son importance, son
ancienneté…
 L’information doit être
 extraite,
 stockée,
 traitée,
 maintenue…
 c’est la tâche du système d’information !
L’information est omniprésente ….
 L’ordinateur n’est qu’un

élément parmi beaucoup
d’autres. Tout élément est
susceptible de produire,
consommer ou véhiculer de
l’information !
7
Notion de système d’information
contraintes
Flux de décisions
Système de
pilotage
Flux d’informations Système d’information
Entrées Sorties
Système opérationnel
Les parties prenantes du SI
Personne, machine, logiciel…

producteur ou consommateur Le gestionnaire L’informaticien
d’information du SI (interne ou externe)
Interne Externe
 Simple opérateur  Client  Responsable de  Analyse des besoins
 Cadre  Fournisseur la cohérence du SI,  Programmation
 Directeur  Administration
de son évolution, de  Déploiement des
la sécurité, de la solutions
 Actionnaire  Organisme
formation des
 Propriétaire financier utilisateurs, des
… … procédures, de
l’interopérabilité…
Différents niveaux d’utilisation d’une
même information
SP
01000100101001
010001001010011100110101
010001001010011100
010001001010011100110
SI
EDI
SO
SI, pour quoi faire ?
 Différentes missions du SI
 Collecter (sources externes et internes)

 Saisie, numérisation
 Extraction, veille
 Stocker
 Supports divers et multiples
 Indexation, mots clés, thesaurus…
 Maintenir en état d’utilisation sur une période longue
 Traiter
 Produire des informations sous la forme appropriée aux besoins de l’utilisateur
 Restituer, diffuser (sous différentes formes)
 Électronique ou papier
 Importance des formats de fichiers
 Supports de communication (filaire, non-filaire…)
SI et fonctions de l’entreprise
SI, processus métier et workflow
 Le SI sert de support de communication entre les

différentes fonctions de l’entreprise mais aussi avec ses
partenaires
 La recherche d’une standardisation, normalisation

aboutit au découpage des tâches en tâches
élémentaires appelées processus métier (ou
opérationnel)
 Les processus, une fois modélisés, pourront être pris en

charge par un moteur de workflow qui permettra
d’automatiser certaines tâches en fonction
d’événements prédéterminés
Exemple de concept de SI : la FSTS
 Flux physique: Etudiants, examens, concours,

enseignants, départements
 Flux d’information : Nom, prénom, date de naissance,

code massar
 Flux de décision: Nombre d’étudiants admis, seuil

d’admissibilité, règlement intérieur, …
Exemple de concept de SI : la RAM
 Flux physique: avions, réservations, trajets, …
 Flux d’information : détail vol: Heure départ, heure

arrivée, destination, source, …
 Flux de décision: Grille tarifaire, nouvelles lignes,…
Comment conceptualiser un bon système
d’information
Années 70  Les approches cartésiennes
 Les approches systémiques

Années 80
 les approches objet

Années 90
d’information
d’information
définition
des besoins
MODELE EN CASCADE
conception
implémentation
tests
utilisation
maintenance
d’information
MODELE EN V
définition
validation
des besoins
conception test
du système du système
conception test
des composants des composants
codage
d’information
MODELE EN SPIRALE
La méthode Merise: Introduction
 Un bibliothécaire vous demandes, de lui automatiser la gestion de sa

bibliothèque.
 Il a un ordinateur que lui seul l’utilise, et il veut une simple application

avec MS Excel ou bien MS Access.
La méthode Merise: Introduction
Quoi faire Qui fait

Avec quoi?
? quoi ?
Bibliothécaire: Il
vous demande de lui Bibliothécaire: Il a
automatiser la un ordinateur que
gestion de sa lui seul l’utilise.
bibliothèque.
Technicien: Vous
Technicien: Vous
allez lui créer une
allez lui demander
application avec
des informations.
Excel ou Access.
La méthode Merise: Approche générale
 Merise est une méthode d’analyse informatique et une démarche

de construction des systèmes d’information(SI).
 Elle s’est apparu à la fin des années 1970(78/79), développée par

une équipe de spécialistes informaticiens dirigée par H.Tardieu.
 Elle se base sur un ensemble de signes graphique pour représenter

un modèle.
La méthode Merise: Approche générale
 Elle permet de faire un lien de communication entre les différents

acteurs d’un projet.
 La méthode Merise se base sur la démarche 3 découpages sur 3

niveaux.
La méthode MERISE (Principes de base)
 Passage par différentes étapes :

Système d ’Information Manuel
Expression des besoins
Modèle Conceptuel
Modèle Logique
Modèle Physique
SI et BD - Sara AREZKI
Système d ’Information automatisé
25
La méthode MERISE (Principes de base)
 Expression des besoins
 définition des attentes du S.I. automatisé
 inventaire des éléments nécessaires au S.I.
 délimitation du système en s ’informant auprès des futurs utilisateurs.
 Modèle Conceptuel
 Modèle organisationnel ou logique
 Modèle physique
 choix logiciel pour le système d ’information
 choix matériel pour le système d ’information
La méthode MERISE – Approche par
niveau / par étape
 Démarche par niveaux : formalise le système futur :
 en contribuant à la stratégie de l ’entreprise,
 en mettant en œuvre les règles de gestion
 en tenant compte des aspects organisationnels et techniques.
 Démarche par étapes : hiérarchise les décisions au cours de la vie du

projet :
 conception,
 développement
 mise en œuvre
 généralisation de l ’emploi du S.I. futur
 évolution du S.I. futur.
La méthode MERISE – Approche par
niveau / par étape
 Intérêts de cette double approche :

 maîtrise des risques (coûts, délais, personnel,…)
 favorise l ’introduction de nouvelles technologies
 facilite l ’évolution des S.I.
La méthode MERISE – Trois niveaux de
modélisation
 Niveau Conceptuel :
 réponse à la question QUOI ? (ce que fait l’entreprise)
 que faire ? Avec quelles données ?
 Modèle Conceptuel des Données (MCD)
 Modèle Conceptuel des Traitements (MCT)
 Niveau organisationnel :
 réponse aux questions QUI, QUAND, OÙ ?
 Modèle logique des données (MLD)
 modèle organisationnel des traitements (MOT)
La méthode MERISE – Trois niveaux de
modélisation
 Niveau physique ou opérationnel:

 réponse à la question COMMENT ? (quels sont les moyens de le faire)
 intégration des moyens techniques, matériels et logiciels
 modèle physique des données (MPD)
 modèle opérationnel des traitements (MPT)
La méthode MERISE – Chronologie des
étapes
Etude de l ’existant 50%
Recueil des informations
Niveau
MCD MCT
Conceptuel
25%
MOT
Niveau
Logique
Validation
10%
MLD
Niveau Modèle Physique des Données 15%

SI et BD - Sara AREZKI physique Modèle Opérationnel des traitements 31
La méthode MERISE – Chronologie des
étapes
Partie 2
Les Bases de Données
Sommaire
1. La structuration des données

2. L’approche base de données
3. Les systèmes de gestion de base de données
4. La modélisation des données
5. Le modèle entité-relation
La structuration des données
 Structure en mémoire centrale (MC)

 Fichiers
 Bases de données
Structure en mémoire centrale
 Principes
 Stockage des données dans la mémoire volatile d’un
ordinateur
 Problèmes
 Stockage temporaire
 «Petits» volumes de données
 Langages de programmation
 Contexte mono-processus (mono-utilisateur en général)
Structure en fichier
 Stockage persistant sur disque
 «Gros» volumes de données
 Langages de programmation et SGF
 Contexte mono-utilisateur (en général)
Approche fichier avec PC
Direction des études Bibliothèque Service social
Appli Appli Appli

En Cobol en Java en C
Fichiers Elèves Fichiers Elèves Fichiers Elèves

et UVs et Livres et Chambres
Système de gestion de fichiers
Application bibliothèque
Programme 1
Description du fichier des Elèves
Edition du fichier Elèves
par ordre alpha
*2
Programme 2
Description du fichier des Elèves
Mise à jour du fichier Elèves
SGF Fichier Elèves
via nom élève
Problèmes de l’approche fichier
 Difficulté à saisir les liens entre les données

 Pas de partage de données entre les utilisateurs
 Pas de vision globale des données
 Redondance des données
 Risque d'incohérence des données
 Pas d'indépendance entre les données et les traitements
 Problème de gestion de la sécurité des données
 Multiplicité des traitements, des langages, des matériels
Les Bases de données
 Stockage persistant sur disque
 «Très gros» volumes de données
 Langage de requêtes et langages de programmation SGBD
 Contexte multi-utilisateurs
Approche centralisée
PC Windows BD
Appli C
Elèves
Uvs
Appli Cobol Appli Java
Livres
Chambres
PC SGBD
NT
Description
BD
PC Linux
Terminaux
42
Approche client/serveur
PC Windows BD
Appli Cobol Elèves

Uvs
Livres
SGBD Chambres
PC
Appli Java
NT
Description
BD
Appli C
PC Linux
43
Apport d’une approche base de données
 Intégration :
 Description unique et globale des données
 Eviter les redondances
 Eviter les incohérences
 Indépendance :
 Indépendance entre données et traitements
 Séparation entre les descriptions logiques et physiques des
données
Apport d’une approche base de données (2)
 Sécurité :
 Contrôle sémantique des données
 Protection contre les accès non autorisés
 Protection contre les pannes
 Facilités pour l’utilisateur :

 Partage des données
 Vision « haut niveau » et « personnalisée » des données
 Manipulation « aisée » des données
 Accès efficaces aux données
 Répartition des données et des traitements
Bases de données et Systèmes de
gestion des bases de données
 BD :
 Collection de données décrites selon un certain modèle
 SGBD :
 Système logiciel gérant les données d’une BD, selon un
modèle fixé
 Un SGBD doit permettre la définition, la manipulation et le
contrôle des données
SGBD – Système de Gestion des Bases de
Données
 Système de Gestion de Bases de Données

 Logiciels ou ensemble de logiciels permettant l’utilisation
efficace de Bases de Données :
 Définition
 Construction
 Manipulation
 Partage
 Protection
SGBD: Bref historique
 Première présentation officielle de l’approche relationnelle: E.F. Codd

(IBM) 1970
 Premiers prototypes de SGBD: Système R d’IBM et INGRES à Berkeley
 Premier langage de requêtes:

 SEQUEL (qui deviendra SQL) pour le système R 1974
 Premiers SGBD relationnels commerciaux

 ORACLE (1979)
 SQL/DS IBM (1981)
 INFORMIX, DB2, UNIFY, …
Objectifs du SGBD
 Garantir la qualité des données enregistrées : ex- retrouver les données des commandes
passées
 Garantir la cohérence des données : ex- le client de chaque commande est il répertorié?
 Permettre à plusieurs utilisateurs d’accéder aux données simultanément
 Protéger les données en cas d’incident
 Contrôler l’accès aux données confidentielles
 Offrir de bonnes performances d’accès
La modélisation des données
 Modèle de données :
 Ensemble de concepts pour décrire :
 Les données
 Les liens entre les données
 La sémantique des données
 En général, un ensemble d’opérations est associé pour manipuler les
données
 Exemples de modèles :
 Entité/association
 Hiérarchique/réseau
 Relationnel
 Objet, relationnel-objet
Modèle Entité/Association [Chen 76]
code nbH coord
UV
1,n
num
note S’inscrire
3,n nom
Élève
0,n 0,1 age
adresse
datePrêt Emprunter Louer
côte 0,1 1,1 no

Livre Chambre
titre prix
Modèle Entité/Association - 2
Livre
0,1
cote
Emprunter
Eleve titre
UV 0,n datePret
S’inscrire num
code 1,n 3,n
nom
nbH note Louer
age 0,1
coord
adresse Chambre
1,1 no
prix
Critique du modèle Entité/Association
 Avantages Inconvénients
 Sémantique riche  Uniquement un modèle de
 Extension aux concepts description de données
objets (héritage, ...)  Pas de langage de
 Aspect visuel manipulation associé
 Pas de SGBD E/A
 Modèle de conception de
BD  Pas un modèle
d’implantation de BD
Le modèle hiérarchique
 Système IMS d’IBM conçu à la fin des années 60 pour le programme Appolo
(NASA)
 Exemple
Élève UV
Livre UV Chambre Elève
Le modèle hiérarchique
 Schéma BD
 Structure arborescente (forêt)
 BD
 Collection d’enregistrements reliés par des pointeurs
 Langage de manipulation
 Navigationnel et procédural
 Utilisation de pointeurs
 (Exemple du langage DL/1 du système IMS)
 Problèmes :
 Pas d’indépendance logique/physique
 Redondance des données, risques d’incohérence
Le modèle réseau
 Modèle défini par le groupe DBTG du comité CODASYL en 1971 (revu en 1978)
 Exemple
Élève UV
Livre Chambre Inscrit
Le modèle réseau
 Schéma BD
 Structure de graphe orienté acyclique (DAG)
 BD
 Collection d’enregistrements reliés par des pointeurs
 Navigationnel et procédural, Standard CODASYL 71, 78
 Utilisation de pointeurs
 Systèmes
 IDS2 d’Honeywell (1975), Total de Cincom (1974), Adabas de Soft. Ag (1978)
 Problèmes
 Pas d’indépendance logique/physique
Le modèle relationnel
 [CODD 70] « A Relational Model for Large Shared Data Banks »

 Exemple
Élève(num, nom, adresse, age)

UV(code, nbH, coord)
Inscrit(numElève, codeUV, note)
Livre(côte, titre, numElève, datePrêt)
Chambre(no, prix, numElève)
Le modèle relationnel (2)« MLD » Ecole
LIVRE
COT E
NUM
ELEVE T ITRE
UV INSCRIT NUM DATEPRET
CODE CODE NO
NBH NUM NOM
COORD NOTE AGE CHAMBRE
ADRESSE
NO
NUM
PRIX
Le modèle relationnel
 Schéma BD
 Structure de relation
 BD
 Ensemble d’enregistrements reliés par des valeurs
 Ensembliste, Déclaratif
 Standard international [ SQL 86, 89, 92 ou SQL2]
 Prototypes de recherche
 System/R chez IBM (1976), Ingres à Berkeley (1976)
 Systèmes commerciaux
 SQL/DS et DB2 d’IBM (1982), Oracle (1983), Ingres (1983), Informix (1981),
Sybase (1984), SqlServer (1998)
 MySQL (1995), Access
Avantage du modèle relationnel
 Indépendance logique/physique
 Langage de manipulation simple
 Basé sur une théorie mathématique solide
 Standard
La conception d’une base de
données
Sommaire
1. La conception d’une base de données

2. Les étapes de conception d’une base de données
3. Le dictionnaire des données
4. Les formes normales
5. Le modèle conceptuel de données
6. Les règles de normalisation
7. Le modèle logique de données
8. L’algèbre relationnel
Conception d’une base de données
 Modélisation conceptuelle indispensable avant la conception d’une

application de base de données
 Plusieurs Méthodes
 Entité/Association
 Merise
 Booch
 OMT (Object Modeling Technique)
 UML
Etapes de conception d’une BD
 Analyse du besoin : construction du dictionnaire des données
 Structuration des données : détermination des entités et associations
 Construction du schéma de la base de données : mise en relation des entités
 Mise en œuvre dans un SGBD
Le Dictionnaire des données -1-
Pour être traitées de manière informatisée, les données

doivent être décrites dans un formalisme compris par le
système informatique qui va les gérer. Les formats
génériques utilisés sont:
 Le type alphabétique (rien que des caractères)
 Le type alphanumérique (des caractères, des chiffres)
 Le type numérique (les nombres)
 Le type date
 Le type logique (0-1, Vrai-Faux, Oui-Non)
Le Dictionnaire des données -2-
Le dictionnaire des données est un document qui permet

de recenser, de classer et de trier les informations (les
données) collectées lors des entretiens ou de l’étude des
documents.
Le Dictionnaire des données – cas pratique-
Le Dictionnaire des données – cas pratique-
Les dépendances fonctionnelles
 Une donnée B dépend fonctionnellement (ou est en dépendance

fonctionnelle) d’une donnée A lorsque la connaissance de la valeur de
la donnée A nous permet la connaissance d’une et au maximum une
seule va leur de B.
 Exemple: la connaissance de la valeur d’un numéro de client nous

permet de connaître sans ambiguïté la valeur d’un et d’un seul nom
de client.
 Formalisme: Le formalisme de représentation

d’une dépendance fonctionnelle est le suivant:
 Numéro adhérent  (Nom adhérent, prénom, adresse,

code postal, ville, téléphone, email)
 Dépendances fonctionnelles composées: Une

dépendance fonctionnelle qui comporte plusieurs
attributs est dite composée.
 Exemple:
 (Code athlète, code sport)  (année de pratique)
 (Numéro coureur, Numéro de course)  (Temps)
 Connaissant le n° de coureur et le n° de la course, nous
connaissons de façon certaine le temps chronométré d’un
coureur précis sur une course précise.
 Dépendances fonctionnelles élémentaire: Une dépendance fonctionnelle

AB est élémentaire s’il n’existe pas une donnée C, sous-ensemble de A,
décrivant une dépendance fonctionnelle de type C.
 Exemple:
 RéférenceProduit  Désignation
 NuméroCommande, RéférenceProduit  Quantité
 NuméroCommande, RéférenceProduit  Désignation
 La troisième dépendance fonctionnelle n’est élémentaire car il existe à

l’intérieur d’elle: RéférenceProduit  Désignation qui était déjà une
dépendance fonctionnelle élémentaire. Pour connaître la désignation,
Numéro de commande est dans ce cas superflu.
 Dépendances fonctionnelles élémentaire directe: on dit que la dépendance

fonctionnelle A B est directe s’il n’existe aucun attribut C tel que l’on puisse
avoir A  C et C  B. En d’autres termes, cela signifie que la dépendance entre
A et B ne peut être obtenue par transitivité.

 Exemple:
 NumClasse  NumElève
 NumElève  NomElève
 NumClasse  NomElève
 La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire:
NumClasse  NumElève  NomElève
Le graphe de dépendances fonctionnelles
 Le graphe des dépendances est une étape intéressante car il

épure le dictionnaire en ne retenant que les données non
déduites et élémentaires et permet une représentation spatiale
de ce que sera le futur MCD.
Numéro adhérent
Nom adhérent prénom adresse CP VILLE Email
Méthodologie d’élaboration des DF
 L’élaboration des dépendances fonctionnelles est réalisée

à l’aide du dictionnaire des données. La démarche
consiste à chercher :
 Les dépendances fonctionnelles formées par deux rubriques,
élémentaires et directe.
 Les dépendances fonctionnelles composées.
Dépendances fonctionnelles: – cas pratique-
 NumCli  (Nom, Prénom, Adresse, Code Postal, Ville)
 CodeArticle  (Désignation, Prix unitaire)
 (NumCli, CodeArticle, Date)  Quantité
CodeArticle Date NumCli
Qté
Désignation Prix Nom Prénom Adresse CP Ville
Le modèle conceptuel de données: MCD
 Le modèle conceptuel de données est un modèle qui nous permet de

concevoir le schéma de données utilisables dans notre SI.
 Il se situe dans l’intersection du découpage des données avec le niveau

conceptuel.
 Il introduit la notion d’entités, de relations et de propriétés.
 Il décrit de façon formelle les données utilisées par le SI.
 Les éléments de base d’un MCD :

 Les propriétés.
 Les entités.
 Les relations.
 Les propriétés: sont les informations de base qui décrivent les

éléments(les entités) d’un SI.
 Exemple: Le numéro client, nom clients, prénom client, adresse client sont des
propriétés qui décrivent l’élément(l’entité) Client.
 Chaque propriété dispose d’un type(alphabétique, alphanumérique,

numérique, date, logique,…).
Le MCD: Les entités
 Les entités: Une entité est la représentation d'un élément dans un SI.
 Chaque entité regroupe un ensemble de propriétés.
 La représentation d’une entité s’appelle une occurrence de l’entité.
 Exemple d’une entité:
Le MCD: L’occurrence
 Exemples d’occurrences d’une entité:
 Question: dans les occurrences précédentes de l’entité Client, est-ce

qu’il est possible d’avoir 2 occurrences avec le même nom et prénom?
C’est-à-dire, avoir 2 clients différents mais avec le même nom et prénom!
 La réponse : est oui !!!
Le MCD: L’identifiant
 L’identifiant est une propriété qui permet de connaître de façon unique

et sûre les occurrences d’une entité donnée.
 Explication: Dans la question de l’exemple précédent, nous allons ajouté

une propriété au début de l’entité qui s’appelle numéro client(ce numéro
doit être unique) pour faire la différence entre deux occurrences qui
peuvent avoir le même nom et prénom.
 Exemple d’une entité avec identifiant:
 Exemple d’occurrences avec identifiant:
Le MCD: La relation ou l’association
 Une relation ou association est la liaison qui lie entre les entités du SI.
 Exemple: Un client peut commander des produits.
 Les entités de notre SI sont : Client et Produit.

 La relation est Commander.
Le MCD: La relation ou l’association
 Le MCD de l’exemple est le suivant :
Le MCD: Les cardinalités
 Une cardinalité est le nombre de fois où l’occurrence d’une entité

participe aux occurrence de la relation.
 Dans notre exemple nous devons poser les questions suivantes:

 Combien de fois au minimum un client peut commander un produit ?
 Combien de fois au maximum un client peut commander un produit ?
Cardinalité maximale
1,n
Cardinalité minimale
 Il faut poser les mêmes questions pour l’entité Produit :
 Un produit peut-être acheté au minimum par combien de clients ?

 Un produit peut-être acheté au maximum par combien de clients ?
1,n 0,n
 Notions sur les cardinalités:
 La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu’une o

ccurrence d’une entité participe aux occurrences d’une relation.
 La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu’une oc

currence d’une entité participe aux occurrences de la relation.
 Exercice:
 Nous voulons créer un MCD complet qui représente l’élevage des femmes pour
les enfants.
 Une femme est représenter par son nom et son prénom, les enfants aussi.
 Corrigé:
MCD : Représentation graphique
Le MCD: Rappels
 Analyse et conception pour créer des bases de données.

 Il faut utiliser des modèles : Modélisation.
 Méthode Merise : contient plusieurs modèles.
 MCD -> MLD -> MPD (Base de données).
 MCD:
◦ Entité -> propriétés.
◦ Associations.
◦ Cardinalités.

Le MCD: Rappels
 MCD:
 Occurrence exemple d’une Entité.
 Cardinalités : minimal 0 ou 1;
 maximal 1 ou n;
 Une entité doit obligatoirement avoir un identifiant qui doit être
souligné sur le MCD.

Exercice
Un médecin fixe le prix de sa consultation tous les ans. Son carnet

de consultations indique ses rendez-vous. A chaque consultation, il
reçoit un ou plusieurs malades s'ils sont de la même famille.
L'examen clinique lui permet de détecter les symptômes
(température, mal de tête, fréquence cardiaque élevée, souffle au
coeur, …...) et de diagnostiquer une ou plusieurs maladies ou
pathologies (rhume, crise de foie, spasmophilie, acouphènes,
hypoglycémie...). A chaque maladie peuvent être associés un ou
plusieurs symptômes. Cette même maladie peut être diagnostiquée
plusieurs fois, à chaque consultation.

Corrigé

Pourquoi normaliser?
1. Normaliser un schéma relationnel c'est le remplacer par un
schéma équivalent où toutes les relations vérifient
certaines propriétés.
2. Ces propriétés sont basées sur l'analyse des dépendances
fonctionnelles à l intérieur de chaque relation.
La normalisation est utile :

 pour limiter les redondances de données,
 minimiser l’espace de stockage
 pour limiter les pertes de données,
 pour limiter les incohérences au sein des données
 pour améliorer les performances des traitements. éviter les
problèmes de mises à jour.

MCD: Les règles de Normalisation -1-
Un bon schéma entités-associations doit répondre à

9 règles de normalisation, que le concepteur doit
connaître par cœur.

MCD: Les règles de Normalisation -2-
1. Normalisation des entités (importante) : toutes les entités qui sont

remplaçables par une association doivent être remplacées.
2. 2. Normalisation des noms : le nom d’une entité, d’une association
ou d’un attribut doit être unique.
3. . Normalisation des identifiants : chaque entité doit posséder un
identifiant.
4. Normalisation des attributs (importante) : remplacer les attributs en
plusieurs exemplaires en une association supplémentaire de
cardinalités maximales n et ne pas ajouter d’attribut calculable à
partir d’autres attributs
5. Normalisation des associations (importante) : il faut éliminer les
associations fantômes redondantes ou en plusieurs exemplaires
6. Normalisation des cardinalités : une cardinalité minimale est
toujours 0 ou 1 (et pas 2, 3 ou n) et une cardinalité maximale est
toujours 1 ou n (et pas 2, 3, ...).
MCD: Les règles de Normalisation – Règle n°1


Par exemple, sur la ci-dessus la quantité commandée dépend à la fois du

numéro de client et du numéro d’article, par contre la date de commande
non. Il faut donc faire une entité commandes à part.

les cardinalités sont toutes 1,1 donc c’est une association fantôme

MCD: Les règles de Normalisation –3-
A ces 6 règles de normalisation, il convient d’ajouter les 3

premières formes normales traditionnellement énoncées
pour les schémas relationnels, mais qui trouvent tout aussi
bien leur place en ce qui concerne les schémas entités-
associations.

La première forme normale
Définition : Dans une entité, toutes les propriétés sont élémentaires et il existe au
moins une clé caractérisant chaque occurrence de l’objet représenté.
Le MCD est dit en 1FN si toutes ses entités et relations sont en première forme
normale.

Exemple 1 : Passage en première forme normale d’une

entité non normalisée
Pièce
NPIECE
LIBPIECE
PUNIT
QTITEC
L’entité Pièce n’est pas normalisée.

L’entité pièce devient :
Pièce Contenir Commande

0, n 1, n N° commande
N° Pièce QTITEC
Libellé pièce
Prix unitaire

Exemple 2 : Passage en 1FN d’une relation non normalisée
Commande Client
NCDE 1, 1 Concerner NCLI
1, n
DATEC QTITEC NOMCLI
La relation « Concerner » n’est pas en 1FN.

Commande Client
1, 1 Concerner 1, n
NCDE NCLI
DATEC NOMCLI
1, n
Pièce
Contenir 0, n
QTITEC NPIECE

La deuxième forme normale
Définition : Une entité ou relation est en deuxième

forme normale si chaque propriété de cette entité,
ou une relation, dépend de sa clé primaire par une
dépendance fonctionnelle élémentaire. C.à.d., il
n’existe pas de df avec une partie de la clé primaire.
Le MCD est dit en 2FN si toutes ses entités et relations

sont en deuxième forme normale.

Exemple 1 : Passage en deuxième forme normale d’une entité en 1FN
Commande
# NCDE
# NPRODUIT
- DATE_CDE
- QTITEC
L’entité « commande » est en 1FN.

Mais n’est pas en 2FN.

Le MCD en 2FN est :

Commande 1, n Contenir Produit
0, n
NCDE QTITEC NPRODUIT
DATE_CDE
Remarque :
Toute entité en 1FN possédant une clé primaire simple (non composée)
est en 2FN.

Exemple 2 : Passage en 2FN d’une relation en 1FN
Produit Fabriquer Machine

NPRODUIT 1, n 1, n NMACH
Quantité fabriquée/ jour
LIBPRODUIT Prix unit. Produit NOMMACH
Prix unit. Machine
La relation « Fabriquer » est en 1FN

Mais n’est pas en 2FN.

Le MCD en 2FN est :
Produit Fabriquer Machine

NPRODUIT 1, n 1, n NMACH
Quantité fabriquée/ jour
LIBPRODUIT NOMMACH
Prix unit. Produit Prix unit. Machine

La troisième forme normale
Définition :
Une entité ou relation est en troisième forme
normale si :
•Elle est en 2FN.
•Toute propriété de cette entité ou
relation dépend de sa clé primaire par une
dépendance fonctionnelle élémentaire
directe.
Exemple 1 : Passage en troisième forme normale d’une entité en 2FN
Règles de gestion :
 Chaque Produit a un code de TVA.
 Chaque code peut identifier le taux de TVA
correspondant.
Produit
NPRODUIT
LIBPRODUI
CODTVA
TAUXTVA
L’entité « pièce » est en 2FN.

Mais n’est pas en 3FN car : NPRODUIT  TAUXTVA n’est pas directe.

Le MCD en 3FN est :
Produit TVA
1, 1 Avoir 1, n
NPRODUIT CODTVA
LIBPRODUI TAUXTVA

Exemple 2 : Passage en 3FN d’une relation en 2FN
Le montant HT d’une ligne de commande est le produit de la quantité et le prix
unitaire du produit.
Commande Contenir Produit

1, n 0, n
NCDE Montant HT NPRODUIT
DATE_CDE Montant TVA PRIX UNIT
NPRODUIT+ NCDE  Montant TVA n’est pas directe

Montant TVA=Montant HT*20%
On doit supprimer le MONTANT TVA de la relation

MCD en 3FN:
Commande Contenir Produit

1, n 0, n
NCDE Montant HT NPRODUIT
DATE_CDE PRIX UNIT

Le modèle logique de données
 Le Modèle Logique des Données (MLD) est

une étape intermédiaire pour passer du modèle
E/A, qui est un modèle sémantique, vers une
représentation physique des données : fichiers,
SGBD hiérarchique, SGBD réseau, SGBD
relationnel.
 Nous nous limitons au seul MLD relationnel, qui

prépare le passage aux SGBD relationnels.
Le modèle logique de données
 La table relationnelle correspond à un objet du SI

(commande, client …)
 Elle est composée d’attributs/colonnes : les données

élémentaires qui décrivent l’objet
( n° commande, date commande, …).
 Elle possède une clé primaire (sous-ensemble

d’attributs) dont la valeur est unique pour chaque n-
uplet/ligne de la table.
 Exemple :
Commande (nucommande, datcommande, adr_livr)

Passage du MCD au MLD : Les entités
Toute Entité devient une table dont la clé primaire est

l'identifiant de l'Entité.
Client
Codcli
Nomcli se traduit par :
Adrcli
Client (codcli, nomcli, adrcli)

Passage du MCD au MLD : Les associations
Toute association binaire (1/1) - (0/N) ou (1/N) se traduit en ajoutant

une clé étrangère (identifiant de l'entité de cardinalité (0,N) ou (1,N) ) à
la table provenant de l'entité dont la cardinalité est (1,1).
toujours un seul client
Client Commande
codcli 0,N 1,1 nucom
passe
nomcli datcom
adrcli adrlivr
se traduit par :
toujours un seul
Client (codcli, nomcli, adrcli) client (attribut
Commande (nucom, datcom, adrliv, codcli) monovalué)
Toute association binaire (1/1) - (0/1)
se traduit en ajoutant une clé étrangère (identifiant de l'entité de
cardinalité (0,1) ) à la table provenant de l'entité dont la cardinalité
est (1,1).
toujours un seul employé
Employé Département
nuemp 0,1 1,1 nudep
nomemp dirige
nomdep
se traduit par :
toujours un seul
Employé (nuemp, nomemp) employé
Département (nudep, nomdep, nuemp)

Association binaire (0/1) - (0/N) ou (1/N)

Solution 1: idem à association (1/1) – (0/N) ou (1/N). Problème de clé étrangère
pas toujours définie (certains SGBD supportent, d’autres non).
Solution 2: on crée une table ayant pour clé primaire l'identifiant de l'entité (0/1)
et pour clé étrangère l'identifiant de l'autre entité. On ajoute les éventuelles
propriétés de l'association à la table. Plus lourd.
Employé 0,1 Classer 0,n Projet

nuemp dateaffect refproj
nomemp budget
se traduit par :
Employé (nuemp,refproj,nomenp, dateaffect) (solution 1)
Classer(nuemp, refproj, dateaffect) (solution 2)

Association binaire (0/N) ou (1/N) - (0/N) ou (1/N)
se traduit par une nouvelle table dont la clé primaire est composée des
identifiants des deux entités. Les éventuelles propriétés de l'association
deviennent les attributs de cette table.
0,n Classer 0,n

Skieur CompétitionRefc
rang omp
Nomski
spécialité datcomp
se traduit par :
Classer (nomski, refcomp, rang)

>2
On crée une table ayant pour clé primaire les identifiants des différentes
entités de l'association. Les propriétés de l'association deviennent les
attributs de la table.
Classe
No_classe
0,n
0,n Assure 0,n
Matière Professeur
codsalle
No_matiere No_prof
se traduit par :
Assure (no_classe, no_matiere, no_prof, codsalle)
Langages de Requêtes relationnels
 Langages de requêtes: Permettent la manipulation et

l’extraction des données d’une base de données.
 Le modèle relationnel supporte de simples et puissants LRs:
 Solide fondation formelle basée sur la logique.
 Permet beaucoup d’optimisation.
 Langages de requêtes != langages de programmation!
 Les LRs ne sont pas équivalents à la machine de Turing.
 Ils ne sont pas destinés à être utilisés pour des calculs complexes.
 Ils supportent un accès facile et efficient à de larges ensembles de
données.

Introduction
 Une requête est appliquée aux instances relationnelles et

son résultat est aussi une instance relationnelle.
 Les schémas des relations d’entrée d’une requête sont fixes (la
requête exécutera cependant indépendamment de l’instance!)
 Le schéma du résultat d’une requête donnée est aussi fixe! Il est
déterminé par la définition des éléments du langage des requêtes.

Les opérateurs de l'algèbre relationnelle
 Les opérateurs unaires (1 opérande relation)

 Projection 
 Sélection 
 Les opérateurs binaires (2 opérandes relation)

 Produit Cartésien 
 Jointure
 Différence -
 Union 
 Intersection 
 Division 

La projection 
 Signature : Relation  Liste d'attributs  Relation

 Notation : PROJY(R) ou Y(R)
 Elle ne conserve que les types d'attributs (colonnes) Y
de la relation et supprime les doublons
COMMANDE
Objet Client Nb
Objet Client
table Klein 4  Objet, Client(R)
table Klein
table Klein 2 placard Blériot
placard Blériot 3

La projection 
Exemple : Personne(N°personne, Nom, Prénom, Ville)
N°personne Nom Prénom Ville
1 Alami Mohamed Rabat

2 Omari Ali Fès
3 Mourchid Mohamed Meknès
4 Mamoune Kamal Rabat

5 Bennani Ali Fès
T1=  Prénom, Ville(Personne)

La projection 
T1=  Prénom, Ville(Personne) est la table suivante :

Prénom Ville
Mohamed Rabat
Ali Fès
Mohamed Meknès
Kamal Rabat

La Sélection 
 Signature : Relation  Expression Logique  Relation
 Notation : SELECT C(R) ou  C (R)
 La sélection ne conserve de la relation que les tuples (lignes)
qui vérifient l'expression logique sur noms d'attributs
(construite avec les opérateurs logiques , ,  et les
comparaisons =, <, >, , , ).
 Le schéma relationnel est conservé.
R Chauffeur Départ Destination

Chauffeur Départ Destination
Karl Paris Le Havre
Bébert Paris Bordeaux Tonio Paris Le Havre
Karl Paris Le Havre
Tonio Paris Le Havre
Dédé Lyon Marseille
 Départ="Paris"Destination="Le Havre" (R)

Le Produit Cartésien 
 Signature : Relation  Relation  Relation
 Notation : PROD(R1, R2) ou R1  R 2
 On renomme les types d'attributs que R1 et R2 ont en commun,

puis on concatène chaque tuple de la relation R1 avec chaque
tuple de la relation R2 pour former l'extension.
Remarques : On doit renommer les types d'attributs en double.

On obtient toutes les combinaisons possibles !

Le Produit Cartésien (exemple)
Stock1 Fabrication
Pièce Nb-P Fournisseur Pièce Nb Objet
vis 2000 Germond vis 8 table

écrou
charnière
4000
500
Martin
André
 écrou
charnière
8
4
table
placard
poignée 200 André vis 16 placard
Pièce1 Nb-P Fournisseur Pièce2 Nb Objet

vis 2000 Germond écrou 8 table
vis 2000 Germond charnière 4 placard
vis 2000 Germond vis 16 placard
écrou 4000 Martin vis 8 table
écrou 4000 Martin écrou 8 table
… … ... ... ... ...

Le produit cartésien
Exemple : Soient les deux relations Produit et Fournisseur :
Référence Libellé Code Nom

Fournisseur Fournisseur
AX01 Cordon
AF09 Mourchid
AY02 Piston
AF08 Alami

Le produit cartésien
La relation ProduitFournisseur est :

Référence Libellé Code Nom
Fournisseur Fournisseur
AX01 Cardan AF09 Mourchid
AX01 Cardan AF08 Alami
AY02 Piston AF09 Mourchid
AY02 Piston AF08 Alami

La -Jointure
 Signature : Relation  Relation  -Expression 
Relation
 Notation : JOIN -Expression (R,S) ou R -Expression S
 La jointure est la superposition de tout enregistrement
de R avec un enregistrement de S dans laquelle on ne
garde que les tuples qui vérifient la -Expression.
Remarque : Comme pour le produit cartésien, on

renommera les types d'attributs communs
à R et à S.

La -Jointure (exemple)
Stock1 Fabrication

écrou 4000 Martin Stock.pièce = écrou 8 table
charnière 500 André Fabrication.pièce charnière 4 placard
Pièce1 Nb-P Fournisseur Pièce2 Nb Objet

vis 2000 Germond vis 16 placard
charnière 500 André charnière 4 placard
 -Expression vérifiée

1er exemple de jointure
Elève Num Nom Adresse Age Elève.Num=Chambre.numElève
1 Bélaïd Maisel 20
2 Millot CROUS 20
3 Meunier Maisel 21 Chambre No Prix numElève
10 200 3
21 150 2
Elève Num Nom Adresse Age No Prix numElève

Chambre
2 Millot CROUS 20 21 150 2

3 Meunier Maisel 21 10 200 3
 1 tuple de Chambre  1 tuple de résultat
 1 tuple de Elève  0 ou 1 tuple de résultat
 On a perdu Bélaïd !

2ème exemple de jointure
Inscrit NumElève CodeUV Note Inscrit.NumElève=Elève.Num
2 BD 10 Elève Num Nom Adresse Age

1 BD 20 1 Bélaïd Maisel 20
2 IO 17 2 Millot CROUS 20
3 IO 18 3 Meunier Maisel 21
Inscrit Num Nom Adresse Age NumElève CodeUV Note

Elève
1 Bélaïd Maisel 20 1 BD 20
2 Millot CROUS 20 2 IO 17
2 Millot CROUS 20 2 BD 10
3 Meunier Maisel 21 3 IO 18
 1 tuple de Inscrit  1 tuple de résultat

 1 tuple de Elève  0 à n tuples de résultat
 On a dupliqué Millot !

Equi-jointure et Jointure naturelle
 Dans l'équi-jointure, la -expression est omise. On ne garde que les tuples

pour lesquels les valeurs des colonnes communes à R et S sont égales.
 La jointure naturelle notée R*S ou R S est une équi-jointure dans
laquelle on ne garde qu'une seule des colonnes communes.
Remarque : La jointure naturelle peut également s'exprimer

à l'aide d'une sélection, d'un produit cartésien
et d'une projection.

La Jointure naturelle (exemple)
Stock1 Fabrication

charnière 500 André charnière 4 placard
Pièce Nb-P Fournisseur Nb Objet
vis 2000 Germond 8 table

vis 2000 Germond 16 placard
écrou 4000 Martin 8 table
charnière 500 André 4 placard

L'union  et l'intersection 
Union
 Notation : R  S
 Pour deux tables R et S de même schéma relationnel, l'union retourne les
tuples qui sont dans R, dans S ou dans R et dans S.
Intersection
 Notation : R  S
 Pour deux tables R et S de même schéma relationnel, l'intersection retourne les
tuples qui sont à la fois dans R et dans S.

La différence -
Signature : Relation  Relation  Relation

 Notation : R-S
 Pour deux tables R et S de même schéma relationnel, l'union retourne
les tuples qui sont dans R à l'exception de ceux qui sont également
dans S.

Résumé
 Le modèle relationnel a des langages de requêtes

rigoureusement définis et qui sont simples et puissants.
 L’algèbre relationnelle est plus opérationnelle; elle est
utile comme représentation interne des plans d’évaluation
des requêtes.
 Une requête donnée peut être exprimée de diverses
manières; un optimisateur choisira la voie la plus
efficiente.

Système Ďinformation Et Bases de Données

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Système Ďinformation Et Bases de Données

Transféré par

Droits d'auteur :

Formats disponibles

Système d’Information

Année universitaire 2017/2018

Les Systèmes d’Information

Le modèle est inconnu,

Le modèle est connu,

 L’ordinateur n’est qu’un

Flux d’informations Système d’information

Personne, machine, logiciel…

 Collecter (sources externes et internes)

 Le SI sert de support de communication entre les

 La recherche d’une standardisation, normalisation

 Les processus, une fois modélisés, pourront être pris en

 Flux physique: Etudiants, examens, concours,

 Flux d’information : Nom, prénom, date de naissance,

 Flux de décision: Nombre d’étudiants admis, seuil

 Flux physique: avions, réservations, trajets, …

 Flux d’information : détail vol: Heure départ, heure

 Flux de décision: Grille tarifaire, nouvelles lignes,…

Années 70  Les approches cartésiennes

 Les approches systémiques

 les approches objet

 Un bibliothécaire vous demandes, de lui automatiser la gestion de sa

 Il a un ordinateur que lui seul l’utilise, et il veut une simple application

Quoi faire Qui fait

 Merise est une méthode d’analyse informatique et une démarche

 Elle s’est apparu à la fin des années 1970(78/79), développée par

 Elle se base sur un ensemble de signes graphique pour représenter

 Elle permet de faire un lien de communication entre les différents

 La méthode Merise se base sur la démarche 3 découpages sur 3

 Passage par différentes étapes :

Expression des besoins

 Modèle organisationnel ou logique

 Démarche par étapes : hiérarchise les décisions au cours de la vie du

 Intérêts de cette double approche :

 Niveau physique ou opérationnel:

Niveau Modèle Physique des Données 15%

Les Bases de Données

1. La structuration des données

 Structure en mémoire centrale (MC)

 Stockage persistant sur disque

 «Gros» volumes de données

 Langages de programmation et SGF

 Contexte mono-utilisateur (en général)

Direction des études Bibliothèque Service social

Appli Appli Appli

Fichiers Elèves Fichiers Elèves Fichiers Elèves

 Difficulté à saisir les liens entre les données

 Stockage persistant sur disque

 «Très gros» volumes de données

 Langage de requêtes et langages de programmation SGBD

Appli Cobol Elèves

 Facilités pour l’utilisateur :

 Système de Gestion de Bases de Données

 Première présentation officielle de l’approche relationnelle: E.F. Codd

 Premiers prototypes de SGBD: Système R d’IBM et INGRES à Berkeley

 Premier langage de requêtes:

 Premiers SGBD relationnels commerciaux

 Permettre à plusieurs utilisateurs d’accéder aux données simultanément

 Protéger les données en cas d’incident

 Contrôler l’accès aux données confidentielles

 Offrir de bonnes performances d’accès

datePrêt Emprunter Louer

côte 0,1 1,1 no

Livre UV Chambre Elève