Le modèle de données entité-relation , également appelé ER , est l'un des différents modèles de données que vous pouvez utiliser pour raisonner sur vos données.
En particulier, il s'agit d'un modèle conceptuel de données , car il n'est lié à aucune implémentation particulière. C'est une tâche laissée au modèle logique de données.
Le modèle de données ER est si général, si haut niveau, qu'il peut être implémenté par une variété de types de bases de données complètement différents.
C'est formidable parce que vous ne pensez pas aux détails de mise en œuvre, mais à la place, vous ne pensez qu'à vos données et à la façon dont elles sont organisées . Et ce faisant, vous êtes obligé d'analyser le problème d'une manière à laquelle vous n'aviez pas pensé auparavant.
Je trouve que les diagrammes ER sont parfaits pour vous aider à analyser un scénario impliquant des données.
Le modèle ER vous donne les outils pour représenter, à l'aide d'une notation graphique, toutes les données dont vous avez besoin pour modéliser, les relations entre les différents types de données et les informations qui y sont associées.
Il y a 2 éléments qui composent un modèle ER :
- les entités
- les relations
Les entités sont des types de données, comme des éléments ou des personnes, qui ont des propriétés communes.
Les relations sont les relations entre les entités.
Laissez-moi vous donner un exemple, parlons des livres et de leurs auteurs. Nous avons 2 entités :
- réserver
- auteur
Un livre particulier est une instance de l'entité livre.
Puisque nous avons 2 entités, nous avons 2 relations entre eux. L'un est la relation entre un livre unique et l'entité des auteurs. L'un est la relation entre un auteur unique et l'entité livres. Si nous y réfléchissons, nous avons :
- un livre a un auteur
- un auteur peut écrire de nombreux livres différents
La notation visuelle des entités
Étant donné cet exemple simple, nous pouvons commencer à introduire la notation visuelle qui nous aidera à créer le modèle de données ER de notre scénario.
Remarque :Il existe de nombreuses façons de dessiner des diagrammes ER. Je vais utiliser celui qui, à mon avis , est plus visuel et a plus de sens.
Les entités sont représentées sous forme de rectangles, contenant du texte pour les identifier :
La notation visuelle des relations
La relation entre les entités est représentée, dans sa forme la plus élémentaire, à l'aide d'une ligne qui relie deux relations et d'un losange contenant du texte pour identifier le type de relation :
Notez que je n'ai pas créé 2 relations « livre a auteur » et « auteur a écrit livre ». J'ai fait une seule relation "auteur" entre un Livre et un Auteur.
Cardinalités
Une fois que nous avons une relation, nous devons maintenant indiquer les nombres impliqués. En ce moment, nous avons beaucoup de questions :
- Combien d'auteurs un livre peut-il avoir ?
- Un auteur peut-il écrire plusieurs livres ?
- Un auteur doit-il écrire au moins un livre pour être appelé auteur ?
- Un livre peut-il être écrit par plusieurs auteurs ?
- Un livre peut-il exister sans au moins un auteur ?
Toutes ces questions sont bonnes à poser, et dans ce cas, je pense que les réponses sont assez évidentes. Et lorsque la réponse n'est pas évidente, vous pouvez réfléchir au problème et ajouter vos propres contraintes.
Il existe différentes manières d'indiquer visuellement les cardinalités sur un diagramme. Certains préfèrent changer la forme de la ligne lorsqu'elle est liée à une entité.
Je préfère les chiffres, qui rendent les choses plus claires :
Les chiffres ci-dessus signifient ceci :un livre peut être écrit par 1 ou plusieurs auteurs. n signifie n'importe quel nombre d'éléments.
Et un auteur peut avoir écrit de 0 livres (peut-être qu'il en écrit un maintenant) à un nombre infini de livres.
La première est appelée une relation zéro à plusieurs . La seconde est une relation un-à-plusieurs .
Nous pouvons également avoir :
- Relations individuelles
- relations plusieurs à plusieurs
- Relations de zéro à un
Attributs
Chaque entité peut avoir un ou plusieurs attributs.
Disons que nous utiliserons la relation ci-dessus dans une librairie. Chaque auteur a un nom, une biographie, une URL de site Web.
Chaque livre a un titre, un éditeur, une année de parution, un ISBN. L'éditeur pourrait également être une entité, si nous le voulons. Mais on peut aussi le définir comme un attribut d'un livre.
Voici comment nous pouvons représenter les informations ci-dessus :
Attributs d'identification
Les entités doivent être identifiées par une clé unique. L'entité livre peut être identifiée de manière unique par l'attribut ISBN. Chaque livre a un seul ISBN (considérant que nous ne représentons pas un seul exemplaire d'un livre, mais un "titre" de livre).
Nous identifions les attributs de la clé primaire en les sous-tendant :
L'auteur, en revanche, n'a pas d'identifiant unique pour le moment. Deux auteurs peuvent avoir le même nom.
Il faut donc ajouter un attribut clé unique. Par exemple un id attribut :
Les attributs d'identifiant peuvent s'étendre sur plusieurs attributs.
Par exemple, l'identifiant du passeport et le pays de l'auteur identifient de manière unique la personne et peuvent remplacer l'id attribut que nous avons ajouté :
Laquelle choisir ? C'est une question de ce qui a le plus de sens dans votre application. Si nous modélisons une librairie, nous ne pouvons pas nous attendre à avoir le pays et l'identifiant de passeport de tous les auteurs de livres. Nous allons donc utiliser un id aléatoire nous choisirons et associerons à chaque auteur.
Attributs de relation
Les attributs ne sont pas uniques aux entités. Les relations peuvent également avoir des attributs.
Considérons que nous devons modéliser une bibliothèque. En plus des entités livre et auteur, nous introduisons maintenant l'entité lecteur , une personne qui emprunte le livre pour le lire. Nous prenons son nom et son numéro de carte d'identité lorsqu'ils l'empruntent :
Mais nous manquons toujours d'informations. Nous devons savoir quand la personne a emprunté le livre et la date à laquelle elle l'a rendu, afin que nous puissions stocker les informations sur toute l'histoire d'un livre particulier dans notre bibliothèque. Ces informations n'appartiennent ni aux entités livre ni lecteur; il appartient à la relation :
Entités faibles
Nous avons parlé des clés primaires ci-dessus et de la façon dont elles aident à identifier de manière unique une entité.
Certaines entités dépendent d'autres entités pour leur existence et sont appelées entités faibles .
Supposons que nous ayons besoin de modéliser des commandes pour une boutique en ligne.
Pour chaque commande, nous stockons l'identifiant de la commande, qui commence à 1 et augmente au fil du temps, la date et l'heure à laquelle elle a été passée, ainsi que les informations sur le client, afin que nous sachions qui facturer et où l'expédier.
Ensuite, nous devons également savoir ce qu'ils ont commandé. Nous créons une entité faible "article commandé", qui représente chaque article du panier au moment du paiement.
Cette entité stockera le prix de l'article au moment du paiement (ainsi, lorsque nous modifions le prix des produits en vente, cela n'affectera pas les commandes déjà passées), la quantité d'articles commandés et les options choisies. Disons que nous vendons des t-shirts, nous devons donc stocker la couleur et la taille du t-shirt commandé.
Il s'agit d'une entité faible car une entité d'article commandé ne peut pas exister sans une entité de commande.
Relations récursives
Une entité peut avoir une relation récursive avec elle-même. Supposons que nous ayons une entité personne. Nous pouvons modéliser la relation parent-enfant de cette manière :
Une personne peut avoir de 0 à n enfants, un enfant a 2 parents (en considérant le scénario le plus simple).
Relations ISA
ISA signifie IS-A, et c'est un moyen de modéliser des généralisations dans le modèle ER.
Nous l'utilisons pour regrouper des entités similaires sous un parapluie commun. Par exemple, un auteur et un lecteur, dans le cas de l'exemple des livres et de la bibliothèque, peuvent être généralisés à l'aide d'une entité personne.
Ils ont tous les deux un nom, nous extrayons donc le nom jusqu'à l'entité personne, et gérons juste les particularités d'être auteur ou lecteur dans l'entité correspondante :
Relations non binaires
Toutes les relations ne sont pas strictement binaires. Prenons un scénario de leçon.
Un cours a lieu dans une salle de l'école aujourd'hui à 10h00, avec un professeur, parlant à une classe de physique.
Ainsi, un cours est donné à un moment précis de la journée, il implique une matière, un professeur, une classe et une salle.
Nous pouvons le modéliser de cette manière :
