La création de systèmes d'information modernes est une tâche complexe dont la solution nécessite l'utilisation de techniques et d'outils spéciaux. Il n'est pas surprenant que récemment, parmi les analystes et les développeurs de systèmes, il y ait eu un intérêt croissant pour CASE (Computer-Aided Software/System Engineering) - les technologies et outils CASE qui permettent de systématiser et d'automatiser au maximum toutes les étapes du développement logiciel.

Le livre proposé au lecteur est un guide pratique pour créer des systèmes d'information à l'aide d'outils efficaces d'analyse, de conception et de génération de code issus de la technologie PLATINUM - BPwin et ERwin. Il contient également une description des méthodes d'analyse structurelle et de conception de modèles de données dans la mesure nécessaire aux travaux pratiques. L'application des méthodes est illustrée par des exemples.

Le livre est écrit sur la base de l’expérience personnelle de l’auteur acquise lors du développement de systèmes d’information, en donnant des conférences et en animant des cours pratiques sur les technologies CASE et les outils CASE au centre de formation de la société Interface Ltd. Il s'adresse aux spécialistes du domaine des technologies de l'information : analystes système, chefs de projet, développeurs - et peut également être utile aux étudiants de premier cycle et des cycles supérieurs qui étudient les bases de l'analyse des systèmes et de la conception des systèmes d'information.

Livre:

Une relation est une relation logique entre des entités. Chaque relation doit être appelée un verbe ou une phrase verbale (Phrases verbales de relation) (Fig. 2.20). Le nom de la relation exprime une contrainte ou une règle métier et facilite la lecture du diagramme, par exemple :

Chaque CLIENT <размещает> ORDRES;

Chaque commande <выполняется> EMPLOYÉ.

Riz. 2.20. Nom de la relation - Phrases verbales de relation

La connexion montre quelles commandes le client a passées et quel employé exécute la commande. Par défaut, le nom de la connexion n'est pas affiché dans le diagramme. Pour afficher le nom, dans le menu contextuel qui apparaît si vous cliquez avec le bouton gauche sur un endroit du diagramme qui n'est pas occupé par les objets du modèle, sélectionnez Options d'affichage/Relation, puis activez l'option Phrase verbale.

Au niveau logique, vous pouvez établir une relation d'identification un-à-plusieurs, une relation plusieurs-à-plusieurs et une relation un-à-plusieurs non-identifiante (respectivement, ce sont les boutons de gauche à droite dans l'outil palette).

IDEF1X fait la distinction entre les entités dépendantes et indépendantes. Le type d'une entité est déterminé par sa relation avec d'autres entités. Une relation d'identification est établie entre une entité indépendante (extrémité parent de la relation) et dépendante (extrémité enfant de la relation). Lorsqu'une relation d'identification est établie, ERwin convertit automatiquement l'entité enfant en entité dépendante. L'entité dépendante est représentée par un rectangle aux coins arrondis (entité Commande En figue. 2.21). Une instance d'une entité dépendante est définie uniquement par sa relation avec l'entité parent, c'est-à-dire dans la structure de la Fig. 2.21 les informations sur une commande ne peuvent pas être saisies et n'ont aucun sens sans informations sur le client qui la passe. Lorsqu'une relation d'identification est établie, les attributs de la clé primaire de l'entité parent sont automatiquement transférés vers la clé primaire de l'entité enfant. Cette opération d'ajout d'attributs à une entité enfant lors de la création d'une relation est appelée migration d'attributs. Dans l'entité enfant, les nouveaux attributs sont marqués comme clé étrangère - (FK).

Riz. 2.21. Une relation d'identification entre une table indépendante et dépendante

À l'avenir, lors de la génération d'un schéma de base de données, les attributs de clé primaire recevront l'attribut NOT NULL, ce qui signifie qu'il sera impossible de faire une entrée dans le tableau des commandes sans informations sur le numéro de client.

Lorsqu'une relation non identifiante est établie (Figure 2.22), l'entité enfant reste indépendante et les attributs clés primaires de l'entité parent migrent vers les composants non clés de l'entité parent. Une relation non identificatoire est utilisée pour relier des entités indépendantes.

Riz. 2.22. Relation non identifiante

Instance d'entité Employé peut exister indépendamment de toute instance d’une entité Département, c'est-à-dire qu'un employé peut travailler dans une organisation sans être inscrit dans aucun département.

Une connexion identifiante est représentée sur le schéma sous la forme d'une ligne continue avec un point épais à l'extrémité enfant de la connexion (voir Fig. 2.21), une connexion non identifiante est représentée sous la forme d'une ligne pointillée (Fig. 2.22).

Pour créer une nouvelle connexion :

placez le curseur sur le bouton souhaité dans la palette d'outils (connexion identifiante ou non identifiante) et cliquez sur le bouton gauche de la souris (Fig. 2.2) ;

Cliquez d'abord sur l'entité parent puis sur l'entité enfant.

La forme de la ligne de communication peut être modifiée. Pour ce faire, vous devez saisir la ligne de connexion souhaitée avec la souris et la déplacer d'un endroit à l'autre jusqu'à ce que la ligne commence à être meilleure.

Bouton dans la palette d'outils

Correspond au lien identifiant, bouton

Relations plusieurs-à-plusieurs et bouton

Correspond à une relation non identificatoire.

Pour modifier les propriétés d'une relation, cliquez avec le bouton droit sur la relation et sélectionnez Éditeur de relations dans le menu contextuel.

Dans l'onglet Général de la boîte de dialogue qui apparaît, vous pouvez définir la puissance, le nom et le type de connexion (Fig. 2.23).

Pouvoir de communication (Cardinalité) - sert à désigner le rapport entre le nombre d'instances de l'entité mère et le nombre d'instances de l'enfant.

Il existe quatre types de puissance (Fig. 2.24) :

le cas général où une instance d'une entité parent correspond à 0, 1 ou plusieurs instances d'une entité enfant n'est marqué d'aucun symbole ;

le symbole P marque le cas où une instance de l'entité parent correspond à 1 ou plusieurs instances de l'entité enfant (la valeur zéro est exclue) ;

le symbole Z marque le cas où une instance de l'entité parent correspond à 0 ou 1 instance de l'entité enfant (les valeurs multiples sont exclues) ;

Le nombre marque le cas d'une correspondance exacte, lorsqu'une instance de l'entité parent correspond à un nombre prédéterminé d'instances de l'entité enfant.

Riz. 2.23. Boîte de dialogue Éditeur de relations

Par défaut, le symbole représentant la force du lien n'est pas affiché sur le diagramme. Pour afficher le nom, dans le menu contextuel qui apparaît si vous cliquez avec le bouton gauche sur un endroit du diagramme qui n'est pas occupé par les objets du modèle, sélectionnez Options d'affichage/Relation puis activez l'option Cardinalité.

Phrase verbale- une phrase caractérisant la relation entre les entités parent et enfant. Pour une relation un-à-plusieurs, identifiante ou non identifiante, il suffit de préciser un nom qui caractérise la relation d'entité parent à enfant (Parent-to-Child). Pour une relation plusieurs-à-plusieurs, les noms Parent-à-Enfant et Enfant-à-Parent doivent être spécifiés.

Riz. 2.24. Désignations de puissance

Type de connexion (identifiant/non identifiant). Pour une relation non identifiante, vous pouvez spécifier des valeurs Null. Dans le cas d'une relation obligatoire (No Nulls), lors de la génération d'un schéma de base de données, l'attribut de clé étrangère recevra l'attribut NOT NULL, malgré le fait que la clé étrangère ne fera pas partie de la clé primaire de l'entité enfant. Dans le cas d'une relation facultative (Nulls Allowed), la clé étrangère peut être NULL. Une relation facultative non identifiante est marquée d'un losange transparent du côté de l'entité mère (voir Figure 2.22).

Riz. 2.25. Onglet Nom de rôle/Actions RI de la boîte de dialogue Éditeur de relations

Dans l'onglet Définition, vous pouvez donner une définition plus complète de la relation afin de pouvoir y faire référence dans le futur.

Dans l'onglet Nom de rôle/Actions RI, vous pouvez définir le nom du rôle et les règles d'intégrité référentielle.

Nom du rôle (nom fonctionnel) - c'est un synonyme d'attribut de clé étrangère qui indique le rôle que joue l'attribut dans une entité enfant.

Riz. 2.26. Noms de rôles clés étrangers

