Apprentissage de la conception de diagrammes de relation d'entité

Bonjour Cet article est consacré à l'un des modèles de conception les plus populaires et les plus connus - ER ( Entity Relationship ), qui a été proposé par des scientifiques du domaine de l'informatique - Peter Chen, en 1976.


Au cours de l'article, en langage simple, à partir d'exemples simples tirés de la vie, nous développerons différentes versions du schéma qui dépendront de leur type de connexion. Commençons!

Conception orientée objet

Tout d'abord, je voudrais dire quelques mots sur la POO (Programmation / Conception Orientée Objet) afin qu'il n'y ait aucun problème à comprendre le paradigme du diagramme lui-même. Il est plus pratique pour moi d'abstraire ce modèle avec le principe de la POO, où l'essence est l'objet, les attributs sont ses caractéristiques et les connexions sont un peu un intermédiaire (dans certains cas, comme méthode).

Démarrage rapide

Le principal avantage du modèle de conception de relation d'entité est qu'il est universel. Vous pouvez concevoir une base de données (Bases de données), le fonctionnement d'un programme, les principes d'interaction, etc.

Que devez-vous savoir au début de l'étude?

- Vous devez savoir au départ que le travail principal est effectué sur la relation de l'essence et de la communication. Pour une perception plus facile, il convient de se rappeler que l'essence est un nom qui est dans un rectangle, et la connexion est un verbe qui est dans un losange. Voici un exemple:



Je pense que vous comprenez quoi. Notre programmeur enseigne le Python. Il semble que tout soit logique. Mais ici, quelles sont ces unités dans l'exemple?

- Ceci est un indicateur du type de connexion! Dans cet exemple, le type de connexion est One-to-One:

$$

Nous reviendrons sur les types de communication, mais un peu plus tard, et maintenant nous devons analyser encore un autre MAIS:
- Le tableau doit être lu dans les deux sens. Si vous lisez de gauche à droite, alors tout est logique, comme cela a été dit précédemment, mais si au contraire ... alors nous réfléchirons encore une fois à ce qu'est la logique. En effet, c'est écrit de cette façon et c'est vrai! Ce n'est là qu'une des caractéristiques de ce modèle, ce qui peut parfois prêter à confusion. Cependant, rien ne vous empêche, comme beaucoup, côté unité, d'ajouter une flèche, comme dans l'exemple ci-dessous:



PS J'espère que vous êtes intéressé. Vous pouvez créer de tels diagrammes dans l'éditeur de diagramme - Dia.

Attributs

Donc, nous avons un programmeur, mais nous ne savons rien de lui ... Sans lequel un programmeur n'est pas programmeur?
- Sans aucun attribut!

Complétons notre exemple:



Oui, les attributs ne distinguent pas vraiment notre programmeur d'une personne ordinaire ... mais à l'avenir nous le corrigerons avec de nouveaux attributs! À mon avis, l'attribut est COLUMN (colonne) dans la table Database.

Les attributs sont vides

S'il n'est pas nécessaire d'indiquer un nom de famille dans le tableau de votre base de données (alors l'attribut sera facultatif), alors l'attribut devrait être composé de deux ovales: externe et interne (à l'intérieur duquel le nom de l'attribut).

Identifier les attributs

Vous pouvez voir un trait de soulignement du nom de l'attribut dans le diagramme - c'est normal. Vous ne devriez pas avoir peur de cela, c'est peut-être juste un attribut identifiant. Autrement dit, c'est un attribut qui doit toujours être rempli, ce qui est obligatoire (clé primaire). À titre d'exemple - l'identifiant bien connu.

Eh bien, maintenant nous devons donner au programmeur des connaissances (quels langages, quelles technologies il connaît).
"Mais nous n'énumérerons pas immédiatement avec chaque attribut séparé les composants de ses connaissances?"
C'est vrai, nous allons utiliser un attribut composite ( un attribut qui se compose d' attributs de composant)! Je tiens à noter que les composants d'attribut peuvent également être composites. La seule question est de savoir comment vous allez l'implémenter.

Types de communication

Super. Nous avons pu comprendre cela. Considérez maintenant les types de communication restants!

Continuons avec le type de connexion - Un à plusieurs:

$$

$$1: N$$

Permettez-moi de vous montrer un exemple:



Maintenant, notre programmeur étudie également Perl. Pas mal.
Cependant, je tiens à noter que l'exemple mentionné ci-dessus n'est qu'une exception, afin de montrer clairement quelle est la relation, car il peut y avoir mille branches, ce qui serait idiot de dessiner. À l'avenir, nous reviendrons à un enregistrement abrégé et correct, et ce modèle fragile mérite d'être rappelé, de sorte qu'il existe une idée générale de ce qui est quoi. J'espère avoir réussi à vous expliquer ce que représente le type de connexion «un à plusieurs».
* Le rapport d'une entité à plusieurs et vice versa *

Avant de continuer à étudier les types de liens, vous devez vous assurer que les attributs existent également dans les liens .
Je ne vais pas le montrer comme un exemple - peut-être, cela peut être compris sans problème, avec des mots. Imaginez simplement que vous avez une connexion Transaction. Supposons que dans votre projet, vous devez enregistrer toutes les informations sur les transactions enregistrées, que ce soit dans un fichier ou une base de données, cela n'a pas d'importance. Vous devez gagner du temps, des exceptions (erreurs survenues) et autre chose. Dans notre cas, tous les éléments ci-dessus sont des attributs qui appartiendront à la connexion. Ces attributs peuvent également être composites, identifiants, facultatifs. La question n'est que dans la mise en œuvre. Continuons.

