Les diagrammes ER (Figure 2) sont utilisés pour le développement des données et constituent un moyen standard de définir les données et les relations entre elles. Ainsi, le détail des entrepôts de données est effectué. Un diagramme ER contient des informations sur les entités du système et la façon dont elles interagissent, y compris l'identification des objets importants pour le domaine (entités), les propriétés de ces objets (attributs) et leurs relations avec d'autres objets (liens). Dans de nombreux cas, le modèle d’information est très complexe et contient de nombreux objets.

Riz. 2. Exemple de diagramme ER

Une entité est représentée par un rectangle avec le nom de l'entité en haut (par exemple, TITRES). Le rectangle peut lister les attributs d'une entité ; Les attributs du diagramme ER saisis en gras1 sont clés (par exemple, Title Identity est un attribut clé de l'entité TITLES, les autres attributs ne sont pas clés).

Une relation est représentée par une ligne entre deux entités (lignes bleues sur la figure).

La ligne unique à droite (Figure 3) signifie « un », la « patte d'oiseau » à gauche signifie « plusieurs », et la relation se lit le long de la ligne, par exemple « un à plusieurs ». Une barre verticale signifie « obligatoire », un cercle signifie « facultatif », par exemple, pour chaque publication dans TITRE, l'éditeur dans PUBLISHERS doit être indiqué, et un éditeur dans PUBLISHERS peut publier plusieurs titres de publications dans TITRES. A noter que les connexions sont toujours commentées (inscription sur la ligne représentant la connexion).

Riz. 3. Élément du diagramme ER

Donnons également un exemple (Fig. 4) d'une image de la relation réflexive « employé », où un employé peut gérer plusieurs subordonnés et ainsi de suite dans la hiérarchie des postes.

Il convient de noter qu'une telle relation est toujours facultative, sinon ce sera une hiérarchie sans fin.

Riz. 4. Diagramme ER de l'attitude réflexive

Les attributs d'entité peuvent être essentiels : ils sont mis en évidence en gras ; obligatoire - ils sont précédés d'un signe "*", c'est-à-dire que leur valeur est toujours connue, facultatif (facultatif) - ils sont précédés d'un O, c'est-à-dire que les valeurs de cet attribut peuvent être absentes ou incertaines à certains des moments.

Si une entité entretient un ensemble de relations mutuellement exclusives avec d’autres entités, alors ces relations sont dites en arc. Par exemple, un compte bancaire peut être émis soit pour une personne morale, soit pour une personne physique. Un fragment d'un diagramme ER pour ce type de relation est présenté sur la Fig. 5.

Riz. 5.Arcs

Dans ce cas, l'attribut OWNER de l'entité COMPTE a une signification particulière pour cette entité - l'entité est divisée en types par catégorie : « pour une personne physique » et « pour une personne morale ». Les entités résultantes sont appelées sous-types et l'entité d'origine devient un supertype. Pour comprendre si un supertype est nécessaire ou non, vous devez établir combien de propriétés identiques possèdent différents sous-types. Il convient de noter que l’utilisation abusive des sous-types et des supertypes est une erreur assez courante. Ils sont représentés comme le montre la Fig. 6.

Riz. 6. Sous-types (à droite) et supertype (à gauche)

Comme indiqué précédemment, l'un des principaux objectifs de la modélisation sémantique est de garantir que les résultats de l'analyse du domaine se reflètent sous une forme simple, visuelle, mais en même temps formalisée et suffisamment informative.

En ce sens, la modélisation de domaine basée sur l’utilisation de diagrammes graphiques est une bonne solution. La forme graphique permet d'afficher sous une forme compacte (grâce à des symboles visuels) la typologie et les propriétés des entités et des relations, et les formalismes sous-jacents aux diagrammes ER permettent de formuler un ensemble final de règles pour concevoir la structure logique d'une base de données. .

Un diagramme est une représentation graphique d'un ensemble d'éléments, le plus souvent représenté sous la forme d'un graphe connecté avec des sommets d'objet et des arêtes de relation. Dans un diagramme ER, les sommets sont des entités et (par exemple, dans la notation de Chen) des propriétés d'entités. Les bords d'un diagramme ER représentent les relations entre les entités et entre une entité et ses propriétés.

Il existe plusieurs notations (langages) différentes pour représenter les diagrammes ER. Historiquement, la notation de Chen est la première ; dans la famille de normes IDEF, le modèle entité-relation est implémenté par la notation IDEF1X ; Les notations Martin et Barker sont utilisées, ainsi que des éléments graphiques UML.

Riz. 5.5. Diagramme ER en notation UML

Notation UML. En figue. La figure 5.5 montre un exemple de diagramme SbA ER en notation UML.

Langue unifiée Modélisation UML(Unified Modeling Language) est un langage permettant de définir, représenter, concevoir et documenter systèmes logiciels, systèmes organisationnels et économiques, systèmes techniques et autres systèmes de natures diverses. La structure UML est ensemble standard diagrammes et notations.

Les principaux objectifs du développement d'UML étaient :

Fournir un langage de modélisation visuelle expressif et prêt à l'emploi qui vous permet de développer et de partager des modèles significatifs ;

Fournir des mécanismes d'extensibilité des concepts linguistiques de base ;

Garantir l’indépendance par rapport aux langages de programmation et aux processus de développement spécifiques.

Intégrer les meilleures pratiques.

Actuellement, UML est en cours de normalisation menée par l'organisme de normalisation dans le domaine des méthodes et technologies orientées objet (OMG - Object Management Group).

Considérons les règles de représentation des entités, des propriétés et des relations dans cette notation.

Chaque type d'entité dans les diagrammes ER de notation UML est représenté sous la forme d'un rectangle contenant le nom de l'entité et une liste de propriétés de l'entité. Le nom de l'entité est généralement un nom singulier (par exemple, DÉPARTEMENT, PROJET, EMPLOYÉ). Le nom de l'entité est indiqué en haut du rectangle avec lettre capitale, les noms de propriété sont répertoriés au bas du rectangle et commencent par une lettre minuscule.

Les entités faibles se caractérisent par le fait qu'elles ne peuvent être identifiées sans ambiguïté qu'à l'aide de leurs propres attributs (en raison de leur dépendance à l'égard des entités « mères » et de l'impossibilité d'une existence indépendante). Dans les diagrammes ER, les entités faibles n'ont pas de clés primaires (par exemple, l'entité SUBJECT)

Les propriétés servent à clarifier, identifier, caractériser ou exprimer l'état d'une entité ou d'une relation. La typologie des propriétés reflétées dans les diagrammes ER est présentée dans le tableau. 5.2.

Tableau 5.2. Représentation des types de propriétés en UML

Type de propriété	Description	Exemple
Propriété de clé primaire	L'identification de la clé primaire (PK) est placée entre accolades après le nom de la propriété.
Polysémique	après le nom de la propriété, les limites possibles de modification du nombre de valeurs sont précisées entre crochets
Dérivé	le nom de la propriété commence par une barre oblique "/"
Conditionnel (facultatif)	après le nom de la propriété, les limites possibles de modification du nombre de valeurs sont précisées entre crochets
Composite	sous le nom d'une propriété composée, sont répertoriés les noms des propriétés simples, en retrait à droite

Les connexions binaires sont indiquées par des lignes indiquant le nom de la connexion et la force de la connexion de la part de chaque entité. La force du lien détermine le nombre d'objets connectés à chaque objet à l'autre extrémité du lien :

1..* - un ou plus;

0..* - zéro ou plus ;

1 – exactement un ;

0..1 – peut-être un.

Une plage peut également être spécifiée (par exemple, 1..10) ou un nombre exact autre que 1

Indiquer n-La connexion aire utilise un losange, à l'intérieur duquel le nom de la connexion est indiqué. Multiplicité n La connexion -aire pour chaque entité montre quel peut être le nombre de ses objets si exactement un objet est impliqué dans la connexion des autres entités participantes. Par exemple, la connexion à trois voies de la Fig. 5.6 précise que tout fournisseur peut fournir des lots de n'importe quelle pièce pour n'importe quel projet.

Riz. 5.6. Exemple de communication à trois

La présence d'une valeur de « 0 » dans le réglage de la puissance de communication déclare la communication comme incomplète (facultatif). Par exemple, la relation FONCTIONNE entre les entités DÉPARTEMENT et EMPLOYÉ dans la Fig. 5.5 doit se lire comme suit : « Chaque salarié travaille nécessairement dans un seul service ; le département emploie un nombre arbitraire d’employés, voire aucun.

