Please enable JavaScript.
Coggle requires JavaScript to display documents.
STRUCTURATION ET TRAITEMENT DE L'INFORMATION, LES RÈGLES DE…
STRUCTURATION ET TRAITEMENT DE L'INFORMATION
LA NOTION DE DONNÉE
DIFFERENCE ENTRE DONNÉES STRUCTURÉES ET NON-STRUCTURÉE
données structurées*
leur contenu est identifiable
on peut les placer dans une catégorie
le contenu est homogène ( toujours du même type )
elles sont plus facile à utiliser et moins chronophage
données non-structurées
impossible a catégoriser
regroupe des infrormations
LA STRUCTURATION DES DONNÉES
c'est faire un
travail d'analyse
pour permettre de
représenter des données
que l'ordinateur pourra exploiter
ex : informatiser sur tableur les infos des clients
à partir des valeurs qu'il doit gérer, l'humain
identifie des groupes de valeurs dont le contenu lui paraît homogène
souvent sous la forme de tableau
L'ANALYSE DES DONÉES À RETENIR POUR LA STRUCTURATION
les données élémentaires
données qui sont
décomposées au max
pour qu'on ai
un regard pertinent sur l'information
ex : décomposer
Adresse
( donnée non élémentaire ) en
AdresseRue
,
AdresseCP
,
AdresseVille
données calculées
données qui ne sont pas retenue dans la structuration
ce sont les données dites calculées car elle peuvent être obtenue par un calcul
ex : CA annuel calculé à partir du CA mensuel
les paramètres
données dont la valeur est unique et stable dans le temps
ex : taux de conversion euro-franc
LE MODÈLE RELATIONNEL
relation
: données structurées présentés dans les tables
ex : la relation CLIENT : CLIENT(NomClient, AdresseRue, AdresseVille, etc )
ensemble des relation représentant les tables =
système relationnel
CLÉ PRIMAIRE ET DÉPENDANCE FONCTIONNELLE
LA CLÉ PRIMAIRE D'UNE RELATION
dans la relation elle est mentionnée en
premier
et
soulignée
ex : CLIENT(
CodeClient
, NomClient, AdresseRue, AdresseVille, etc )
le clé primaire ainsi que ses valeurs ne contienne
aucun doublons
contraintes que la clé primaire doit respecter
stable
: ne doit pas être modifiée ( numéro, email, etc )
non vide
de petite taille
LA DÉPENDANCE FONCTIONNELLE*
si
CodeClient = 3
alors NomClient = Bensaadi, AdresseRue = 148 avenue paul arène et AdresseVille = LaCiotat
pour réaliser les traitements informatiques il faut être sur que
les attributs soient à leur place dans la relation
une clé primaire permet de repérer sans risque de confusion un enregistrement
DÉPENDANCE FONCTIONNELLE ENTRE DEUX RELATION : LA CLÉ ÉTRANGÈRE
LES PROBLÈMES DE REDONDANCE DANS UNE BASE DE DONNÉES
redondance
: c'est la répétition inutile de valeurs identiques au sein des bases de données
une plus grande quantité de travail
un risque de ralentissement dans le traitement
une consommation d'espace mémoire plus large
LA DEPÉNDANCE FONCTIONELLE DIRECTE
principe
: tout attribut dans une relation doit être en dépendance fonctionnelle directe avec la clé primaire
les corrections à apporter un modèle pour supprimer les dépendances
pour réduire au maximum les relation la relation doit éclater en deux relation
la premier conserve les attributs en dépendance directe avec la clé primaire
ETUDIANT (
NumEtudiant
, NomEtudiant, CodeClasse )
la deuxième qui contiendra un attribut en dépendance indirecte la clé primaire
CLASSE (
CodeClasse
, NomClasse )
voir page 10/11
LA CLÉ ÉTRANGÈRE*
ETUDIANT(
NumEtudiant
, NomEtudiant,CodeClasse
dans la table étudiant on rajoute un # devant CodeClasse*
ETUDIANT(
NumEtudiant
, NomEtudiant,#CodeClasse )
CLASSE(
CodeClasse
, NomClasse )
elle peut permettre une jointure entre les relation dans le cadre des requîtes SQL
une clé primaire d'une relation
est utilisée en tant qu'attribut dans une autre relation
pour
matérialiser la dépendance fonctionnelle entre ces deux relation
LA DEPENDANCE FONCTIONNELLE COMPOSÉE : LA CLÉ PRIMAIRE CONCATÉNÉE
LA DÉPENDANCE FONCTIONNELLE COMPOSÉE*
ex : dans le cas d'une note d'un élève il faut connaitre le
NumEtudiant
, le
CodeMat
, le
CodeProf
et la
Note
si on ne connaissait que le
NumEtudiant
et le
CodeProf
sa n'aurait pas été possible
LA CLÉ PRIMAIRE CONCATÉNÉE
objectifs
ex : la création de la relation
RÉSULTATS
RÉSULTAT(
#NumEtudiant, #CodeMat, #CodeProf
, Note )
les relations
ETUDIANT
,
MATIERE
et
PROFESSEUR
sont liées par leur participation à la relation
RÉSULTATS
attention à bien rajouter la date si on dit chaque jour
LES CAS PARTICULIERS
la notion d'identifiant relatif
( identifiant = clé primaire )
certaines relations n'existe que parce qu'un autre relation existe au préalable*
agrégation
lorsque les valeurs saisies sont incohérentes
LES RÈGLES DE NORMALISATION : LES FORMES NORMALES ( FN )
LA PREMIÈRE FORME NORMALE ( 1FN )
l'attribut d'une table doit être
non-redondant
tout attribut non-clé doit être présent une seule fois par modèle
atomique
tout attribut doit être décomposé à son maximum
non-calculé
les donnée calculées sont inutiles si elle peuvent être retrouvées
LA TROISIÈME FORME NORMALE ( 3FN )
doit déjà être en 2FN
tout attribut non-clé est en dépendance fonctionnelle directe avec la clé
APPARTEMENT(
N°appartement
, surface, CodeImmeuble, NomImmeuble )
NomImmeuble
n'est pas en
DF
avec
N°appartement
mais avec
CodeImmeuble
LA DEUXIÈME FORME NORMALE ( 2FN )
tout attribut non-clé est en dépendance fonctionnelle avec la totalité de la clé
ex : COMMANDE(
#codeClient, #codeArticle
, nomArticle )
le
nomArticle
n'a pas de lien avec
#codeClient
doit déjà être en 1FN
utile que pour les relation avec une clé primaire composée
PAGE 18/37