urgence-diagrammes

Une manière courante de représenter un modèle de base de données logique consiste à créer des diagrammes ER (Entité-Relation). Dans ce modèle, une entité est définie comme un objet discret pour lequel des éléments de données sont stockés, et une relation décrit la relation entre deux objets.

Dans l’exemple d’un responsable d’agence de voyages, il y a 5 objets principaux :

Touristes

Pièces justificatives

Les relations entre ces objets peuvent être définies en termes simples :

Chaque touriste peut acheter un ou plusieurs (plusieurs) bons.

Chaque bon correspond à son paiement (il peut y avoir plusieurs versements si le bon est par exemple vendu à crédit).

Chaque tournée peut avoir plusieurs saisons.

Le billet est vendu pour une saison d'une tournée.

Ces objets et relations peuvent être représentés par un diagramme ER, comme le montre la figure 2.

Riz. 2. Diagramme ER pour l'application de base de données des gestionnaires d'agences de voyages

Objets, attributs et clés

Le modèle est développé davantage en définissant des attributs pour chaque objet. Les attributs d'objet sont des éléments de données liés à un objet spécifique qui doivent être préservés. Nous analysons le dictionnaire de données compilé, sélectionnons les objets et leurs attributs et développons le dictionnaire si nécessaire. Les attributs de chaque objet de l'exemple sont présentés dans le tableau 2.

Tableau 2. Objets et attributs de base de données

Un objet	Touristes	Pièces justificatives	Visites	Saisons	Paiements
			Nom	date de début	date de règlement
				Date de fin
	Nom de famille		Information
Les attributs
Les attributs

A noter qu'il manque plusieurs éléments. Les informations d'enregistrement mentionnées dans la spécification fonctionnelle ont été omises. Comment en tenir compte, vous réfléchirez par vous-même et finaliserez l'exemple proposé. Mais plus important encore, les attributs nécessaires pour connecter les objets entre eux font toujours défaut. Ces éléments de données ne sont pas représentés dans le modèle ER, car ils ne sont pas en fait des attributs « naturels » des objets. Elles sont traitées différemment et seront prises en compte dans le modèle de données relationnel.

Le modèle relationnel se caractérise par l'utilisation de clés et de relations. Il existe une différence dans le contexte d'une base de données relationnelle entre les termes relation et relation. Une relation est traitée comme un tableau bidimensionnel non ordonné avec des lignes non liées. Le schéma de données est formé entre des relations (tables) via des attributs communs, qui sont des clés.

Il existe plusieurs types de clés, et elles diffèrent parfois uniquement par leur relation avec d'autres attributs et relations. Une clé primaire identifie de manière unique une ligne dans une relation (table) et chaque relation ne peut avoir qu'une seule clé primaire, même si plusieurs attributs sont uniques. Dans certains cas, plusieurs attributs sont requis pour identifier les lignes d'une relation. L'ensemble de ces attributs est appelé clé composite. Dans d'autres cas, la clé primaire doit être spécialement créée (générée). Par exemple, dans la relation « Touristes », il est judicieux d'ajouter un identifiant touristique unique (code touristique) comme clé primaire de cette relation pour organiser les connexions avec d'autres relations de base de données.

Un autre type de clé, appelé clé étrangère, existe uniquement en termes de schéma de données entre deux relations. Une clé étrangère dans une relation est un attribut qui est la clé primaire (ou une partie de clé primaire) dans une autre relation. Il s'agit d'un attribut distribué qui forme un schéma de données entre deux relations dans la base de données.

Pour la base de données conçue, nous développerons les attributs des objets avec des champs de code comme clés primaires et utiliserons ces codes dans les relations de base de données pour faire référence aux objets de base de données comme suit (Tableau 3).

Il est trop tôt pour considérer le schéma de base de données construit comme complet, car sa normalisation est nécessaire. Un processus appelé normalisation de base de données relationnelle est utilisé pour regrouper les attributs de manière spéciale afin de minimiser la redondance et la dépendance fonctionnelle.

Tableau 3. Objets et attributs de base de données avec champs de code étendus

Un objet	Touristes	Pièces justificatives	Visites	Saisons	Paiements
Les attributs	Code touristique	Code de voyage		Code de saison	Code de paiement
		Code touristique	Nom	date de début	date de règlement
		Code de saison		Date de fin
	Nom de famille		Information		Code de voyage

Normalisation

Les dépendances fonctionnelles se produisent lorsque la valeur d'un attribut peut être déterminée à partir de la valeur d'un autre attribut. Un attribut déterminable est dit fonctionnellement dépendant d’un attribut déterminant. Par conséquent, par définition, tous les attributs non clés (sans clé) dépendront fonctionnellement de la clé primaire dans chaque relation (puisque la clé primaire identifie de manière unique chaque ligne). Lorsqu'un attribut d'une relation ne définit pas de manière unique un autre attribut, mais le restreint à un ensemble de valeurs prédéfinies, on parle de dépendance à plusieurs valeurs. Une dépendance partielle se produit lorsqu'un attribut de relation dépend fonctionnellement d'un attribut de la clé composite. Les dépendances transitives sont observées lorsqu'un attribut non clé dépend fonctionnellement d'un ou plusieurs autres attributs non clés dans une relation.

