Vous êtes sur la page 1sur 45

Database Foundations

3-1
Informations supplémentaires sur les relations

Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés.


Feuille de route
Vous êtes ici

Mise en
Informations correspondance
Suivi des
supplémentaires Normalisation et terminologie
modifications
sur les relations et règles de modélisation
de données
de données

DFo 3-1
Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 3
Informations supplémentaires sur les relations
Objectifs
Voici les objectifs de cette leçon :
• Identifier les relations barrées
• Résoudre des relations N:N
• Identifier et illustrer les relations non transférables
• Identifier et dessiner des entités de supertype et de
sous-type
• Identifier des relations hiérarchiques, récursives et
d'arc

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 4
Identifier les relations (barrées)
• Quel est l'UID de l'entité ACCOUNT ?
ACCOUNT BANK
# Number # Number

• L'UID nécessite à la fois le numéro de compte (ACCOUNT


Number) et la relation entre les entités BANK et ACCOUNT.
ACCOUNT BANK
# Number # Number

• L'UID de l'entité ACCOUNT est constitué du numéro de


compte (ACCOUNT Number) ainsi que de celui de la banque
(BANK Number), ce qui est représenté par la barre sur la
ligne de la relation.
DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 5
Relations identifiantes avec plusieurs
entités
• Une entité peut être identifiée de manière unique par le biais
de plusieurs relations.
WORK
ASSIGNMENT
Date Assigned
Duration
Position
EMPLOYEE PROJECT
# ID # Number
Name Title

• L'UID de l'affectation de travail (WORK


ASSIGNMENT) est constitué de l'ID d'employé
(EMPLOYEE ID) et du numéro de projet (PROJECT
Number) (représenté par des barres).
DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 6
Relations N:N

• Les attributs décrivent seulement des entités.


• Si des attributs décrivent une relation, celle-ci doit
être résolue.
ORDER PRODUCT
include
# Number # ID
included in
* Date * Name
* Total ° Description
* Price

Où ajouteriez-vous l'attribut Quantity (Quantité) ?

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 7
Résolution de relations N:N : Exemple 1
• Résolution d'une relation N:N avec une nouvelle entité
d'intersection et deux relations 1:N barrées.

ORDER ORDER ITEM


# Number include * Quantity Entité
° Date for d'intersection
° Total
includes
contained in
• L'UID de l'article commandé
(ORDER ITEM) est constitué PRODUCT
du numéro de commande # ID
* Name
(ORDER Number) et de l'ID ° Description
de produit (PRODUCT ID). * Price

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 8
Caractéristiques de l'entité d'intersection :

• Les relations de l'entité d'intersection sont toujours


obligatoires.
• Les entités d'intersection contiennent généralement
des valeurs exploitables, telles que la quantité
utilisée et les dates. Il s'agit souvent d'entités
volumineuses et volatiles.
• Une entité d'intersection est identifiée par ses
deux relations d'origine (relations identifiantes).

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 9
Scénario : Résolution de relations N:N

Matt, comment résoudriez-vous la


relation N:N suivante entre les entités
MEMBER et BOOK ?
Faculty

MEMBER BOOK
# ID # ID
* First Name take * Title
° Last Name ° Publisher ID
taken by * Author ID
* Street Address
° City
° State
° Zip

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 10
Scénario : Création d'une entité
d'intersection
Je créerais une entité d'intersection avec des
relations identifiantes menant aux entités d'origine.

BOOK TRN
* TRNS Date
for for
° TRNS Type
Matt
on on
MEMBER BOOK
# ID
# ID
* First Name
° Last Name * Title
* Street Address ° Publisher ID
° City * Author ID
° State
° Zip

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 11
Résolution de relations N:N : Exemple 2

• L'historique des postes occupés par un employé n'est


pas stocké dans les entités EMPLOYEE et JOB.

EMPLOYEE JOB
# id # id
* first name * title
held
° last name ° minimum salary
° email held by ° maximum salary
* hire date
* salary

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 12
Résolution des relations N:N à l'aide d'une
entité d'intersection avec des relations
barrées
held for JOB HISTORY held for
° start date
° end date

hold held by

EMPLOYEE JOB
# id # id
* first name * title
° last name ° minimum salary
° email ° maximum salary
* hire date
* salary

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 13
Projet - Exercice 1

DFo_3_1_1_Project

Base de données du magasin Oracle Baseball League


Résolution de relations n à n

DFo 3-1
Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 14
Informations supplémentaires sur les relations
Relations non transférables
• La transférabilité est la capacité d'une relation entre
deux instances d'une entité à évoluer au fil du temps.
• Une relation non transférable ne peut pas être
déplacée entre les instances des entités qu'elle relie.
• Une relation non transférable est représentée par un
losange.

PERSON born in COUNTRY


birthplace of

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 15
Relations non transférables

• Une relation non transférable ne peut être


qu'obligatoire.
• Par exemple, le pays de naissance d'une personne
n'est pas transférable.

PERSON born in COUNTRY