Le dernier type de connexion reste - Beaucoup à beaucoup:

$$

$$M: N$$

Comme d'habitude, je vais vous montrer par exemple, mais pas avec le programmeur, mais par l'exemple de la relation du spectateur avec le film, sur n'importe quel service pour regarder des films:



Il y a deux questions litigieuses. Commençons.

D'abord:
- Pourquoi la communication ressemble-t-elle plus à une entité?

Pour simplifier la relation de type "plusieurs à plusieurs", des entités intermédiaires sont utilisées .

"Pourquoi n'y a-t-il pas de succursales?"

- Le spectateur peut s'abonner à de nombreux films.
- Les films peuvent avoir de nombreux téléspectateurs qui s'y abonnent.

Maintenant, regardons une autre façon d'implémenter la relation Much to Many, qui sera un peu plus difficile à écrire, mais peut-être plus compréhensible pour ceux qui ne connaissent pas les entités intermédiaires:



Comme vous l'avez peut-être remarqué, dans cet exemple, il existe un type de connexion «un à plusieurs», voire plusieurs.
C'est vrai et facile à expliquer. Le fait est que le type de connexion «plusieurs à plusieurs» équivaut à deux communications «un à plusieurs».

$$

$$M: N = 1: N + N: 1$$

Vous vous demandez probablement pourquoi nous, entre la connexion et l'entité, avons deux arêtes.
C'est déjà un peu plus difficile à expliquer. Lisez attentivement.
Le fait est qu'il existe des connexions optionnelles et obligatoires . Rappelez-vous l'identité:

Les connexions facultatives créent une participation partielle, tandis que les connexions obligatoires créent une pleine participation.

- Qu'est-ce qu'une participation partielle et totale?

La participation partielle est également l'une des exceptions, quelque peu similaire à un attribut facultatif, elle dépend simplement de l'entité. Imaginez l'image. Il existe deux entités:
Acheteur et produits. Type de connexion - Un à plusieurs.
Ils ont une connexion commune - les achats. Mais nous devons comprendre autre chose. Sans lequel l'acheteur n'est pas l'acheteur?
- Sans au moins un achat!
Ce cas est représentatif d'une connexion partielle, car nous donnons le choix de "Acheter et devenir acheteur ou refuser". Dans ce cas, nous aurons un bord entre le lien «Achats» et l'entité «Produits». Considérez maintenant la pleine participation.

La pleine participation est le cas lorsqu'il n'y a pas de choix. Notre programmeur restera programmeur, même s'il n'apprend rien, car nous fixons sur le schéma qu'il doit apprendre quelque chose, et il ne peut y avoir aucune exception. Nous réparons cette entreprise avec deux bords. Le type de participation dépend de la façon dont vous concevez, si l'échantillonnage est nécessaire au stade de la communication.
C'est fait. Nous continuons.

Rappelez-vous l'exemple «One to Many», où après le lien «Teaches» il y avait des noms de YP (Langages de Programmation), ce qui a conduit à un grand nombre de branches, car il n'était pas correct en termes d'écriture. Pensez-y, car nous n'avons pas à faire de branchements à chaque PL. Nous pouvons simplement créer une entité «langage de programmation», dans laquelle nous plaçons les attributs qui seront responsables de son nom, son âge, sa puissance et bien plus encore. Je pense que vous comprenez. Je vous conseille d'utiliser l'entrée abrégée "Beaucoup à plusieurs".

Entités faibles

Considérez le concept final.

Imaginez que vous ayez une table «Parent» et «Enfant», respectivement, les mêmes entités dans le diagramme. Peut-on exister sans l'autre? Je pense que non. A la fois biologique et en général logique.

Essence faible: il ne peut y avoir de pomme sans pommier

.

Dans cet exemple, l'entité «Enfant» est une entité faible.

Les entités faibles sont les entités qui ne peuvent exister sans une autre entité.

Nous créons l'entité «Enfant», dans l'espoir que les parents / parents n'ont pas d'enfants du même nom, sinon, notre entité, qui peut être une table dans la base de données, peut difficilement être appelée normalisée (une table dans laquelle les règles de l'automatisation des données et il existe un identifiant de clé primaire), car nous ne pouvons pas distinguer les enfants de façon banale.

Cependant, de tels cas se produisent, mais vous pouvez résoudre ce problème en ajoutant un attribut supplémentaire. Dans ce cas, l'attribut "Nom" est ce qui crée une situation similaire, et il est appelé le composant clé d'une entité faible . Le nom de ces attributs, en ovales, est souligné par une ligne pointillée, et l'essence et la connexion sont placés dans des figures supplémentaires dans lesquelles ils sont composés.

Je vais vous présenter ceci à titre d'exemple:

Conclusion

En conclusion, je veux dire que l'un des travaux coopératifs fondamentaux et compétents est une bonne explication des tâches, une bonne présentation du produit à développer, ce qui aide à concevoir des modèles. La relation d'entité est un modèle de conception qui est populaire depuis des décennies. Il vous permet de créer des graphiques élégants qui, avec la bonne approche, peuvent être complétés et modifiés à l'avenir. Prenez le temps d'apprendre. Merci de votre attention!

Les sources

- Livre "MySQL Guide" Authorship:
Seyed M.M. «Saied» Tahagghoghi, Hugh E. Williams
- en.wikipedia.org/wiki/Entity –relationship_model