Dans l'exemple représenté sur la Fig. 2.26, essentiellement Employé clé externe Numéro de département a un nom fonctionnel "Where Works" qui indique le rôle que joue cet attribut dans l'entité. Par défaut, seul le nom du rôle est affiché dans la liste des attributs. Pour afficher le nom complet de l'attribut (à la fois le nom fonctionnel et le nom du rôle), dans le menu contextuel qui apparaît si vous cliquez avec le bouton gauche sur n'importe quel endroit du diagramme qui n'est pas occupé par les objets du modèle, sélectionnez Options d'affichage/Entités et puis activez l'attribut Rolename/option (Fig. 2.25). Le nom complet est affiché sous la forme du nom fonctionnel et du nom de base séparés par un point (voir Figure 2.26).

Il est obligatoire d'utiliser des noms de rôle lorsque deux ou plusieurs attributs de la même entité sont définis sur la même portée, c'est-à-dire qu'ils ont la même portée, mais des significations différentes. En figue. 2.27 essence Vente de monnaie contient des informations sur un acte de change dans lequel deux devises sont impliquées - vendues et achetées. Les informations sur les devises sont contenues dans l'entité Devise. Par conséquent, les entités Vente de monnaie Et Devise doit être lié deux fois et la clé primaire est - Numéro de devise doit migrer vers l'entité deux fois Devise comme clé étrangère. Il est nécessaire de distinguer ces attributs, qui contiennent des informations sur le numéro de la devise vendue et achetée (ils ont des significations différentes), mais font référence à la même entité. Devise (avoir une plage de valeurs commune). Dans l'exemple de la Fig. 2.27 attributs reçus noms de rôle Vendu Et Acheté.

Riz. 2.27. Le cas des noms de rôles obligatoires

Un autre exemple de dénomination de rôle obligatoire est connexions récursives(parfois appelé « hameçon ») lorsque la même entité est à la fois parent et enfant. Lors de la définition d'une relation récursive, l'attribut doit migrer en tant que clé étrangère vers les attributs non-clés de la même entité. Un attribut ne peut pas apparaître deux fois dans la même entité sous le même nom, il doit donc recevoir le nom du rôle. En figue. 2.26 essence Employé contient l'attribut de clé primaire Numéro personnel. Les informations sur le manager de l'employé sont contenues dans la même entité, puisque le manager travaille dans la même organisation. Pour faire référence au manager d'un employé, vous devez créer une relation récursive (dans la figure 2.26, la connexion est manager/subordonné) et attribuer un nom de rôle (« Manager »). Notez qu'une relation récursive ne peut être que non identifiante. Sinon, la clé étrangère devrait faire partie de la clé primaire et recevoir l'attribut NOT NULL lors de la génération du schéma. Cela rendrait impossible la construction d'une hiérarchie - l'arbre de reporting doit avoir une racine - un employé qui ne rend compte à personne au sein de l'organisation.

La relation commande/suivi est illustrée à la Fig. 2.26 vous permet de stocker une hiérarchie arborescente de subordination des employés. Ce type de communication récursive est appelé récursion hiérarchique et définit une relation dans laquelle un leader (une instance d'une entité parent) peut avoir de nombreux subordonnés (instances d'une entité enfant), mais un subordonné n'a qu'un seul leader (Figure 2.28).

Récursion hiérarchique Récursion réseau

Riz. 2.28. Subordination des instances d'entités dans la récursion hiérarchique et réseau

Un autre type de récursion est récursivité du réseau, lorsqu'un leader peut avoir de nombreux subordonnés et, à l'inverse, un subordonné peut avoir de nombreux managers. La récursivité du réseau définit un réseau de relations entre les instances d'une entité parent et enfant. C'est le cas lorsqu'une entité est dans une relation plusieurs-à-plusieurs avec elle-même. Pour résoudre une relation plusieurs-à-plusieurs, vous devez créer une nouvelle entité (les relations plusieurs-à-plusieurs seront abordées en détail ci-dessous).

Riz. 2.29. Exemple d'implémentation de la récursion du réseau

En figue. 2.29 considère un exemple de mise en œuvre de la récursion de réseau. La structure modélise les relations familiales entre les membres de la famille de toute complexité. Attribut Type de relation peut prendre les sens « père-fils », « mère-fille », « grand-père-petit-fils », « belle-mère-belle-fille », « beau-père », etc. Puisqu'une famille la relation relie toujours deux personnes, de l'essence Relatif à. essence Parenté deux liens identificatoires sont établis avec les noms de rôles « Senior » et « Junior ». Chaque membre de la famille peut être lié à n'importe quel autre membre de la famille ; de plus, le même couple de parents peut être lié par différents types de relations familiales.