La relation peut être modifiée en spécifiant un rôle. Par exemple, pour la connexion récursive COMPOSITION sur la Fig. 5.5 les rôles sont indiqués : « Détail comprend..." et "Détail dans le cadre de…».

Une relation plusieurs-à-plusieurs peut avoir ses propres propriétés qui caractérisent l'interaction des entités (par exemple, les connexions PARTICIPATION et MISE EN ŒUVRE DU PROJET sur la Fig. 5.5). Dans ce cas, pour représenter la connexion, utilisez élément graphique, correspondant à une entité faible. Le rectangle de l'entité est attaché à la ligne de lien (ou au losange dans le cas de n-ary liaison) avec une ligne pointillée.

Notation de Chen. Chaque type d'entité dans la notation de Chen est représenté par un rectangle contenant le nom de l'entité (nom singulier).

La communication (à la fois binaire et n-ary) sur le diagramme ER est affiché sous la forme d'un losange avec le nom de la connexion à l'intérieur. Les noms verbaux sont généralement utilisés comme noms.

Les propriétés sont affichées sous forme d'ellipses contenant le nom de la propriété. L'ellipse est reliée à l'entité ou connexion correspondante par une ligne (Fig. 5.7).

Riz. 5.7. Fragment d'un diagramme ER en notation de Chen

Les participants à la communication sont connectés à la communication par des lignes. La double ligne indique la participation complète (obligatoire) de l'entité dans le cadre de ce côté. Par exemple, la connexion GESTION obligatoire de la part de l'entité PROJET (Fig. 5.8) signifie que chaque projet doit avoir un responsable. Cependant, tous les employés ne devraient pas diriger un projet.

Le type de connexion est indiqué par les indices « 1 » ou « M » au-dessus de la ligne correspondante. Par exemple, la relation GESTION (Fig. 5.8) est de type un-à-plusieurs : un employé peut gérer plusieurs projets ; La relation PARTICIPATION (Fig. 5.7) est du type plusieurs-à-plusieurs : un employé peut participer à plusieurs projets, et plusieurs employés peuvent participer à un projet.

Introduction

Idées centrales du moderne informatique sont basés sur le concept selon lequel les données doivent être compilées dans des bases de données afin de refléter l'évolution du monde réel et de répondre aux besoins d'information des utilisateurs. Ces bases de données sont constituées et fonctionnent sous le contrôle de systèmes logiciels spéciaux (ensembles de langages de programmation et de logiciels), appelés systèmes de gestion de bases de données (SGBD). La base de données elle-même est un référentiel pour une grande quantité de données systématisées avec lesquelles vous pouvez effectuer certaines actions : ajouter, supprimer, modifier, copier, organiser.

L'augmentation du volume des données stockées et l'élargissement du cercle des utilisateurs des systèmes d'information ont conduit à l'utilisation généralisée du SGBD relationnel (tabulaire) le plus pratique et relativement facile à comprendre. Pour assurer un accès simultané aux données par de nombreux utilisateurs, souvent situés assez loin les uns des autres et du lieu où sont stockées les bases de données, des versions multi-utilisateurs en réseau de bases de données basées sur une structure relationnelle ont été créées. D'une manière ou d'une autre, ils résolvent des problèmes spécifiques de processus parallèles, d'intégrité (exactitude) et de sécurité des données, ainsi que d'autorisation d'accès.

Au cours des dernières années, on a observé une tendance vers des structures de données plus complexes. Types simples informations présentées sous forme de chiffres et chaînes de texte, sans perdre leur importance, sont aujourd'hui complétés par de nombreux documents multimédias, images graphiques, séries chronologiques, données procédurales ou actives et une myriade d'autres éléments complexes. formulaires d'informations. À cet égard, toute une galaxie de SGBD ont émergé, prenant en charge de nouvelles collections de données et capables de tirer parti des avantages du matériel moderne. Un de ces SGBD est MS Access 2003 (2007), inclus dans le package Programmes Microsoft Office, et est l'un des SGBD relationnels les plus populaires pour les ordinateurs locaux.

La popularité du SGBD Microsoft Access est due à Pour les raisons suivantes:

l'accessibilité à l'étude et la compréhensibilité nous permettent d'être l'un des meilleurs systèmes création rapide applications de gestion de bases de données ;

complètement russifié;

la possibilité d'utiliser la technologie OLE ;

soutien à l'idéologie du WWW ;

la technologie visuelle vous permet de voir en permanence les résultats de vos actions et de les corriger ; de plus, travailler avec le concepteur de formulaires peut faciliter considérablement l'étude plus approfondie des systèmes de programmation tels que Visual Basic ou Delphes ;

le système d'aide est largement et clairement présenté ;

la présence d'un large ensemble de « maîtres » dans le développement d'objets.

Actuellement, les systèmes d'information automatisés (AIS) sont largement utilisés dans diverses grandes organisations.

Cible de ce projet: application pratique des connaissances acquises au cours de l'étude du cours « Bases de données » et acquisition de compétences pratiques dans la conception et la création de systèmes d'information (SI) basés sur des bases de données.

Concepts de base du modèle ER : entité, instance d'entité, attribut, clé, relation, types de relations

Les principaux concepts du modèle ER sont l'entité, la relation et l'attribut.

Une entité est un objet réel ou imaginable sur lequel des informations doivent être stockées et accessibles. Dans les diagrammes du modèle ER, une entité est représentée sous la forme d'un rectangle contenant le nom de l'entité. Dans ce cas, le nom de l'entité est le nom du type, et non celui d'une instance spécifique de ce type. Pour plus d'expressivité et une meilleure compréhension, le nom de l'entité peut être accompagné d'exemples d'objets spécifiques de ce type.

Chaque instance d'une entité doit pouvoir être distinguée de toutes les autres instances de la même entité (cette exigence est quelque peu analogue à l'exigence selon laquelle il n'y a pas de tuples en double dans les tables relationnelles).

Un attribut d'entité est tout détail qui sert à clarifier, identifier, classer, quantifier ou exprimer l'état de l'entité. Les noms d'attributs sont saisis dans un rectangle représentant l'entité, sous le nom de l'entité, et sont représentés en minuscules, éventuellement accompagnés d'exemples.

Une clé d'entité est un ensemble non redondant d'attributs dont les valeurs collectives sont uniques pour chaque instance d'entité. La non-redondance signifie que la suppression d'un attribut d'une clé brise son caractère unique. Une entité peut avoir plusieurs clés différentes. Les attributs clés sont soulignés dans le diagramme.

