16. Proposez un modèle entités-associationsbien formépermettant de modéliser la situation décrite ci-dessus.
2.7.3 Cas d’une entreprise de dépannage
Une entreprise de dépannage possède plusieurs services spécialisés regroupant chacun un certain nombre d’employés. Les employés ne travaillent que dans un service, ils ont une fonc-tion dans l’entreprise, éventuellement un supérieur et des subalternes. Leur salaire dépend de leur fonction et de leur ancienneté au sein de l’entreprise. En plus du petit outillage courant, l’entreprise de dépannage dispose de gros matériels demandant une qualification particulière aux salariés susceptibles de l’utiliser. Tous les salariés ne sont pas qualifiés pour l’utilisation de tout le matériel. Ce matériel est référencé au niveau de l’entreprise. Un matériel particulière-ment complexe est référencé comme un tout et, le cas échéant, par composants, les composant étant eux-mêmes parfois décomposables. Une intervention de dépannage se fait toujours à la demande d’un client et sous la direction d’un responsable. Une intervention de dépannage se décompose en un certain nombre d’actes de dépannage faisant intervenir un employé. Chaque acte de dépannage comporte un coût. Lorsqu’un employé participe à un acte de dépannage, la date de début et de fin de la participation de l’employé est notée.
17. Proposez un modèle entités-associations bien formé permettant de modéliser la situation décrite ci-dessus.
Bases de données relationnelles
3.1 Introduction au modèle relationnel
3.1.1 Présentation
Le modèle relationnel a déjà été introduit dans la section 1.1.2.
Dans ce modèle, les données sont représentées par des tables, sans préjuger de la façon dont les informations sont stockées dans la machine. Les tables constituent donc lastructure logique1 du modèle relationnel. Au niveau physique, le système est libre d’utiliser n’importe quelle technique de stockage (fichiers séquentiels, indexage, adressage dispersé, séries de pointeurs, compression, . . .) dès lors qu’il est possible de relier ces structures à des tables au niveau logique.
Les tables ne représentent donc qu’une abstraction de l’enregistrement physique des données en mémoire.
Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la puissance et à la simplicité de ses concepts. En outre, contrairement à certains autres modèles, il repose sur des bases théoriques solides, notamment la théorie des ensembles et la logique des prédicats du premier ordre.
Les objectifs du modèle relationnel sont :
– proposer des schémas de données faciles à utiliser ;
– améliorer l’indépendance logique et physique (cf. section 1.2.2) ; – mettre à la disposition des utilisateurs des langages de haut niveau ; – optimiser les accès à la base de données ;
– améliorer l’intégrité et la confidentialité ;
– fournir une approche méthodologique dans la construction des schémas.
De façon informelle, on peut définir le modèle relationnel de la manière suivante :
– les données sont organisées sous forme de tables à deux dimensions, encore appelées relations, dont les lignes sont appelées n-uplet outupleen anglais ;
– les données sont manipulées par des opérateurs de l’algèbre relationnelle ; – l’état cohérent de la base est défini par un ensemble de contraintes d’intégrité.
Au modèle relationnel est associée a la théorie de la normalisation des relations qui per-met de se débarrasser des incohérences au moment de la conception d’une base de données relationnelle.
1Le termestructure logiqueenglobe ici le niveau conceptuel et les niveaux externes d’ANSI/SPARC (cf. section 1.2.3) et correspond approximativement au niveau logique de Merise (cf. section 2.1.2).
3.1.2 Éléments du modèle relationnel
Définition 3.1 -attribut- Un attribut est un identificateur (un nom) décrivant une information stockée dans une base.
Exemples d’attribut : l’âge d’une personne, le nom d’une personne, le numéro de sécurité sociale.
Définition 3.2 -Domaine- Le domaine d’un attribut est l’ensemble, fini ou infini, de ses valeurs possibles.
Par exemple, l’attributnuméro de sécurité socialea pour domaine l’ensemble des combinaisons de quinze chiffres etnoma pour domaine l’ensemble des combinaisons de lettres (une combinai-son comme cette dernière est généralement appelée chaîne de caractères ou, plus simplement, chaîne).
Définition 3.3 -relation- Une relation est un sous-ensemble du produit cartésien de n domaines d’attributs (n>0).
Une relation est représentée sous la forme d’un tableau à deux dimensions dans lequel les nattributs correspondent aux titres desncolonnes.
Définition 3.4 -schéma de relation- Un schéma de relation précise le nom de la relation ainsi que la liste des attributs avec leurs domaines.
Le tableau 3.1 montre un exemple de relation et précise son schéma.
N˚ Sécu Nom Prénom
354338532195874 Durand Caroline 345353545435811 Dubois Jacques 173354684513546 Dupont Lisa
973564213535435 Dubois Rose-Marie
T. 3.1 – Exemple de relation de schémaPersonne(N˚ sécu : Entier, Nom : Chaîne, Prénom : Chaîne)
Définition 3.5 -degré- Le degré d’une relation est son nombre d’attributs.
Définition 3.6 -occurrence ou n-uplets ou tuples- Une occurrence, ou n-uplets, ou tuples, est un élément de l’ensemble figuré par une relation. Autrement dit, une occurrence est une ligne du tableau qui représente la relation.
Définition 3.7 -cardinalité- La cardinalité d’une relation est son nombre d’occurrences.
Définition 3.8 -clé candidate- Une clé candidate d’une relation est un ensemble minimal des attributs de la relation dont les valeurs identifient à coup sûr une occurrence.
La valeur d’une clé candidate est donc distincte pour toutes les tuples de la relation. La notion de clé candidate est essentielle dans le modèle relationnel.
Règle 3.9 Toute relation a au moins une clé candidate et peut en avoir plusieurs.
Ainsi, il ne peut jamais y avoir deux tuples identiques au sein d’une relation. Les clés candidates d’une relation n’ont pas forcément le même nombre d’attributs. Une clé candidate peut être formée d’un attribut arbitraire, utilisé à cette seule fin.
Définition 3.10 -clé primaire- La clé primaire d’une relation est une de ses clés candidates. Pour signaler la clé primaire, ses attributs sont généralement soulignés.
Définition 3.11 -clé étrangère- Une clé étrangère dans une relation est formée d’un ou plusieurs attributs qui constituent une clé primaire dans une autre relation.
Définition 3.12 -schéma relationnel- Un schéma relationnel est constitué par l’ensemble des schémas de relation.
Définition 3.13 -base de données relationnelle- Une base de données relationnelle est constituée par l’ensemble des n-uplets des différentes relations du schéma relationnel.
3.1.3 Passage du modèle entités-associations au modèle relationnel
Règles de passage
Pour traduire un schéma du modèle entités-associations vers le modèle relationnel, on peut appliquer les règles suivantes :
1. La normalisation devrait toujours être effectuée avant le passage au modèle relationnel (cf. section 2.5.4). Dans les faits, elle est parfois faitea posteriori(section 3.2), ce qui impose toujours une surcharge de travail importante.
2. Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité devient un attribut de la relation. L’identifiant est conservé en tant que clé de la relation.
3. Chaque type-association dont aucune patte n’a pour cardinalité maximale 1 donne nais-sance à une relation. Chaque attribut de ce type-association devient un attribut de la relation. L’identifiant, s’il est précisé, est conservé en tant que clé de la relation, sinon cette clé est formée par la concaténation des identifiants des type-entités qui interviennent dans le type-association.
4. Un association dont au moins une patte a une cardinalité maximale à 1 (ce type-association devrait être binaire et n’a généralement pas d’attribut) ne devient pas une relation. Il décrit en effet une dépendance fonctionnelle (cf. section 3.2). La relation corres-pondant au type-entité dont la patte vers le type-association a une cardinalité maximale valant 1, se voit simplement ajouter comme attribut (et donc comme clé étrangère) l’iden-tifiant de l’autre type-entité.
Cas particulier d’un type-assocuation du type1vers1
Dans l’exemple de la figure 3.1 toutes les cardinalités maximales du type-associationEtre sont de 1. L’application des règles de passage du modèle entités-associations au modèle rela-tionnel énoncées ci-dessus nous donnerait :
– Citoyen(Num-Citoyen,Num-Candidat, Nom, Prénom, Adresse) – Candidat(Num-Candidat),Num-Citoyen, Parti)
F. 3.1 – Reprise de l’exemple de la figure 2.30 d’un type-associationEtreoù toutes les cardi-nalités maximales sont de 1.
L’attributNum-Candidatdans la relation Citoyenest une clé étrangère de la relationCandidat.
L’attributNum-Citoyendans la relationCandidatest une clé étrangère de la relationCitoyen.
Le type-associationEtreétant du type 1 vers 1, il est entièrement matérialisé dans la relation Candidat par l’attribut Num-Citoyen. Il est donc inutile de la rematérialiser dans la relation Citoyen. L’attributNum-Candidatdans la relationCitoyendoit donc être supprimé. D’autre part, dans la relationCandidat, l’attributNum-Citoyen, en plus d’être une clé étrangère, constitue une clé candidate. On peut donc se passer de la cléNum-Candidat.
Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure 3.1 devient donc :
– Citoyen(Num-Citoyen, Nom, Prénom, Adresse) – Candidat(Num-Citoyen, Parti)
oùNum-Citoyen, en plus d’être la clé de la relationCandidat, est une clé étrangère de la relation Citoyen.
Cas particulier d’un type-entité sans attribut autre que sa clé
Lorsqu’un type-entité ne possède pas d’attribut en dehors de sa clé, il ne faut pas nécessai-rement en faire une relation.
F. 3.2 – Ici, le type-entitéDatene doit pas se matérialiser par une relation.
Par exemple, le type-entitéDatede la figure 3.2 ne doit pas se traduire par une relation. Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure 3.2 est donc :
– Exemplaire(Num-Exemplaire, date-achat)
– Personne(Num-Personne, nom, prénom, adresse)
– Emprunter(Num-Exemplaire, Num-Personne, Date, date-retour)
Exemple complet
F. 3.3 – Exemple très simplifié de modélisation entités-associations
Comme exemple d’application, voici les relations déduites du schéma entités-associations de la figure 3.3 :
– Patient(Num-Patient, Nom-Patient, Num-Mutuelle) – Mutuelle(Num-Mutuelle, Nom-Mutuelle)
– Médecin(Num-Médecin, Nom-Médecin, Prénom-Médecin) – Affection(Num-Affection, Nom-Affection)
– Hospitaliser(Num-Patient, Num-Affection, Num-Médecin, Date-Entrée, Chambre, Durée-Hospitalisation)