ASUR_2010 - contenu1

E:\francois\education\2009-2010\ASUR\ASUR_2010 - contenu1.doc Francois Kieffer Page 1 sur 11
Contenu ASUR – 2010
Extrait du référentiel
UE 2 : Connaissances de base et outils pour les réseaux d’entreprise (130h)
MASbd = Les Bases de données 20h
Introduction théorique TD 4h François Kieffer
Déploiement TP 4h François Kieffer
Gestion des utilisateurs TP 4h François Kieffer
Les backup TP 4h François Kieffer
Notions de SQL TP 4h François Kieffer
Chaque TP ou TD donne lieu à un compte rendu noté ?
1 Théorie des bases de données (rappels?)
Utilité, relevé d'information, méthodes de modélisation, merise et schémas de merise,
1.1 Utilité
Une base de données vise à modéliser une partie du monde réel et sert de support à des
applications informatiques pour stocker, protéger les données formelles de l'organisation et
les manipuler (calculs, statistiques, tris, extractions, mises en corrélations, …).
- Modéliser : pour représenter la réalité des données manipulées par l'organisation
(fournisseurs, articles, désignations, prix, adresses de postes, utilisateurs, etc.
…) selon une structure logique, à l'aide de système de modélisation (merise,
UML),
- Stocker sous forme de tables de "fiches", enregistrements ou occurrences
d'entité, dans des fichiers ou dans un SGBD(R) que l'on peut sauvegarder ou
précharger,
- Protéger : restreindre l'accès aux données aux personnes autorisés, assurer la
préservation des données contre les risques informatiques,
- Manipuler en effectuant des extractions grâce à un langage de requêtes (SQL)
Ceci dans le but de conserver les archives de l'entreprise, son savoir-faire, son expertise et
de faciliter la diffusion des informations nécessaires.
Exemple :
Annuaire(nom, prénom, âge, CP, Ville)
- tableau  Redondances (CP, Ville, …)
- 2
ème
tableau : (CP, Ville)
Note : toute situation ne nécessite pas forcément de Base de données.
Exemple :
Un groupe de DB, de disques suffisamment important pour justifier une BDD
Si ce n’est que pour en faire la liste, un tableau suffit.
SGBD : Système de gestion de Bases de Données
SGBDR : SGBR relationnel : il est possible d’établir des relations entre les données de la BDD
Exemples : Oui : Oracle, MySQL, Ingre, SQL Server ; Non : SQL (langage).
Comment faire ?
Réponse : l’analyse.
1. Analyse des besoins : Pourquoi, à quoi ça sert ? Quand ?
2. Comment ? Techniques d’analyse.
Pourquoi une technique d’analyse (Merise ou UML) ?
Les gros volumes de données nécessitent une approche rigoureuse du problème de la
modélisation. Pour parvenir à un résultat cohérent, des méthodistes ont développé une

E:\francois\education\2009-2010\ASUR\ASUR_2010 - contenu1.doc Francois Kieffer Page 2 sur 11
méthode (encore en cours d’évolution) nommée Merise et, parallèlement, un langage de
modélisation dit universel (UML).
Après l’analyse des besoins, la première action, dans la création d'une BDD, est de dégager
les concepts, les données élémentaires, les exemples de données de l'interview de
l'organisation.
1.2 Le relevé d'informations
Le relevé d'information est la chose la plus difficile de l'analyse merise ou UML.
Les informations à modéliser sont trouvées lors de l'interview de l'organisation : réunions
d'information avec le personnel, consultation des procédures internes, lecture des
documents d'archives et description des activités et de la structure de l'entreprise,
rétroconception du logiciel existant, audit des pratiques professionnelles.
1.2.1 En théorie c'est ça …
Concepts, données et valeurs
Avant d'aborder le MCD, on va pouvoir relever trois types d'informations qui sont
des concepts, des données ou des valeurs.
Les concepts sont des choses, des objets que l'on va gérer. Ils deviendront
probablement des entités du schéma entité association vu plus loin.
Les données sont des informations élémentaires sur les concepts.
Données et concepts sont souvent masqués par des valeurs de ceux-ci ou exprimés
par des euphémismes ou des synonymes.
Attention !
Les acteurs ne sont pas des informations à mémoriser.
Les personnes sont souvent des acteurs mais parfois des concepts lorsqu'il s'agit de gérer du
personnel.
Donnée
Une donnée est une information élémentaire que l'on ne peut pas décomposer.
Exemple oui : description, prix, quantité, numéro d'identification, nom, prénom, ville, code
postal, etc. …
Exemple non : fournisseur, article, ingénieur
Dans le discours du sujet, une donnée est souvent rattachée à un concept.
Exemple oui : description de l'article, nom de l'employé, numéro du client, numéro de
commande, etc. …
Exemple non : description (tout court, sans dire de quoi)
Concept
Un concept est une information complexe qui peut être décomposée en données.
Exemple oui : article, commande, client, employé, etc. …
Exemple non : description, organisation gérée, tapis Z7 cendré.
Pour détecter un concept, on va relever les noms de choses, d'objets, de personnes ou de
types. Ce seront souvent des concepts.
Ce seront sûrement des concepts si des données y sont rattachées.
Valeur
Certains concepts ou données sont masqués par des valeurs exposant différentes
occurrences de ceux-ci.
Exemple oui : Strasbourg, Nantes, Rennes, Lyon et Mulhouse sont des occurrences du
concept 'ville'.
Ces mêmes valeurs sont, de plus, des occurrences de la donnée 'nom ville'.
Exemple non : type article, ville.
Remarques importantes :