Le processus de normalisation consiste en la construction étape par étape d'une base de données sous forme normale (NF).

1. La première forme normale (1NF) est très simple. Toutes les tables de base de données doivent satisfaire une seule exigence : chaque cellule des tables doit contenir une valeur atomique, en d'autres termes, une valeur stockée dans Domaine L'application de base de données ne doit pas avoir de structure interne dont les éléments peuvent être requis par l'application.

2. La deuxième forme normale (2NF) est créée lorsque toutes les dépendances partielles sont supprimées des relations de la base de données. S'il n'y a pas de clés composites dans la relation, ce niveau de normalisation est alors facilement atteint.

3. La troisième forme normale (3NF) de la base de données nécessite la suppression de toutes les dépendances transitives.

4. La quatrième forme normale (4NF) est créée lorsque toutes les dépendances à valeurs multiples sont supprimées.

La base de données de notre exemple est en 1NF, puisque tous les champs des tables de la base de données ont un contenu atomique. Notre base de données est également en 2NF, puisque nous avons introduit artificiellement dans chaque table des codes uniques pour chaque objet (Code Touristique, Code de Voyage, etc.), grâce à quoi nous avons obtenu 2NF pour chacune des tables de la base de données et l'ensemble de la base de données en général. Reste à traiter les troisième et quatrième formes normales.

Notez qu'ils n'existent que par rapport à différents types de dépendances d'attributs de base de données. Il y a des dépendances - vous devez évaluer la base de données NF, il n'y a pas de dépendances - la base de données est déjà en NF. Mais cette dernière option n'est pratiquement jamais trouvée dans les applications réelles.

Alors, quelles dépendances transitives et multivaluées sont présentes dans notre exemple de base de données de gestionnaire d'agence de voyages ?

Analysons l'attitude des "Touristes". Considérons les dépendances entre les attributs « Code touristique », « Nom », « Prénom », « Patronyme » et « Passeport » (Fig. 3). Chaque touriste, représenté en relation par la combinaison « Nom et prénom", n'a qu'un seul passeport pour la durée du voyage, tandis que les homonymes complets doivent avoir des numéros de passeport différents. Ainsi, les attributs « Nom - Prénom - Patronyme » et « Passeport » forment une clé composite pour les touristes.

Riz. 3. Exemple de dépendance transitive

Comme le montre la figure, l'attribut « Passeport » dépend transitivement de la clé « Code Touristique ». Par conséquent, afin d'éliminer cette dépendance transitive, nous divisons la clé composite de la relation et la relation elle-même en 2 selon des relations biunivoques. La première relation, laissons-la avec le nom « Touristes », comprend les attributs « Code touristique » et « Nom », « Prénom », « Patronyme ». La deuxième relation, appelons-la « Informations sur les touristes », est formée des attributs « Code du tourisme » et de tous les autres attributs de la relation « Touristes » : « Passeport », « Téléphone », « Ville », « Pays », "Indice". Ces deux nouvelles relations n'ont plus de dépendance transitive et sont en 3NF.

Il n'y a pas de dépendances à valeurs multiples dans notre base de données simplifiée. Par exemple, supposons que pour chaque touriste, plusieurs numéros de contact doivent être stockés (domicile, travail, téléphone portable, etc., ce qui est très courant en pratique), et non un seul, comme dans l'exemple. Nous obtenons une dépendance multivaluée de la clé - "Code touristique" et les attributs "Type de téléphone" et "Téléphone" ; dans cette situation, la clé cesse d'être une clé. Ce qu'il faut faire? Le problème est également résolu en divisant le schéma de relation en 2 nouveaux schémas. L'un d'eux doit représenter des informations sur les téléphones (la relation « Téléphones ») et le second sur les touristes (la relation « Touristes »), qui sont contactés via le champ « Code du Tourisme ». Le « Code touristique » par rapport aux « Touristes » sera la clé primaire, et par rapport aux « Téléphones », ce sera une clé externe.

Modèle logique– une représentation graphique de la structure de la base de données, tenant compte du modèle de données adopté (hiérarchique, réseau, relationnel, etc.), indépendante de l'implémentation finale de la base de données et de la plateforme matérielle. En d'autres termes, il montre CE QUI est stocké dans la base de données (les objets du domaine, leurs attributs et les relations entre eux), mais ne répond pas à la question COMMENT (Fig. 1).

Description du domaine :

De grosusineAieaction