Une relation est une association représentée graphiquement établie entre deux entités. Cette association est toujours binaire et peut exister entre deux entités différentes ou entre une entité et elle-même (relation récursive). Dans toute connexion, deux extrémités sont identifiées (conformément à la paire d'entités connectées existante), chacune indiquant le nom de la fin de la connexion, le degré de fin de la connexion (combien d'instances de cette entité sont connectées ), le caractère obligatoire de la connexion (c'est-à-dire si une instance de cette entité doit participer à cet égard).

Une connexion est représentée comme une ligne reliant deux entités ou menant d'une entité à elle-même. Dans ce cas, au point où la connexion « rejoint » l'entité, une entrée à trois points dans le rectangle de l'entité est utilisée, si de nombreuses instances de l'entité peuvent être utilisées pour cette entité dans la connexion, et une entrée à un seul point entrée, si une seule instance de l’entité peut participer à la connexion. L'extrémité requise de la connexion est représentée par une ligne continue et l'extrémité facultative par une ligne discontinue.

Chaque lien a deux extrémités et un ou deux noms. Le nom est généralement exprimé sous une forme verbale indéfinie : « avoir », « appartenir », etc. Chaque nom fait référence à sa propre extrémité de la connexion. Parfois, les noms ne sont pas écrits parce qu’ils sont évidents. Chaque lien peut avoir l'un des types de lien suivants :

Unà une

Untrop

Plusieurs à plusieurs

Riz. 1 – Types de connexions

Une relation un-à-un signifie qu'une instance de la première entité (celle de gauche) est associée à une instance de la deuxième entité (celle de droite). Une relation biunivoque indique le plus souvent que nous n’avons en réalité qu’une seule entité, incorrectement divisée en deux.

Une relation un-à-plusieurs signifie qu'une instance de la première entité (celle de gauche) est associée à plusieurs instances de la deuxième entité (celle de droite). C’est le type de communication le plus couramment utilisé. L’entité de gauche (du côté « un ») est appelée le parent, celle de droite (du côté « plusieurs ») est appelée l’enfant.

Une relation plusieurs-à-plusieurs signifie que chaque instance de la première entité peut être associée à plusieurs instances de la deuxième entité, et chaque instance de la deuxième entité peut être associée à plusieurs instances de la première entité. Le type de relation plusieurs-à-plusieurs est un type de relation temporaire qui est acceptable pendant les premières étapes du développement du modèle. À l’avenir, ce type de relation devrait être remplacé par deux relations un-à-plusieurs en créant une entité intermédiaire.

Chaque connexion peut avoir l'une des deux modalités de communication suivantes :

Peut être

Doit

Riz. 2 – Modalités de communication

La modalité « peut » signifie qu'une instance d'une entité peut être associée à une ou plusieurs instances d'une autre entité, ou ne peut être associée à aucune instance.

La modalité « doit » signifie qu'une instance d'une entité doit être associée à au moins une instance d'une autre entité.

Conversion du modèle ER en un modèle de données relationnel

Examinons la transformation d'un modèle ER en un modèle de données relationnel à l'aide d'un exemple abstrait. Supposons qu'un modèle ER soit donné. Il faut obtenir un ensemble de tables (relations) de la forme Table (Clé, Attribut1, Attribut2, ..., AttributN). La clé peut être composée. Il est pratique de rendre uniques les noms des attributs à l'échelle du modèle ER, puis lors de la construction d'un modèle relationnel, ils devront (presque jamais) être renommés.

Conversion d'ensembles d'entités (Entités en abrégé)

1. Conversion d'une entité régulière

Riz. 3 – Conversion d’une entité régulière

Une entité normale est convertie en une table séparée, les champs de la table seront tous les attributs de l'entité : Entité (Clé, Attribut1, Attribut2)

1. Conversion d'une entité faible

L'entité faible est convertie dans un tableau séparé, les champs du tableau seront tous les attributs de l'entité plus les attributs clés de toutes les entités avec lesquelles cette entité faible est identifiée.

Les champs clés de toutes les tables parents seront inclus dans la clé de la table enfant. Pour la table des enfants ils seront appelés clé étrangère: Entité1 (Clé1, Clé2, Attribut1, Attribut2).

Clé 1

Attribut 1

Attribut2

Entité 1

Essence2

Clé2

Riz. 4 – Faible transformation d’entité

1. Conversion des sous-types d'entité

1 façon. Un tableau est créé dans lequel tous les attributs sont placés. Afin d'indiquer à quel sous-type appartient un objet, vous devez saisir un champ d'attribut supplémentaire : Entité1 (Clé, Attribut1, Attribut2, Attribut3, Attribut4, Attribut4, Attribut).

L'inconvénient de cette méthode est que de nombreux champs vides restent dans le tableau : pour un objet de sous-type 1, les attributs 4 et 5, et pour un objet de sous-type 2, les attributs 2 et 3 resteront vides.

Méthode 2. Un tableau distinct est créé pour chaque sous-type. Il comprend tous les attributs de ce sous-type et tous les attributs du supertype :

Sous-type1 (Clé, Attribut1, Attribut2, Attribut3)

Sous-type2 (Clé, Attribut1, Attribut4, Attribut5)

L’inconvénient de cette approche est que les sous-types ne sont plus liés les uns aux autres.

3 voies. Une table est créée pour le supertype et une table pour chaque sous-type, qui inclut les champs clés du supertype :

Entité1 (Clé, Attribut1)

Sous-type1 (Clé, Attribut2, Attribut3)

Sous-type2 (Clé, Attribut4, Attribut5)

L'inconvénient de cette approche est que les informations sur chaque objet sont désormais dispersées dans deux tables.

Riz. 5 – Conversion des sous-types d’entité

Transformer les liens

1. Connexion M:M

Pour les connexions – double losange, vous n’avez rien à faire, toutes les informations sont déjà stockées dans la table de l’entité faible.

Riz. 6 – Communication M:M

Un nouveau tableau est créé contenant les champs clés de chaque entité participant à la relation et les propres attributs de la relation, le cas échéant. Le nom reflète généralement les entités liées ou fait référence à la nouvelle table par le nom de la relation.

Entité1Entité2 (Clé1, Clé2, Attribut1).

Si l'attribut propre d'une connexion est clé, alors en fait il ne s'agit plus d'une connexion binaire, mais d'une connexion de plus grande arité, c'est-à-dire cet attribut peut être remplacé par une nouvelle entité avec laquelle existe une relation biunivoque. Dans ce cas, vous devez appliquer les règles pour les relations ternaires et autres

1. Lien 1 : M

Riz. 7 – Lien 1:M

1 façon. De la même manière que dans le cas de M:M, une nouvelle table est créée contenant les champs clés de chaque entité participant à la relation. Le nom reflète généralement les entités liées ou fait référence à la nouvelle table par le nom de la relation. La clé sera la clé de la deuxième entité.

Entité1Entité2(Clé1, Clé2).

Méthode 2. Une nouvelle table n'est pas créée, et les champs clés de l'entité parent sont ajoutés à la table de l'entité enfant (ils ne seront pas inclus dans la clé de l'entité enfant). Les champs clés de l'entité parent représentent la clé étrangère de l'entité enfant.

Il est préférable d'utiliser cette méthode si la relation est exactement une relation, c'est-à-dire que toutes les instances d'entité sont impliquées dans la relation. Dans ce cas, le champ de clé étrangère ne sera jamais vide.

Table d'entité enfant : Entité2 (Clé2, Attribut1, Clé1).

1. Communication 1:1

Riz. Communication 8 – 1:1

1 façon. De la même manière que dans le cas de M:M, une nouvelle table est créée contenant les champs clés de chaque entité participant à la relation. Le nom reflète généralement les entités liées ou fait référence à la nouvelle table par le nom de la relation. La clé sera la clé de toute entité.

Il est préférable d'utiliser cette méthode si la relation n'est pas « exactement à un », c'est-à-dire que toutes les instances d'entité ne participent pas à la relation.

Entité1Entité2(Clé1, Clé2) ou Entité1Entité2(Clé1, Clé2).

Méthode 2. Exactement de la même manière que dans le cas 2 1:M, une nouvelle table n'est pas créée, mais les champs clés d'une autre entité (on la considérera comme le parent) sont ajoutés à la table d'une des entités (on la considérera un enfant).

Si la relation n'est pas exactement une relation avec la table parent, c'est-à-dire que toutes les instances d'entité ne participent pas à la relation, le champ de clé étrangère de certains enregistrements peut être vide.

Table d'entité enfant : Entité1 (Clé1, Attribut1, Clé2),

ou Entité2 (Clé2, Attribut2, Clé1).

3 voies. Deux tableaux pour les entités liées 1:1 sont fusionnés en un seul. La clé de la nouvelle table peut être une combinaison des clés des deux tables. Si la relation est « exactement à un » dans au moins une direction, alors la clé de cette entité peut être considérée comme la clé de la table jointe.

Tableaux : Entity1(Key1, Attribute1) et Entity2(Key2, Attribute2) sont remplacés par

Entité1Entité2(Clé1, Attribut1, Clé2, Attribut2)

ou peut-être Entity1Entity2(Key1, Attribute1, Key2, Attribute2),

ou Entity1Entity2 (Clé1, Attribut1, Clé2, Attribut2).

Les mêmes règles s'appliquent pour relier une entité à elle-même, mais comme la même entité est impliquée deux fois dans la relation, les champs clés doivent apparaître deux fois dans le même tableau. Par conséquent, vous devez renommer l’une des clés.

Regardons la relation 1:M, méthode 2. La clé étrangère a été renommée.

Riz. 9 – Relation 1:M, clé étrangère renommée

Entité1 (Clé1, Attribut1, AutreClé1).

Pour les relations avec une arité supérieure à 2, la même méthode est généralement utilisée que pour une relation binaire M:M : une nouvelle table est créée contenant les champs clés de tous tableaux associés: Entité1Entité2Entité3(Clé1, Clé2, Clé3).

Règles de conversion d'un modèle ER en modèle relationnel

Règle 1. Chaque entité est associée à une relation dans le modèle de données relationnel. Dans ce cas, les noms de l'entité et la relation peuvent être différents, car les noms des entités ne peuvent pas être soumis à des restrictions syntaxiques supplémentaires, à l'exception du caractère unique du nom au sein du modèle. Les noms de relations peuvent être limités par les exigences d'un SGBD particulier ; le plus souvent, ces noms sont des identifiants dans certains langue de base, ils sont de longueur limitée et ne doivent pas contenir d'espaces et certains caractères spéciaux. Par exemple, une entité peut être appelée « Catalogue de livres », et il convient de nommer la relation correspondante, par exemple LIVRES (sans espaces et en lettres latines).