birthplace of

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 16
Scénario
Transférable ou
• Une adhésion non transférable ?
(MEMBERSHIP) doit être
détenue par (held by) une
seule personne (PERSON).
• La relation d'adhésion ne
peut pas être déplacée vers
une autre personne.
MEMBERSHIP held by PERSON
holds the
membership

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 17
Projet - Exercice 2

DFo_3_1_2_Project

Base de données du magasin Oracle Baseball League


Identifier et illustrer les relations non transférables

DFo 3-1
Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 18
Informations supplémentaires sur les relations
Entités de supertype et de sous-type

• L'entité de supertype a une relation parent-enfant


avec un ou plusieurs sous-types.

PK- IdSuperType
Supertype FK1- IdSousTypeA
FK2- IdSousTypeB

PK, FK1- Sous- Sous- PK, FK1-


IdSuperTypeA type A type B IdSuperTypeB

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 19
Entités de supertype et de sous-type

• L'entité de sous-type est un sous-groupe de l'entité


dans un type d'entité possédant des attributs
distincts de ceux des autres sous-groupes.
PK- IdSuperType
Supertype FK1- IdSousTypeA
FK2- IdSousTypeB

PK, FK1- Sous- Sous- PK, FK1-


IdSuperTypeA type A type B IdSuperTypeB

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 20
Dessin d'un sous-type
INSURANCE
• Chaque sous-type est une id

spécialisation d'un supertype et HEALTH


donc doit être inclus dans une deductible

entité. LIFE
payout amount
• Les attributs et les relations
communs à tous les sous-types LIABILITY
value cap
doivent uniquement être indiqués
OTHER
dans le supertype, mais chaque
sous-type en hérite.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 21
Dessin d'un sous-type
INSURANCE
• Un sous-type peut avoir et a id

généralement ses propres HEALTH


attributs et relations. deductible

LIFE
• Il ne peut jamais exister un seul payout amount
sous-type ; il faut en créer un
autre pour contenir le reste. LIABILITY
value cap
OTHER

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 22
Caractéristiques d'un sous-type
• Les sous-types :
– héritent de tous les attributs du supertype ;
– héritent de toutes les relations du supertype ;
– ont généralement leurs propres attributs ou relations ;
– sont dessinés au sein du supertype ;
– n'existent jamais seuls ;
– peuvent eux-mêmes avoir des sous-types ;
– présentent des clés primaires identiques pour le supertype
et le sous-type.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 23
Entités de supertype et sous-type :
exemple
Sharon veut ajouter les types de catégorie de chambre que les
clients peuvent réserver. Par exemple :
• Standard
• Club
• Suite
Elle dispose déjà d'une entité nommée CHAMBRE qui contient
les détails des chambres. Cette entité jouerait alors le rôle
d'entité de supertype. Les catégories de chambre hériteraient
des propriétés de l'entité de supertype, en plus de leurs
attributs spécifiques. La catégorie de chambre serait l'entité
de sous-type.

Standard Suite
Club

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés.
24
Généralisation et spécialisation

• La généralisation est une approche ascendante où


plusieurs entités de niveau inférieur sont combinées
pour former une entité de niveau supérieur en
fonction de leurs caractéristiques communes.
VEHICULE
Approche
ascendante

VOITURE CAMION

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 25
Généralisation et spécialisation

• La spécialisation est une approche descendante où


l'entité de niveau supérieur est divisée en entités de
niveau inférieur.

EMPLOYE
Approche
descendante

EMPLOYE ANCIEN
ACTUEL EMPLOYE

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 26
Règles régissant les entités de sous-type

• Exhaustivité :
– Chaque instance d'un supertype est également une
instance de l'un des sous-types.
– OTHER (AUTRE) doit être inclus en tant que sous-type pour
catégoriser les instances qui ne sont pas définies par l'un
des sous-types existants.
– Exemple : Un employé doit être à temps plein, à temps
partiel ou autre.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 27
Règles régissant les entités de sous-type

• Exclusion mutuelle :
– Chaque instance du supertype appartient à un seul et
unique sous-type.
– Exemple : Un employé ne peut pas être à la fois à temps
plein et à temps partiel.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 28
Identification correcte des sous-types

1. Ce sous-type est-il une STAFF


MANAGER
sorte de supertype ? # id
* first name * budget
2. Ai-je pensé à tous les cas * last name * target
revenue
* date of birth
possibles ? * salary
(Exhaustivité)
ORDER COOK
3. Chaque instance TAKER
* training
appartient-elle à un seul et * overtime
OTHER
unique sous-type ? rate

(Exclusion mutuelle)

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 29
Sous-types imbriqués Supertype STAFF
imbriqué
HOTEL
STAFF
• Vous pouvez # id
MANAGER
* budget
imbriquer * first name
* target
* last name
des sous- * date of birth
revenue
types. * salary
COOK
* training
ORDER TAKER
* overtime rate OTHER

NON STAFF
# id
* first name * date of birth
* last name * salary

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 30
Projet - Exercice 3

DFo_3_1_3_Project

Base de données du magasin Oracle Baseball League


Identifier et dessiner des entités de supertype et de
sous-type