E:\francois\education\2009-2010\ASUR\ASUR_2010 - contenu1.doc Francois Kieffer Page 3 sur 11
Dans tous les cas, il ne faut relever que les données et concepts pertinents pour l'étude,
gérés par le système décrit, et ne pas se laisser perturber par des informations qui
constituent le bruit de l'étude.
A noter que les information sur l'entreprise elle même ne sont pas à relever, seules les
données avec lesquelles on travaille sont à noter.
Exemple descriptif : la société InfoTech travaille avec des fournisseurs à Strasbourg, Lyon et Nancy.
InfoTech n'est pas une donnée, c'est la description de l'organisation ;
- Fournisseur est un concept (dont on ne sait rien d'autre)
- Strasbourg, Lyon, … sont des occurrences de la donnée 'nom ville' du concept 'ville'.
- À indique qu'il y a un lien, une association, une relation entre les concepts fournisseur et ville
1.2.2 … mais en pratique …
Certains concepts sont ambigus. Ainsi dans certains cas, des concepts seront relégués au
rang de donnée.
Exemple descriptif : la société InfoTech travaille avec des fournisseurs à Strasbourg, Lyon et Nancy.
Les noms des villes ne font pas l'objet d'une gestion particulière.
- InfoTech n'est pas une donnée, c'est la description de l'organisation ;
- Fournisseur est un concept (dont on ne sait rien d'autre)
- Strasbourg, Lyon, … sont des occurrences de la donnée 'nom ville' du concept 'ville'.
- À indique qu'il y a un lien entre 'Fournisseurs' et 'Ville'. Mais comme la ville n'a pas besoin
d'être de façon précise, codifiée (ajout au sujet) le nom de la ville sera noté seul et le concept
risque de disparaître.
Les données seront consignées dans un dictionnaire des données, les concepts resteront au
brouillon, à titre d'indication pour une future utilisation.
1.3 Représentation (Merise)
Pour représenter une base de données, on utilise souvent la modélisation Merise qui apporte
des règles de représentation et formalise les schémas de modélisation des BDD.
On y trouve des éléments similaires à ceux utilisés dans MS-Access trois niveaux
conceptuels, trois schémas et trois normalisations des noms :
Graphe des Dépendances
Fonctionnelles ;
Données, dépendances ; Modèle Conceptuel de
Données
Schéma Conceptuel des
Données
Entités, attributs, identifiants,
associations, cardinalités, etc. …
SLD Tables, propriétés, clés primaires,
relations
Modèle Logique de
Données ou Modèle
Relationnel MR Relations, propriétés, clés
primaires, clés étrangères
MPD Implémentation du MR en langage de définition des données
(création des tables de la BDD)
Le MCD contient parfois des informations qu'il est impossible de traduire sous forme
schématique dans les modèles suivants. On aura donc parfois recours à des contraintes
exprimées textuellement.
Voir schéma gestion commerciale……
1.4 Modèle relationnel
Le modèle relationnel est la représentation textuelle du MLD et MCD.
Une relation est un ensemble de données associées de manière cohérentes : elle
appartiennent toutes au même concept et à la même occurrence de ce concept.

E:\francois\education\2009-2010\ASUR\ASUR_2010 - contenu1.doc Francois Kieffer Page 4 sur 11
Exemple :
Relation client :
cliNum cliRaisonSociale cliZip cliVille cliadr1
C1 Toto 68000 Colmar Ici
C45d Titi 67000 Strasbourg La-bas
VEBBU2O34 GRRRR 68750 Bergheim Quelque-part
…
Relation Commande
cdeNum cdeDate cliNum
1 23/12/2005 C1
24 01/01/2009 C1
345 01/01/2009 VEBBU2O34
Le schéma relationnel montre toutes les relations, les attributs, les références de la base.
Dans ce modèle, il manque cependant l'expression des contraintes (une valeur ne doit pas
dépasser une certaine limite, un enregistrement doit être simultané avec la présence d'un
autre dans une autre table, etc. …)
Client(cliNum, cliRaisonSociale, cliadr1, cliZip, cliVille)
Clé primaire : cliNum
Commande(cdeNum, cdeDate, cliNum)
Clé primaire : cdeNum
Clé étrangère : cliNum référence cliNum dans client*
* officiellement, on devrait dire : "l'attribut clinum est en dépendance de référence avec
l'attribut cliNum de la table Client", mais je trouve que c'est un peu long.
Les colonnes sont nommées champ ou attribut
- nom de l’attribut est unique dans une relation
- nom attribut peu exister plusieurs fois dans des tables différentes. Ce sont des
champs différents mais qui signifient la même chose, même sémantique.
- Le domaine est la liste, l’ensemble des valeurs acceptées pour le champ.
Exemple : {Colmar, Strasbourg, Bergheim} est le domaine de ville
- L’ordre des attribut n’a pas d’importance mais convention : identifiant de
l’occurrence est devant, les champs qui font référence à des identifiants d’autres
tables sont derrière. Les champs sont souvent regroupés par ensembles signifiant
cohérents (adresse : CP, Ville, N°, Rue ; description : libellé, poids, volume ; etc. …).
Les lignes sont nommées enregistrement ou tuple et représentent les valeurs d’une
occurrence, d’un « objet » représenté par la relation.
Exemple :
C1 Toto 68000 Colmar Ici
Est un enregistrement de la relation Client.
1.5 Privilèges (Droits d'accès)
Pour assurer la sécurité des données, on va mettre en place un système de droits sur les
tables et les champs de celles-ci.
Ces droit sont : création, interrogation, modification, suppression (CIMS).
Création permet de créer des enregistrements, des tables, des utilisateurs.
Interrogation permet d'extraire des enregistrements partiels ou entiers, d'afficher le
contenu de table, la structure des tables, la liste ou les droits des utilisateurs et
groupes.
Modification permet de modifier des valeurs, la structure de tables, les droits des
utilisateurs.
Suppression permet de supprimer des enregistrements, des champs, des tables, des
droits, des utilisateurs ou groupes.
Ils sont données hiérarchiquement selon :
Droits globaux sur la base

E:\francois\education\2009-2010\ASUR\ASUR_2010 - contenu1.doc Francois Kieffer Page 5 sur 11
Droits globaux pour la catégorie d'utilisateur (adm, usr)
Droits de groupes puis de sous-groupes
Droits particuliers à un utilisateur.
Cependant, il vaut mieux ne pas multiplier les niveaux et les groupes de droits, afin de ne
pas risquer de maillage des droits :
Droit de création groupe interdit sur une table puis sous groupe autorisé sur une partie de
cette table. Donc en contradiction avec la règle du groupe …
Tentative de cession de privilèges refusés = erreur.
Exemple XXXXX (voir sujet CGO)
Un tableau de définition des privilèges du LID et LMD, table Client
Utilisateur/groupe Consultation Insertion modification Suppression
adm Aucun
Concepteur Oui Non Non Oui
Gestion Oui Non Oui Non
Production Non Non Non Non
Ventes Oui Oui Oui Non
Une hiérarchisation de base des privilèges
PUBLIC (Base) = all
adm = all
usr = select, insert, delete, update : all, create, alter, drop, grant, revoke : none
production : insert on client : none, delete on client : none
…
1.6 Exercices
♥=facile, ♦=moyen, ♠=difficile, ♣=expert, $=rusé, sioux, *=squelette de source fourni.
1.6.1 Exo droits ♥
♥♥
♥
Expliquez quels sont les risques de ne pas respecter la hiérarchisation d’attribution des
droits.
Proposez une solution simple pour pallier à cette difficulté.
1.6.2 Exo MCD ♥
♥♥
♥
L'entreprise de négoce ECOTECH désire informatiser la gestion de ses fournisseurs et de ses
clients ainsi que des commandes de produits qu'elle passe avec chacun des deux types de
tiers.
→ Déterminez combien de concepts complexes sont en présence.
→ Faites la liste et le schéma des dépendances fonctionnelles entre ces concepts, en
ajoutant les données nécessaires.
→ Imaginez une série d'informations élémentaires pour chaque concept
→ Construisez un schéma conceptuel de cette organisation
1.6.3 Exo MCD ♥
♥♥
♥
L'entreprise ECOTECH désire modifier son mode de production et effectuer le
reconditionnement des produits vendus. Pour cela, elle s'est dotée de machines de
conditionnement. A cet effet, pour un article M, il est nécessaire d'ajouter un emballage E
pour en faire un produit fini F.
Dans certains cas l'article M pourra figurer en plusieurs exemplaires dans le produit F. Il est
même possible qu'un produit F soit le résultat de l'emballage de différents M en nombre
d'exemplaires multiples
Il est évident qu'un article emballage ne peut être vendu seul et qu'un article de type M non
plus
→ Complétez le modèle conceptuel (DD, GDF, SCD) de l'exercice précédent.