Traduction d’un diagramme Entité/Relation dans le modèle relationnel

Cours bases de données traduction d’un diagramme Entité/Relation dans le modèle relationnel, tutoriel & guide de travaux pratiques bases de données en pdf.

– Rappel du cours précédent :

Type T d’entités faible : il n’a pas de clé propre, il faut prendre des clés d’autres types T1, ……, Tn
pour lesquels il existe des associations fonctionnelles de T vers les Ti.
De telle entités faible s’introduisent quand on veut éclater une association d’arité (nombre de composants) ≥3 en une famille d’associations binaires fonctionnelles.

Le modèle relationnel (E.F. Codd 1970 IBM)

Buts de ce modèle:
– Indépendance des programmes d’applications et des sessions interactives vis à vis de la représentation interne des données.
– Base théorique solide pour traiter des problèmes de cohérence et de redondance.
1) Les tables ou le modèle relationnel tel qu’il apparaît à l’utilisateur
Pour un SGBD relationnel on a les propriétés suivantes :
1. Il n’y a que des tables
• Un table consiste en un schéma relationnel qui comporte :
– Le nom de la table,.
– Un nom (appelé aussi attribut de la table) et un type (scalaire) pour chaque colonne.
• Des contraintes de fonctionnalité, on décrète que tel attribut ou groupe d’attributs G est clé de la table. On déclare les clés candidates et les clés principales.
• Un contenu : des lignes pour lesquels l’élément contenu en colonne A est dit type associé à l’attribut A.
L’ordre des lignes et celui des colonnes est ignoré
a) Ordre des colonnes
C’est un ordre sur les attributs qui n’est pas pertinent. On ne peut référencer une colonne que par son nom (attribut).
b) Ordre des lignes
Il traduit une évolution temporelle de la table donc cet ordre n’est pas pertinent.
On voit donc qu’il n’est pas possible de référencer une ligne.
Mais 2 lignes distinctes doivent différer sur au moins un attribut.
Il y a des opérateurs
Il sont à disposition de l’utilisateur, ils génèrent des tables à partir d’autres tables.
• Création d’une table en SQL (Structured Query Language)
CREATE TABLE Voix_Publique
( Nom VARCHAR
Max_impair INTEGER
Max_pair INTEGER
Quartier VARCHAR
Arrondissement INTEGER
PRIMARY KEY(Nom) )
INSERT INTO Voix_Publique VALUES (‘rue jussieu’,45,4,‘Saint Victor’,5)
2) Modélisation mathématique des tables par les relations
C’est à dire les sous ensemble de produit cartésiens ou encore les ensembles de listes toutes de même taille.
Soit T une table avec des attributs A1, ……, An de domaines associés D1, ……, Dn .
On lui associe une relation R ⊆ D1×D2 ×……Dn .
R est l’ensemble des n-uplet (x1, ……, xn) tels que la table T contienne une ligne ayant : – en colonne A1 la valeur x1. M M
– en colonne An la valeur xn.
Les lignes de T sont des n-uplets de R
Les colonnes de T sont des composantes de R (projection de R sur ces composantes)
Un groupe d’attributs G={Ai1, ……Aik} de T est une clé de T, si et seulement si la relation R est
fonctionnelle par rapport aux composantes i1, ……,ik .
• Formalisme simple sur une théorie mathématique riche.
L’ordre (contingent à la représentation tabulaire) sur les lignes de T a disparu dans cette formalisation car il n’y a pas d’ordre intrinsèque sur les n-uplets de R.
Hélas l’ordre des colonnes lui reste bien présent et intrinsèque, ce qui est fâcheux.
Soit X,Y deux ensembles.
X×Y ≠ Y×X sauf si X=Y ou X=∅ ou Y=∅
(a,b) a,b∈R (a,b) ≠ (b,a)
R ⊆X×X
{(a,b) ∈ X×X (a,b) ∈R} ≠ {(b,a) ∈ X×X (a, b) ∈R}
3) Modélisation mathématique par les ensembles de fonctions de même domaine
Soit T une table avec des attributs A1, ……, An de domaines associés D1, ……, Dn .
On lui associe un ensemble F de fonctions toutes de domaine { A1, ……, An }.
Toutes les fonctions de f∈F vérifient f(A1)∈D1 …… f(An)∈Dn .
En fait :
f∈F ⇔ il existe une ligne de la table T dont : l’élément en colonne A1 est exactement f(A1) M M
l’élément en colonne An est exactement f(An)
– Les lignes de T sont exactement les f de F (vues de façon déroulés) on écrit f(Ai) en colonne Ai, l’ordre des lignes de T a donc disparu car il n’y a pas d’ordre intrinsèque sur l’ensemble F.
– La colonne Ai de T correspond aux f(Ai), f variant dans F. Les colonnes T correspondent donc aux éléments du domaine (ensemble sans ordre intrinsèque) commun des fonctions dans F.
On a perdu l’ordre sur les colonnes.
Traduction d’un diagramme Entité/Relation dans le modèle relationnel
1. Un type d’entités (pas faible) se représente par une table, les attributs de la table sont les attributs du type d’entités, les domaines associés sont les types scalaires associés à ces attributs dans le diagramme E/R.
Tables associés :
Employé(ENom, salaire)
Chef de Rayon (ENom)
Rayon (RNom, RNuméro)
Article (ANom, ANuméro)
2. un sous type E d’un type F se traduit par une table dont les attributs sont ceux du type E et ceux de la clé principale du type F. Par exemple :Chef de Rayon
• Type d’entité (non faible)
Pour un type d’entité (non faible) on associe une table qui possède les propriétés suivantes :
– Les attributs de la table sont les noms des attributs du type d’entités.
– Le domaine d’un attribut de la table est celui associé à l’attribut correspondant du type d’entités.
Exemple :
1. Employé(ENom, Salaire)
2. Rayon(RNom, RNuméro)
3. Article(ANom, ANuméro) ANuméro signifie que c’est une clé potentiel
4. Fournisseur(FNom, FAdresse)
5. Commande(CoNuméro, Date)
6. Client(CNom, CAdresse, Solde)
• Sous type E d’un type F
On lui associe une table dont les attributs sont les noms des attributs de E et ceux des attributs de la clé principale de F, les domaines sont ce qu’on pense.

…….