[PDF](+30👁️) Télécharger Conception Et Réalisation SQL Server ( Livre Blanc De Stéphane Grare) pdf
Réaliser une base de données sous SQL Server
La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes d'informations informatisés. Power AMC est un logiciel de modélisation. Microsoft SQL Server est un système de gestion de base de données.
Ce tutoriel se présente sous forme d'ouvrage avec pour objectif la réalisation d'une base de données sous Microsoft SQL Server en passant par la conception à l’aide de la méthode d'analyse Merise sous Power AMC. L'ouvrage se destine exclusivement aux étudiants de la formation professionnelle de l’Afpa, qui souhaitent apprendre et comprendre les grandes étapes nécessaires à la conception et à la réalisation d’une base de données.
Plus d'informations sur http://system-sg.blogspot.frTélécharger gratuit Conception Et Réalisation SQL Server ( Livre Blanc De Stéphane Grare) pdf
Conception et Réalisation
D'une base de données
Merise • PowerAMC • SQL Server • T-SQL
Stéphane G rare
Conception et Réalisation
D'une base de données
Merise - PowerAMC - SQL Server - T-SQL
Stéphane Grare
Le code de la propriété intellectuelle du 1er juillet 1992 interdit en
effet expressément la photocopie à usage collectif sans autorisation
des ayants droit. Or, cette pratique s'est généralisée notamment dans
les établissements d'enseignement, provoquant une baisse brutale des
achats de livres, au point que la possibilité même pour les auteurs de
créer des œuvres nouvelles et de les faire éditer correctement est
aujourd'hui menacée.
En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement
ou partiellement le présent ouvrage, sur quelque support que ce soit, sans
autorisation de l'éditeur ou du Centre Français d'Exploitation du Droit de Copie, 20,
rue des Grands-Augustins, 75006 Paris.
DANGER
3 HC"0CCPILLAGE
t TUE LE LIVRE
Préface
Ce tutoriel se présente sous forme d'ouvrage avec pour objectif la
réalisation d'une base de données sous Microsoft SQL Server en passant par la
conception à l'aide de la méthode d'analyse Merise sous Power AMC. Il s'agit plus
exactement d'un recueil et de notes de synthèses issues de différents supports.
La méthode Merise est une méthode d’analyse, de conception et de
réalisation de systèmes d’informations informatisés. Power AMC est un logiciel de
modélisation. Il permet de modéliser les traitements informatiques et leurs bases
de données associées commercialisés par la société Sybase. Microsoft SQL Server
est un système de gestion de base de données (abrégé en SGBD ou SGBDR pour
"Système de Gestion de Base de Données Relationnelles") développé et
commercialisé par la société Microsoft. Bien qu'il ait été initialement co-développé
par Sybase et Microsoft, Ashton-Tate a également été associé à sa première
version, sortie en 1989. Cette version est sortie sur les plateformes Unix et OS/2.
Depuis, Microsoft a porté ce système de base de données sous Windows et il est
désormais uniquement pris en charge par ce système.
L'ouvrage se destine exclusivement aux étudiants de la formation
professionnelle de l'Afpa, qui souhaitent apprendre et comprendre les grandes
étapes nécessaires à la conception et à la réalisation d'une base de données. Il ne
remplace en aucun cas les supports de formation nécessaire à l'apprentissage.
Tout au long de l'ouvrage, nous utiliserons une base de données nommée
« Papyrus ». Des exemples pourront porter sur des bases fictives afin d'apporter
des notions supplémentaires.
4
Table des matières
Merise.10
Introduction à la méthode Merise.10
Cahier des charges.11
Les règles de gestion.11
Conception de la base de données avec Power AMC.12
Créer des domaines.13
Le dictionnaire des données.14
Utilisation de la palette.16
Les cardinalités.23
Règles de normalisation.24
Le modèle logique des données (MLD).25
Modèle physique de données (MPD).27
Créer la base de données.29
Création de la base de données sous SQL Server.29
En utilisant l'interface.29
Par le code.30
Création de tables sous SQL Server.33
Avec Power AMC.33
Par l'interface.41
Par le code.45
Modifications de tables et contraintes.51
En utilisant l'interface.51
Par le code.58
Supprimer une table
62
Par l'interface
62
Par le code.62
Supprimer une base de données.62
Par l'interface.63
Par le code.63
Groupes de fichiers.63
Les partitions.70
Fonction de partition.71
Schéma de partitionnement.72
Partitionner des tables et des index.73
SELECT sur des tables partitionnées.74
Gestion du partitionnement.76
Schémas de la base de données.76
Alimenter la base de données.78
Saisir des données dans vos tables.78
Par l'interface.80
Par le code.81
Par l'option insertion de SQL Server.85
Les index.90
Créer un index.90
Supprimer un index.94
Reconstruire un index.95
Les vues.96
Création d'une vue.96
Création d'une vue avec du code T-SQL.99
Suppression d'une vue.101
Les vues indexées.102
Gestion des schémas
103
Créer un schéma
104
Modification d'un schéma.105
Suppression d'un schéma.108
Générer des scripts.108
Sauvegarder et restaurer la base.114
Sauvegarde de la base de données.114
Sauvegarder par l'interface.116
Sauvegarder par le code.117
Restauration de la base de données.118
Restauration par l'interface.119
Restauration par le code.122
Plan de maintenance.122
Sécurité de la base.128
Gestion des accès serveur.128
Gestion des connections à SQL Server.128
Créer les profils de connexion sous Windows.128
Créer les profils de connexion au serveur.135
Modification des connections à SQL Server.138
Suppression des connections à SQL Server.139
Gestion des utilisateurs de base de données.139
En utilisant l'interface.139
Par le code.140
Modification des utilisateurs de base de données.141
En utilisant l'interface.141
Par le code.141
Suppression des utilisateurs de base de données.142
En utilisant l'interface.142
Par le code
142
Gestion des droits
142
Droits d'instruction.142
Droits d'utilisation.143
Droits au niveau base de données.148
En utilisant l'interface.148
Par le code.149
Les rôles.149
Les rôles prédéfinis.149
Les rôles définis par l'utilisateur.150
Programmations SGBD.153
Le Langage DML.153
Les variables locales.153
Les variables système.153
La forme conditionnelle IF.154
La fonction CASE.154
La boucle WHILE.155
L'instruction RETURN.155
L'instruction PRINT.155
La clause OUTPUT.155
Les messages d'erreurs.156
Utilisation de NOCOUNT, EXISTS.157
Les fonctions utilisateur.157
Création d'une fonction.158
Modification d'une fonction.163
Suppression d'une fonction.164
Procédures Stockées.165
Création d'une procédure stockée.165
Modifier une procédure stockée
174
Suppression d'une procédure stockée
175
Les curseurs.176
Fonctions de curseurs.179
Ensembliste VS Curseur.179
Les transactions et les verrous.180
Le code T-SQL.181
Verrouillages dans SQL Server.182
Gestion des erreurs.184
Points d'enregistrements.184
Les déclencheurs.185
Les déclencheurs du DML.185
Les déclencheurs du DDL.194
Déboguer le Transact SQL.201
Activer le débuggeur.202
Fonctionnement du débuggeur.209
Déboguer un déclencheur.210
Utilisation de l'envoi d'email via le protocole SMTP.211
Par l'interface.212
Par le code.217
FAQ.220
Merise
Introduction à la méthode Merise
La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes
d'informations informatisés.
Merise part de l'idée selon laquelle la réalité dont elle doit rendre compte n'est pas linéaire,
mais peut être définie comme la résultante d'une progression, menée de front, selon trois
axes, qualifiées de "cycles".
Cycle d'abstraction Directions genèra:e et financière + intormaüque
La méthode Merise d'analyse et de conception propose une démarche articulée simultanément
selon 3 axes pour hiérarchiser les préoccupations et les questions auxquelles répondre lors de
la conduite d'un projet :
• Cycle de vie : Phases de conception, de réalisation, de maintenance puis nouveau cycle de
projet.
• Cycle de décision : Des grands choix (GO-NO GO : Étude préalable), la définition du projet
(étude détaillée) jusqu'aux petites décisions des détails de la réalisation et de la mise en
oeuvre du système d'information. Chaque étape est documentée et marquée par une prise de
décision.
• Cycle d'abstraction : Niveaux conceptuels, logique / organisationnel et physique /
opérationnel (du plus abstrait au plus concret). L'objectif du cycle d'abstraction est de prendre
d'abord les grandes décisions métier, pour les principales activités (Conceptuel) sans rentrer
dans le détail de questions d'ordre organisationnel ou technique.
Relativement à ces descriptions (encore appelées modèles) la méthode Merise préconise 3
niveaux d'abstraction :
- Le niveau conceptuel qui décrit la statique et la dynamique du système d'information en
se préoccupant uniquement du point de vue du gestionnaire.
- Le niveau organisationnel décrit la nature des ressources qui sont utilisées pour supporter
la description statique et dynamique du système d'information. Ces ressources peuvent être
humaines et/ou matérielles et logicielles.
- Le niveau opérationnel dans lequel on choisit les techniques d'implantation du système
d'information (données et traitements).
La conception du système d'information se fait par étapes, afin d'aboutir à un système
d'information fonctionnelle reflétant une réalité physique. Il s'agit donc de valider une à une
chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part,
les données étant séparées des traitements, il faut vérifier la concordance entre données et
traitement afin de vérifier que toutes les données nécessaires aux traitements sont présentes
et qu'il n'y a pas de données superflues.
Cahier des charges
Nous allons présenter un exemple détaillé afin d'appréhender les différentes étapes de la
conception à la réalisation d'une base de données auquel nous nous rapporterons tout au long
de l'ouvrage.
Le souci majeur de M. Purchase, chef de la production informatique de la société Bidouille
Express, est d'assurer la gestion et le suivi des produits consommables tels que :
- Papier listing en continu sous toutes ses formes,
- Papier pré imprimé (commandes, factures, bulletins de paie...)
- Rubans pour imprimantes
- Bandes magnétiques,
- Disquettes,
Pour chacun de ces produits, il existe plusieurs fournisseurs possibles ayant déjà livré la
société ou avec lesquels M. Purchase est en contact. De plus, de nombreux représentants
passent régulièrement vanter leurs produits et leurs conditions de vente : ceci permet à M.
Purchase de conserver leurs coordonnées pour d'éventuelles futures commandes ou futurs
appels d'offres. M. Purchase demande à chaque fournisseur ou représentant de lui proposer 3
tarifs différents en fonction de la quantité commandée et de mentionner leur délai de
livraison.
Un degré de satisfaction est géré pour chaque fournisseur.
La commande est envoyée au fournisseur pour l'achat d'un ou plusieurs produits pour une
quantité et un prix donnés. Cette quantité peut être livrée en plusieurs fois. Les seules
informations mémorisées sont la date de dernière livraison ainsi que la quantité livrée totale.
Les règles de gestion
- Plusieurs fournisseurs ou représentants peuvent vendre le même produit à un prix fixé par
le fournisseur, dépendant des quantités commandées (3 tranches de prix).
- Une commande est passée à un fournisseur ; elle se compose de plusieurs lignes,
référençant chacune un produit.
- Le prix unitaire à la commande est fonction de la quantité commandée.
Conception de la base de données avec Power AMC
Power AMC est un logiciel de modélisation. Il permet de modéliser les traitements
informatiques et leurs bases de données associées. Nous allons utilisez Power AMC pour la
construction du Modèle Conceptuel de données à l'aide de la méthode Merise.
Au niveau conceptuel on veut décrire le modèle (le système) de l'entreprise ou de l'organisme
• Le Modèle conceptuel des données (MCD), schéma représentant la structure du système
d'information, du point de vue des données, c'est-à-dire les dépendances ou relations entre
les différentes données du système d'information (par exemple : Le client, la commande, la
ligne de commande...),
• Et le Modèle conceptuel des traitements (MCT), schéma représentant les traitements, en
réponse aux événements à traiter (par exemple : La prise en compte de la commande d'un
client).
Le MCD repose sur les notions d'entité et d'association et sur les notions de relations. Le MCT
quant à lui est très peu utilisé est ne sera pas étudié au cours de ce tutoriel.
Pour créer un MCD avec Power AMC, créer un modèle directement à partir de l'écran de
démarrage ou alors en passant par le menu : Fichier / Nouveau modèle...
Dans « Type de modèle, sélectionnez « Modèle Conceptuel de Données » puis
« Diagramme Conceptuel ». Nous nommerons notre exemple « Papyrus ».
Créer des domaines
Vous avez la possibilité de créer un type de données pour des champs déterminés sous Power
AMC par le menu « Modèle » / « Domaine ». Par exemple, on peut définir un champ Adresse
qui correspondra toujours au type de données défini (dans l'exemple, notre champ Adresse
sera de type caractère variable de longueur 40).
Le dictionnaire des données
Les champs utilisés dans les différentes entités sont listés dans le tableau ci-dessous :
CODART
Code produit
char(4)
CONFGU
Contact chez le fournisseur
varchar(15)
DATCOM
Date de commande
smalldatetime
DELL IV
Délai de livraison
smaliint
DERLIV
Date dernière livraison
date
LIBART
Libellé Produit
varchar{30)
NUMCOM
Numéro de commande
int
N UMF OU
N 3 de compte fournisseur
int
NUMLIG
N® de ligne commande
tin vint
IMGMFOU
Nom fournisseur
varchar(30)
OBSCOM
Observations
varchar(25)
PGSFOU
Code postal fournisseur
char(5)
PRIUNI
Prix unitaire de vente
smallmoney
PRIX1
Prix unitaire 1
smallmoney
PRIX2
Prix unitaire 2
smallmoney
PR 1X3
Prix unitaire 3
smallmoney
QTE1
Borne quantité livraison 1
smaliint
QTE2
Borne quantité livraison 2
smaliint
QTE3
Borne quantité livraison 3
smaliint
QTEÀNN
Quantité annuelle
smaliint
QTECDE
Quantité commandée
smaliint
QTELIV
Quantité livrée
smaliint
RUEFOU
Adresse fournisseur
varchar(3ü)
SATISF
Indice satisfaction
tinyint
STKALE
Stock d’alerte
smaliint
STKPHY
Stock physique
smaliint
UNIMES
Unité de mesure
char{5)
VILFGU
Ville fournisseur
varchar{30)
Pour accéder aux dictionnaires des données avec Power AMC, utilisez le menu. Cliquez sur
« Modèle » puis sur « Informations ».
Propriétés du modèle...
Packages...
Règles de gestion...
Domaines...
Informations...
Entités...
TdFntifinntç...
Vous pouvez alors remplir la liste comme suit :
On devra préciser le type des données attendues pour chaque attribut.
CGDART
CODART
CCI N FO U
Caractère (4)
CO N FO IJ
DATCC
DELLIV
• Types de données standard
a J *
DERLN
LÏBAR
NCi'MFC
N IJ MCI
N IJ M Fl
NÏÏMÏÏ
OBSCC
PRIUN
PRÏXÏ
PR 1X2
PFIÏX3
QTË'ïj
QTË2
Q TE 3
QTËÀÜ
QTËCD
QTËLPv
FlLIËFi
SATIS
STKAL
SfKPH
UNÏMË:
VÏLFOL
Caractère variable [151 ' 15
Entier
u Caractère
Binaire
Entier court
Caractère variable
Binaire variable
Entier long
Caractère long
Binaire long
Octet
Caractère long var.
Numérique
Texte
Bitmap
Décimal
Multibyte
Image
Réel
Multibyte variable
OLE
Réel court
Réel long
Date
Monnaie
Heure
Autre
Séquentiel
Date & heure
Non défini
Booléen
Date système
Code :
Longueur : 4 Précision :
( J
Annuler
Aide
À noter que dans le cas où vous ne le remplissez pas, celui-ci se remplira automatiquement
au fur à mesure que nous compléterons notre modèle.
Utilisation de la palette
On utilisera la palette pour positionner les différents éléments qui composeront votre modèle
conceptuel des données.
Palette
S
<25
'Si.
%
&
&
i!ï3
m
%
£
©
l)
m
J
s
m
\
~\
□
O
O
a/
0 >
PS : Si celle-ci n'apparaît pas à l'écran, vous avez la possibilité de l'afficher en utilisant le
menu « Outils » puis « Personnaliser les barres d'outils... ».
Paramètres relatifs aux licences...
Ressources ►
Appliquer un profil utilisateur..,
Personnaliser les barres d'outils...
Préférences d'affichage...
Options du modèle...
Options générales...
Vous devez alors cliquer sur la case « Palette » pour pouvoir l'afficher.
LJ L'entité et les attributs
L'entité est définie comme un objet de gestion considéré d'intérêt pour représenter l'activité à
modéliser (exemple : entité Produit) et chaque entité est porteuse d'une ou plusieurs
propriétés simples (appelé attributs), dites atomiques. Exemples : CODART (qui représentera
le code du produit), LIBART (libellé du produit)...
PlEduit
CODART
CaractE-re !'4S
-=:Q>
LIBART
CaiactèrE variât Ie {3Æ )
<o>
STKALE
Enti£* csurt
<o>
STKPHY
Entier ccurt
<o>
QTEANN
EntiEf csurt
<o>
UNIMES
CaractÈiE variable
<o>
CODART
<pi>
Pour compléter votre entité, cliquez droit / propriété.
Sur l'onglet « Général », on indique le nom de notre entité. Pour compléter nos différents
attributs, cliquez sur l'onglet « Attributs ».
Si vous avez créé un domaine, alors c'est ici que vous devez l'indiquer. Le type de données se
sélectionne alors automatiquement.
On cochera les cases « O » s'il s'agit d'une donnée obligatoire ou facultative et « P » pour
indiquer la clé primaire. Une entité doit en effet posséder une propriété unique et
discriminante, qui est désignée comme identifiant (exemple : CODART). On reportera cette
information sur l'onglet « Identifiants ».
On devra préciser le type des données attendues pour chaque attribut.
Par construction, le MCD impose que tous les attributs d'une entité aient vocation à être
renseignées (il n'y a pas d'attribut « facultatif »). Les informations calculées (ex: montant
taxes comprises d'une facture), déductibles (ex: densité démographique = population /
superficie) ne doivent pas y figurer.
L'association (ou relation)
Ce sont des liaisons logiques entre les entités. Elles peuvent être de nature factuelle, ou de
nature dynamique. Par exemple, une personne peut acheter un objet (action d'acheter), mais
si l'on considère qu'une personne est propriétaire d'un objet, alors l'association entre l'objet et
cette personne est purement factuelle.
Les associations se représentent dans une ellipse (ou un rectangle aux extrémités rondes),
reliée par des traits aux entités qu'elles lient logiquement.
Une association peut elle aussi contenir des attributs.
La plupart des associations sont de nature binaire, c'est à dire composées de deux entités
mises en relation par une ou plusieurs associations. C'est le cas par exemple de l'association
"est propriétaire" mettant en relation "être humain" et "appartement".
Cependant il arrive qu'une association concerne plus de deux entités (on dit alors qu'il s'agit
d'association "n-aires").
Mais dans ce cas il y a de grandes difficultés pour exprimer les cardinalités. On aura tout
intérêt à essayer de transformer le schéma de manière à n'obtenir que des associations
binaires.
Il arrive dans certains cas que l'attribut "date" soit d'une importance capitale, notamment
dans les applications SGBDR portant sur la signature de contrats à échéance ou dans la durée
(assurance par exemple). Il n'est pas rare alors que le seul attribut "date" constitue à lui seul
une entité.
ETRE HUMAIN
Numéro se ou
A13
Nom
AJ2
P renom
A25
Date de naissance
D
Li*u d& naijgjn&e
A32
Sexe
BL
Q.n
DATE
Date de souisoriplion
ü.n
_f sou s crû \
V l
U _
POUCE
Numéro de contrat
j
Date d 1 échéance
Ù
Type de poiice
Aie
C Jpitil mobllïitf
MN
On appelle alors cela une entité temporelle. Une entité temporelle possède souvent un seul
attribut, mais dans le cas où elle possède plusieurs attributs (année, mois, jour, heure,
minute, seconde...), l'ensemble de ces attributs constitue alors la clef de l'entité.
Mais dans ce cas on peut aussi retirer cette entité et introduire la date en tant qu'attribut de
l'association "souscrit". Deux mêmes entités peuvent être plusieurs fois en association.
Il est permis à une association d'être branchée plusieurs fois à la même entité, par exemple
l'association binaire réflective suivante :
Une occurrence d'association est un lien particulier qui relie deux occurrences d'entités. Le
schéma ci-dessous présente deux exemples d'occurrences de l'association « Habite ».
Remarque : Certains auteurs définissent l'identifiant d'une association comme étant la
concaténation des identifiants des entités qui participent à l'association.
Toute occurrence d'une association de dimension n doit être reliée à n occurrences d'entités.
Par exemple, pour une association ternaire dans laquelle participent trois entités « A », « B »
et « C », toute occurrence doit être reliées à 3 occurrences des entités respectives A, B et C.
On ne peut donc pas avoir une occurrence à 2 pattes de la forme ci-dessous.
Occurrence de A
1_
Occurrence de C
Dans le schéma ci-dessous, les entités "Personne physique" (des êtres humains) et "Personne
morale" (des sociétés, associations, collectivités, organisations...) sont généralisées dans
l'entité "Propriétaire". On dit aussi que l'entité "Propriétaire" est une entité parente et que les
entités "Personne morale" et "Personne physique" sont des entités enfants, car il y a une
notion d'héritage...
Par exemple une entité "Être humain" est une généralisation pour toute entité faisant appel à
une personne, comme les entités "Étudiant", "Client", "Artiste", "Souscripteur", "Patient",
"Assujetti"... On les appelle aussi "entités-génériques". Certains ateliers de modélisation
représentant les données sous la forme d'entités « encapsulées ».
Les cardinalités
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à
laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une
borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut
prendre sa valeur :
. La borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une entité
peut participer à une relation
. La borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une entité
peut participer à une relation
On note les cardinalités de chaque côté de l'association, sur les traits faisant la liaison entre
l'association et l'entité.
ETRE HUMAIN
Nu m«fc se eu
611
Nom
A32
Prtrwm
A25
Date de naissance
D
Litu 4 * n iis j ne#
A32
Sexe
BL
APPARTEMENT
Numéro aippartement
Ligne adresse 1
A32
Ligne adresse 2
A32
Ligne adresse 3
A32
Code postal
A7
Ville
A32
Pays
A32
Bâtiment
AB
Ëfoilitr
AB
Etage
A3
Porte
A4
Dans l'exemple précédent, tout employé est dirigé par un autre employé (sauf le directeur
d'où le 0,n) et un employé peut diriger plusieurs autres employés, ce qui explique les
cardinalités sur le schéma.
Des relations différentes entre mêmes entités peuvent posséder des cardinalités
différentes. C'est même souvent le cas.
ÊTRE HUMAIN
Nunwo «eu
ai a
Nom
A32
Priera
A2S
Date de naissance
D
Li«u 44 njisfinet
A3 2
Sexe
B|_
Oji-
APPARTEMENT
Numéro appartement
1
Ligne adies&e 1
A32
Ligne adresse 2
A32
Ligne adresse 3
A32
Code pgsljl
A7
Ville
A32
Pays
A32
B ati m e ni
AB
Escalier
AS
Etage
A3
Perte
A4
La relation
La relation
La relation
« loue » est de type n:m.
« réside » est de type l:n.
« possède » est de type n:m.
Pour revenir à notre cas pratique, on en déduit les cardinalités suivantes :
Règles de normalisation
. Normalisation des entités : Toutes les entités qui sont remplaçables par une association
doivent être remplacées.
. Normalisation des noms : Chaque entité doit posséder un identifiant qui caractérise ses
individus de manière unique. Le nom d'une entité, d'une association ou d'un attribut doit être
unique.
. Normalisations des identifiants : L'identifiant peut être composé de plusieurs attributs,
mais les autres attributs de l'entité doivent être dépendant de l'identifiant en entier (et non
pas une partie de cet identifiant). Ces deux premières formes normales peuvent être oubliées
si on suit le conseil de n'utiliser que des identifiants non composés de type numéro.
. Normalisation des attributs des associations : Les attributs d'une entité doivent
dépendre directement de son identifiant. Par exemple, la date de fête d'un client ne dépend
pas de son identifiant numéro de client, mais plutôt de son prénom. Elle ne doit pas figurer
dans l'entité clients, il faut donc faire une entité « calendrier » à part, en association avec
clients.
En effet, d'une part, les attributs en plusieurs exemplaires posent des problèmes d'évolutivité
du modèle (comment faire si un employé à deux adresse secondaires ?) et d'autre part, les
attributs calculables induisent un risque d'incohérence entre les valeurs des attributs de base
et celles des attributs calculés.
. Normalisation des associations : Les attributs des associations doivent dépendre des
identifiants de toutes les entités en association. Par exemple, 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.
. Normalisation des cardinalités : Il faut éliminer les associations fantômes, redondantes
ou en plusieurs exemplaires.
Le modèle logique des données (MLD)
La transcription d’un MCD en modèle relationnel s'effectue selon quelques règles simples qui
consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire,
puis à observer les valeurs prises par les cardinalités maximums de chaque association pour
représenter celle-ci soit (ex : card. max 1-n ou 0-n) par l'ajout d'une clé étrangère dans une
table existante, soit (ex : card. max n-n) par la création d'une nouvelle table dont la clé
primaire est obtenue par concaténation de clés étrangères correspondant aux entités liées.
Règle n°l : Toute entité doit être représentée par une table. Toute entité devient une table
dans laquelle les attributs deviennent des colonnes. L'identifiant de l'entité constitue alors la
clé primaire de la table.
Règle n°2 : Dans le cas d'entités reliées par des associations de type 1:1, les tables doivent
avoir la même clef.
Règle n°3 : Dans le cas d'entités reliées par des associations de type l:n, chaque table
possède sa propre clef, mais la clef de l'entité côté 0,n (ou l,n) migre vers la table côté 0,1
(ou 1,1) et devient une clef étrangère (index secondaire).
Règle n°4 : Dans le cas d'entités reliées par des associations de type n:m, une table
intermédiaire dite table de jointure, doit être créée, et doit posséder comme clef primaire une
conjonction des clefs primaires des deux tables pour lesquelles elle sert de jointure.
Règle n°5 : Cas des associations pourvues d'au moins un attribut :
. Si le type de relation est n:m, alors les attributs de l'association deviennent des attributs de
la table de jointure.
. Si le type de relation est l:n, il convient de faire glisser les attributs vers l'entité pourvue
des cardinalités 1:1.
. Si le type de relation est 1:1, il convient de faire glisser les attributs vers l'une ou l'autre des
entités.
Avec Power AMC, le modèle logique de données se génère automatiquement si vous avez
préalablement complété comme il se doit votre Modèle Conceptuel de données. Cliquez sur
« Outils » de la barre de menu puis « Générer un Modèle Logique de Données... ».
Editeur de correspondances...
Générer un Modèle Conceptuel de Données..
Ctrl+Maj+C
Générer un Modèle Logique de Données...
Ctrl+Maj + L
Générer un Modèle Physique de Données...
Ctrl+Maj+P
Générer un Modèle Orienté Objet...
Ctrl+Maj+O
Des options de configurations sont alors disponibles :
Cliquez sur « Ok » pour générer le MLD :
La base de données relationnelle PAPYRUS est constituée des relations suivantes :
PRODUIT ( CODART. LIBART, STKLE, STKPHY, QTEANN, UNIMES)
ENTCOM ( NUMCOM. OBSCOM, DATCOM, NUMFOU)
LIGCOM ( NUMCOM. NUMLIG. CODART, QTECDE, PRIUNI, QTELIV, DERLIV)
FOURNIS ( NUMFOU. NOMFOU, RUEFOU, POSFOU, VILFOU, CONFOU, SATISF)
VENDRE ( CODART. NUMFOU. DELLIV, QTE1, PRIX1, QTE2, PRIX2, QTE3, PRIX3)
Modèle physique de données (MPD)
Le MPD est une implémentation particulière du MLD pour un matériel, un environnement et un
logiciel donné. Notamment, le MPD s'intéresse au stockage des données à travers le type et la
taille (en octets ou en bits) des attributs du MCD. Cela permet de prévoir la place nécessaire à
chaque table dans le cas d'un SGBDR.
Le MPD tient compte des limites matérielles et logicielles afin d'optimiser l'espace consommé
et d'optimiser le temps de calcul (qui représentent deux optimisations contradictoires). Dans
le cas d'un SGBDR, le MPD définit les index et peut être amené à accepter certaines
redondances d'information afin d'accélérer les requêtes.
Tout comme pour le modèle logique de données, avec Power AMC, le modèle physique de
données se génère automatiquement si vous avez préalablement complété comme il se doit
votre Modèle Conceptuel de données. Cliquez sur « Outils » de la barre de menu puis
« Générer un Modèle Physique de Données... ».
Editeur de correspondances...
Générer un Modèle Conceptuel de Données..
Générer un Modèle Logique de Données...
Générer un Modèle Physique de Données...
Générer un Modèle Orienté Objet...
Ctrl+Maj+C
Ctrl+Maj+L
Ctrl+Maj+P
Ctrl+Maj+O
Vous devez alors configurer les différentes options et notamment le SGBD dans lequel nous
allons créer notre base de données.
Sur l'onglet « Détails » on précisera les options suivantes
Nous obtenons le MPD suivant :
Créer la base de données
Création de la base de données sous SQL Server
Les bases de données sont les ensembles ou nous allons stocker des objets tels que les tables, les
vues, les index... Il existe deux façons de créer des bases de données sous SQL Server. En utilisant
l'interface proposée par « Microsoft SQL Server Management Studio », ou bien en utilisant le code
T-SQL. Chacune de ces deux méthodes possède ses avantages et ses inconvenants, il vous appartient
d'adopter celle que vous trouvez la plus productive ou bien la plus pratique.
En utilisant l'interface
Pour créer une base de données sous SQL Server en utilisant le programme « Microsoft SQL
Server Management Studio » (SSMS), cliquez droit sur « Bases de données » pour
« Nouvelle base de données... ».
.. . Microsoft SQL Server Management Studio
Fichier Edition Affichage Outil: Fenêtre Communauté Aide
Nouvelle requête [Jj ^ S Si Ql bâ ■ -
Explorateur d'objets ▼ fl- X
Connexion T ^ jjf] ^
B IjJ (localj (SQL Si
srver 10,0.4000 - 03112-375\cdi01)
1+1 li ^ ! i v,T L .ȣ
0 lJ Sécurité
0 _J Objets ser
0 Réplicatio
0 lSI Gestion
0 S Agent SQL
Nouvelle base de données,,.
Joindre..,
Restaurer la base de données...
Restaurer les fichiers et les groupes de fichiers...
Démarrer PowerShell
Rapports ►
Actualiser
Nous nommerons la base « Papyrus ».
Par le code
Vous pouvez également créer la base de données en utilisant le langage Transact SQL. Le T-
SQL (Transact Structured Query Langage) est un langage de communication avec une base de
données relationnelle SQL Server. Il définit une batterie « simple », mais complète de toutes
les opérations exécutables sur une base de données (lecture de données, opérations
d'administration du serveur, ajout, suppression et mises à jour d'objets SQL - tables, vues,
procédures stockées, déclencheurs, types de données personnalisés...). Ce langage est
composé d'instructions, réparties dans de 3 catégories distinctes :
- DML : Data Modification Language, soit langage de manipulation de données. Dans cette
catégorie, s'inscrivent les instructions telles que l'instruction SELECT ou encore les
instructions qui nous permettent la création, la mise à jour et la suppression de données
stockées dans les tables de la base de données. Il est important de retenir que le DML sert
simplement pour les données, et en aucun cas pour la création, mise à jour ou suppression
d'objets dans la base de données SQL Server.
- DDL : Data Définition Language, soit langage de définition de données. Les instructions de
cette catégorie, permettent d'administrer la base de données, ainsi que les objets qu'elle
contient. Elles ne permettent pas de travailler sur les données.
- DCL : Data Control Language, soit langage de contrôle d'accès. Cette catégorie
d'instructions nous permet de gérer les accès (autorisations) aux données, aux objets SQL,
aux transactions et aux configurations générales de la
Lire la suite
- 9.12 MB
- 15
Vous recherchez le terme ""
30
1
0
