Conception logique
Projet base de données – 1A – ENS Cachan
GROSSHANS Nathan
nathan.grosshans@lsv.ens-cachan.fr
3 mars 2017
Motivation
I Les données d’une base de données sontorganisées, au niveau logique, d’une certaine manière conforme à un certainmodèle logique de données.
I Parmi ces modèles logiques on notera le modèle relationnel, ou encore XML.
I Après l’élaboration du schéma conceptuel, il est nécessaire de traduire celui-ci en schéma logiqueéquivalent conforme à un certain modèle.
I Ceci s’effectue parapplications successives au schéma source detransformations préservant la sémantique du schéma.
Livre de référence utilisé pour cette séance
Hainaut J.-L.,Bases de données : Concepts, utilisation et développement. 1ère édition (2009).
Introduction
Modèle
Modèle logique de données classique : lemodèle relationnel.
Définition
Un schéma est ditrelationnels’il respecte les contraintes suivantes.
1. Le schéma comporte des types d’entités (appelés tables).
2. Tout type d’entités possède au moins un attribut (appelé colonne).
3. Un attribut est mono-valué et atomique ; il est obligatoire ou facultatif.
4. Les seules contraintes sont celles qui sont induites par les identifiants (identifiant primaire ousecondaire) et les attributs de référence (clés étrangères).
5. Le schéma relationnel ne contient pas d’autres constructions.
6. Les noms ne contiennent pas d’espaces, de tirets, de signes de ponctuation, d’accents ou d’autres symboles spéciaux autres que ‘_’.
Clés étrangères
Définitions
I Étant donné deux tables T et T0, une clé étrangère deT vers T0 est un ensemble de colonnesE deT, copie d’un identifiant E0 deT0 vérifiant que pour tout n-uplet t deT, il existe un n-uplet t0 de T0 tel que la valuation donnée aux colonnes de E dans t corresponde à la valuation donnée aux colonnes de E0 danst0 (contrainte référentielle).
I Les colonnes de E et E0 sont donc enmême nombre et de mêmes types.
I Les colonnes de E sont soit toutes obligatoires, soit toutes facultatives et coexistantes (tout n-uplet a soit toutes ses colonnes à NULL, soit elles sont toutes différentes de NULL et référencent un n-uplet de T0).
I En général,E0 est l’identifiant primaire de T0.
Introduction
Clés étrangères
Représentation graphique
. . .T . . . ref :e1
.. . ek
. . .T’
id :e10 .. . ek0 . . .
Exemple
CONTRAT num_contrat : uint id_client : uint type : varchar(50) duree : uint id : num_contrat
id_client ref : id_client
CLIENT id_client : uint nom : varchar(30) prenom : varchar(30) anciennete : uint id : id_client
Principe
I Application successive derègles de traduction à un schéma EA source jusqu’à obtenir un schéma relationnel.
I De telle manière que le schéma obtenu après chaque étape soit sémantiquement équivalentau schéma original.
I On supposera ici que le schéma EA source estsimple, c’est-à-dire qu’il vérifie les propriétés suivantes.
I Les types d’associations sont simples, c’est-à-dire binaires, sans attributs ni identifiants, et chacun des rôles ayant pour cardinalité 0–1, 1–1 ou 0–N.
I Le schéma ne contient pas de relation est-un.
Types d’entités
Les types d’entités se traduisent directement, sans transformation.
Traduction
Types d’associations
Un-à-plusieurs
E1 id_1 id : id_1
E2 id_2 id : id_2 R
0–N 1–1
E1 id_1 id : id_1
E2 id_2 id_1 id : id_2 ref : id_1
Types d’associations
Un-à-un
E1 id_1 id : id_1
E2 id_2 id : id_2 R
0–1 1–1
E1 id_1 id : id_1
E2 id_2 id_1 id : id_2 id’ : id_1
ref
Traduction
Types d’associations
Plusieurs-à-plusieurs
E1 id_1 id : id_1
E2 id_2 id : id_2 R
0–N 0–N
E1 id_1 id : id_1
R id_1 id_2 id : id_1
id_2 ref : id_1 ref : id_2
E2 id_2 id : id_2
Divers
Identifiants
SoitE un type d’entités et un identifiant deE contenant :
I les attributs a1, . . . ,ak;
I les rôles opposésR1.E1, . . . ,Rl.El.
SoitT la table obtenue par traduction deE, ainsi que T1, . . . ,Tl les tables obtenues par traduction, respectivement, deE1, . . . ,El. On noteraC1, . . . ,Cl les ensembles des colonnes référençant, respectivement, les identifiants primaires deT1, . . . ,Tl. L’identifiant correspondant deT sera{a1, . . . ,ak} ∪Sli=1Ci. Noms
Veiller à ce que les noms soientconformesaux restrictions imposées dans la définition d’un schéma relationnel ; les convertir sinon.
Contraintes d’intégrité additionnelles
Il faut lesréexprimersur le schéma relationnel.
Traduction
Exemple
PERSONNE nss : uint
nom : varchar(30) prenom : varchar(30) date_naissance : date id : nss
DIPLOME nom : varchar(50)
id : DELIVRE.INSTITUTION nom
A 0–N
0–N
INSTITUTION id_institution : uint nom : varchar(50) ville : varchar(50) budget[0–1] : uint id : id_institution id’ : nom
ville DELIVRE
1–1
0–N
DIRIGE
0–1
1–1
APPARTIENT
mère 0–N
fille 0–1
Exemple
DIPLOME id_institution : uint nom : varchar(50) id : id_institution
nom
ref : id_institution
A nss : uint
id_institution : uint nom : varchar(50) id : nss
id_institution nom
ref : nss
ref : id_institution nom
PERSONNE nss : uint
nom : varchar(30) prenom : varchar(30) date_naissance : date id : nss
INSTITUTION id_institution : uint nom : varchar(50) ville : varchar(50) budget[0–1] : uint mere[0–1] : uint dirigeant : uint id : id_institution id’ : nom
ville id’ : dirigeant ref : mere ref : dirigeant
Restructuration
Principe
I Si le schéma EA source n’est pas simple, il faut d’abord le restructurer pour que ce soit le cas.
I Cela se fait à nouveau par transformations successives préservant la sémantique.
Cardinalité
Si la cardinalité i–j d’un rôle dans un type d’associations n’est pas 0–1, 1–1 ou 0–N, alors on la remplace par 0–N et l’on ajoute une contrainte additionnelle forçant la bonne cardinalité.
Contraintes d’intégrité additionnelles
Il faut veiller, si nécessaire, à les adapter suite à chaque étape de restructuration.
Types d’associations complexes
E1 id_1 id : id_1
E2 id_2 id : id_2
. . . . . .
En id_n id : id_n
R id id : id
E1 E2 . . . En
0–N 0–N
0–N
Restructuration
Types d’associations complexes
E1 id_1 id : id_1
E2 id_2 id : id_2
. . . . . .
En id_n id : id_n
R id id : id
R1.E1 R2.E2 . . . Rn.En R1
0–N
1–1
R2
0–N
1–1
Rn
0–N
1–1
Relations est-un
Matérialisation
. . .A . . .
B1
. . . . . .
. . . Bn
. . . . . .
. . .A . . .
B1
. . . id :R1.A . . .
R1 1–1
0–1
. . . . . .Bn id :Rn.A . . . Rn
1–1 0–1
. . .
En fonction de la variante, il faut ajouter diverses contraintes.
I Sans contraintes : aucune contrainte.
I Recouvrement total :
∀a∈A,|{i ∈[n]| ∃b ∈Bi,b.Ri.A=a}| ≥1.
I Disjonction:∀a∈A,|{i ∈[n]| ∃b ∈Bi,b.Ri.A=a}| ≤1.
I Partition :∀a∈A,|{i ∈[n]| ∃b ∈Bi,b.Ri.A=a}|= 1.
Restructuration
Relations est-un
Héritage descendant
A id a1
. . . al
id : id . . .
B1
b1,1
. . . b1,k1
. . .
. . . Bn
bn,1
. . . bn,kn
. . .
A0 id a1
. . . al
id : id . . .
B1
id a1
. . . al
b1,1
. . . b1,k1
id : id . . .
. . .
Bn
id a1
. . . al
bn,1
. . . bn,kn
id : id . . .
Relations est-un
Il faut obligatoirement ajouter les contraintes suivantes.
I ∀i,j ∈[n],∀(b,b0)∈Bi×Bj,(b.id =b0.id ⇒ ∀ι∈[l],b.aι = b0.aι).
I ∀a0∈A0,@i ∈[n],∃b ∈Bi,b.id =a0.id.
De plus, en fonction de la variante, il faut ajouter diverses contraintes.
I Sans contraintes : aucune contrainte.
I Recouvrement total :|A0|= 0.
I Disjonction:
∀i,j ∈[n],(i 6=j ⇒ {b.id |b∈Bi} ∩ {b0.id |b0∈Bj}=∅).
I Partition :|A0|= 0∧ ∀i,j ∈[n],(i 6=j ⇒ {b.id |b∈ Bi} ∩ {b0.id |b0 ∈Bj}=∅).
Restructuration
Relations est-un
Héritage ascendant
A id a1
. . . al
id : id . . .
B1
b1,1
. . . b1,k1
. . .
. . . Bn
bn,1
. . . bn,kn
. . .
A id a1
. . . al
B1_b1,1[0–1]
. . .
B1_b1,k1[0–1]
. . . . . . . . .
Bn_bn,1[0–1]
. . .
Bn_bn,kn[0–1]
id : id . . .
Relations est-un
Il faut obligatoirement ajouter la contrainte suivante :∀a∈A,∀s ∈ [n],∀i,j ∈[ks],(Bs_bs,i 6= NULL⇔Bs_bs,j 6= NULL).
Cette contrainte est plus complexe si au moins un des attributs d’un des sous-types est facultatif.
De plus, en fonction de la variante, il faut ajouter diverses contraintes.
I Sans contraintes : aucune contrainte.
I Recouvrement total :
∀a∈A,|{i ∈[n]|Bi_bi,16= NULL}| ≥1.
I Disjonction:∀a∈A,|{i ∈[n]|Bi_bi,16= NULL}| ≤1.
I Partition :∀a∈A,|{i ∈[n]|Bi_bi,1 6= NULL}|= 1.