Si un attribut est migré en tant que clé étrangère vers plusieurs niveaux, alors le nom complet de la clé étrangère (nom du rôle + nom de l'attribut de base) est affiché au premier niveau, et seul le nom du rôle est affiché au deuxième ou plus. les niveaux. En figue. La figure 2.30 montre une structure de données qui contient une entité Équipe, essence Joueur, qui stocke des informations sur les joueurs de chaque équipe et l'entité But, contenant des informations sur les buts marqués par chaque joueur. Attribut de clé étrangère Numéro d'équipe essence Joueur a le nom de rôle "Dans quelle équipe joue-t-il".

Riz. 14h30. Migration des noms de rôle

Au niveau suivant, essentiellement But, seul le nom du rôle de l'attribut de clé étrangère correspondant est affiché (Dans quelle équipe joue-t-il).

Les règles d'intégrité référentielle (RI) sont des constructions logiques qui expriment des règles métier pour l'utilisation des données et représentent des règles d'insertion, de remplacement et de suppression. Lors de la génération d'un schéma de base de données basé sur les options de modèle logique spécifiées dans l'onglet Nom de rôle/Actions RI, des règles d'intégrité référentielle déclaratives seront générées, qui doivent être prescrites pour chaque relation, ainsi que des déclencheurs qui garantissent l'intégrité référentielle. Les déclencheurs sont des programmes qui sont exécutés chaque fois qu'une commande d'insertion, de remplacement ou de suppression (INSERT, UPDATE ou DELETE) est exécutée. En figue. 2.30 il existe une relation d'identification entre les entités Équipe Et Joueur. Que se passe-t-il si vous supprimez une commande ? Instance d'entité Joueur ne peut pas exister sans la commande (attribut de clé primaire Dans quelle équipe joue-t-il ? Numéro d'équipe ne peut pas prendre la valeur NULL), il faut donc soit interdire la suppression d'une équipe alors qu'elle compte au moins un joueur (pour supprimer une équipe, vous devez d'abord supprimer tous les joueurs), soit supprimer immédiatement tous ses joueurs ainsi que l'équipe. De telles règles de suppression sont appelées « restriction » et « cascade » (Parent RESTRICT et Parent CASCADE, voir Fig. 2.25). Notez que les entités Joueur Et But, à leur tour, sont également reliés par un lien d'identification et si une équipe est supprimée en cascade, tous les joueurs de l'équipe et tous les buts qu'ils ont marqués seront supprimés. L'exécution d'une commande pour supprimer une ligne peut en réalité entraîner la suppression de milliers de lignes dans la base de données. Vous devez donc utiliser la règle de suppression en cascade avec prudence. Si une règle de restriction de suppression est définie, si vous essayez de supprimer une équipe qui compte au moins un joueur, le serveur SGBD relationnel renverra une erreur.

En figue. 2.26 une relation facultative non identifiante est établie entre les entités Département Et Employé. Instance d'entité Employé peut exister sans référence de département (attribut de clé étrangère Où travaille-t-il? Numéro de département peut être NULL). Dans ce cas, il est possible de définir une règle pour le mettre à zéro - SET NULL. Lors de la suppression d'un département, l'attribut de clé étrangère de l'entité Employé - Où travaille-t-il ? Numéro de département sera NULL. Cela signifie que lorsqu'un service est supprimé, l'employé continue de travailler dans l'organisation sans être affecté à aucun service et les informations le concernant sont enregistrées.

Il est possible de définir deux règles de suppression supplémentaires (si prises en charge par le SGBD) :

SET DEFAULT - lors de la suppression, l'attribut de clé étrangère se voit attribuer une valeur par défaut. Par exemple, lorsqu'une équipe est supprimée, les joueurs peuvent être transférés dans une autre équipe.

NONE - une fois supprimé, la valeur de l'attribut de clé étrangère ne change pas. Le dossier du joueur « est en suspens », c'est-à-dire qu'il fait référence à une équipe qui n'existe plus. Cette situation est typique des tables « plates ». Par exemple, si les informations sur les joueurs et les équipes sont stockées dans des fichiers dbf, vous pouvez supprimer l'entrée de l'équipe sans que le fichier des joueurs sache que l'équipe correspondante n'existe pas. Par conséquent, sur les systèmes de bureau ou de serveur de fichiers, la fonctionnalité qui applique les règles d'intégrité référentielle est implémentée dans l'application client.

Les règles de suppression contrôlent ce qui se passe dans la base de données lorsqu'une ligne est supprimée. De même, les règles d'insertion et de mise à jour contrôlent ce qui arrive à la base de données si des lignes sont modifiées ou ajoutées. Par exemple, vous pouvez définir une règle qui vous permet d'ajouter une nouvelle équipe uniquement si au moins un joueur y est inscrit. Le comportement souhaité peut être obtenu par les actions suivantes :

Définir la force de la connexion entre les entités Équipe Et Joueur, égal à "Un ou plusieurs" - 1 ou plus (type P). On suppose qu'une relation d'identification a été établie.

Attribuez l'action de déclenchement RI "Parent Insert-CASCADE" de sorte que lorsqu'une nouvelle ligne est créée dans la table Équipe au moins une ligne a été automatiquement créée dans la table enfant Joueur.

Attribuez l'action du déclencheur RI "Parent Delete-CASCADE" à la connexion afin que lorsqu'une ligne est supprimée de la table Équipe la ou les lignes correspondantes du tableau Joueur ont également été supprimés.

ERwin attribue automatiquement une valeur d'intégrité référentielle par défaut à chaque relation avant de l'ajouter au diagramme. Les modes RI attribués par ERwin par défaut (affichés dans le tableau 2.4) peuvent être modifiés dans l'éditeur Referential Integrity Default, qui est appelé en cliquant sur le bouton RI Defaults dans la boîte de dialogue Target Server (menu Serveur/Target Server).

Tableau 2.4. Valeurs RI attribuées par défaut dans ERwin, ainsi que les modes possibles pour chaque type de communication

Lien d'identification	Valeurs nulles autorisées	Relation non identifiante (pas de valeurs nulles)	Connexion catégorielle
Modes possibles de suppression d'enfant	RESTRICTION, CASCADE, AUCUN	RESTRICTER, CASCADE, AUCUN, FIXER NULL, FIXER PAR DÉFAUT		RESTREINT, CASCADE,
AUCUN
Modes par défaut de suppression d'enfant	AUCUN	AUCUN	AUCUN	AUCUN
Insertion enfant Modes possibles	RESTREINT, CASCADE,		RESTRICTER, CASCADE, AUCUN, DÉFINIR LA VALEUR PAR DÉFAUT	RESTREINT, CASCADE,
AUCUN	AUCUN
Modes par défaut d'insertion enfant	LIMITER	FIXER NULL	LIMITER	LIMITER
Modes possibles de mise à jour enfant	RESTRICTION, CASCADE, AUCUN	RESTRICTER, CASCADE, AUCUN, FIXER NULL, FIXER PAR DÉFAUT	RESTRICTER, CASCADE, AUCUN, DÉFINIR LA VALEUR PAR DÉFAUT	RESTRICTION, CASCADE, AUCUN
Modes par défaut de mise à jour enfant	LIMITER	FIXER NULL	LIMITER	LIMITER
Parent Supprimer Modes possibles	RESTRICTION, CASCADE, AUCUN	RESTRICTER, CASCADE, AUCUN, FIXER NULL, FIXER PAR DÉFAUT	RESTRICTER, CASCADE, AUCUN, DÉFINIR LA VALEUR PAR DÉFAUT	RESTREINT, CASCADE,
AUCUN
Modes par défaut de suppression parent	LIMITER	FIXER NULL	LIMITER	CASCADE
Modes possibles d'insertion parent	RESTRICTION, CASCADE, AUCUN	RESTRICTER, CASCADE, AUCUN, FIXER NULL, FIXER PAR DÉFAUT	RESTRICTER, CASCADE, AUCUN, DÉFINIR LA VALEUR PAR DÉFAUT	RESTRICTION, CASCADE, AUCUN
Modes par défaut d'insertion parent	AUCUN	AUCUN	AUCUN	AUCUN
Modes possibles de mise à jour parent	RESTRICTION, CASCADE, AUCUN	RESTRICTER, CASCADE, AUCUN, FIXER NULL, FIXER PAR DÉFAUT	RESTRICTER, CASCADE, AUCUN, DÉFINIR LA VALEUR PAR DÉFAUT	RESTRICTION, CASCADE, AUCUN
Modes par défaut de mise à jour parent	LIMITER	FIXER NULL	LIMITER	CASCADE

Communication plusieurs-à-plusieurs n’est possible qu’au niveau du modèle logique de données. En figue. La figure 2.31 ci-dessus montre un exemple de relation plusieurs-à-plusieurs. Un médecin peut voir plusieurs patients, un patient peut être soigné par plusieurs médecins. Une telle connexion est indiquée par une ligne continue avec deux points aux extrémités.

Nous aurons besoin du concept d'anomalie - un écart entre les contraintes d'intégrité des schémas de données conceptuels et logiques (ainsi que physiques). Le but de la normalisation est précisément l'élimination des anomalies qui apparaissent lors de l'activation, de la mise à jour et de la suppression des données.

Les quatre premières formes normales (plus précisément, première, deuxième, troisième et Boyce-Codd) sont regroupées en un seul groupe car leurs définitions sont basées sur le concept classique de fonction définie sur un diagramme de relations et sur le théorème de Heath.

Deux formes plus normales (quatrième et cinquième) utilisent des modifications dépendances fonctionnelles. Dernier forme normale- domain-key - marque un retour aux origines - une approche logique de la théorie relationnelle.

Une méthode pratique sera recommandée pour obtenir le diagramme de base dans les quatre premières formes normales, donnant presque toujours la version finale du diagramme. L’exactitude de cette construction devra être vérifiée par des méthodes formelles, c’est-à-dire que des techniques heuristiques et une théorie de la normalisation seront nécessaires.

Discutons d’abord de la manière acceptée de présenter le matériel sur la normalisation. Naturellement, nous partirons de la théorie de la normalisation développée dans le cadre du modèle de données relationnelles. Cependant, l'expérience a montré qu'avec une telle présentation, les débutants ont du mal à saisir le concept le plus important d'anomalie, défini comme une caractéristique de « l'inexactitude » de la cartographie d'un modèle commercial conceptuel dans un modèle de base de données. C'est pourquoi

Nous utiliserons la cartographie du modèle relationnel vers le modèle entité-relation que vous connaissez déjà et étudierons la normalisation dans le modèle ER. Cela vous permettra d'utiliser la sémantique nécessaire pour travailler avec les anomalies.

Repensons aux liens entre les relations, aux liens entre les relations et aux clés étrangères.

5.1 Relations et clés étrangères

Les chapitres précédents ont exploré les concepts de connexion des entités et les relations entre elles. Distinguons-les bien. Le concept de connexion n’est pas de nature algébrique, puisque les connexions sont actives. Dans les implémentations, les connexions définissent la structure de la base de données et fonctionnent lors de la manipulation des données et des modifications de schéma. Une connexion est un concept algébrique. La signification des données obtenues lors de la connexion dépend entièrement du développeur. Le sens de la connexion est strictement défini par l’entreprise simulée.

La sémantique des connexions est assez développée. En plus de la cardinalité des extrémités, des propriétés telles que le caractère obligatoire et l'identifiabilité sont utilisées. Dans le modèle relationnel, ils ne peuvent pas être exprimés directement (de tels mots n'existent pas). Nous considérerons donc les premières formes normales dans le cadre du modèle « entité-relation ».

Les relations entre les relations/entités dans le modèle relationnel et les diagrammes ER sont formées par une contrainte d'intégrité référentielle appelée « clé étrangère » (en abrégé FK).

Afin de ne pas créer une fausse impression de pauvreté du modèle relationnel comme de l'impossibilité de mettre en œuvre quelque chose, rappelons-nous que la connexion n : m y est représentée à travers deux connexions 1 : n, et que les connexions complexes peuvent être modélisées en différentes manières. Même les agrégats peuvent être représentés d’une manière ou d’une autre en introduisant des entités qui décrivent leur composition. De tels modèles peuvent être mis en œuvre efficacement dans un programme, mais ils seront très probablement peu pratiques pour les humains. Les possibilités de modélisation des structures de données au sein du modèle relationnel sont assez larges mais bien sûr pas illimitées.