Règle 2 : Chaque attribut d'entité devient un attribut de la relation correspondante. Pour chaque attribut, un type de données spécifique autorisé dans le SGBD et le caractère obligatoire ou facultatif de cet attribut sont spécifiés (c'est-à-dire l'admissibilité ou l'inadmissibilité des valeurs NULL pour celui-ci).

Règle 3. La clé primaire d'une entité devient la CLÉ PRIMAIRE de la relation correspondante. Les attributs inclus dans la clé primaire d'une relation se voient automatiquement attribuer la propriété requise (NON NULL).

Règle 4. Dans chaque relation correspondant à une entité subordonnée, un ensemble d'attributs de l'entité principale est ajouté, qui est la clé primaire de l'entité principale.

Dans la relation correspondant à l'entité subordonnée, cet ensemble d'attributs devient une FOREING KEY.

Pour modéliser un type de relation facultatif au niveau physique, les attributs correspondant à une clé étrangère sont définis pour autoriser les valeurs nulles (attribut NULL). Avec un type de connexion obligatoire, les attributs reçoivent la propriété de ne pas avoir de valeurs non définies (l'attribut NOT NULL).

Théorie de la normalisation

La normalisation des relations (tables) est l'une des parties fondamentales de la théorie des bases de données relationnelles. La normalisation vise à éliminer la redondance dans les relations et à modifier leur structure afin que le processus de collaboration avec elles ne soit pas alourdi par diverses difficultés superflues. Si cette approche est ignorée, l’efficacité de la conception diminue rapidement, ce qui, associé à d’autres libertés similaires, peut avoir des conséquences critiques.

Première forme normale

Une relation est sous sa première forme normale (en abrégé 1NF) si tous ses attributs sont atomiques, c'est-à-dire si aucun de ses attributs ne peut être divisé en attributs plus simples qui correspondent à d'autres propriétés de l'entité décrite.

Nous appellerons la relation originelle la relation principale, et la valeur de l'attribut non atomique la relation subordonnée.

Afin de normaliser une relation source dont les attributs sont non atomiques, il est nécessaire de combiner les schémas des relations principales et subordonnées. De plus, si, par exemple, une table correspondant à une relation non normalisée est déjà contenue dans la base de données et remplie d'informations, la tâche est compliquée par le fait que la valeur d'un attribut non atomique peut, à son tour, contenir plusieurs tuples.

Considérons une relation qui a les attributs « Code employé », « Nom complet », « Poste », « Projets ». Évidemment, un employé peut travailler sur plusieurs projets. Supposons qu'un projet soit décrit par un identifiant, un titre et une date d'échéance.

Code employé

Nom et prénom

Titre d'emploi

Projets

Ivanov Ivan Ivanovitch

Programmeur

ID : 123 ; Titre : Système de contrôle de chaudière à vapeur ; Date de soumission : 30/09/2011
ID : 231 ; Nom : PS pour la surveillance et l'avertissement en cas de dépassement de la concentration maximale admissible de divers gaz dans la pièce ; Date de soumission : 30/11/2011
ID : 321 ; Nom : Module de reconnaissance faciale pour système de sécurité ; Date de soumission : 12/01/2011

Il est facile de remarquer que tous les attributs de cette relation ne sont pas atomiques (indivisibles). En particulier, l'attribut « Projets » peut être divisé en trois attributs plus simples : « Code du projet », « Titre », « Date de livraison », et la valeur de cet attribut pour l'employé Ivan Ivanovitch Ivanov contient plusieurs tuples - des informations sur trois projets.

Considérons l'algorithme de normalisation du rapport à 1NF.

Créer une nouvelle relation dont le schéma sera obtenu en fusionnant les schémas principal et subordonné de la relation d'origine en un seul.

Pour chaque tuple de la relation d'origine, inclure dans la nouvelle autant de lignes qu'il y a de tuples contenus dans la relation subordonnée de ce tuple.

Remplissez les valeurs des attributs de la nouvelle relation correspondant aux attributs de la relation subordonnée. Remplissez les lignes de la nouvelle relation avec les valeurs des attributs atomiques de celle d'origine.

Appliquons cet algorithme à la relation ci-dessus. Le nouveau schéma relationnel sera composé de 6 attributs : « Code employé », « Nom complet », « Poste », « Code projet », « Titre », « Date de livraison ». Pour un seul tuple d'une relation donnée, ajoutez trois lignes à la nouvelle, une pour chaque projet (selon le nombre de tuples dans la relation subordonnée). Vous pouvez maintenant remplir les valeurs d'attribut séparées avec des tuples de la relation subordonnée. Ensuite, nous transférerons les valeurs des attributs atomiques à chacune de ces lignes : « Code de l'employé », « Nom complet », « Poste » (les trois lignes contiendront mêmes valeurs ces attributs).

Le résultat ressemblera à ceci :

Code employé

Nom et prénom

Titre d'emploi

Code de projet

Nom

Date d'échéance

Ivanov Ivan Ivanovitch

Programmeur

123

Système de contrôle de chaudière à vapeur

30.09.2011

Ivanov Ivan Ivanovitch

Programmeur

231

PS pour surveiller et avertir du dépassement de la concentration maximale admissible de divers gaz dans la pièce

30.11.2011

Ivanov Ivan Ivanovitch

Programmeur

321

Module de reconnaissance faciale pour système de sécurité

01.12.2011

Deuxième forme normale

Une relation en 1NF peut aussi avoir une redondance. La deuxième forme normale vise à l'éliminer. Mais avant de commencer à le décrire, il faut d’abord identifier les défauts du premier.

Supposons que la relation initiale contienne des informations sur la fourniture de certains biens et leurs fournisseurs.

Code fournisseur

Ville

Statut de la ville

Code produit

Quantité

Moscou

300

Moscou

400

Moscou

100

Iaroslavl

200

Stavropol

300

Stavropol

400

Pskov

100

On sait d'avance que cette relation contient les dépendances fonctionnelles suivantes :

( (Code fournisseur, Code produit) -> (Quantité),

(Code fournisseur) -> (Ville),

(Code fournisseur) -> (Statut),

(Ville) -> (Statut) )

Clé primaire dans la relation : (Code Fournisseur, Code Produit).

Il est évident que la relation est redondante : elle décrit deux entités : l’offre et le fournisseur. À cet égard, les anomalies suivantes surviennent :

Anomalie d'insertion. Vous ne pouvez pas ajouter d'informations sur un fournisseur qui n'a pas encore livré de marchandises à une relation.

Anomalie de suppression. S'il n'y a eu qu'une seule livraison du fournisseur, lorsque les informations la concernant sont supprimées, toutes les informations concernant le fournisseur seront supprimées.

Mettre à jour l'anomalie. Si vous devez modifier des informations sur le fournisseur (par exemple, le fournisseur a déménagé dans une autre ville), vous devrez alors modifier les valeurs d'attribut dans tous les enregistrements concernant les livraisons de sa part.

Signification physique La redondance de la relation originelle réside dans le fait qu'elle décrit non pas une entité, mais deux : l'offre et le fournisseur.

Pour éliminer ces anomalies, il faut décomposer la relation originelle en projections :

Le premier doit inclure la clé primaire et tous les attributs non clés qui en dépendent explicitement ;

Les projections restantes (dans ce cas, il n'y en a qu'une) incluront les attributs non clés qui dépendent implicitement de la clé primaire, ainsi que la partie de la clé primaire dont dépendent explicitement ces attributs.

En conséquence, deux relations seront obtenues :

Code fournisseur

Code produit

Quantité

300

400

100

200

300

400

100

La première relation correspond désormais aux dépendances fonctionnelles suivantes : (Code fournisseur, Code produit) -> (Quantité)

Code fournisseur

Ville

Statut de la ville

Moscou

Iaroslavl

Stavropol

Pskov

La deuxième relation correspond à :

( (Code fournisseur) -> (Ville),

(Code fournisseur) -> (Statut),

(Ville) -> (Statut) )

Cette décomposition a éliminé les anomalies décrites ci-dessus : il était possible d'ajouter des informations sur un fournisseur qui n'avait pas encore livré la marchandise, de supprimer des informations sur une livraison sans supprimer les informations sur le fournisseur et de mettre à jour facilement les informations si le fournisseur déménageait dans une autre ville.

Définition de la deuxième forme normale : Une relation est en deuxième forme normale (en abrégé 2NF) si et seulement si elle est en première forme normale et que chacun de ses attributs non-clés est irréductiblement dépendant de la clé primaire.

Modélisation sémantique

L'utilisation généralisée des SGBD relationnels et leur utilisation dans une grande variété d'applications montrent que le modèle de données relationnel est suffisant pour modéliser les zones problématiques. Cependant, concevoir une base de données relationnelle en termes de relations basées sur le mécanisme de normalisation dont nous avons brièvement parlé est souvent un processus très complexe et peu pratique pour le concepteur.

Dans le même temps, les limites du modèle de données relationnelles se manifestent dans les aspects suivants :

Le modèle ne fournit pas suffisamment de moyens pour représenter la signification des données. La sémantique du domaine réel doit être représentée dans la tête du concepteur de manière indépendante du modèle. Cela concerne notamment le problème de représentation des contraintes d’intégrité que nous avons évoqué.

Pour de nombreuses applications, il est difficile de modéliser le domaine à l'aide de tables plates. Dans un certain nombre de cas, dès le stade initial de la conception, le concepteur doit s'efforcer de décrire le domaine sous la forme d'un tableau (éventuellement même non normalisé).

Bien que l'ensemble du processus de conception se déroule sur la base de la prise en compte des dépendances, le modèle relationnel ne fournit aucun moyen pour représenter ces dépendances.

Bien que le processus de conception commence par l'identification de certains objets de domaine essentiels à l'application (« entités ») et par l'identification des relations entre ces entités, le modèle de données relationnel n'offre aucun appareil permettant de séparer les entités et les relations.

Les besoins des concepteurs de bases de données en outils de modélisation de domaine plus pratiques et plus puissants ont donné naissance à la tendance des modèles de données sémantiques. Étant donné que tout modèle de données sémantique développé, comme un modèle relationnel, comprend des parties structurelles, de manipulation et intégrales, l'objectif principal des modèles sémantiques est de fournir la possibilité d'exprimer la sémantique des données.

Le plus souvent, en pratique, la modélisation sémantique est utilisée dès la première étape de la conception d'une base de données. Dans ce cas, un schéma conceptuel de base de données est produit en termes de modèle sémantique, qui est ensuite converti manuellement en un schéma relationnel (ou autre). Ce processus est effectué sous le contrôle de méthodes dans lesquelles toutes les étapes d'une telle transformation sont clairement spécifiées.

La compilation automatisée d'un schéma conceptuel en un schéma relationnel est moins fréquemment mise en œuvre. Dans ce cas, deux approches sont connues : basée sur la présentation explicite du diagramme conceptuel comme information initiale pour le compilateur et la construction de systèmes de conception intégrés avec création automatisée du diagramme conceptuel sur la base d'entretiens avec des experts du domaine. Dans les deux cas, le résultat est un schéma de base de données relationnelle sous une troisième forme normale (il serait plus exact de dire que l'auteur ne connaît pas de systèmes offrant un niveau de normalisation plus élevé).

Enfin, la troisième possibilité, qui n'a pas encore dépassé (ou est en train de sortir) au-delà des projets de recherche et d'expérimentation, consiste à travailler avec une base de données dans un modèle sémantique, c'est-à-dire SGBD basé sur des modèles de données sémantiques. Dans ce cas, deux options sont à nouveau envisagées : fournir interface utilisateur basé sur un modèle de données sémantique avec mappage automatique des constructions sur un modèle de données relationnel (il s'agit d'une tâche à peu près du même niveau de complexité que la compilation automatique d'un schéma de base de données conceptuel en un schéma relationnel) et une implémentation directe d'un SGBD basé sur certains modèle de données sémantique. Les plus proches de la deuxième approche sont les SGBD modernes orientés objet, dont les modèles de données sont proches des modèles sémantiques à bien des égards (bien qu'à certains égards ils soient plus puissants et à d'autres plus faibles).

Modèle ER étendu (modèle EER)

Les concepts d'un modèle ER conventionnel sont suffisants pour représenter la plupart des schémas de bases de données, tels que la plupart des systèmes de bases de données commerciaux. Cependant, des domaines tels que les systèmes de conception assistée par ordinateur, les systèmes de préparation de production assistés par ordinateur, etc. imposent des exigences plus complexes à la base de données. Pour leur modélisation sémantique, le modèle ER a été complété par de nouveaux concepts et transformé en un modèle EER (Enhanced ER model). Un tel modèle contient tous les éléments du modèle ER ainsi que des concepts supplémentaires, à savoir les concepts de généralisation, de spécialisation et d'agrégation.

La généralisation est la combinaison d'un ensemble de classes (types) d'entités en plusieurs type général entités - superclasse. Si, au cours du processus d'analyse d'entité, il est découvert que deux ou plusieurs classes (types) d'entités ont ensembles généraux attributs, alors ces classes peuvent être combinées en une superclasse.

La spécialisation est le contraire de la généralisation. Cela consiste dans le fait qu'une certaine classe ou type général (agrégé, superclasse) est divisé en plusieurs sous-classes plus spécifiques (spécialisées).

L'agrégation est le processus de combinaison de plusieurs entités indépendantes (types) en un type agrégé (complexe).

Modèles conceptuels de RE

Conformément aux principales étapes de conception d'une base de données, après avoir construit un modèle conceptuel, un système de gestion de base de données est sélectionné, à l'aide duquel la base de données et le travail avec celle-ci seront organisés. Chaque SGBD prend en charge certains types et types de données, ainsi que des moyens de représenter les relations entre les données qui composent le modèle de données du SGBD. La deuxième étape de la conception d'une base de données consiste à présenter le modèle conceptuel construit à l'étape précédente à l'aide du modèle de données du SGBD ou à mapper le modèle conceptuel dans le modèle de données du SGBD. Cette étape est souvent appelée conception logique d’une base de données. Le modèle résultant est souvent également appelé modèle conceptuel ou schéma, mais spécifié selon les concepts du modèle de données du SGBD. Dans certaines sources, le modèle résultant est appelé structure de données logique ou modèle de données de base de données.

Le concept de modèle de données SGBD peut être caractérisé de différentes manières. D'une part, un modèle de données SGBD est un moyen de structurer des données qui est considéré comme une sorte d'abstraction isolée du domaine. D'autre part, un modèle de données SGBD est un outil permettant de représenter le modèle conceptuel d'un domaine et la dynamique de son évolution sous la forme d'une base de données.

En tenant compte des deux aspects ci-dessus, nous définirons les principales structures des modèles de données SGBD utilisées pour représenter le modèle conceptuel du domaine (entités, attributs, relations).

Un élément de données (champ) est la plus petite unité de données nommée. Utilisé pour représenter la valeur d'un attribut.

La notion de « type de données » est inextricablement liée à un élément de données, que le champ correspondant peut accepter. Peut être utilisé dans différents SGBD différents types les données dont les plus courantes, utilisées dans de nombreux SGBD, sont les suivantes : numérique (numeric), caractère (char), date (date), etc.

Un enregistrement est une collection nommée de champs. Utilisé pour représenter une collection d'attributs d'une entité (enregistrement d'entité).

Une instance d'enregistrement est un enregistrement avec des valeurs de champ spécifiques.

Une clé primaire est l'ensemble minimum de champs d'enregistrement qui identifie de manière unique une instance d'un enregistrement de fichier.

Un fichier est une collection nommée d’instances d’enregistrement du même type. Utilisé pour représenter un ensemble homogène d’entités.

Un ensemble de fichiers est une collection nommée de fichiers traités dans le système. Utilisé pour représenter plusieurs ensembles d'entités.

La notion de « groupe » est une notion générale de « fichier » et d'« enregistrement ».

Un groupe est une collection nommée d’éléments de données et d’autres groupes.

Le concept le plus important du modèle conceptuel est le concept de relations entre entités (ensembles d'entités). Dans les modèles de données SGBD, le concept correspondant est reflété par le concept de « relation de groupe ».

Une relation de groupe est une relation binaire nommée définie sur deux ensembles d'instances des groupes considérés. En fonction de la nature des relations binaires, on distingue les relations de groupe de type 1:1, 1:M, M:1, M:N. Les paires de nombres sont appelées coefficients de rapport de groupe. Dans une relation de groupe, un membre du groupe est désigné comme propriétaire de la relation et l'autre comme membre.

Deux formes sont utilisées pour représenter une relation de groupe :

un graphique. Les groupes sont représentés par les sommets du graphique, les connexions entre les groupes sont représentées par des arcs dirigés du groupe propriétaire vers le groupe membre, indiquant le nom de la relation et le coefficient.

Par type de graphiques il y a :

modèle hiérarchique(un graphe sans cycles est un arbre) ;

modèle de réseau (graphe orienté général).

b) Tabulaire. La relation entre les groupes est représentée par un tableau dont les colonnes représentent les clés des groupes correspondants. Pour décrire formellement un tableau, le concept mathématique (théorique des ensembles) de relation est utilisé. Le modèle de données correspondant est appelé modèle relationnel.

Exemples de modèles ER

Exemple 1

Modèle ER : Office du logement

Description de la tâche : Les employés des bureaux de logement ont besoin d'une base de données pour stocker des informations sur les demandes de réparations reçues des résidents. Le bureau du logement dessert un ensemble de maisons comprenant plusieurs rues. La demande vient de l'appartement. La demande est acceptée par le répartiteur, il fixe le numéro et la date de réception de la demande, détermine le type de demande et le délai pour sa réalisation. L'application est réalisée par une équipe de spécialistes. Chaque spécialiste ne peut travailler qu'en une seule équipe, chaque équipe a un contremaître.

Riz. 10 – Exemple de modèle ER d’un office du logement

Exemple 2

urgence- maquette du bureau « Cornes et sabots »

Description de la tâche : Le bureau « Cornes et Sabots » s'occupe de Activités commerciales pour la vente de produits fabriqués à partir de cornes et de sabots et la fourniture de services magiques.

Un employé de l'organisation a un nom complet, un numéro personnel et un poste. Les employés sont répartis dans plusieurs départements. Chaque département a un numéro, un nom et un chef. Un employé ne peut pas gérer plus d'un département.

L'organisation travaille avec des entreprises clientes. Chaque entreprise a un nom et une adresse. Plusieurs contrats peuvent être conclus avec une entreprise.

Le contrat est caractérisé par un numéro, une date et un type uniques. Chaque contrat est supervisé par un certain employé. Au fur et à mesure que les biens et services visés par le contrat sont vendus au client, des factures sont émises à certains intervalles.

La facture est caractérisée par un numéro unique, la date d'émission, les modalités et le montant de paiement, ainsi qu'une liste des biens et services vendus, indiquant leur quantité. Des pénalités sont imposées sur les factures impayées. La facture peut être payée en plusieurs fois, chaque paiement étant caractérisé par un numéro, une date et un montant. Le numéro de paiement est unique au sein de son compte. Les prix des biens et services peuvent changer avec le temps.

Riz. 11 – Exemple de maquette ER du bureau « Cornes et Sabots »

Un exemple de développement d'un modèle ER simple

Lors du développement de modèles ER, nous devons obtenir les informations suivantes sur le domaine :

1. Liste des entités de domaine.

2. Liste des attributs de l'entité.

3. Description des relations entre entités.

Les diagrammes ER sont pratiques car le processus d’identification des entités, des attributs et des relations est itératif. Après avoir développé la première version approximative des diagrammes, nous les affinons en interrogeant des experts en la matière. Dans le même temps, la documentation dans laquelle les résultats des conversations sont enregistrés sont les diagrammes ER eux-mêmes.

Supposons que nous soyons confrontés à la tâche de développer un système d'information pour une certaine société de commerce de gros. Tout d'abord, nous devons étudier le domaine et les processus qui s'y déroulent. Pour ce faire, nous interrogeons les salariés de l’entreprise, lisons la documentation, étudions les bons de commande, les factures, etc.

Par exemple, lors d'une conversation avec un directeur commercial, il s'est avéré que lui (le responsable) estime que le système en cours de conception doit effectuer les actions suivantes :

Stockez les informations client.

Imprimez les factures pour les marchandises libérées.

Surveiller la disponibilité des marchandises dans l'entrepôt.

Sélectionnons tous les noms dans ces phrases - ce seront des candidats potentiels pour des entités et des attributs, et analysons-les (nous soulignerons les termes peu clairs avec un point d'interrogation) :

L'acheteur est un candidat évident pour l'entité.

La facture est un candidat clair pour une entité.

Le produit est un candidat clair pour l'entité

(?) Entrepôt - en général, combien d'entrepôts l'entreprise possède-t-elle ? S'il y en a plusieurs, alors il sera candidat à une nouvelle entité.

(?) La présence d'un produit est très probablement un attribut, mais un attribut de quelle entité ?

Un lien évident apparaît immédiatement entre les entités : « les acheteurs peuvent acheter de nombreux biens » et « les biens peuvent être vendus à de nombreux acheteurs ». La première version du diagramme ressemble à ceci :

Riz. 12 – Première version du diagramme ER

Après avoir posé des questions supplémentaires au gérant, nous avons découvert que l'entreprise dispose de plusieurs entrepôts. De plus, chaque produit peut être stocké dans plusieurs entrepôts et être vendu depuis n'importe quel entrepôt.

Où dois-je placer les entités « Facture » ​​et « Entrepôt » et à quoi dois-je les lier ? Demandons-nous, comment ces entités sont-elles liées entre elles et avec les entités « Acheteur » et « Produit » ? Les acheteurs achètent des biens et reçoivent des factures contenant des données sur la quantité et le prix des biens achetés. Chaque acheteur peut recevoir plusieurs factures. Chaque facture doit être émise à un seul acheteur. Chaque facture doit contenir plusieurs marchandises (il n'y a pas de facture vide). Chaque produit, à son tour, peut être vendu à plusieurs acheteurs via plusieurs factures. De plus, chaque facture doit être émise depuis un entrepôt spécifique, et de nombreuses factures peuvent être émises depuis n'importe quel entrepôt. Ainsi, après clarification, le schéma ressemblera à ceci :

Riz. 12 – Deuxième version du diagramme ER

Nous devons maintenant réfléchir aux attributs des entités. Il en résulte ce qui suit :

Chaque acheteur est une personne morale et dispose d'un nom, d'une adresse et de coordonnées bancaires.

Chaque produit a un nom, un prix et est également caractérisé par des unités de mesure.

Chaque facture comporte un numéro unique, une date d'émission, une liste de marchandises avec quantités et prix, ainsi que le montant total de la facture. La facture est émise depuis un entrepôt spécifique et vers un acheteur spécifique.

Chaque entrepôt a son propre nom.

Écrivons à nouveau tous les noms qui seront des attributs potentiels et analysons-les :

Entité– le terme est rhétorique, nous ne travaillons pas avec des particuliers. Nous n'y prêtons pas attention.

Nom de l'acheteur – caractéristique explicite acheteur.

L'adresse est une caractéristique claire de l'acheteur.

Les coordonnées bancaires sont une caractéristique claire de l’acheteur.

Le nom du produit est une caractéristique claire du produit.

(?) Prix du produit - il semble que ce soit une caractéristique du produit. Cette caractéristique diffère-t-elle du prix figurant sur la facture ?

Une unité de mesure est une caractéristique claire d'un produit.

Le numéro de facture est une caractéristique claire et unique de la facture.

La date de facturation est une caractéristique claire de la facture.

(?) Liste des marchandises dans la facture - la liste ne peut pas être un attribut. Vous devrez probablement séparer cette liste en une entité distincte.

(?) La quantité de marchandises figurant sur la facture est une caractéristique évidente, mais une caractéristique de quoi ? Il s’agit d’une caractéristique non seulement d’un « produit », mais d’un « produit sur la facture ».

(?) Le prix du produit sur la facture - encore une fois, cela ne doit pas seulement être une caractéristique du produit, mais une caractéristique du produit sur la facture. Mais le prix du produit a déjà été vu ci-dessus – est-ce la même chose ?

Le montant de la facture est une caractéristique explicite de la facture. Cette caractéristique n'est pas indépendante. Le montant de la facture est égal à la somme des coûts de toutes les marchandises incluses dans la facture.

Le nom de l’entrepôt est une caractéristique claire de l’entrepôt.

Chaque produit a un certain prix actuel. Il s'agit du prix auquel le produit est actuellement vendu. Bien entendu, ce prix peut évoluer avec le temps. Le prix du même produit dans différentes factures émises en temps différent, peut être différent. Ainsi, il existe deux prix : le prix des marchandises figurant sur la facture et prix actuel marchandises.

Avec le concept émergent de « Liste des marchandises dans la facture », tout est assez clair. Les entités « Facture » et « Produit » sont liées entre elles par une relation plusieurs à plusieurs. Une telle relation doit être divisée en deux relations un-à-plusieurs. Cela nécessite une entité supplémentaire. Cette entité sera l’entité « Liste des marchandises dans la facture ». Son lien avec les entités « Facture » et « Produit » est caractérisé par les phrases suivantes - « chaque facture doit comporter plusieurs entrées de la liste des marchandises dans la facture », « chaque entrée de la liste des marchandises dans la facture doit être incluse dans exactement une seule facture", "chaque produit peut être inclus dans plusieurs entrées de la liste des marchandises de la facture", "chaque entrée de la liste des marchandises de la facture doit être associée à exactement un produit." Les attributs « Quantité de marchandises dans la facture » et « Prix des marchandises dans la facture » sont des attributs de l'entité « Liste des marchandises dans la facture ».

Nous ferons de même avec la connexion reliant les entités « Entrepôt » et « Produit ». Introduisons une entité supplémentaire "Article en entrepôt". L'attribut de cette entité sera « Quantité de marchandises en stock ». Ainsi, le produit sera répertorié dans n'importe quel entrepôt et sa quantité dans chaque entrepôt sera différente.

Maintenant, vous pouvez mettre tout cela dans un diagramme :

Riz. 13 – Troisième (dernière) version du diagramme ER

Bibliographie:

Systèmes d'information en économie : un manuel pour les étudiants. plus haut écoles, institutions / V.B. Outkine, K.V. Baldin. – M. : Centre d'édition « Académie », 2004. – 288 p.

Développement et exploitation de systèmes d'information automatisés : manuel. allocation / Éd. prof. L.G. Gagarine. – M. : Maison d'édition « FORUM » : INFRA-M, 2007. – 384 p. : ill. - (Formation professionnelle).

Date K. Introduction aux systèmes de bases de données. – M. : Dialectique, 2000.

Perchikov V.I., Savinkov V.M. Dictionnaire explicatif de l'informatique. – M. : Finances et Statistiques, 2001.

Riordan R. Fondamentaux des bases de données relationnelles. – M. : édition russe, 2001.

Saukap R. Conception de systèmes de bases de données relationnelles. – M. : édition russe, 2006.

Systèmes de bases de données et de gestion des connaissances / Ed. A.N. Naumova. – M. : Finances et Statistiques, 2005.

Sportak M., Pappas F. Les réseaux informatiques et technologies de réseau. – Kiev : TID DS LLC, 2002.

Outkine V.B. Bases de l'automatisation des activités professionnelles. – M. : RDL, 2001.

Utkin V.B., Sazanovich A.N., Mdicharadze V.G. L'informatique. – M. : RDL, 2007.

MegaPlus : électronique, ordinateurs, communications. 2010. - N ° 5.

1.5 Modélisation ER

La modélisation des données est la première étape vers la conception d'une base de données ; c'est une transition des objets du monde réel vers modèle informatique BD.

Le modèle ER sert à intégrer différentes vues de données à un niveau conceptuel. Sur la base du modèle ER, des diagrammes ER sont construits, qui affichent les trois composants principaux du modèle ER : entités, attributs, relations.

1.5.1 Entités

Puisqu’une entité est un objet du monde réel, les mots « entité » et « objet » signifient souvent la même chose.

Au niveau de la modélisation ER, une entité désigne en réalité un ensemble d'entités, et non une seule entité. En d'autres termes, une entité dans la modélisation ER correspond à une table, et non à une ligne dans un environnement relationnel ; une ligne distincte dans le modèle ER est appelée une instance d'entité (occurrence d'entité). Une entité est représentée par un rectangle dans lequel est inscrit le nom de l'entité.

1.5.2 Attributs

Les attributs décrivent les propriétés d'une entité. Par exemple, l'entité STUDENT comprend les attributs NSTBIL (numéro d'identification de l'étudiant), FIO (nom de l'étudiant), KURS (cours), etc.

Riz. 1.24. Attributs de l'entité STUDENT dans le modèle ER.

Les attributs ont des domaines. Un domaine est un ensemble de valeurs possibles pour un attribut. Par exemple, le domaine de la valeur numérique de la moyenne pondérée cumulative d'un élève peut être écrit sous forme d'intervalle.

Les clés primaires du modèle ER sont soulignées. S'il existe plusieurs clés primaires, toutes sont soulignées.

Les attributs peuvent être simples ou composés. Un attribut composite est un attribut qui peut être divisé en plusieurs attributs. Par exemple, l'attribut ADRESSE peut être divisé en RUE, VILLE, etc.

Les attributs peuvent être à valeur unique ou à valeurs multiples. Un attribut à valeur unique est un attribut qui ne peut prendre qu'une seule valeur. Par exemple, un numéro d’identification fiscale peut avoir une seule signification pour chaque personne. Les attributs uniques ne sont pas nécessairement simples. Par exemple, numéro de série 78-03-06-137846 est un attribut à valeur unique, mais en même temps c'est un attribut composé, car il peut être divisé en région dans laquelle le produit a été fabriqué (78), code de ville (03), équipe de production (06), numéro de produit (137846).

Un attribut à plusieurs valeurs est un attribut qui peut prendre plusieurs valeurs. Par exemple, une personne peut être diplômée de plusieurs universités et disposer de plusieurs numéros de téléphone.

Dans un SGBD relationnel, les attributs à valeurs multiples ne peuvent pas être utilisés. S'il existe des attributs à valeurs multiples, il est alors nécessaire de créer plusieurs nouveaux attributs au sein de cette entité ou de créer une nouvelle entité constituée des composants d'un attribut à valeurs multiples.

Un attribut dérivé est un attribut qui n'a pas besoin d'être stocké dans la base de données ; il est obtenu à l'aide d'un algorithme. Par exemple, l'âge d'un employé peut être obtenu comme la valeur entière de la différence entre date actuelle et date de naissance.

1.5.3. Connexions

La relation est une association. Les entités participant à une communication sont appelées participants. Un verbe ou un document peut être utilisé pour nommer les connexions. Par exemple, un département est géré par un employé, les marchandises sont reçues sur la base d'un contrat conclu, etc.

Les relations entre les entités dans une relation quantitative peuvent être « un-à-un », « un-à-plusieurs ». Le terme « connectivité » est utilisé pour désigner les types de connexions.

La cardinalité exprime un certain nombre d'instances d'entité associées à une instance de l'entité associée. Le diagramme ER n'indique pas la force de la communication, mais dans la programmation d'applications, les informations sur les nombres maximum et minimum d'instances d'entité peuvent être utiles. Par exemple, un groupe ne peut pas commencer les cours s’il compte moins de 10 élèves.

Des relations s'établissent entre les entités. Si une entité dépend de l’existence d’une ou plusieurs autres entités, alors elle dépend de l’existence. Par exemple, si les employés ont des personnes à charge, alors pour calculer les impôts, vous pouvez établir la relation « l'employé a des personnes à charge ». Dans ce cas, l’entité dépendante dépend de l’entité salariée.

Si une entité peut exister en dehors d’autres entités, alors elle est indépendante de l’existence. Par exemple, l'entité « pièce » peut exister indépendamment de l'entité « fournisseur ».

Si une entité est indépendante de l’existence d’une autre entité, la relation entre elles est appelée relation faible ou relation non identifiante. Des liens faibles se produisent si la clé primaire de l'entité associée ne contient pas les composants principaux de l'entité parent. Par exemple, il existe deux entités COURSE et CLASS, décrites comme

COURS ( CODE-CRS, DEPT_CODE,…)

CLASSE ( CODE DE LA CLASSE, CRS_CODE,…)

Entre ces entités il y a connexion faible, parce que l'attribut CLASS_CODE est la clé primaire de l'entité CLASS, tandis que l'attribut CRS_CODE de l'entité CLASS est une clé étrangère. La clé primaire de l'entité CLASS n'hérite pas du composant clé primaire de l'entité COURSE. Un couplage faible est représenté par une ligne pointillée sur un diagramme ER.

Une relation forte, également appelée relation d’identification, se produit lorsque les entités liées dépendent de l’existence. Une relation forte entre deux entités se produit lorsque la clé primaire de l'entité associée contient un composant de clé primaire de l'entité parent. Par exemple, les entités

COURS ( CODE-CRS, DEPT_CODE,…)

CLASSE ( CRS_CODE, SECTION CLASSE,…)

Ils ont un lien fort, parce que la clé composite de l'entité CLASS inclut la clé primaire de l'entité COURSE. Dans un diagramme ER, les relations fortes sont représentées par une ligne continue.

Il est important de garder à l’esprit que l’ordre dans lequel les tables sont créées et chargées est important. Pour les données par exemple, il est impossible que la clé étrangère de la table CLASS fasse référence à une table COURSE qui n'existe pas encore. Le problème après la séquence de création de table dans certains SGBD ne se pose qu'après le chargement des données. Pour éviter les violations d'intégrité au niveau des liens, une relation 1:M doit charger le côté « 1 », qu'il soit fort ou faible.

La participation d'une entité à une relation peut être requise ou non. La participation d'entité est facultative si une instance d'entité ne nécessite pas qu'une instance d'entité correspondante soit présente dans une relation distincte. Par exemple, dans le cadre d'un cours (COURS), des groupes sont créés (CLASS), au moins dans certains cours, des groupes peuvent ne pas être créés. Ceux. une instance d'entité (ligne) dans la table COURSE ne nécessite pas nécessairement une instance d'entité correspondante dans la table CLASS. Par conséquent, l’entité CLASS est traitée comme facultative par rapport à l’entité COURSE. Une relation facultative sur un diagramme ER est représentée par un petit cercle du côté de l'entité facultative. L'existence de l'optionnalité indique que l'entité optionnelle min a une valeur de puissance de communication de 0.

La participation d'une entité à une relation est obligatoire si une instance d'entité nécessite nécessairement une instance d'entité correspondante dans une relation distincte. S'il n'y a pas d'image à proximité de l'entité caractère supplémentaire, cela signifie que cette entité participe à connexion obligatoire avec une entité liée. La cardinalité minimale pour une entité requise est 1.

a) L'entité CLASS est facultative pour l'entité COURSE

b) Les entités COURE et CLASS en relation obligatoire.

Figure 1.25. Représentation des connexions obligatoires et facultatives dans le modèle ER.

En termes de conception de base de données, l'existence d'une relation forte entre une entité mère et sa ou ses entités associées est associée à des entités faibles.

Une entité faible est une entité qui remplit deux conditions :

condition de dépendance à l'égard de l'existence, c'est-à-dire il ne peut exister sans l’entité à laquelle il est connecté ;

sa clé primaire est dérivée en partie ou en totalité de l'entité parent de la relation.

Dans le modèle ER, les entités faibles sont représentées sous forme de petits segments à chacun des quatre coins du rectangle de l’entité.

Riz. 1.26. Entité faible dans les diagrammes ER.

Une entité faible hérite de toutes les parties de la clé primaire de son partenaire de relation forte. C'est le concepteur de la base de données qui décide si une entité doit ou non être déclarée faible.

Le degré de relation indique le nombre d'entités associées. Une relation unaire existe lorsqu'une association est maintenue au sein d'une seule entité. Une relation binaire existe lorsque deux entités sont associées. Une relation ternaire se produit lorsque trois entités sont connectées. Même s'il y en a plus diplômes élevés connexions, elles sont assez rares et n’ont pas de noms particuliers.

Si une entité a des connexions avec elle-même, alors une telle connexion est dite récursive.

Riz. 1.27. Représentation ER de la connexion récursive

La hiérarchie de généralisation affiche les relations ascendants-descendants. Dans le contexte des bases de données relationnelles, une hiérarchie de vues génériques affiche les relations entre les supertypes d'une entité de niveau supérieur et les sous-types d'une entité de niveau inférieur. Ceux. le supertype contient des attributs partagés, tandis que le sous-type contient des attributs uniques.

Riz. 1.28. Hiérarchie des représentations généralisées.

Les relations sont héritées, c'est-à-dire Un sous-type d'entité hérite des attributs et des relations du supertype d'entité. Par exemple, tous les pilotes, mécaniciens et comptables ont un matricule, un nom complet, adresse du domicile etc., mais ils peuvent avoir des attributs propres à leur spécialisation. En d’autres termes, un supertype d’ensemble d’entités est généralement associé à plusieurs sous-types d’ensemble d’entités uniques et ne se chevauchant pas. Ces obligations qui ne se chevauchent pas sont désignées par la lettre « G ».

Le surtype et le(s) sous-type(s) entretiennent une relation 1:1. Par exemple, la structure de table EMPLOYEE pourrait être remplacée par deux tables, l'une représentant le supertype EMPLOYEE et l'autre représentant le sous-type PILOT.

Certains supertypes contiennent des sous-types qui se chevauchent. Par exemple, un employé peut être enseignant, mais en même temps administrateur.

Les liens croisés sont représentés par les symboles « G ».

Riz. 1.29. Hiérarchie de représentations généralisées avec sous-types qui se croisent.

Le modèle conceptuel de base de données est

Un modèle conceptuel est une sorte de diagramme visuel, dessiné selon une notation acceptée et montrant en détail la relation entre les objets et leurs caractéristiques. Un modèle conceptuel est créé pour une conception ultérieure de la base de données et sa traduction, par exemple, en base relationnelle données. Le modèle conceptuel représente les connexions entre les objets de données et leurs caractéristiques sous une forme visuellement pratique.

Définitions acceptées dans la base de données conceptuelle

Pour assurer l'uniformité de la programmation des bases de données, les concepts suivants ont été introduits pour les bases de données conceptuelles :

1. Objet ou entité. Il s'agit de la chose ou de l'objet réel (pour les personnes) que l'utilisateur (client) souhaite observer. Par exemple, Ivanov Ivan Ivanovitch ;
2. Attribut c'est une caractéristique d'un objet correspondant à son essence. Par exemple. Nous nous posons la question : quelles informations doivent être stockées sur Ivan Ivanovitch Ivanov ? Les réponses à cette question seront les attributs de l'objet Ivan Ivanovitch Ivanov ;
3. Le troisième concept de la conception conceptuelle de bases de données est connexion ou relation entre les objets.

Lexicalement, il est plus correct de dire la relation entre les objets CBD et la relation entre les entités CBD (base de données conceptuelle), mais vous pouvez trouver le plus diverses combinaisons essence, objet, connexion et relation (erreurs de traduction).

Modèle de base de données conceptuel symboles

Modèle conceptuel de base de données : notations graphiques communes

Un diagramme entité/relation (objet/relation) est appelé diagramme ER ou EDR (diagramme entité-relation). Le modèle entité-relation lui-même a été proposé par le professeur Peter Pin-Shen Chen en 1976. Les règles et conventions d'écriture d'un diagramme ER sont appelées notation. Il existe deux notations courantes pour les diagrammes ER :

• Notation de Peter Chen ;
• Notation Gordon Everest. Appelé patte d'oie ou fourchette.

Notation du diagramme ER selon Peter Chen

Chen a proposé et adopté les conventions suivantes pour les diagrammes ER :

• Une entité ou un objet est désigné par un rectangle ;
• Les relations sont représentées par un diamant ;
• Les attributs des objets sont indiqués par un ovale ;
• Si une entité est associée à une relation, alors leur relation est indiquée par une ligne droite avec une flèche. Une relation facultative est indiquée par une ligne pointillée. Une connexion puissante est indiquée par une double ligne.

Chaque attribut peut être associé à un objet (entité).

Notation Gordon Everest

Gordon Everest a introduit une nouvelle désignation pour les connexions, appelées fourches ou pattes d'oie. Il a également introduit qu'un objet doit être représenté par un rectangle avec le nom du type d'objet comme nom à l'intérieur du rectangle. De plus, ce nom doit être unique au sein de la base de données en cours de création.

Les attributs ne sont pas séparés en une figure distincte, mais s'inscrivent dans le rectangle de l'objet comme un nom avec un mot qualificatif.

La connexion entre les objets est indiquée par une ligne droite. Les liaisons multiples sont indiquées par une fourchette à la fin. La connexion elle-même est signée avec un verbe, tel que « Inclut » ou « Appartient ».

modèle conceptuel de la base de données ERD Fork

Modules complémentaires

Les attributs d'un diagramme ER peuvent avoir leur propre attribut (composite).

Un simple diagramme ER est assez facile à dessiner. Un diagramme ER riche et tridimensionnel est une autre affaire. Vous trouverez ci-dessous quelques conseils pour vous aider à créer des diagrammes ER efficaces :

• Identifier tous les objets d'un système donné et définir les relations entre ces objets ;
• Un objet ne doit apparaître qu'une seule fois à un emplacement spécifique du diagramme ;
• Définissez un nom précis et approprié pour chaque objet, attribut et relation dans le diagramme. Choisissez simple et mots compréhensibles. Les termes simples et familiers l’emportent toujours sur les mots vagues et techniques. Pour les objets, les noms, pour les connexions, les verbes (avec explications possibles). N'oubliez pas le caractère unique des noms d'objets ;
• Supprimez les relations implicites, redondantes ou inutiles entre les objets ;
• Ne reliez jamais une relation à une autre relation ;
• Utilisez des couleurs pour classer des objets similaires ou mettre en évidence des zones clés dans un diagramme.