DFo 3-1
Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 31
Informations supplémentaires sur les relations
Modélisation des données hiérarchiques
COMPANY COMPANY
Représentation des données # ID
made up of hiérarchiques sous la forme made up of

within
d'un ensemble de within
relations 1:N.
DIVISION DIVISION
# Div ID
made up of made up of
Les UID d'un ensemble
within
d'entités hiérarchiques
within

DEPARTMENT peuvent être propagés via DEPARTMENT


# Dept ID
made up of plusieurs relations barrées. made up of

within within

TEAM TEAM
# Team ID

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 32
Relations récursives

• Les relations récursives sont des relations où une


instance d'entité est liée à une autre instance de la
même entité.
Chaque employé
EMPLOYEE (EMPLOYEE) peut
# ID être dirigé par
* First name (managed by) un seul
° Last name et unique employé.
Chaque employé peut ° Manager ID managed by
être le manager (the * Job
manager of) d'un ou de ° Salary
plusieurs employés. the manager of

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 33
Relations récursives

• Elles sont toujours modélisées avec une boucle.

Chaque employé
EMPLOYEE
(EMPLOYEE) peut
# ID
être dirigé par
* First name (managed by) un seul
° Last name et unique employé.
Chaque employé peut ° Manager ID managed by
être le manager (the * Job
manager of) d'un ou de ° Salary
plusieurs employés. the manager of

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 34
Examen des relations récursives
Exemples d'instances :
rondelles, écrous, boulons, pale de
PIECE DE
ventilateur, courroie de ventilateur,
BASE bouchon de radiateur, flexibles,
thermostat

Exemples Exemples
SOUS- ASSEMBLAGE
d'instances : d'instances :
ASSEMBLAGE
ventilateur, radiateur, système de
module d'allumage, refroidissement,
carburateur, starter système
automatique d'allumage, circuit
carburant, moteur
PRODUIT

Exemples d'instances :
voiture, camion, taxi,
tracteur, semi-remorque

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 35
Modélisation générique
• Une autre façon de modéliser la relation récursive
d'une nomenclature consiste à créer une entité
COMPONENT (COMPOSANT) générique.
• Cela créerait une relation N:N récursive
COMPONENT
# ID a part of

made up of

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 36
Résolution d'une relation récursive N:N

• Résolvez la relation COMPONENT


récursive N:N avec une # ID
entité d'intersection.
assembled by the detail part of

master for detail of

ASSEMBLY RULE
o Quantity

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 37
Relation d'arc
• Un arc est un groupe de relations exclusives : une
seule des relations peut exister pour chaque instance
d'une entité.
• L'arc tracé entre les deux relations les relie et
démontre une exclusivité mutuelle.
• Cette relation implique une condition "OR".
• L'arc indique que, à tout moment, n'importe quelle
instance de l'entité ne peut avoir qu'une seule
relation valide parmi les relations de l'arc.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 38
Caractéristiques d'une relation d'arc
– Les relations d'un arc portent souvent le même nom.
– Les relations d'un arc doivent être soit toutes obligatoires,
soit toutes facultatives, et doivent présenter la même
cardinalité.
– Un arc appartient à une seule entité et ne doit comprendre
que les relations qui proviennent de cette entité.
– Une entité peut avoir plusieurs arcs, mais une relation
spécifique ne peut participer qu'à un seul arc.
– Une relation d'arc est représentée par une ligne en arc
englobant plusieurs lignes de relation.
• Les relations incluses dans l'arc affichent un cercle sur la ligne d'arc
de la relation.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 39
Relations d'arc
• Une entité de supertype et ses sous-types peuvent être
modélisés sous la forme d'une relation d'arc.
• Exemple : une entité EMPLOYEE (EMPLOYE) est soit
CURRENT EMPLOYEE (EMPLOYE ACTUEL), soit
EX-EMPLOYEE (ANCIEN EMPLOYE), mais pas les deux
(peut également être modélisé en tant que supertype/sous-
type).
CURRENT
be
EMPLOYEE
EMPLOYEE be

be
EX-
be
EMPLOYEE

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 40
Scénario : Relation d'arc

Matt, sauriez-vous créer une entité


pouvant présenter une relation d'arc ?

Professeur

Je peux créer une entité commune


nommée MEMBERSHIP qui
contiendrait les détails communs à
toutes les catégories d'adhésion. Matt

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 41
Scénario : Création d'une entité commune

holds FACULTY

held by
MEMBERSHIP

held by
STUDENT

holds

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 42
Projet - Exercice 4

DFo_3_1_4_Project

Base de données du magasin Oracle Baseball League


Identifier des relations hiérarchiques, récursives et
d'arc

DFo 3-1
Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 43
Informations supplémentaires sur les relations
Synthèse
Dans cette leçon, vous avez appris comment :
• identifier les relations barrées ;
• résoudre des relations N:N ;
• identifier et illustrer les relations non transférables ;
• identifier et dessiner des entités de supertype et de
sous-type ;
• identifier des relations hiérarchiques, récursives et
d'arc.

DFo 3-1
Informations supplémentaires sur les relations Copyright © 2017, Oracle et/ou ses affiliés. Tous droits réservés. 44