Discutons d'une approche générale de l'analyse des structures qui sera discutée plus en détail en utilisant l'exemple de deux entités liées « Employé » et « Département », illustrées dans la figure 5.1. A gauche se trouve une option avec une connexion identifiante, à droite avec une connexion non identifiante.

Riz. 5.1. Exemple de relations un-à-plusieurs

Je voudrais vous rappeler encore une fois que nous avons convenu de considérer les exemples tels qu'ils sont décrits dans le texte, et non tels qu'ils se produisent ou peuvent se produire dans la vie. Cette limitation est nécessaire pour que l’information soit perçue par tous et toujours de la même manière.

Dans les deux versions du dispositif, chaque salarié est affecté à l'un des services. Nous avons une relation (« à-plusieurs » du côté de la relation « Employé »). Pour la relation "Employé", vous ne pouvez pas sélectionner un numéro de service n° de service qui n'existe pas dans la liste des services (l'entité "Service"). Un département peut n'avoir aucun employé, un, deux employés ou plus.

Nous avons constaté avec un exemple similaire (section 2.2.7) qu'une situation paradoxale se présente. Le directeur est affecté à un département, et le chef de ce département est subordonné au directeur et sera en même temps son patron. Mais peut-être que les départements sont des centres de coûts, et ils ont décidé d'attribuer le salaire du directeur aux dépenses de l'un des départements. Dans nos exemples de formation, vous ne devriez pas vous soucier de tels détails, sauf indication contraire, bien entendu. Dès le début, vous devez vous habituer à penser, entre autres, au côté commercial, mais lorsque vous résolvez des problèmes éducatifs, vous ne devez pas étendre les tâches à l'analyse des options possibles.

Quelle est la différence entre les diagrammes de la figure 5.1 ? Un lien identificatoire fait penser à l’employé avant tout comme à un membre du service. Un lien non identificatoire signifie que l’affiliation au département est marquée comme quelque chose d’importance secondaire.

5.2 Types de communications. Relations identifiantes et non identifiantes, obligatoires et facultatives

Les types de relations identifiantes et non identifiantes (voir Figure 5.1) ne concernent pas la théorie des bases de données relationnelles, mais le standard de modélisation IDEF1X sur lequel se base ERwin (alias AllFusion Data Modeller).

Si une clé étrangère crée une entité dépendante (faible), elle est alors transmise au groupe d'attributs qui forment la clé primaire de cette entité. Dans ce cas, une connexion d'identification est formée. C'est toujours obligatoire.

Une relation non identificatoire permet de relier deux entités fortes. Il transmet la clé à la zone d'attribut non clé.

Pour une relation non identifiante, vous pouvez préciser obligatoire (la relation entière, pas la fin de celle-ci). Si la relation est requise (dans ERwin, il s'agit de l'indicateur No Nulls), alors les attributs de clé étrangère recevront l'indicateur NOT NULL, ce qui signifie que les valeurs nulles ne sont pas autorisées. Pour une relation facultative (Nulls Allowed), la clé étrangère peut être NULL.

Après nous être familiarisés avec le langage SQL dans "SQL Language", en utilisant l'ingénierie directe, il sera possible de générer un script SQL qui crée un fragment du schéma de la base de données. Mais même maintenant, si vous êtes déjà au moins un peu familier avec SQL, en allant dans Outils > Forward Engineer/Schema Generation, puis en cliquant sur le bouton Aperçu, affichez le texte généré.

Pourquoi allons-nous utiliser un modèle entité-relation plus complexe lorsque nous envisageons la normalisation, plutôt que de nous limiter à l’approche classique du modèle relationnel ? Après tout, l'ajout des concepts d'entités fortes et faibles, de relations d'identification, de relations non identifiantes obligatoires et facultatives complique considérablement la sémantique du modèle de données.

L'introduction des cinq concepts de niveau supérieur ci-dessus fournit un langage qui reflète mieux les caractéristiques du problème et est donc plus compréhensible pour le développeur. Cela permettra d'obtenir rapidement et sans transformations formelles le schéma original de la base relationnelle sous une forme presque complète (nous exprimerons plus tard cette idée plus précisément : « sous la troisième forme normale ou forme normale de Boyce-Codd »).

Une relation est une relation logique entre des entités. Chaque relation doit être appelée un verbe ou une phrase verbale. Le nom de la relation exprime une contrainte ou une règle métier et facilite la lecture du diagramme. Par défaut, le nom de la connexion n'est pas affiché dans le diagramme. Au niveau logique, vous pouvez établir une relation d'identification un-à-plusieurs, une relation plusieurs-à-plusieurs et une relation un-à-plusieurs non-identifiante. Une relation est un concept de niveau logique auquel correspond une clé étrangère au niveau physique. Dans ERwin, les relations sont représentées par cinq informations principales :

● type de lien (identifiant, non identifiant, catégorie complète/incomplète, lien non spécifique) ;

● entité mère ;

● entité enfant (dépendante) ;

● pouvoir de communication (cardinalité) ;

● acceptabilité des valeurs vides (nulles).

IDEFIX fait la distinction entre les entités dépendantes et indépendantes. Le type d'une entité est déterminé par sa relation avec d'autres entités. Une relation d'identification est établie entre une entité indépendante (parente) et dépendante (enfant). L'entité dépendante est représentée par un rectangle aux coins arrondis. Lorsqu'une relation d'identification est établie, les attributs de la clé primaire de l'entité parent sont automatiquement transférés vers la clé primaire de l'entité enfant. Cette opération d'ajout d'attributs à une entité enfant lors de la création d'une relation est appelée migration d'attributs. Dans l'entité enfant, les nouveaux attributs sont marqués comme clé étrangère - FK.

Lorsqu'une relation non identifiante est établie, l'entité enfant reste indépendante et les attributs de clé primaire de l'entité parent sont inclus dans les attributs non clés de l'entité enfant. Une relation non identificatoire est utilisée pour relier des entités indépendantes. Pour définir des relations ERwin, sélectionnez le type de relation, puis utilisez la souris pour sélectionner les entités parent et enfant. Le lien d'identification est représenté par une ligne continue ; non identifiant - ligne pointillée. Les lignes se terminent par un point du côté de l'entité enfant.

Cardinalité - sert à indiquer le rapport entre le nombre d'instances de l'entité mère et le nombre d'instances de l'enfant.

Il existe quatre types d'entités :

· le cas général où une instance d'une entité parent correspond à 0, 1 ou plusieurs instances d'une entité enfant ; non marqué d'un quelconque symbole ;

· le symbole P marque le cas où une instance de l'entité parent correspond à 1 ou plusieurs instances de l'entité enfant (la valeur zéro est exclue) ;

· le symbole Z marque le cas où une instance de l'entité parent correspond à 0 ou 1 instance de l'entité enfant (les valeurs multiples sont exclues) ;

· un nombre marque le cas d'une correspondance exacte, lorsqu'une instance de l'entité parent correspond à un nombre prédéterminé d'instances de l'entité enfant.

· l'admissibilité des valeurs vides (NULL) dans les relations non identifiantes est représentée par ERwin comme un losange vide sur l'arc de relation du côté de l'entité mère.

Le nom de la connexion au niveau logique est un verbe qui relie les entités. Le nom du lien physique (qui peut être différent du nom du lien logique) pour ERWin signifie le nom de la contrainte ou de l'index. Pour afficher le nom de la relation, sélectionnez une option dans le menu : Format/Affichage de la relation/Phrase verbale.

Certaines entités définissent toute une catégorie d'objets du même type. Dans ERwin, dans ce cas, une entité est créée pour définir la catégorie et pour chaque élément de la catégorie, puis une relation de catégorisation est introduite pour eux. L’entité parent d’une catégorie est appelée un supertype et ses enfants un sous-type.

Par exemple, l'entité « document entrant » peut être à la fois une demande et une commande. Le premier et le second ont des ensembles d'attributs différents, se chevauchant partiellement (l'intersection minimale des sous-types est la clé primaire). La partie commune de ces attributs, dont la clé primaire, est placée dans l'entité de supertype « document entrant ». Diverses parties (par exemple, les données sur le contenu, l'expéditeur) sont placées dans des entités de sous-type.

Dans une entité de supertype, un attribut discriminateur est introduit qui vous permet de distinguer les instances spécifiques d'une entité - un sous-type.

Selon que toutes les entités de sous-types possibles sont incluses dans le modèle, la relation catégorielle est complète ou incomplète.

Figure 1.4 - Exemple d'un ensemble incomplet de catégories

Figure 1.5 - Exemple d'un ensemble complet de catégories

3. Une entité peut être une entité générale dans un certain nombre de relations de catégorisation.

4. Les attributs de la clé primaire de l'entité catégorie doivent correspondre aux attributs de la clé primaire de l'entité générale.

5. Toutes les instances d'une entité de catégorie ont la même valeur de discriminateur et toutes les instances d'autres catégories doivent avoir des valeurs de discriminateur différentes (voir Fig. 4 et Fig. 5).

Les rôles.

Un nom de rôle (nom fonctionnel) est synonyme d'un attribut de clé étrangère qui indique le rôle que joue l'attribut dans une entité enfant. Par défaut, seul le nom du rôle est affiché dans la liste des attributs. Pour afficher le nom complet d'un attribut (à la fois le nom fonctionnel et le nom du rôle), sélectionnez Format/Affichage d'entité dans le menu contextuel, puis activez l'option Nom de rôle/Attribut. Le nom complet est affiché sous la forme du nom fonctionnel et du nom de base, séparés par un point. Le nom du rôle est spécifié dans l'onglet Nom du rôle de la boîte de dialogue Relation. Cette fenêtre est appelée en double-cliquant sur la ligne de connexion.

Il est obligatoire d'utiliser des noms de rôle lorsque deux ou plusieurs attributs de la même entité sont définis sur la même portée, c'est-à-dire ils ont la même gamme de significations, mais des significations différentes.

Représentation.

Les vues, ou, comme on les appelle parfois, les tables temporaires ou dérivées, sont des objets de base de données dans lesquels les données ne sont pas stockées de manière permanente, comme dans une table, mais sont générées dynamiquement lors de l'accès à la vue. Une vue ne peut pas exister seule, mais est définie uniquement en termes d'une ou plusieurs tables. L'utilisation de vues permet au concepteur de base de données de fournir à chaque utilisateur ou groupe d'utilisateurs une vue différente des données, ce qui résout les problèmes de facilité d'utilisation et de sécurité des données.

Cette méthodologie est basée sur l'approche entité-relation et a été développée en tenant compte de la nécessité d'automatiser les processus de conversion d'un modèle en base de données. Une entité dans IDEF1x décrit une collection ou un ensemble d'instances dont les propriétés sont similaires, mais qui se distinguent clairement les unes des autres par une ou plusieurs caractéristiques. Chaque instance est une implémentation d'une entité. Ainsi, une entité dans IDEF1x décrit un ensemble spécifique d'instances du monde réel.

Dans cette méthodologie, on distingue deux types d’entités :

Une entité indépendante est une entité d'instance qui peut être identifiée de manière unique sans relations avec d'autres entités ;

Une entité dépendante est une entité dans laquelle les identifications sans ambiguïté des instances de l'entité dépendent de sa relation avec une autre entité.

Une entité est décrite dans un diagramme IDEF1x par un objet graphique sous forme de rectangle. Chaque rectangle représentant une entité est divisé par une ligne horizontale en une partie contenant des champs clés et une partie contenant des champs non clés. La partie supérieure est appelée zone clé et la partie inférieure est appelée zone de données. La zone clé contient la clé primaire de l'entité. Une clé primaire est un ensemble d'attributs choisis pour identifier les instances uniques d'une entité. Les attributs de clé primaire sont situés au-dessus de la ligne dans la zone clé. Comme son nom l'indique, un attribut non clé est un attribut qui n'a pas été sélectionné comme attribut clé. Les attributs non clés sont situés sous la ligne, dans la zone de données.

Le choix d'une clé primaire pour une entité est une étape très importante et demande beaucoup de soin. Plusieurs attributs ou groupes d'attributs peuvent être utilisés comme clés primaires. Les attributs qui peuvent être sélectionnés par les clés primaires sont appelés attributs clés candidats (attributs potentiels). Les candidats clés doivent identifier de manière unique chaque enregistrement d'entité. Selon cela, aucune partie de la clé ne peut être NULL, vide ou manquante.

Les attributs et groupes d'attributs doivent :

Identifiez de manière unique une instance d’une entité.

N'utilisez pas de valeurs NULL.

Ne changez pas avec le temps. L'instance est identifiée à l'aide d'une clé. Lorsque la clé change, l'instance change en conséquence.

Soyez le plus court possible pour utiliser l’indexation et la récupération de données. Si vous devez utiliser une clé qui est une combinaison de clés d'autres entités, assurez-vous que chaque partie de la clé respecte les règles.

Lors du choix d'une clé primaire pour une entité, les développeurs de modèles utilisent souvent une clé supplémentaire (de substitution), c'est-à-dire un nombre arbitraire qui identifie de manière unique un enregistrement dans une entité. Une clé de substitution est la mieux adaptée pour servir de clé primaire car elle est courte et constitue le moyen le plus rapide d’identifier les instances d’un objet. De plus, des clés de substitution peuvent être générées automatiquement par le système afin que la numérotation soit continue, c'est-à-dire pas de lacunes.

Les clés potentielles qui ne sont pas sélectionnées comme clés primaires peuvent être utilisées comme clés secondaires ou alternatives. Les clés alternatives représentent souvent différents index d'accès aux données dans l'implémentation finale d'une base de données relationnelle.

Si les entités d'un diagramme IDEF1x sont liées, la relation transmet une clé (ou un ensemble d'attributs de clé) à l'entité enfant. Ces attributs sont appelés clés étrangères. Les clés étrangères sont définies comme les attributs de clé primaire d'un objet parent transmis à un objet enfant via leur relation. Les attributs transférés sont appelés attributs de migration.

Identification des entités et des attributs.

En examinant ce domaine, j'ai identifié les entités et attributs suivants :

PRODUIT ACCORD D'ENTREPÔT FOURNISSEUR TYPE DE MARCHANDISES

Relations entre entités

Les relations entre entités sont de trois types : un-à-un, un-à-plusieurs et plusieurs-à-plusieurs. ERWin utilise des relations un-à-plusieurs et plusieurs-à-plusieurs.

Les entités résultantes sont interconnectées comme suit :

Transition vers la couche physique

Le modèle de données physique dépend du SGBD spécifique, il est en fait le reflet du catalogue système. Le modèle physique contient des informations sur tous les objets de base de données. Puisqu'il n'existe pas de normes pour les objets de base de données (par exemple, il n'existe pas de norme pour les types de données), le modèle physique dépend de l'implémentation spécifique du SGBD. Par conséquent, plusieurs modèles physiques différents peuvent correspondre à un même modèle logique. Si, dans le modèle logique, le type de données spécifique de l'attribut n'a pas d'importance, alors dans le modèle physique, il est important de décrire toutes les informations sur des objets physiques spécifiques - tables, colonnes, index, procédures, etc. Diviser le modèle de données en logique et physique vous permet de résoudre plusieurs problèmes importants.

Une relation plusieurs-à-plusieurs n'est possible qu'au niveau du modèle de données logique. Ainsi, lors du passage au niveau physique, ERWin convertit automatiquement la relation plusieurs-à-plusieurs en ajoutant une nouvelle entité associative et en établissant deux nouvelles relations un-à-plusieurs. de nombreuses relations de l'ancienne à la nouvelle entité.

Les diagrammes des niveaux logiques et physiques obtenus à la suite de la conception se trouvent à l'annexe 2.

6. Simulation dans ERwin

La place d'ERwin dans la modélisation de l'information
Le processus de création d'un modèle d'information comprend les étapes suivantes :

• définition de l'entité ;
• définir des dépendances entre entités ;
• définition de clés primaires et alternatives ;
• définir des attributs d'entité ;
• amener le modèle au niveau requis de forme normale ;
• passage à la description physique du modèle : affectation des correspondances nom d'entité - nom de table, attribut d'entité - attribut de table ; définir des déclencheurs, des procédures et des restrictions ;
• génération de base de données.

ERwin crée une représentation visuelle (modèle de données) du problème à résoudre. Cette vue peut être utilisée pour une analyse détaillée, un affinement et une diffusion dans le cadre de la documentation requise dans le cycle de développement. Cependant, ERwin est loin d’être un simple outil de dessin. ERwin crée automatiquement la base de données (tables, index, procédures stockées, déclencheurs d'intégrité référentielle et autres objets nécessaires à la gestion des données).

Cartographie de la couche logique et physique du modèle de données dans ERwin

Il existe deux niveaux de représentation et de modélisation dans ERwin : logique et physique. Le niveau logique signifie une représentation directe de faits réels. Par exemple, les personnes, les tables, les départements, les chiens et les ordinateurs sont des objets réels. Ils sont nommés en langage naturel, avec tous les séparateurs de mots (espaces, virgules, etc.). Le niveau logique ne prend pas en compte l'utilisation d'un SGBD spécifique, ne définit pas les types de données (par exemple, entiers ou réels) et ne définit pas d'index pour les tables.
Le SGBD cible, les noms d'objets et les types de données, les index constituent le deuxième niveau (physique) du modèle ERwin.
ERwin offre la possibilité de créer et de gérer ces deux niveaux différents de présentation d'un même diagramme (modèle), ainsi que de disposer de nombreuses options d'affichage à chaque niveau.

Composants du diagramme ERwin et types de base de vues de diagramme

Un diagramme ERwin est construit à partir de trois blocs principaux : les entités, les attributs et les relations. Si l’on considère un diagramme comme une représentation graphique des règles d’un domaine, alors les entités sont des noms et les relations sont des verbes.
Le choix entre les niveaux d'affichage logique et physique se fait via la barre d'outils ou le menu. Au sein de chacun de ces niveaux, il existe les modes d'affichage suivants :

• Mode "Entité" - le nom de l'entité (pour le modèle logique) ou le nom de la table (pour la représentation physique du modèle) est affiché à l'intérieur des rectangles ; sert à faciliter la révision d'un grand diagramme ou à placer des rectangles d'entités sur le diagramme.
• Le mode "définition d'entité" permet de présenter le schéma à d'autres personnes.
• Mode "Attributs". Lorsque vous passez d'un domaine à un modèle, vous devez saisir des informations sur ce qui constitue une entité. Ces informations sont saisies en spécifiant des attributs (au niveau physique - colonnes du tableau). Dans ce mode, l'entité rectangle est divisée par une ligne en deux parties - les attributs (colonnes) qui composent la clé primaire sont affichés dans la partie supérieure et les attributs restants sont affichés dans la partie inférieure. Ce mode est le principal lors de la conception aux niveaux logique et physique.
• Mode "Clés primaires" - à l'intérieur des rectangles des entités, seuls les attributs/colonnes qui composent la clé primaire sont affichés.
• Mode icône. À des fins de présentation, chaque tableau peut se voir attribuer une icône (bitmap).
• Mode « Affichage de la phrase verbale ». Les arcs de liens affichent des phrases verbales qui lient des entités (pour la couche logique) ou des noms de clés étrangères (pour la couche physique).

Un graphique peut s'étendre sur plusieurs écrans et sur plusieurs feuilles une fois imprimé. Pour revoir le modèle, en plus du défilement de l'écran, il existe des modes permettant de réduire/agrandir l'image, d'afficher l'intégralité du modèle et d'afficher une partie sélectionnée du modèle.

Outils pour créer un modèle dans ERwin

Les outils de création de modèles de base sont disponibles à la fois dans le menu et via la fenêtre Outils. Avec leur aide, des entités indépendantes et dépendantes sont créées, des relations identifiantes et non identifiantes, des catégories complètes et incomplètes, des relations non spécifiques et des éléments de texte.
En cliquant avec la souris sur une entité, vous entrez dans l'un des nombreux éditeurs ERwin :

• éditeurs associés à l'entité dans son ensemble (définition de l'entité, informations complémentaires, déclencheurs, index, caractéristiques de la table, procédures stockées associées à la table) ;
• éditeurs d'attributs (définitions d'attributs, colonnes de table dans la vue du modèle physique, référentiel d'outils L4G, par exemple, attributs étendus dans PowerBuilder).

Identification de l'entité. Entités dans ERwin

Dans un diagramme, une entité est représentée par un rectangle. Selon le mode de présentation du diagramme, le rectangle peut contenir le nom de l'entité, sa description, une liste de ses attributs et d'autres informations.
La ligne horizontale du rectangle divise les attributs de l'entité en deux ensembles : les attributs qui composent la clé primaire dans la partie supérieure et les autres (non inclus dans la clé primaire) dans la partie inférieure.
Une entité est un ensemble d’objets réels ou abstraits, tels que des personnes, des lieux, des événements, des faits, qui possèdent des caractéristiques communes. L'essence est un concept logique. L'entité correspond à une table dans un vrai SGBD. Dans ERwin, une entité représente visuellement trois principaux types d'informations :

• les attributs qui composent la clé primaire ;
• attributs non clés ;
• type d'entité (indépendant/dépendant).

Une clé primaire est un attribut ou un ensemble d'attributs qui identifie de manière unique une instance d'une entité. Si plusieurs ensembles d'attributs peuvent identifier de manière unique une entité, alors le choix de l'un d'entre eux est effectué par le développeur sur la base d'une analyse du domaine.
Pour chaque clé primaire, ERwin crée un index unique lors de la génération de la structure de la base de données.
Les instances d'une entité indépendante peuvent être identifiées de manière unique sans définir ses relations avec d'autres entités ; une entité dépendante, en revanche, ne peut être identifiée de manière unique sans identifier ses relations avec d’autres entités. Une entité dépendante est affichée dans ERwin sous la forme d'un rectangle arrondi.

Relations dans ERwin

Une connexion est une dépendance fonctionnelle entre deux entités (en particulier, une entité peut se connecter avec elle-même). Par exemple, il est important de connaître le nom de famille de l'employé, et il est tout aussi important de savoir dans quel service il travaille. Ainsi, entre les entités « département » et « employé » il existe une relation « consiste en » (le département est constitué d'employés). Une relation est un concept de niveau logique auquel correspond une clé étrangère au niveau physique. Dans ERwin, les relations sont représentées par cinq informations principales :

• type de lien (identifiant, non identifiant, catégorie complète/incomplète, lien non spécifique) ;
• entité mère ;
• entité enfant (dépendante);
• pouvoir de communication (cardinalité);
• Acceptabilité des valeurs vides (nulles).

Une relation est dite identifiante si une instance d’une entité enfant est identifiée par sa relation avec une entité mère. Les attributs qui composent la clé primaire de l'entité parent sont également inclus dans la clé primaire de l'entité enfant. Une entité enfant dans une relation d'identification est toujours dépendante.
Une relation est dite non identifiante si une instance d’une entité enfant est identifiée autrement que par la relation avec l’entité mère. Les attributs qui constituent la clé primaire de l'entité parent sont également inclus dans les attributs non clés de l'entité enfant.
Pour définir des relations ERwin, sélectionnez le type de relation, puis utilisez la souris pour sélectionner les entités parent et enfant. Le lien d'identification est représenté par une ligne continue ; non identifiant - ligne pointillée. Les lignes se terminent par un point du côté de l'entité enfant.
Lors de la définition d'une relation, les attributs de clé primaire de l'entité parent sont migrés vers la portée d'attribut correspondante de l'entité enfant. Par conséquent, ces attributs ne sont pas saisis manuellement.
Les attributs de clé primaire d'une entité parent migrent avec leurs propres noms par défaut. ERwin vous permet de saisir des rôles pour eux, c'est-à-dire nouveaux noms sous lesquels les attributs migrés seront représentés dans l’entité enfant. Si un attribut est migré plusieurs fois, un tel changement de nom est nécessaire. Par exemple, l'entité « transaction intermédiaire » possède les attributs « code entreprise vendeur » et « code entreprise acheteur ». Dans ce cas, la clé primaire de l'entité « entreprise » (« code entreprise ») a deux rôles dans l'entité enfant.
Au niveau physique, le nom du rôle est le nom de la colonne de clé étrangère dans la table enfant.
La force d'une relation est le rapport entre le nombre d'instances d'une entité parent et le nombre correspondant d'instances d'une entité enfant. Pour toute relation autre que non spécifique, cette relation s'écrit 1:n.
ERwin, conformément à la méthodologie IDEF1X, propose 4 options pour n, qui sont représentées par un symbole supplémentaire dans l'entité enfant : zéro, un ou plusieurs (par défaut) ; zéro ou un ; exactement N, où N est un nombre spécifique.
L'acceptabilité des valeurs vides (NULL) dans les relations non identifiantes est représentée par ERwin comme un losange vide du côté de l'entité mère de l'arc de relation.
Les désignations de puissance, respectivement zéro, un ou plusieurs, un ou plusieurs, zéro ou un en notation IE, sont indiquées sur la Fig. 1.

Fig. 1. Notation de puissance de communication en notation IE

Le nom d'une relation au niveau logique est un « verbe » qui relie les entités. Le nom physique d'un lien (qui peut être différent du nom logique) pour ERwin est le nom d'une contrainte ou d'un index.

Édition du modèle graphique

Tous les objets du modèle ERwin peuvent être modifiés par les moyens courants sous Windows - regroupement, copie, suppression, déplacement, utilisation du tampon système. La définition des couleurs et des polices s'effectue dans des boîtes de dialogue pratiques.
Les composants du modèle représentés par du texte (noms d'entités, attributs, éléments de texte) peuvent être édités directement à l'écran.

Clés alternatives

Une clé alternative est un attribut (ou un groupe d'attributs) différent de la clé primaire et identifiant de manière unique une instance d'une entité. Par exemple, pour l'entité salarié (numéro salarié, nom, prénom, patronyme), le groupe d'attributs « nom », « prénom », « patronyme » peut être une clé alternative (en supposant qu'aucun homonyme complet ne travaille à l'entreprise).
Pour la clé alternative, comme pour la clé primaire, ERwin crée automatiquement des index lors de la génération de la base de données.

Index inversés

Les attributs qui composent la clé alternative identifient de manière unique les instances de l'entité. Dans ERwin, vous pouvez également créer des groupes d'attributs qui n'identifient pas de manière unique les instances d'une entité, mais sont souvent utilisés pour accéder aux données. Pour chacun de ces groupes d'attributs, ERwin crée des index non uniques.
Les mêmes attributs d'entité peuvent être inclus dans plusieurs groupes de clés différents.

Unification des attributs

Une entité dépendante peut hériter de la même clé étrangère de plusieurs entités parent, ou de la même entité parent via plusieurs relations. À moins que différents rôles ne soient introduits pour un tel héritage multiple, ERwin suppose que les attributs de clé étrangère n'apparaissent qu'une seule fois dans une entité dépendante.
L'unification est la combinaison de deux ou plusieurs groupes d'attributs de clé étrangère en une seule clé étrangère (groupe d'attributs), en supposant que les valeurs des attributs du même nom dans l'entité enfant sont toujours les mêmes.
Regardons un exemple : l'entité « employé » possède une clé primaire « code employé » et est associée à une relation d'identification avec les entités « conjoint » et « enfants ». Dans ce cas, la clé primaire est migrée vers les entités dépendantes. À son tour, l’entité « conjoint » est reliée par un lien non identifiant à l’entité « enfants ». Il existe deux chemins de migration clés, mais dans l'entité Enfants, l'attribut ID d'employé apparaît une fois en tant qu'élément de clé primaire.
Il existe des cas où l'unification des attributs donne un résultat incorrect du point de vue du domaine. Pour annuler l'unification, les noms de rôle sont saisis pour les attributs.

Certaines entités définissent toute une catégorie d'objets du même type. Dans ERwin, dans ce cas, une entité est créée pour définir la catégorie et pour chaque élément de la catégorie, puis une relation de catégorisation est introduite pour eux. L’entité parent d’une catégorie est appelée un supertype et ses enfants un sous-type.
Par exemple, l’entité « employé » peut contenir des données sur les employés à temps plein et les employés temporaires. Le premier et le second ont des ensembles d'attributs différents, se chevauchant partiellement (l'intersection minimale des sous-types est la clé primaire). La partie commune de ces attributs, y compris la clé primaire, est placée dans l'entité supertype employé.
Diverses parties (par exemple, les données sur le salaire horaire des travailleurs temporaires et les données sur le salaire et les vacances pour les travailleurs à temps plein) sont placées dans des entités de sous-type.
Dans une entité de supertype, un attribut discriminateur est introduit qui vous permet de distinguer les instances spécifiques d'une entité - un sous-type.
Selon que toutes les entités de sous-types possibles sont incluses dans le modèle, la relation catégorielle est complète ou incomplète. En poursuivant l'exemple, si un supertype peut contenir des données sur les employés licenciés, alors cette relation est une catégorisation incomplète, puisqu'il n'y a aucun enregistrement pour cela dans les entités de sous-type.
Dans ERwin, une catégorie complète est représentée par un cercle avec deux soulignements, et une catégorie incomplète est représentée par un cercle avec un soulignement.

Implémentation de l'intégrité référentielle à l'aide d'ERwin

L'intégrité référentielle est l'exigence selon laquelle les valeurs de clé étrangère d'une instance d'entité enfant correspondent aux valeurs de clé primaire de l'entité parent. L'intégrité référentielle peut être surveillée pour toutes les opérations qui modifient les données (INSERT/UPDATE/DELETE). Les contrôles d'intégrité référentielle dans ERwin incluent la génération automatique de déclencheurs et l'utilisation de mécanismes d'intégrité référentielle déclaratifs (pour les SGBD qui prennent en charge ces mécanismes).
Pour chaque relation au niveau logique, des exigences peuvent être spécifiées pour le traitement des opérations INSERT/UPDATE/DELETE pour les entités parent et enfant. ERwin propose les options suivantes pour gérer ces événements :

• manque de vérification;
• contrôle de validité ;
• interdiction d'exploitation;
• exécution en cascade d'une opération (DELETE/UPDATE) ;
• Définissez sur une valeur vide (NULL) ou une valeur par défaut spécifiée.

En fonction de l'option sélectionnée, ERwin crée automatiquement les déclencheurs nécessaires dans le dialecte SQL du SGBD cible. Parallèlement, ERwin utilise une bibliothèque de modèles de déclencheurs modifiables.
Lors de la génération d'une structure de base de données, les déclencheurs qui garantissent l'intégrité référentielle peuvent être remplacés à trois niveaux :

1. Les déclencheurs peuvent être remplacés pour fournir des règles pour l'ensemble du modèle.
2. Les déclencheurs spécifiés pour une relation spécifique peuvent être remplacés.
3. Les déclencheurs spécifiés pour une table spécifique peuvent être remplacés.

Le type de remplacement est spécifié par le développeur lors de la génération du schéma de base de données (Fig. 6 - Remplacement du type RI, remplacement des relations, remplacement de l'entité, respectivement).

Stockage des informations dans le modèle ERwin

En règle générale, les modèles ERwin sont enregistrés sur le disque sous forme de fichier. Il est possible de stocker le modèle dans le SGBD cible. Pour ce faire, en utilisant ERwin lui-même, une métabase ERwin est créée dans le SGBD cible. Cette base de données stocke les informations sur le modèle. Dans un cas particulier, la base de données peut également être constituée de fichiers dBase, avec lesquels ERwin travaille via ODBC.

Un exemple de développement de modèle dans ERwin

Examinons le cycle de développement en utilisant l'exemple donné dans l'article de Codd.
Rappelons brièvement le contenu du problème. Les dossiers des employés sont conservés. Pour chaque salarié, des informations sont stockées sur les enfants et une liste des postes occupés par ce salarié. Pour les postes, des informations sur les salaires officiels établis sont stockées.
Commençons par créer le niveau logique du modèle. Pour ce faire, définissez le mode d'affichage de l'entité (Affichage/Niveau d'entité). A l'aide de la barre d'outils, nous allons créer les entités « employé », « enfants », « historique professionnel », « historique salaire ». Nous nommerons les entités en russe.
Après avoir sélectionné chaque entité, nous en définirons une description détaillée en russe dans l'éditeur « Définition d'entité ». Cette description apparaîtra dans les rapports ERwin et pourra être affichée dans un graphique.
Indiquons les liens entre les entités. Par exemple, « employé » est lié par la relation d'identité « est un parent » à l'entité « enfants ». La description de la relation est saisie dans l'éditeur "Editeur/Relation".
Le résultat du travail est affiché sur le diagramme ERwin (Fig. 2).

Riz. 2. Diagramme de niveau d'entité

Passons maintenant au mode de paramétrage des attributs (Affichage/Niveau d'attribut). Dans l'éditeur "Entité/Attribut", nous définirons les noms des attributs clés et non clés en russe. Notez que pour l'entité enfant « enfants », l'attribut clé « numéro d'employé » n'est pas spécifié manuellement. ERwin gère sa migration depuis l'entité parent. La même chose se produit avec d'autres entités enfants.
Pour l'attribut « nom » de l'entité « employé », nous indiquons qu'il s'agit d'une clé alternative (nous supposerons que tous les employés ont des noms/prénoms uniques). Pour ce faire, après le nom de l'attribut, nous plaçons le pointeur AK1 entre parenthèses.
Le résultat du travail est affiché sur le diagramme ERwin (Fig. 3) en notation IDEF1X.

Riz. 3. Diagramme de niveau d'attribut en notation IDEF1X

La vue du même diagramme en notation IE (Information Engineering) est présentée sur la figure 4.

Riz. 4. Diagramme de niveau d'attribut en notation IE

Puisque nous avons spécifié les noms des attributs et des entités en russe, pour passer au niveau physique du modèle, nous devons leur attribuer des identifiants de tables, de colonnes et de restrictions qui satisfont aux règles du SGBD cible (cela signifie généralement l'utilisation de lettres latines). , chiffres et quelques caractères spéciaux).
Dans l'éditeur "Database Schema", précisez le nom de la table correspondant à chaque entité. Ensuite dans l'éditeur "Attribute Definition" nous définissons les noms des colonnes du tableau correspondant aux attributs de l'entité. ERwin propose également la migration des noms de colonnes vers des tables subordonnées.
A ce stade, vous pouvez également utiliser l'éditeur "Attributs étendus" pour définir les attributs étendus PowerBuilder (format d'affichage, masque d'édition, règles de contrôle, alignement, titres et commentaires).
L'éditeur de définitions de relations précise le nom physique de la relation, qui correspond au nom de la contrainte créée par ERwin dans la base de données.
Maintenant, tout est prêt pour créer une base de données et vous devez sélectionner le SGBD cible (si cela n'a pas été fait auparavant). Choisissons, par exemple, Sybase System 10.
Dans l'éditeur de schéma de base de données SYBASE, nous définissons les types de données pour les colonnes du tableau.
La boîte de dialogue dans laquelle le type de données est sélectionné est illustrée à la Fig. 5.

Riz. 5. Définition du modèle physique

Vous pouvez maintenant procéder à la création de la base de données. Pour cela, exécutez la commande "Génération de schéma Sybase". ERwin construira un package d'instructions de génération de base de données SQL. La figure 6 montre la boîte de dialogue de sélection des paramètres de génération de package pour générer une base de données. La figure montre qu'un filtre peut être défini (toutes les tables ne sont pas générées), qu'un ensemble d'instructions SQL peut être visualisé (aperçu), imprimé, enregistré dans un fichier (rapport) et généré (généré).

Riz. 6. Sélection des paramètres de génération de base de données

7. Fonctionnalités avancées d'ERwin

Ingénierie inverse

L'ingénierie inverse, c'est-à-dire la reconstruction d'un modèle d'information à partir d'une base de données existante, est utilisée lors du choix de la plate-forme optimale (redimensionnement) pour une base de données de bureau ou mainframe existante, ainsi que lors de l'extension (ou de la modification) d'une structure existante qui a été construite sans nécessité. documentation d'accompagnement. Une fois le processus de récupération du modèle terminé, ERwin « présente » automatiquement les tableaux dans le diagramme. Vous pouvez désormais effectuer des modifications à l'aide du diagramme logique - ajouter des entités, des attributs, des commentaires, des connexions, etc. Une fois les modifications terminées, une commande - synchroniser le modèle avec la base de données - met à jour toutes les modifications apportées.
Le modèle peut être construit à l'aide à la fois des données du catalogue de base de données et du package d'instructions SQL utilisé pour créer la base de données.

Synchronisation de la base de données

Lors du développement d'un système d'information, une situation peut survenir lorsque la structure de la base de données et le modèle d'information ne correspondent pas. ERwin offre la possibilité de les faire correspondre.
A cet effet, une fonction de synchronisation de base de données est fournie. Après connexion au SGBD, une liste d'incohérences entre la structure de données existante et le modèle est proposée. Par exemple, si une nouvelle table est créée dans la base de données, ERwin proposera de l'inclure dans le modèle. Si une nouvelle table est ajoutée au modèle, ERwin vous proposera de la créer dans la base de données réelle. De même, lors de l'ajout de colonnes à une base de données ou un modèle, ERwin vous propose d'effectuer les opérations de synchronisation appropriées. La procédure de sélection des tables synchronisées est illustrée à la Fig. 7.

Riz. 7. Sélection des tables synchronisées

ERwin "connaît" les fonctionnalités de stockage de données dans des SGBD individuels telles que les segments (dans Sybase) et les tablespaces (dans Oracle). Les informations de configuration physique peuvent être incluses dans le modèle et utilisées dans l'ingénierie directe et inverse.

Interfaces vers le SGBD

ERwin prend en charge l'interface directe avec les principaux SGBD : DB2 versions 2 et 3, Informix versions 5.1, 6.0, 7.1, Ingres, NetWare SQL, ORACLE versions 6 et 7, Progress, Rdb versions 4 et 6, SQL/400 versions 2 et 3, SQLBase versions 5 et 6, SQL Server versions 4 et 6, Sybase version 4.2, Sybase System 10 et 11, Watcom SQL. Notez que les versions les plus modernes et les versions précédentes du SGBD principal sont prises en charge (Fig. 8).

Riz. 8. Sélection d'un SGBD pour créer un modèle

ERwin prend également en charge les SGBD de bureau : Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV et Paradox.
La conception au niveau physique se fait en termes de base de données destinée à être utilisée dans le système. Il est important qu'ERwin « connaisse » la correspondance entre les capacités des SGBD de différents fabricants, ce qui permet de convertir le schéma physique conçu pour un SGBD en un autre.
Pour créer la structure physique de la base de données, la génération d'un script DDL (langage de définition de données) peut être demandée. Celui-ci utilise le dialecte SQL pour le type et la version de serveur sélectionnés. Bien que le code généré n'ait pas besoin d'être modifié, il peut être enregistré dans un fichier ou imprimé.

Prise en charge 4GL

ERwin est disponible en plusieurs éditions différentes, ciblant les outils de développement 4GL les plus courants. Les outils pris en charge incluent PowerBuidler de Powersoft, SQL Windows de Gupta, Visual Basic de Microsoft et Oracle*CASE d'Oracle.
Les capacités d'interaction bidirectionnelles avec les bases de données d'ERwin assurent une gestion des informations orientée à la fois vers le serveur et vers le client. Par exemple, pour PowerBuilder, vous pouvez afficher/modifier les attributs étendus dans les éditeurs ERwin.
L'accent mis par ERwin sur les outils 4GL vous permet de définir la plupart des paramètres directement liés à la base de données pour les futures applications dès la phase de conception du modèle d'information.
Montrons les principes d'organisation d'une telle interaction en utilisant l'exemple de PowerBuilder.
PowerBuilder crée plusieurs tables internes dans la base de données pour stocker son référentiel (attributs étendus pour datawindow). L'utilisation d'attributs étendus garantit que le style d'affichage des mêmes colonnes de base de données reste le même pour toutes les applications créées par le groupe de travail. Dans les attributs étendus, des paramètres tels que le format d'affichage, le style d'édition, l'expression de validation, la valeur initiale, l'alignement, la largeur et la hauteur de l'élément d'affichage, l'étiquette du formulaire d'édition, le titre pour l'affichage du tableau sont spécifiés.
Pour les attributs étendus, les mêmes opérations de synchronisation sont autorisées que pour l'ensemble du modèle, c'est-à-dire que les descriptions peuvent être chargées dans la base de données et, à l'inverse, les définitions d'attributs étendus créées à partir de l'environnement PowerBuilder peuvent être chargées depuis la base de données dans ERwin pour modification.
Un exemple de définition d'attributs étendus est présenté sur la figure 9.

Riz. 9. Définition des attributs étendus de PowerBuilder

La fonction de génération DataWindow d'ERwin permet de générer des prototypes de fenêtres de données pour une future application déjà au stade de la création d'un modèle d'information. Pour créer une fenêtre de données, un assistant est proposé, avec lequel vous spécifiez le style de la fenêtre et les colonnes du tableau sélectionnées.