Modélisation d'une base de données (ERD) présentant un comportement excentrique

Question

L'une des bases de données sur lesquelles je travaille présente un comportement bizarre que je veux prendre en compte dans le diagramme entité-relation.

Un des comportements est qu'il y a une table de 'réservation' et une table de 'facture'. Lorsqu'une «réservation» est facturée, l'enregistrement est inséré dans la table «facture», puis supprimé du tableau «réservation».

Cependant, une référence est toujours conservée du numéro de réservation.

Comment modélisons-nous ceci? Une grosse flèche entre les tables et du texte à côté pour décrire ce qui se passe?

Non, le changement du schéma de base de données n'est pas possible à ce moment

Modifier: Ceci est le type de diagramme que je veux utiliser: alt text http://img813.imageshack.us/img813/5601/erdartistperformssong.png Link

Answer 1

Si, par ERD, vous voulez dire les diagrammes "Chen" originaux où la relation était des mots écrits dans un diamant, alors vous avez une relation entre Booking et Invoice. C'est un type spécial de relation qui n'est PAS implémenté avec une clé étrangère simple; il est implémenté via un mouvement compliqué et une contrainte.

Si, par ERD, vous voulez dire les diagrammes dessinés par ERwin, alors vous n'avez pas un moyen facile de le faire. Il tend à vous concentrer sur les relations PK-FK. Vous avez une relation non-PK-FK entre ces choses. Une sorte de ligne avec du texte est à peu près tout ce que vous pouvez faire.

Les flèches, BTW, ne sont pas appropriées parce que l'ERD montre "l'état" de la base de données. Les données circulant ne font pas partie d'une ERD. Vous avez une relation, ce n'est simplement pas une relation PK-FK typique. C'est une relation atypique basée sur des lignes existant à certains endroits et qui n'existe pas dans d'autres.

Dans l'UML, vous pouvez facilement dessiner cela comme une «contrainte» entre les relations.

Answer 2

Cela ressemble à un flux de processus et non à une relation d'entité. Si au moment où l'entrée est ajoutée à la facture, et l'entrée est supprimée de la réservation, il n'y a jamais de relation entre les deux. Il n'y a jamais une situation où vous pouvez traverser cette relation parce qu'il n'y a jamais un enregistrement dans les deux endroits qui peuvent être liés ensemble.

ERD ne décrit pas complètement la base de données. Il y a d'autres choses comme le flux de processus et les cas d'utilisation qui détaillent d'autres facettes du système.

Ceci est une sorte d'analogie avec UML pour les logiciels. Un diagramme de classes ne vous montre pas toutes les différentes façons dont les classes interagissent. Une classe peut s'initialiser localement et appeler des fonctions d'une autre classe, mais comme il n'y a pas de composition ou d'héritage qui relie ces deux classes, le diagramme de classes ne montre pas cette relation. Ce n'est que lorsque vous documentez entièrement le système avec tous les différents types de diagrammes que vous pouvez voir toutes les facettes de son fonctionnement.

Answer 3

Je ne sais pas de quoi parlent ces gens.

1. Le diagramme de relation d'entité ne décrit pas complètement les données; oui bien sûr, il ne montre que les entités et les relations, il n'affiche pas les attributs. C'est pourquoi on l'appelle une ERD et non un Data Model.Evidemment beaucoup de gens ici ne peuvent pas faire la différence.

2. Le modèle de données est censé afficher autant que possible. Mais cela dépend de (a) la norme [le cas échéant] que vous utilisez et (b) la Notation. Certains montrent plus que d'autres. IDEF1X qui est la seule norme de modélisation relationnelle (NIST 184 de 1993). C'est le plus complet et montre des complexités et des complexités que les autres notations ne montrent pas. Récemment MS et d'autres ont sorti des notations "simplifiées", bien sûr, beaucoup de choses sont perdues dans les "ERD".

3. Ce n'est pas un "flux de processus", c'est une relation dans une base de données.

4. UML est totalement inapproprié pour la modélisation de données, en particulier lorsqu'il existe au moins un standard plus plusieurs notations de modélisation de données non standard mais couramment utilisées. Il n'y a rien qui peut être montré dans UML qui ne peut pas être montré dans IDEF1X. Mais la plupart des développeurs n'en ont jamais entendu parler (les développeurs ne devraient pas modéliser à moins d'avoir acquis des compétences de modélisation, mais c'est une autre histoire).

5. Ceci est parfaitement légal; il peut ne pas être communément connu, mais il est légal et nommé. C'est une relation Supertype-Sous-type, sauf que la cardinalité est 1 :: 0-n au lieu de 1 :: 0-1. La notation IDEF1X (à droite) a un symbole de sous-type. Notez qu'il n'y a qu'une seule relation à la fin du parent; et un chacun à la fin de l'enfant. Et bien sûr, les pieds des corbeaux montrent la cardinalité. Ces relations peuvent être Exclusif ou Non exclusif; le vôtre est exclusif; c'est ce que signifie le X à travers le demi-cercle.

   • ERwin est la seule modélisation (non schématisant) outil qui met en œuvre IDEF1X, et a donc le complément complet de la notation IDEF1X.

   • Bien sûr, la norme, la capacité de modélisation, sont tous dans l'esprit, pas dans l'outil. Je dessine des modèles de données conformes à IDEF1X à l'aide d'un outil de dessin simple.

6. Je trouve que certains développeurs au symbole reculent face Subtype, donc je montre une version simplifiée (à gauche) dans mes modèles IDEF1X; il est destiné à transmettre le sens de l'exclusivité, tandis que la rétention de la ligne unique à la fin du parent indique qu'il s'agit d'un sous-type.

Lott: Cliquez ici ▶ Link to Data Model ◀ Lott: Cliquez ici

Link to IDEF1X Notation pour ceux qui ne sont pas familiers avec la modélisation relationnelle standard.