Introduction au modèle de données ER

Un aperçu simple mais complet du modèle de données entité-relation

LeModèle de données entité-relation, aussi appeléER, est l'un des différentsmodèles de donnéesvous pouvez utiliser pour raisonner sur vos données.

En particulier, c'est unmodèle de données conceptuel, car il n'est lié à aucune implémentation particulière. C'est une tâche laissée au modèle de données logique.

LeModèle de données ERest 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 génial parce que vous ne pensez pas aux détails de l'implémentation, mais au lieu de cela, vous ne pensez qu'àvos données et leur organisation. 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 dans lequel des données sont impliquées.

Le modèle ER vous donne les outils pour représenter, à l'aide d'une notation graphique, toutes les données à 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:

  • leentités
  • lerapports

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 avons2 entités:

  • livre
  • auteur

Un livre particulier est une instance de l'entité livre.

Puisque nous avons 2 entités, nous avons2 relationsentre eux. L'une est la relation entre un seul livre et l'entité auteurs. L'une est la relation entre un seul auteur 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

Compte tenu de 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. J'utiliserai celui qui,À mon avis, est plus visuel et a plus de sens.

Les entités sont représentées sous forme de rectangles, avec du texte pour les identifier:

Entities

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 avec du texte pour identifier le type de relation:

Relation example

Notez que je n'ai pas créé 2 relations «livre a auteur» et «auteur a écrit livre». J'ai fait une seule relation «d'auteur» entre un livre et un auteur.

Cardinalités

Une fois que nous avons une relation, nous devons maintenant indiquer les nombres impliqués. Pour le moment, nous nous posons de nombreuses 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?

Ce sont toutes de bonnes questions à 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 clarifient les choses:

Cardinality example

Les chiffres ci-dessus signifient ceci: un livre peut être écrit par un ou plusieurs auteurs.nsignifie n'importe quel nombre d'éléments.

Et un auteur peut avoir écrit de 0 livres (peut-être en écrit-il un maintenant) à un nombre infini de livres.

Le premier s'appelle unrelation zéro à plusieurs. Le second est unrelation un-à-plusieurs.

On peut aussi avoir:

  • relations individuelles
  • relations plusieurs à plusieurs
  • relations zéro à un

Les 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 bio, une URL de site Web.

Chaque livre a un titre, un éditeur, une année de publication, 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:

Attributes example

Attributs d'identifiant

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 (étant donné que nous ne représentons pas un seul exemplaire d'un livre, mais un «titre» de livre).

Nous identifions les attributs de clé primaire en les sous-jacents:

Key

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 unidattribut:

id attribute

Les attributs d'identifiant peuvent s'étendre sur plusieurs attributs.

Par exemple, la pièce d'identité du passeport et le pays de l'auteur identifient de manière unique la personne et pourraient remplacer leidattribut que nous avons ajouté:

multiple attributes key

Lequel choisir? Il s'agit de savoir 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 utiliserons donc un aléatoireidnous choisirons et nous associerons à chaque auteur.

Attributs de relation

Les attributs ne sont pas uniques aux entités. Les relations peuvent également avoir des attributs.

Considérez que nous devons modéliser une bibliothèque. En plus du livre et des entités auteur, nous présentons maintenant leentité de lecture, 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:

relation without attribute

Mais nous manquons toujours d'informations. Nous avons besoin de savoir quand la personne a emprunté le livre et la date à laquelle elle l'a retourné, afin que nous puissions stocker les informations sur toute l'histoire d'un livre particulier dans notre bibliothèque. Ces informations n'appartiennent ni au livre ni aux entités de lecture; il appartient à la relation:

relation attributes

Entités faibles

Nous avons parlé des clés primaires ci-dessus et de la manière dont l'aide identifie de manière unique une entité.

Certaines entités dépendent d'autres entités pour leur existence et sont appeléesentités faibles.

Supposons que nous devions modéliser les commandes d'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 de la commande.

weak entity

Cette entité enregistrera le prix de l'article au moment de la commande (donc lorsque nous modifierons 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é.

C'est une entité faible car une entité d'article commandé ne peut exister sans entité d'ordre.

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:

recursive relation

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 même parapluie. 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 en utilisant une entité personne.

Ils ont tous les deux un nom, nous extrayons donc le nom jusqu'à l'entité personne, et gérons simplement les particularités d'être un auteur ou un lecteur dans l'entité correspondante:

isa relation

Relations non binaires

Toutes les relations ne sont pas strictement binaires. Prenons un scénario de leçon.

Une leçon a lieu dans une salle de l'école aujourd'hui à 10h00, avec un professeur, parlant à une classe de physique.

Ainsi, une leçon est donnée à un moment particulier de la journée, elle implique une matière, un enseignant, une classe et une salle.

Nous pouvons le modéliser de cette manière:

non-binary relation


Plus de didacticiels sur les bases de données: