Apprenez à connaître le diagramme ER (Entity Relationship), ses parties et ce qui ne va pas souvent lors de sa création.
Avez-vous déjà créé un modèle de base de données relationnelle ? Ou peut-être essayez-vous de créer votre premier ? Vous savez (ou vous le découvrirez bientôt) qu'il peut parfois être assez difficile de traduire des problèmes réels en logique de base de données.
L'un des outils qui pourraient vous aider est le diagramme ER. La sagesse commune en matière de conception de base de données veut que plus votre diagramme ER est bon, plus il sera facile de créer le modèle de base de données. Cet élément important donne le ton à toutes les frustrations ou réussites futures. Avec un bon diagramme ER, la création d'un modèle de base de données relationnelle est assez simple. Bien sûr, des erreurs peuvent être commises à n'importe quelle phase de la modélisation de la base de données. Cependant, avoir un bon diagramme ER peut vous aider à éviter certaines de ces erreurs.
Voyons donc ce qu'est le diagramme ER et comment nous pouvons éviter ses erreurs courantes.
Qu'est-ce qu'un diagramme ER ?
"ER Diagram", ou ERD, est l'abréviation de Entity Relationship Diagram. Il cartographie le problème à modéliser, mais d'une manière structurée qui montre les relations entre les entités.
Les éléments constitutifs d'un diagramme ER
Les diagrammes ER se composent des éléments suivants :
- Entité
- Relations
- Attributs d'entité ou de relation
Le premier élément du diagramme ER est l'entité . L'entité est un objet ou une occurrence sur laquelle nous voulons stocker des informations. Fondamentalement, c'est tout ce sur quoi nous pouvons collecter des données. Par exemple, nous pouvons stocker des données sur les employés, les étudiants, les enseignants, les acheteurs, les produits, les départements, les paiements, les emplacements, etc.
Une fois que nous avons des entités, il est nécessaire de créer des relations . Une relation montre comment une entité est connectée et associée à une ou plusieurs autres entités.
Le dernier élément du diagramme ER est un attribut d'entité ou de relation . Un attribut est une description d'une propriété appartenant à une entité ou une relation. Les attributs ont des valeurs. Certains attributs des entités mentionnées ci-dessus pourraient être :
- Employé, étudiant, enseignant, acheteur – ID, nom, prénom, date de naissance, adresse, etc.
- Produit – ID, catégorie, description, couleur, numéro de série, etc.
- Département – ID, nom du service, chef de service, nombre d'employés, etc.
- Paiements – ID, date et heure, montant.
- Emplacement – Ville, code postal, région, pays, continent.
Types de relations
Avant d'aborder les erreurs habituelles trouvées dans les diagrammes ER, il est important de comprendre les types de relations possibles. La plupart des erreurs ERD sont essentiellement des relations définies de manière erronée entre des entités.
Il existe trois types de relations entre les entités :
- Individuel (1:1)
- Un à plusieurs (1 : N)
- Plusieurs à plusieurs (M : N)
Relations un à un (1:1)
Le premier type de relation est one-to-one , ou 1:1 . Dans cette relation, une seule instance d'une entité ne peut être connectée qu'avec une seule instance d'une autre entité (et inversement, bien sûr).
Disons que nous avons l'entité étudiant avec les attributs nom et nom de famille . Nous avons également l'entité id avec pour seul attribut id . La relation 1:1 signifierait qu'un étudiant ne peut avoir qu'un seul numéro d'identification. Cela signifie également qu'un numéro d'identification ne peut appartenir qu'à un seul étudiant.
Cette relation est très rarement observée dans les bases de données. Si un seul ID peut être connecté à un seul étudiant, il n'est pas nécessaire de les séparer en deux entités différentes.
Voici un exemple de cette relation :
Relations un à plusieurs (1 : N)
Le type de relation de base de données le plus courant est un-à-plusieurs ou 1 :N . Une relation un-à-plusieurs signifie que chaque instance d'une entité peut être connectée à plusieurs instances d'une autre entité. Cela signifie également que chaque instance de la deuxième entité ne peut être associée qu'à une seule instance de la première entité.
Par exemple, il y a une entité acheteur avec les attributs id , nom , et nom de famille . Nous voulons établir une relation avec l'entité paiement qui a les attributs id , date , et valeur . Il s'agit d'une relation 1:N car un acheteur peut effectuer un ou plusieurs paiements. Cependant, un paiement ne peut pas être effectué par plusieurs acheteurs; il ne peut être fait que par un seul acheteur.
Voici l'exemple :
Cette relation peut aussi être vue dans l'autre sens. Dans cette situation, cela s'appelle plusieurs à un ou N:1 . Bien sûr, ce n'est pas un nouveau type de relation. C'est la même chose que 1 : N, mais il est regardé dans la direction opposée.
Par exemple, supposons que nous ayons l'entité employé avec les attributs id , nom , et nom de famille . Nous voulons établir un employé la relation de avec l'entité service qui a les attributs id et nom . La relation entre ces deux entités est N:1. Cela signifie que chaque employé ne peut travailler que dans un seul service, mais que plusieurs employés peuvent travailler dans le même service.
Relations plusieurs à plusieurs (M :N)
Un plusieurs à plusieurs ou M : N relation signifie que chaque instance de la première entité peut être associée à plusieurs instances de la seconde entité. Cela signifie également que chaque instance de la deuxième entité peut être associée à plusieurs instances de la première entité.
Voyons comment cela fonctionne entre les entités étudiant et conférence . Disons que étudiant a les attributs id , nom , et nom de famille . L'entité conférence a les attributs id et nom . Une relation plusieurs-à-plusieurs peut être interprétée de la manière suivante :un étudiant peut assister à un ou plusieurs cours, tandis qu'un cours peut être suivi par un ou plusieurs étudiants.
Voici le schéma de cet exemple :
Dans la modélisation de base de données, ces relations sont généralement divisées en deux ou plusieurs relations 1 : N ou N : 1 en introduisant de nouvelles entités.
Erreurs typiques commises lors de la création d'un diagramme ER
De nombreuses erreurs de diagramme ER entrent dans l'une de ces quatre catégories :
- Relations incorrectes entre les entités
- Utiliser une instance d'entité au lieu d'une entité
- Confondre un attribut avec une entité
- Attributs complexes
Examinons chacun individuellement.
Relations incorrectes entre les entités
Les erreurs les plus courantes se produisent lors de la définition de la relation entre les entités . Il n'y a généralement pas d'erreurs dans une relation 1:1. Cependant, il est très facile de confondre une relation 1 :N avec une relation M :N. Cela découle généralement de la non-compréhension des exigences fournies par l'utilisateur final. Il est essentiel d'avoir des exigences très clairement définies et une compréhension approfondie de la raison pour laquelle la base de données est nécessaire et de la manière dont elle sera utilisée. Si nous créons un diagramme ER avec des données insuffisantes et une compréhension incomplète, cela entraînera très probablement une mauvaise définition des relations entre les entités.
Prenons un exemple. Si vous créez une base de données pour une banque, vous créerez très probablement un diagramme ER avec l'entité client ayant les attributs id , nom , et nom de famille . Vous aurez également une entité appelée compte avec les attributs id et tapez . Si vous manquez d'expérience dans le secteur bancaire, vous penserez probablement qu'il existe toujours une relation 1 : N entre le client et compte entités, comme indiqué ci-dessous.
Un client peut avoir plusieurs comptes dans une même banque. Cependant, un compte ne peut appartenir qu'à un seul client. Est-ce vraiment vrai ? Peut-être que ça l'est, peut-être que non. De nombreuses banques proposent des comptes joints pouvant être utilisés par plusieurs clients. Créez-vous un diagramme ER pour une banque qui offre un tel service ? Si la banque ne propose pas de comptes joints, alors vous avez raison :la relation entre client et compte est 1 :N. Toutefois, si la banque propose des comptes joints, la relation est M :N.
Utiliser une instance d'entité au lieu d'une entité
Une autre erreur courante consiste à utiliser une instance d'entité au lieu d'une entité. Une instance d'entité est une occurrence unique d'une certaine entité - c'est-à-dire une entité qui pourrait en fait être un attribut d'une catégorie plus large.
Disons que nous travaillons dans une entreprise qui attribue des téléphones portables et des ordinateurs portables à certains employés. Ainsi, dans notre base de données, nous aurions une entité appelée ordinateur portable avec les attributs id et modèle et une entité appelée employé avec les attributs id , nom , et nom de famille , à droite?
Il y a un problème ici :un ordinateur portable n'est en fait pas une entité - il y a aussi des téléphones portables à prendre en compte. La solution est de remplacer l'entité portable avec une entité plus générale, telle que équipement . Cette entité pourrait avoir les attributs ID , tapez , et modèle , comme indiqué ci-dessous. Le type peut être composé de valeurs telles que téléphone , PC , tablette , et ordinateur portable . De cette façon, il n'est pas nécessaire de créer une entité distincte pour chaque type d'équipement.
Vous pouvez trouver l'exemple ici :
Confondre un attribut avec une entité
La prochaine erreur courante est de confondre un attribut avec une entité. Disons que nous avons décidé de créer une entité appelée employé qui sera composé des attributs id , nom , nom de famille , date_naissance , id_department , nom_service , et head_department . Cette entité nous causera des problèmes lors de la création d'un modèle de base de données car elle se compose de trop d'attributs qui ne définissent pas de manière unique cette entité particulière .
N'oubliez pas que nous avons défini les entités comme tout ce sur quoi nous pouvons collecter des données. Dans cet esprit, nous pouvons voir que l'employé actuel l'entité peut être scindée en deux entités :employé et département , comme indiqué ci-dessous.
Attributs complexes
La dernière erreur courante dont nous parlerons est d'inclure un attribut complexe dans une entité. En d'autres termes, nous avons un attribut qui devrait en fait être sa propre entité .
Disons que nous avons une entité appelée étudiants défini par les attributs suivants :id , nom , nom de famille , date_naissance , adresse , et exam_passed . Ici, exam_passed est un attribut complexe qui se compose de plusieurs éléments d'information, c'est-à-dire l'ID et la date de l'examen et le score de l'étudiant. Le laisser ainsi serait une erreur. Au lieu de cela, nous devrions créer une nouvelle entité de cet attribut complexe . La nouvelle entité pourrait être nommée examens et se composent des attributs suivants :id , date , identifiant_étudiants , et score .
Vous pouvez trouver l'exemple ici :
Avez-vous obtenu des conseils utiles sur le diagramme ER ?
Ces quatre types d'erreurs sont les plus courantes dans le processus de création d'un diagramme ER. Bien sûr, il n'y a pas de liste complète des erreurs typiques ou des types d'erreurs. Dans la vraie vie, de nombreux types d'erreurs sont susceptibles de se produire. Un manque de planification, un support technique insuffisant et un processus de conception de base de données précipité contribuent tous à leurs propres problèmes. Si vous avez déjà créé des bases de données ou y avez participé du côté commercial, vous en avez probablement déjà expérimenté certaines ! Toutes ces circonstances conduisent à diverses erreurs, dont certaines sont tout à fait uniques.
Avez-vous votre propre exemple d'un diagramme ER pas si bon ? Ou peut-être y a-t-il d'autres erreurs que vous trouvez fréquemment ? Veuillez me le faire savoir dans la section des commentaires.