Les pièces fabriquées à partir de certains matériaux (moulées) sont fournies à l'entrepôt auprès d'un éventail donné de fournisseurs (permanents ou aléatoires) de différentes villes.

Les fournisseurs peuvent être des personnes morales et des entrepreneurs individuels, et ces groupes sont décrits par leur propre ensemble d'attributs caractéristiques ; personnes morales - numéro et date d'enregistrement public. enregistrement, nom, adresse légale, forme de propriété ; entrepreneurs - NIF, nom complet, police d'assurance, numéro de passeport, date de naissance.

Lors d'une livraison, la date, la quantité et le coût, le type d'emballage et le mode de livraison (transport routier, transport ferroviaire, enlèvement) sont pris en compte, et une livraison peut comprendre plusieurs types de pièces.

Les fournisseurs deviennent permanents s'ils effectuent des livraisons d'une valeur supérieure à 1 000 000 de roubles par an.

Les pièces sont livrées aux ateliers de l'usine en tenant compte de la date, de la quantité et du numéro d'atelier. La quantité actuelle de marchandises en stock est maintenue.

Riz. 1. Modèle de base de données logique en notation IDEF1X

Méthodologie IDEF1X– une des approches de modélisation des données basée sur la notion « entité-relation » ( Relation d'entité), proposé par Peter Chen en 1976.

Tableau 2.1. Éléments de base de la notation IDEF1X
Essence(Entité)	Image graphique
Entité indépendante	Nom Identifiant unique Les attributs
Entité dépendante	Les attributs
Connexion(Relation)	Image graphique
Relation non identifiante
Lien d'identification
Relation plusieurs-à-plusieurs
Héritage (généralisation) Incomplet	Parental

Indépendantessence est une entité dont l'identifiant unique n'est pas hérité d'autres entités. Représenté comme un rectangle aux bords droits.

Entité dépendante est une entité dont l'identifiant unique inclut au moins une relation avec une autre entité. Par exemple, une ligne de document ne peut exister sans (en fonction) du document lui-même. Représenté comme un rectangle aux bords arrondis.

La méthodologie IDEF1X se concentre sur la conception de modèles de bases de données relationnelles. Le modèle relationnel est basé sur la notion de relation normalisée (tableau). Dans ce cas, les entités du domaine sont mappées dans des tables de base de données (Fig. 2), qui ont les propriétés suivantes :

Riz.
2. Table de base de données relationnelle

Clé- une colonne ou un groupe de colonnes dont les valeurs identifient de manière unique chaque ligne.

Une table peut avoir plusieurs clés : une primaire, par lesquelles les relations s'enchaînent, tandis que d'autres sont alternatives. Propriétés clés :

unicité (il ne peut pas y avoir de lignes avec la même clé) ;

non-redondance (supprimer tout attribut d'une clé la prive de sa propriété d'unicité).

Base de données relationnelle− il s'agit d'un ensemble de relations interconnectées. Les relations sont spécifiées à l'aide de clés secondaires (clé étrangère – FK), c'est-à-dire des attributs qui sont par ailleurs des clés primaires (PK).

Les principales limitations d'intégrité du modèle relationnel sont :

les attributs de la clé primaire ne peuvent pas prendre une valeur indéfinie (intégrité de l'objet) ;

les clés secondaires ne peuvent pas prendre des valeurs qui ne font pas partie des valeurs des clés primaires de la table associée : si la relation R2 a parmi ses attributs une clé étrangère (FK) qui correspond à la clé primaire (PK) de la relation R1, alors chaque valeur FK doit être égale à une des valeurs PK.

Création d'un modèle de base de données logique dans Visio

Pour créer un modèle de base de données logique dans Visio2013, sélectionnez la catégorie de modèle « Programmes et bases de données » et dans celle-ci le modèle « Diagramme de modèle de base de données » (Fig. 2.3).

Riz. 2.3. Modèle de schéma de modèle de base de données

Avant de commencer à créer un modèle logique, allez dans l'onglet « Base de données » et dans « Afficher les paramètres », définissez les paramètres suivants (Fig. 2.4-2.6).

Riz. 2.4.Paramètres du document (onglet Général)

Riz. 2.6.Paramètres du document (onglet Relation)

Riz. 2.5.Paramètres du document (onglet Tableau)

Pour créer une entité « Part », faites glisser le stéréotype d'entité de la barre d'outils vers l'écran (Figure 2.7).

Riz. 2.7.Création de l'Entité

Définissez le nom de l'entité dans les propriétés en bas de l'écran (Fig. 2.8).

Riz. 2.8.Propriétés de l'Entité (« Définition »)

Ensuite, dans l'onglet Colonnes, créez les attributs d'entité, vérifiez l'identifiant unique (clé primaire) dans la colonne PK et cliquez sur OK (Figure 2.9).

Riz. 2.9. Propriétés de l'entité (« Colonnes »)

De même, créez une deuxième entité, par exemple « Matériel ». Pour créer une connexion entre eux, faites glisser le stéréotype « Relation » avec un point sur l'image de la classe « Partie », car Zéro, une ou plusieurs pièces sont fabriquées à partir de chaque matériau. Faites ensuite glisser la deuxième extrémité de la connexion sur l'image de la classe « Matériau » (Fig. 2.10). La clé étrangère « Code matériau (FK) » apparaîtra automatiquement dans le cadre des attributs de l'entité « Pièce ».

Un losange ouvert du côté Matériau signifie que le matériau ne peut pas être spécifié. Pour supprimer le losange, ouvrez les propriétés de l'entité « Pièce » et cochez cet attribut dans la colonne « Obligatoire ».

Riz. 2.10. Propriétés de la relation (« Définition »)

Exercice : construire un modèle de base de données logique conformément à la description du domaine de votre option de mission.

Pour représenter les connaissances mathématiques en logique mathématique, des formalismes logiques sont utilisés - calcul propositionnel et calcul des prédicats. Ces formalismes ont une sémantique formelle claire et des mécanismes d'inférence ont été développés pour eux. Par conséquent, le calcul des prédicats a été le premier langage logique utilisé pour décrire formellement les domaines liés à la résolution de problèmes appliqués.

Modèles logiques les représentations de connaissances sont implémentées à l'aide d'une logique de prédicat.

Prédicat est une fonction qui prend deux valeurs (vrai ou faux) et est conçue pour exprimer les propriétés des objets ou les relations entre eux. Une expression qui affirme ou nie la présence de propriétés dans un objet est appelée déclaration. Constantes servir à nommer les objets du domaine. Formulaire de phrases ou d'énoncés logiques formules atomiques. Interprétation des prédicats est l'ensemble de toutes les liaisons valides de variables à des constantes. La liaison est la substitution de constantes au lieu de variables. Un prédicat est considéré comme généralement valide s'il est vrai dans toutes les interprétations possibles. On dit qu’une affirmation découle logiquement de prémisses données si elle est vraie chaque fois que les prémisses sont vraies.

Les descriptions de domaines rédigées dans des langages logiques sont appelées modèles logiques .

DONNER (MIKHAIL, VLADIMIR, LIVRE);

($x) (ÉLÉMENT (x, ÉVÉNEMENT-GIVE) ? SOURCE (x, MICHAEL) ? DESTINATION ? (x, VLADIMIR) OBJET (x, LIVRE).

Ici, deux manières d'enregistrer un fait sont décrites : « Mikhaïl a donné le livre à Vladimir ».

L'inférence logique s'effectue à l'aide d'un syllogisme (si B découle de A et C découle de B, alors C découle de A).

En général, les modèles logiques sont basés sur le concept théorie formelle, donné par les quatre :

S= ,

où B est un ensemble dénombrable caractères de base (alphabet) théorie S;

F - sous-ensemble expressions de la théorie S, appelé formules théoriques(les expressions sont comprises comme des séquences finies de symboles de base de la théorie S) ;

A est un ensemble sélectionné de formules appelées axiomes de la théorie S, c'est-à-dire un ensemble de formules a priori ;

R - un ensemble fini de relations (r 1, ..., r n) entre formules, appelées règles d'inférence.

L'avantage des modèles logiques de représentation des connaissances est la possibilité de programmer directement le mécanisme de sortie d'instructions syntaxiquement correctes. Un exemple d’un tel mécanisme est notamment la procédure d’inférence construite sur la base de la méthode de résolution.

Montrons la méthode de résolution.

La méthode utilise plusieurs concepts et théorèmes.

Concept tautologies, une formule logique dont la valeur sera « vraie » pour toutes les valeurs des atomes qu'elles contiennent. Désigné par ?, lu comme « généralement valable » ou « toujours vrai ».

Théorème 1. A?B si et seulement si?A B.

Théorème 2. A1, A2, ..., An ? Dans si et seulement si quand ? (A1?A2?A3?…?An) V.

Symbole? lire comme « il est vrai que » ou « peut être déduit ».

La méthode est basée sur la preuve d'une tautologie

? (X? UN)?(Oui? ? UN)?(X? Oui) .

Les théorèmes 1 et 2 permettent d'écrire cette règle sous la forme suivante :

(X? UN), (Oui? ? UN) ? (X? Oui),

ce qui donne matière à affirmer : il est possible de déduire des prémisses.

Dans le processus d'inférence utilisant la règle de résolution, les étapes suivantes sont effectuées.

1. Les opérations d'équivalence et d'implication sont éliminées :

2. L'opération de négation se déplace à l'intérieur des formules en utilisant les lois de De Morgan :

3. Les formules logiques sont réduites à la forme disjonctive : .

La règle de résolution contient une conjonction de disjonctions sur le côté gauche, par conséquent, amener les prémisses utilisées pour la preuve sous une forme qui représente une conjonction de disjonctions est une étape nécessaire dans presque tous les algorithmes qui implémentent l'inférence logique basée sur la méthode de résolution. La méthode de résolution est facile à programmer, c'est l'un de ses avantages les plus importants.

Supposons que nous devions prouver que si les relations et sont vraies, alors nous pouvons dériver la formule. Pour ce faire, vous devez suivre les étapes suivantes.

1. Amener les prémisses à une forme disjonctive :
, , .

2.Construction de la négation de la conclusion déduite. La conjonction résultante est valide lorsque et sont toutes deux vraies.

3.Application de la règle de résolution :

(contradiction ou « vide disjoint »).

Ainsi, en supposant la fausseté de la conclusion déduite, nous obtenons une contradiction, donc la conclusion déduite est vraie, c'est-à-dire , est déductible des prémisses initiales.

C'est la règle de résolution qui a servi de base à la création du langage de programmation logique PROLOG. En fait, l’interpréteur de langage PROLOG implémente indépendamment une sortie similaire à celle décrite ci-dessus, générant une réponse à la question de l’utilisateur adressée à la base de connaissances.

En logique des prédicats, pour appliquer la règle de résolution, il est nécessaire de procéder à une unification plus complexe des formules logiques afin de les réduire à un système de disjonctions. Cela est dû à la présence éléments supplémentaires syntaxe, principalement les quantificateurs, les variables, les prédicats et les fonctions.

L'algorithme d'unification des formules logiques de prédicats comprend les étapes suivantes.

Après avoir terminé toutes les étapes de l'algorithme d'unification décrit, vous pouvez appliquer la règle de résolution. Généralement, cela implique d'annuler la conclusion tirée, et l'algorithme de dérivation peut être brièvement décrit comme suit : Si plusieurs axiomes sont donnés (théorie TH) et un il faut conclure si une certaine formule est dérivable R.à partir des axiomes de la théorie Th, la négation se construit R. et s’ajoute à Th, ce qui donne une nouvelle théorie Th1. Après avoir réduit les axiomes de la théorie à un système de disjointes, on peut construire une conjonction et des axiomes de la théorie Th. En même temps, il est possible de déduire des disjonctions – des conséquences – à partir des disjonctions initiales. Si R. est déductible des axiomes de la théorie Th, alors dans le processus de dérivation on peut obtenir une certaine clause Q, composée d'une lettre, et la clause opposée . Cette contradiction indique que R. déductible des axiomes Th. D'une manière générale, il existe de nombreuses stratégies de preuve ; nous n'en avons considéré qu'une seule parmi les possibles : la stratégie descendante.

Exemple : imaginons le texte suivant en utilisant la logique des prédicats :

"Si un étudiant sait bien programmer, il peut alors devenir un spécialiste dans le domaine de l'informatique appliquée."

"Si un étudiant réussit bien à l'examen des systèmes d'information, alors il sait bien programmer."

Représentons ce texte en utilisant la logique des prédicats du premier ordre. Introduisons la notation suivante : X- variable pour désigner l'étudiant ; Bien- constante correspondant au niveau de qualification ; R(X)- un prédicat exprimant la possibilité du sujet X devenir spécialiste en informatique appliquée; Q(X, d'accord)- un prédicat désignant la compétence du sujet X programme avec évaluation Bien; R.(X, d'accord)- prédicat précisant la connexion de l'élève X avec note d'examen dans les systèmes d'information.

Construisons maintenant un ensemble de formules correctement construites :

Q(X, bien).

R.(X, bien)Q(X, bien).

Complétons la théorie résultante par un fait spécifique
R.(Ivanov, bien).

Effectuons une inférence en utilisant la règle de résolution pour déterminer si la formule est R(Ivanov) une conséquence de la théorie ci-dessus. En d'autres termes, peut-on déduire de cette théorie que l'étudiant Ivanov deviendra un spécialiste en informatique appliquée s'il réussit bien l'examen des systèmes d'information ?

Preuve

1. Transformons les formules originales de la théorie afin de les amener à une forme disjonctive :

(X, bon) P(X);

(X, bien) (X, bien);

R.(Ivanov, Bien).

2. Ajouter aux axiomes existants la négation de la conclusion tirée

(Ivanov).

3. Construisons une conjonction de disjointes

(X, bien) R(X)? ? P.(Ivanov, bien)? ? Q(Ivanov, bien), remplacer une variable Xà une constante Ivanov.

Le résultat de l’application de la règle de résolution est appelé résolvant. Dans ce cas, la résolvante est (Ivanov).

4. Construisez une conjonction de clauses en utilisant la résolvante obtenue à l'étape 3 :

(X, bien) (X, bien) (Ivanov, bien) (Ivanov, bien).

5. Écrivons la conjonction de la résolvante résultante avec la dernière disjointe de la théorie :

(Ivanov, bien) (Ivanov, bien)(contradiction).

Par conséquent, le fait R(Ivanov) déduit des axiomes de cette théorie.

Pour déterminer l'ordre d'application des axiomes dans le processus d'inférence, les règles heuristiques suivantes existent :

Lors de la première étape de l’inférence, la négation de la conclusion déduite est utilisée.
Chaque étape ultérieure de dérivation implique le résolvant obtenu à l'étape précédente.

Cependant, en utilisant les règles qui définissent la syntaxe d’un langage, il est impossible d’établir la vérité ou la fausseté d’une affirmation particulière. Cela s'applique à toutes les langues. Une instruction peut être construite syntaxiquement correctement, mais s’avérer totalement dénuée de sens. Un degré élevé d'uniformité entraîne également un autre inconvénient modèles logiques- la difficulté d'utiliser des heuristiques qui reflètent les spécificités d'un sujet particulier lors de la preuve. D'autres inconvénients des systèmes formels incluent leur monotonie, le manque de moyens pour structurer les éléments utilisés et l'inadmissibilité des contradictions. Le développement ultérieur des bases de connaissances a suivi le chemin des travaux dans le domaine de la logique inductive, des logiques du « bon sens », des logiques de foi et d'autres schémas logiques qui ont peu de points communs avec la logique mathématique classique.

La qualité de la base de données développée dépend entièrement de la qualité des différentes étapes de sa conception. Le développement de haute qualité d'un modèle de données logique est d'une grande importance, car, d'une part, il garantit l'adéquation de la base de données thématique et, d'autre part, il détermine la structure de la base de données physique et, par conséquent, ses caractéristiques opérationnelles.

Les mêmes données peuvent être regroupées dans des tables de relations différentes façons, c'est à dire. il est possible d'organiser divers ensembles de relations entre des objets d'information interconnectés du domaine. Le regroupement des attributs dans des relations doit être rationnel, minimisant la duplication des données et simplifiant les procédures de traitement et de mise à jour.

Un ensemble particulier de relations possède de meilleures propriétés d’inclusion, de modification et de suppression de données s’il répond à des exigences spécifiques de normalisation des relations.

Normalisation des relations– un dispositif formel de restrictions sur leur constitution, qui permet d'éliminer la duplication des données, d'assurer leur cohérence et de réduire le coût de maintenance de la base de données.

En pratique, les notions de première, deuxième et troisième formes normales sont le plus souvent utilisées.

La relation s'appelle normalisé ou réduit à la première forme normale(1NF), si tous ses attributs sont simples ou atomiques (ci-après dénommés indivisibles). Une relation sous forme normale première aura les propriétés suivantes :

■ il n'y a pas de tuples identiques dans la relation ;

■ les tuples ne sont pas ordonnés ;

■ les attributs ne sont pas ordonnés et diffèrent par leur nom ;

■ toutes les valeurs d'attribut sont atomiques.

Comme le montrent les propriétés répertoriées, toute relation est automatiquement sous sa première forme normale.

Il est facile de montrer que la première forme normale permet le stockage dans une seule relation d'informations hétérogènes, la redondance des données, conduisant à l'insuffisance du modèle logique de données du domaine. Ainsi, la première forme normale n’est pas suffisante pour une modélisation correcte des données.

Pour considérer la question de la réduction des relations à une seconde forme normale, il est nécessaire d’expliquer la notion de dépendance fonctionnelle.

Qu'il y ait une relation R. L'ensemble d'attributs Y dépend fonctionnellement de l'ensemble d'attributs X, si pour n'importe quel état de relation R. pour tous les tuples de ce qui suit, c'est-à-dire dans tous les tuples ayant mêmes valeurs les attributs X, les valeurs des attributs Y coïncident également dans n'importe quel état de la relation R.

De nombreux attributs X appelé déterminant de la dépendance fonctionnelle, et l'ensemble des attributs U – partie dépendante.

En pratique, ces dépendances reflètent les relations trouvées entre les objets du domaine et sont des contraintes supplémentaires définies par le domaine. Ainsi, la dépendance fonctionnelle est un concept sémantique. Cela se produit lorsque les valeurs de certaines données dans le domaine peuvent être utilisées pour déterminer les valeurs d'autres données. Par exemple, connaissant le matricule d’un employé, vous pouvez déterminer son nom de famille. Une dépendance fonctionnelle impose des restrictions supplémentaires sur les données pouvant être stockées dans une relation. Pour l'exactitude de la base de données, il est nécessaire de vérifier toutes les restrictions définies par les dépendances fonctionnelles lors des opérations de modification de la base de données.

La dépendance fonctionnelle des attributs de relation rappelle le concept de dépendance en mathématiques. La dépendance fonctionnelle en mathématiques est un triplet d'objets X, Oui Et F, où X est un ensemble représentant le domaine de définition de la fonction, Oui– un ensemble de valeurs, et F– une règle selon laquelle chaque élément est associé à un et un seul élément. A l’inverse, dans les relations, la valeur d’un attribut dépendant peut prendre différentes valeurs imprévisibles dans différents états de la base de données, correspondant à différents états de la base de données. Domaine. Par exemple, un employé changeant de nom de famille après avoir contracté un mariage légal conduira au fait que, avec la même valeur du déterminant, par exemple un matricule, la valeur de l'argument dépendant sera différente.

La dépendance fonctionnelle des attributs indique seulement que pour chaque état spécifique de la base de données, la valeur d'un attribut peut être utilisée pour déterminer sans ambiguïté la valeur d'un autre attribut. Les valeurs spécifiques de la partie dépendante peuvent être différentes selon les états de la base de données.

La relation est en deuxième forme normale(2NF) s'il est sous la première forme normale (1NF) et qu'il n'y a aucun attribut non clé qui dépend d'une partie de la clé composite.

De la définition de 2NF il résulte que si la clé candidate est simple, alors la relation est automatiquement sous la seconde forme normale.

Cependant, les relations réduites à la seconde forme normale contiennent toujours des informations hétérogènes et nécessitent l'écriture de code de programme supplémentaire sous forme de déclencheurs pour le bon fonctionnement de la base de données. La prochaine étape pour améliorer la qualité des relations est de les amener à la troisième forme normale.

La relation est en troisième forme normale(ZNF), s'il est en 2NF et que tous les attributs non clés sont mutuellement indépendants.

Un modèle de données relationnel composé de relations réduites à 3NF est un modèle de domaine adéquat et ne nécessite que les déclencheurs qui maintiennent l'intégrité référentielle. Ces déclencheurs sont standards et nécessitent peu d’efforts pour être développés.

Ainsi, le développement d'un modèle logique d'une base de données relationnelle peut être représenté comme définissant des relations qui reflètent les concepts du domaine et les amenant à la troisième forme normale.

L'algorithme de développement comprend trois étapes.

Étape I. Réduction à 1NF. Ici, il est nécessaire de définir et de définir des relations qui reflètent les concepts du domaine. Toutes les relations sont automatiquement en 1NF.

Étape II. Réduction à 2NF. Si dans certaines relations une dépendance d'attributs sur une partie d'une clé complexe est détectée, alors ils doivent être décomposés comme suit : les attributs qui dépendent d'une partie d'une clé complexe sont placés dans une relation distincte avec cette partie de la clé, et tous les attributs clés restent dans la relation d'origine.

. La clé est une clé complexe.

– dépendance de tous les attributs à l'égard de la clé de relation;

– dépendance de certains attributs à l'égard d'une partie d'une clé complexe.

– la partie restante de la relation originale ;

- nouvelle attitude.

Stade III. Réduction à 3NF. Si dans certaines relations une dépendance de certains attributs non clés par rapport à d'autres attributs non clés est détectée, alors une décomposition de ces relations est effectuée : attributs non clés qui dépendent d'autres attributs non clés,

former une relation distincte. Dans la nouvelle relation, la clé devient le déterminant de la dépendance fonctionnelle.

Soit par exemple la relation initiale –. À- clé.

Alors les dépendances fonctionnelles ont la forme suivante :

Après avoir décomposé la relation, nous obtenons :

En pratique, il est assez rare qu’un modèle logique de base de données soit développé à l’aide de l’algorithme donné. Plus souvent utilisé diverses options Diagrammes ER pris en charge par les outils CASE appropriés. Les concepts de base des diagrammes ER sont définis dans les normes IDEF1 et IDEF1X. Cependant, l’algorithme ci-dessus est utile pour illustrer les problèmes qui peuvent survenir lors de la définition de relations faiblement normalisées dès les premières étapes de la conception. Comprendre ces problèmes est particulièrement important lors de la réalisation de modifications et d'améliorations de la base de données, lorsque de nouvelles entités sont introduites, de nouvelles dépendances apparaissent, etc.

Développement systèmes d'information(IS) consiste à créer des outils de gestion de l’information. Les SI reçoivent des informations, les traitent selon certaines règles et fournissent le résultat aux consommateurs : pour l'impression, sur un écran, dans des écouteurs et pour la transmission à d'autres systèmes.

Par conséquent, pour créer une propriété intellectuelle de haute qualité, il ne suffit pas de comprendre les processus commerciaux et les besoins du client. Il est important de comprendre quelles informations le système doit gérer. Et pour cela, vous devez savoir quels objets relèvent du domaine du SI conçu et quelles connexions logiques existent entre eux. Pour parvenir à une telle compréhension, des modèles logiques du domaine sont utilisés.

Qu’illustre le modèle logique ?

Le but de la construction d'un modèle logique est d'obtenir une représentation graphique de la structure logique du domaine étudié.

Un modèle logique de domaine illustre les entités ainsi que leurs relations les unes avec les autres.

Les entités décrivent les objets qui font l'objet de l'activité du domaine et les sujets qui exercent des activités au sein du domaine. Les propriétés des objets et des sujets du monde réel sont décrites à l'aide d'attributs.

Les relations entre les entités sont illustrées à l'aide de connexions. Les règles et restrictions des relations sont décrites à l'aide des propriétés de relation. Généralement, les relations définissent soit les dépendances entre entités, soit l'influence d'une entité sur une autre.

Exemple : Commander une pizza

Le client passe une commande pour acheter une pizza. En général, un client peut commander différentes quantités de différents types de pizza. Chaque commande comprend donc des articles. Chaque position indique le type de pizza que le client souhaite recevoir, ainsi que sa quantité.

Exigences principales

Exigences de base pour le contenu du modèle

1. Le modèle logique doit afficher toutes les entités et relations significatives aux fins pour lesquelles nous le dessinons.

2. Tous les objets du modèle (entités et relations) doivent être nommés. La dénomination des entités et des relations doit être effectuée en termes de domaine.

3. Pour les connexions, la multiplicité doit être indiquée (un - plusieurs).

4. Le sens de lecture doit être indiqué pour chaque connexion.

Exemple : les noms des connexions, leurs dimensions et sens de lecture ont été ajoutés au modèle.

5. Au minimum, les attributs de base doivent être spécifiés pour les entités.

Exemple : les attributs de base sont spécifiés pour les entités

Exigences de base pour la qualité du modèle :

<Сущность 1> — <отношение / влияние> — <Сущность 2>.

Lecture d'un exemple discuté précédemment : Un client passe une commande. La commande comprend des positions dont chacune indique quel type de pizza et en quelle quantité le client souhaite recevoir.

Le client peut exister sans commande. Toutefois, une commande ne pourra être enregistrée sans l'indication du client. Un client peut passer un nombre illimité de commandes

Selon le modèle, une commande peut comporter un nombre infini d'articles. Il est nécessaire de préciser dans quelle mesure cela est exact.

2. Le modèle doit être structuré, les entités doivent être regroupées selon leur signification logique.

3. Il est fortement conseillé d’éviter de croiser les connexions.

4. La disposition des objets modèles doit être telle qu'elle soit facile à lire.

Il y a une observation : si le modèle est agréable à regarder, il est fort probable qu'il soit de haute qualité.

Nous devons déterminer pourquoi nous avons besoin d’un modèle logique. À quelles questions devrait-il finalement répondre pour nous ? Pourquoi cela affectera-t-il la qualité de l'analyse et comment cela aidera-t-il à résoudre la tâche qui nous est assignée ?

Sans réponses à ces questions, développer un modèle perd tout son sens, puisque nous ferons quelque chose dont nous n'attendons rien particulièrement. Le résultat sera correspondant.

Les réponses à ces questions nous donnent les exigences du modèle et, lors du développement, elles nous permettront de prendre des décisions concernant son développement et de juger de sa qualité.

Il est nécessaire de déterminer les limites de la modélisation : quelle partie du domaine étudié le modèle doit couvrir.

En règle générale, la réponse à cette question découle d'une compréhension de la tâche qui attend l'analyste commercial.

Dans la plupart des cas, les limites de la modélisation sont déterminées soit par les processus métiers étudiés, soit par un fragment de l'espace d'information de l'entreprise qui relève du problème à résoudre.

L'élaboration d'un modèle logique doit commencer au moment où la recherche sur le domaine commence et se terminer lorsque la tâche est terminée. C'est presque le seul artefact développé tout au long de l'analyse du domaine et de la détermination des exigences du système.

L'élaboration d'un modèle logique est un processus itératif. Il doit être constamment affiné et détaillé à mesure que le domaine et la tâche à accomplir se développent.

Lors de l'analyse, les entités et les relations sont identifiées et affichées sur le modèle.

Le modèle logique doit être construit de telle manière que les entités sont appelées noms, les connexions sont appelées verbes, et la lecture du diagramme générerait, quoique maladroite, des phrases décrivant ce qui se passe dans le domaine. Si cela était réalisé, le modèle s'en sortirait à merveille. Si cela échoue, le développeur du modèle a encore du travail à faire.

Au fur et à mesure du développement du modèle, la composition des entités et des relations est clarifiée et les attributs des entités sont déterminés.

Conclusion

Il est important de se rappeler qu'un modèle logique ne concerne pas la structure de la base de données, mais la structure logique du domaine de votre tâche. En l'excluant des attributs en cours de développement, vous vous privez d'un outil d'analyse et de conception efficace qui permet de prendre en compte très précisément des aspects du métier qui ne sont pas illustrés par des modèles dynamiques.

Et vice versa : l'utilisation opportune et compétente d'un modèle logique en fait un outil très puissant entre les mains d'un analyste commercial ou système.

Sergueï Kalinov