Université de Maroua

********
Faculté des sciences
********
Département de Mathématiques et Informatique

UE : Introduction aux bases de données

Code UE : INF121 / IGE121
Enseignant : Urbain NOUTSA TCHUENTE

Année académique 2022 / 2023

1
 Notes Importantes
Pre-requis
- RAS : être disposé à comprendre

Objectifs du cours
Ce cours a pour objectif d’entraîner l’apprenant vers la compréhension de l’importance des
données et de leur gestion dans toute organisation. En particulier, il s’intéresse à l’apprentissage et à
la résolution des problèmes d’organisation et de manipulation des données. Il doit permettre à
l’apprenant de :
- Comprendre ce qu’est une base de données et les concepts y afférents ;
- Se familiariser avec la conception des modèles EA (ou ER) en vue de produire le modèle
relationnel correspondant ;
- Maîtriser la théorie qui soutient les BD relationnels : l’algèbre relationnelle
- S’initier si possible au langage de requête SQL

Programme

I – Introduction et concepts de base

II – Le Modèle Entité/Association
III – Le Modèle Relationnel
IV – L'algèbre relationnelles
V – Le Langage de requête SQL
VI – Normalisation
Ouvrages :

1. Carrez C., Des Structures aux Bases de Données, Masson

2. Gardarin G., Maîtriser les Bases de Données: modèles et langages, Eyrolles
3. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.
4. Melton J. et A.R. Simon, Understanding SQL, A Complete Guide, Morgan Kaufmann, 1993.
5. Ullman J.D. et Widom J., A first Course in database Systemsd, Prentice Hall, 1999
6. Date C.J., An Introduction to Database Systems, Addison-Wesley

2
 Chapitre I . Présentation générale des Bases
de Données

I.1. Pourquoi les Bases de Données ?

De l’inconvénients des fichiers à la nécessité des Bases de Données
A partir du moment où les ordinateurs sont devenus des outils d’aide à la gestion des
entreprises, on s’est immédiatement posé la question de savoir comment les données peuvent être
archivées et extraites des organes périphériques des ordinateurs.
Au début, les données étaient regroupées en enregistrements physiques. Dans la mesure où
ces enregistrements physiques représentaient des objets de même nature qui se répétaient un certain
nombre de fois, on en faisait une collection pour constituer un fichier. Rapidement est apparu le
disque magnétique qui a permis un accès plus rapide aux données. C’est durant cette période que
l’on a vu se développer les principales notions concernant les fichiers d’ordinateurs et leurs
principales méthodes d’organisation et d’accès : séquentielle, sélective ou direct, séquentielle
indexée.
Bien que ces méthodes aient reçues de nombreux raffinements, elles sont aujourd’hui
toujours valables et sont largement utilisées dans la plupart des applications de gestion automatisée.
Mais ces fichiers qui ont été construits pour répondre aux besoins des applications
informatiques possèdent la plupart du temps des éléments communs, des associations qui ne sont
pas exploitées du fait qu’elles sont utilisées isolement et indépendamment les uns des autres.
En outre, il est fréquent que des données identiques soient répétées dans des fichiers
distincts (par exemple : la désignation d’un produit apparaît dans le fichier PRODUIT utilisé pour la
facturation, dans le fichier STOCK, dans le fichier CATALOGUE, …). Cette redondance des
données coûte de la place sur les supports, complique les mises à jour et multiplie les risques
d’erreurs.
Parallèlement aux limitations concernant l’utilisation des fichiers, d’une part les progrès
technologiques permettant de stocker des masses de données de plus en plus importantes, et d’autre
part les besoins des entreprises nécessitant dans leur organisation une connaissance de plus en plus
fine de leurs activités (financières, commerciales, techniques et de production) sont à l’origine du
concept des bases de données.
Les Bases de Données jouent un rôle central dans les systèmes informatiques :
- Systèmes d’information traditionnel : gouvernement (les fonctionnaires, …), banques
(clients, …), assurances (clients, biens assurés, incidents, …), commerce (articles,
fournisseurs, …), …
- Autres domaines : systèmes téléphoniques, systèmes multimédia (images, son vidéo, …),
internet (messagerie, commerce électronique, …)

I.2. Définition des Bases de Données

Une donnée est une information pertinente pour un utilisateur (du système).
Une Base de Données (BD ou DB : DataBase) est une collection de données structurée de
manière à être exploitée pour le bon fonctionnement d’une entreprise.
On entend par entreprise ici toute collectivité d’individus travaillant en coordination à la
réalisation d’un objectif commun.
Exemple de bases de données :
- Base de Données de gestion du personnel, étudiants, cours, inscription dans une
université
3
 - Base de Données de réservation des vols dans une compagnie aérienne
- Base de Données de gestion des comptes bancaires des clients d’une banque
Remarque : Une BD est développée au sein d’une entreprise, pour son propre fonctionnement.
Inversement, une Banque de Données est un ensemble de données propres à un domaine
d’application, que les « producteurs » réunissent pour ensuite ventiler (généralement
commercialiser) l’usage vers le public extérieur.
Exemple : Banque de Données juridique, médicale, économique, …
La construction et l’exploitation des banques de données font appel à des techniques
spécifiques au domaine.
Bien que la manipulation des données devient de plus en plus facilitée par l’ordinateur, une
base de données peut bien être manuelle (les systèmes d’informations précèdent les ordinateurs).
Exemple : Registre des naissances d’une mairie
L’automatisation des Bases de Données repose sur les SGBD (Systèmes de Gestion de Bases
de Données). Un SGBD est un ensemble de programmes permettant de créer et de manipuler les
Bases de Données.
Exemple de SGBD : Accès, MySQL, Oracle, Informix, PostgréSQL, SQL Server, …

I.3. Caractéristiques et types de BD

Une BD doit satisfaire aux critères suivants :
- Bonne représentation du monde réel : image fidèle de la réalité, données fiables à jour,
utilisateur non informaticien, …
- Non redondance des données : Une même donnée ne sera pas répétée plusieurs fois dans la
BD (elle doit être située physiquement à une seule place) => gain en espace de stockage
- Indépendance des programmes et données : les données qui sont stockées dans la BD doivent
être indépendantes des programmes qui les traite. On doit pouvoir utiliser un autre programme
pour traiter différemment des données sans avoir à toucher à ces données. En effet, les
programmes sont construits pour manipuler les données (après la structuration de celles-ci)
- Cohérence des données : Il ne doit pas être permis d’enregistrer dans une BD des données
incohérentes entre elles. Une BD étant utilisée par plusieurs personnes, les données doivent
être les mêmes pour tous les utilisateurs. Une modification d’une donnée doit être répercutée
immédiatement. => mise à jour unique
- Partage de l’information : les données de la base sont disponibles pour les différents
utilisateurs potentiels. L’ensemble des informations peut ainsi être partagé sans que personne
n’en conserve l’exclusivité. => accès simultané
- Sécurité et confidentialité des données : une donnée est une ressource pour l’entreprise, et
cette ressource doit être protégée. La BD permet d’améliorer la sécurité des données stockées
(gestion des droits d’accès aux données).
Avant l’apparition des BD, chaque service dans une entreprise disposait de ses fichiers
personnalisés. Les dangers de cet état de chose étaient les suivants :
 Données redondantes : une même donnée pouvait apparaître dans plusieurs fichiers,
éventuellement codées sous des formes différentes ;
 Une mise à jour d’une de ces données par un service entraîne une incohérence entre les
fichiers contenant cette donnée ;
 La mise à jour d’une application fait la bête noire des informaticiens. Un traitement
pouvait nécessiter d’utiliser plusieurs fichiers des services différents. Problèmes de
format des fichiers, d’incohérence des données, …
Les données d’une BD doivent pouvoir être utilisées par des programmes et des utilisateurs
différents. Ainsi, la notion de base de données est généralement couplée à celle de réseau afin de
pouvoir accéder en réseau ou non aux données stockées. On peut alors distinguer les bases de
données locales des BDs reparties :

4
  Les BDs locales : elles sont utilisables sur une machine par un utilisateur. Ce dernier
est en même temps utilisateur, développeur et administrateur.

Schéma d’une BD locale

 Les BDs distantes : Ici, les données sont stockées sur des machines distantes et
accessibles par réseau. Les données sont fournies par plusieurs utilisateurs (parfois
des milliers) à travers de multiples transactions. L’avantage majeur est la possibilité
de pouvoir être accédée simultanément par plusieurs utilisateurs. La BD hébergée sur
le serveur est accessible via une architecture client/serveur. Les clients d’horizon
divers envoient leurs requêtes au serveur qui les traitent et leur restitue les résultats.
Serveur
requête
Client
BD
réponse
Les BDs peuvent aussi être différenciées par la nature des informations stockées (BD textuelles,
cartographiques, multimédia, …), le volume des informations (BD individuelle, entrepôt de
données), …

I.4. Architecture SGBD

Une BD regroupe un grand nombre de données élémentaires souvent structurées de manière
complexe. Pour gérer et exploiter ces données, il est nécessaire de disposer d’un Système de
Gestion de Bases de Données (SGBD ou en anglais DBMS : Database Management System). Le
SGBD est un ensemble de programmes permettant de gérer les BD de façon à garantir la cohérence
et la persistance des données. Il a pour rôle de fournir un environnement riche, efficace et simple
pour gérer (décrire la structure, stocker, retrouver, modifier, supprimer, …) les données en assurant
leurs propriétés structurales ainsi que les contraintes de sécurité et de confidentialité. Le SGBD sert
donc d’interface entre les programmes d’application des utilisateurs et la BD.

SGBD
BD
User

L’un des objectifs des SGBD est de présenter à l’utilisateur les données sous forme abstraite.
Le système masque certains aspects concernant le stockage et le traitement des données. L’exigence
d’efficacité conduit à structurer les SGBD en 3 couches (ou niveaux) successives de fonctions :
Vue 1 SGBD

Niveau Niveau
Vue 2
conceptuel physique

Vue 3

1. Le niveau physique : il décrit comment les données sont organisées et stockées ainsi que
leurs modes d’accès possibles sur les supports physiques.
2. Le niveau conceptuel : c’est une représentation abstraite du monde réel indépendante du
support de stockage. Il décrit les données de l’organisation en conservant le plus possible les

5
 liens entre elles. Par exemple, Le fait qu’un employé travaille obligatoirement dans une ou
plusieurs usines doit être représenté le plus fidèlement possible par un modèle conceptuel
(MCD par exemple et utilisé le modèle logique MLD pour évoluer vers le niveau physique).
3. Le niveau externe ou vue (SGBD externe) : ce niveau correspond à la vision de tout ou
partie de la BD. Il fournit les fonctions de présentation des données aux programmes et aux
utilisateurs.
Les différents niveaux de description du SGBD sont formalisés par des langages propres à
chaque SGBD. L’architecture à trois niveaux des SGBD permet d’avoir une autonomie ou
indépendance des données stockées dans la base. On distingue deux niveaux d’indépendance :
 Indépendance physique : la possibilité de modifier le niveau physique sans modifier
le niveau conceptuel. De telles modifications sont parfois nécessaires pour améliorer
les performances du SGBD.
 Indépendance logique : la possibilité de modifier le niveau conceptuel sans modifier
les vues. Ces modifications sont nécessaires lorsque la structure logique de la base
doit évoluer et cette évolution ne doit pas gêner les utilisateurs.
En résumé
Monde réel Vues externes Modèle Modèle logique machine
conceptuel
Niveau externe Niveau logique Niveau physique

Dans le cadre de ce cours, nous allons étudier le niveau logique.

I.5. Historique et modèles de BD

Le milieu des années 60 a vu la naissance de la première génération des SGBD. Un modèle
de BD définit la manière d’organiser (structurer) les données de la base. Les modèles de BD
suscitent l’implémentation des SGBD appropriés. On distingue 4 principaux modèles dans l’ordre
chronologique :
1. Le modèle hiérarchique (1965): Les données sont organisées hiérarchiquement selon une
arborescence. Chaque nœud de l’arbre correspond à une classe d’entité du monde réel et les
chemins entre les nœuds représentent les liens entre les objets. Le système IMS (Information
Management System) d’IBM est fondé sur ce modèle. De nombreuses situations peuvent être
modélisées, mais la structure arborescente du graphe devient limitative lorsque l’on veut
modéliser le partage de certaines données.

2. Le modèle réseau (1965): ce modèle est une extension du modèle hiérarchique dans laquelle
le graphe d’objets n’est pas limité. Il permet de représenter le partage des objets ainsi que les
liens cycliques entre les objets. Exemple : IDS (Integrated Data Store) de General Electric.

3. Le modèle relationnel (1970) : les données sont organisées en tableaux de deux dimensions
(lignes et colonnes). Ce modèle est basé sur le concept central de relation qui est
rigoureusement défini sur le plan mathématique. Les premiers SGBDR sont commercialisés
au début des années 80. ce modèle a connu une très grande popularité grâce à la simplicité
des concepts manipulés et à la facilité d’interrogation à l’aide des langages appropriés.
Exemple : Access, MySQL, SQL Server, oracle, Informix

6
 4. Le modèle Objet (1985) : les données sont stockées sous forme d’objets. Les premiers
SGBDOO apparaissent vers 1990. L’implémentation de ce modèle consistait à étendre les
langages de programmation OO (ex. Smalltalk) aux fonctionnalités des SGBD. Exemples :
Gemstone de GemStone System, ObjectStore, O2, Versant de Versant Corporation.

Remarque : De nos jours les BD relationnelles sont les plus répandues (environ trois quarts des
BD). Dans le cadre de ce cours, c’est le modèle relationnel qui sera étudié.

7
 Chapitre II . Le modèle entité-association

II.1. Modélisation des données

Avant de s'attaquer à tout problème, il est toujours nécessaire de réfléchir profondément aux
tenants et aboutissants de ce que l'on veut réaliser. La conception de bases de données ne fait pas
exception à la règle. Les théoriciens de l'information ont donc proposé des méthodes permettant de
structurer sa pensée et présenter de manière abstraite le travail que l'on souhaite réaliser.
La qualité de l'information et sa disponibilité sont des facteurs de compétitivité pour l'entreprise.
Le système d’information (SI) d’une entreprise est l’ensemble des informations qui y circulent ainsi
que l’ensemble des moyens (procédures et ressources) mis en œuvre pour les gérer. L’objectif d’un
système d’information est de restituer l’information à la personne concernée, sous la forme
appropriée et en temps opportun pour prendre une décision ou effectuer un travail.
Le système d’information de l’entreprise reçoit de son environnement des informations qu’il doit
traiter. Ce sont par exemple des commandes de clients qui doivent être traitées jusqu’à leur
aboutissement, ou l’arrivée des factures des fournisseurs. Le SI reçoit et traite aussi des
informations internes à l’organisation, comme par exemple les documents comptables, ou les
chiffres de production.
On peut distinguer 4 fonctions principales du système d’information :
1- Recueillir l’information
2- Mémoriser l’information
3- Exploiter l’information (traitement)
a. Consulter
b. Organiser
c. Mettre à jour
d. Produire de nouvelles informations par des calculs
4- Diffuser l’information
Le système d’information doit intégrer une base d’information dans laquelle seront mémorisés
les informations mémorisées. Cette base étant sujette à des évolutions, le système d’information
doit être doté d’un mécanisme (appelé processeur d’information) destiné à piloter et à contrôler ces
changements. Le schéma suivant synthétise l’architecture d’un système d’information.

Base d’information

Faits et événements
Processeur d’information
Etats de la base
d’information

Pour nous, il est ici question de faire un bref aperçu de la modélisation les données d’un SI.
Pour cela, nous utilisons le modèle entité-association.
0
 Le modèle EA est un modèle qui permet d’exprimer la sémantique des données
mémorisables et/ou véhiculables à l’aide des concepts d’entité, de propriété ou attribut, de relation
ou association, et du mécanisme des contraintes d’intégrité.

II.2. Concepts de base

II.2.1 Entité et attribut (ou propriété)

L’entité représente l’objet de base du modèle EA ; elle est le reflet d’un objet d’intérêt pour
l’organisme et a une existence propre, elle est identifiable et ne doit représenter qu’un seul et même
concept sémantique. Une entité peut être un objet ayant une existence physique (par exemple un
employé, une voiture ou une maison) ou un objet ayant une existence conceptuelle (par exemple un
service ou un projet).
Exemple : Le service commercial d’une entreprise gère les commandes reçues des clients
comportant des produits à livrer. Les mots soulignés sont les entités de l’application « gestion
commerciale ».
Chaque entité possède des propriétés ou attributs qui le décrivent. Un attribut est une
donnée élémentaire conforme au choix de l’entreprise. Par exemple, une entité employé peut être
décrite par un nom, une date de naissance, un sexe, une adresse, un salaire et un poste qu’il occupe.
Chaque attribut peut prendre un certain nombre de valeurs.
Exemple : ( ???)
Un attribut peut être :
- Composite ou élémentaire : Un attribut composite est un attribut qui peut être divisé en
sous-parties représentant des attributs plus élémentaires ayant des significations
indépendantes. Par exemple, l’attribut Adresse de l’entité employé peut être subdivisé en
AdresseRue, Ville, Département et CodePostal avec comme valeurs « 195 »,
« Ngaoundéré », « Vina », « 1278 ». Les attributs qui ne sont pas divisibles sont appelés
attributs élémentaires.
- stockés ou dérivés (calculés) : On appelle attribut dérivé un attribut dont la valeur peut
être obtenue à partir d’autres valeurs d’attributs. Par exemple, l’attribut Age est un
attribut dérivé car on peut obtenir sa valeur en utilisant la date courante et la valeur de
l’attribut DateNaissance. On appelle attribut stocké un attribut dont on ne peut calculer
à partir d’autres valeurs d’attributs. Sexe, Nom et DateNaissance sont des exemples
d’attributs stockés. Certaines valeurs d’attributs peuvent être dérivées d’attributs
d’entités associées : par exemple, la valeur de l’attribut NombreEmployés d’une entité
service peut s’obtenir en comptant le nombre d’employés travaillant pour le service en
question.
- signalétique, de situation ou de mouvement : Une information signalétique est celle qui
est stable, permanente, qui ne peut être modifiée quelque soit les circonstances. Exemple :
âge (date de naissance), sexe. On les appelle aussi des attributs monovalués car ne peuvent
prendre qu’une valeur unique. Une information de situation est celle qui peut varier au
cours du temps (attributs multivalués). Exemple : quantité en stock. Une information de
mouvement est celle qui n’existe que parce qu’un évènement a eu lieu. Exemple : liste des
étudiants qui ont validé une UV.
- Obligatoire ou facultatif : doit absolument avoir une valeur ou peut e pas avoir de valeur.
Avant d’ajouter une nouvelle donnée, il convient de se poser les questions suivantes (les
règles d’identification des attributs) :
- s’agit-il d’une donnée déjà répertoriée ? (éviter la redondance)
- cette donnée n’est-elle pas déjà répertoriée sous un nom différent ? (éviter synonyme)
1
 - le nom à attribuer à cette donnée n’est-il pas déjà employé pour une autre donnée ?
(éviter les polysèmes)
L’ensemble de toutes les propriétés du SI constitue le dictionnaire de données (DD). C’est
l’inventaire exhaustif des données du domaine étudié.
Le formalisme de représentation d’une entité est le suivant :

Nom_Entité
Attribut1
Attribut2
…
AttributN

II.2.2 Occurrence d’entité de identifiant

Une occurrence d’entité est un objet particulier de la classe des objets définis par l’entité
considérée. Une occurrence d’entité doit être composée d’une et d’une seule occurrence de chacune
des propriétés rattachées à l’entité.
Chaque entité doit avoir une propriété (ou un ensemble de propriétés) particulière appelée
identifiant dont la valeur permet d’identifier de façon unique chaque occurrence de l’entité.
L’identifiant doit apparaître souligné dans l’entité.
Exemple : Considérons la manipulation des étudiants. Le matricule d’un étudiant est une propriété
qui permet d’identifier de façon unique un étudiant. Deux étudiants ne peuvent pas avoir le même
matricule.
Etudiant
Matricule
nom
prenom
Les occurrences de l’entité Etudiant peuvent alors être :
matricule nom prenom
4513 Owona Blaise
8731 Takam Oscar
3242 Aïsha Mahamat

II.2.3 Relation (ou association) et occurrence

Une relation permet de conceptualiser, de modéliser les liens sémantiques pouvant exister
entre des occurrences d’entités qui ont un intérêt pour le domaine d’étude. Une relation se définit
entre une ou plusieurs entités. Le degré d’une relation est le nombre d’entités qui interviennent dans
cette relation.
- relation réflexive : relie une entité à elle-même.
- relation binaire : relie deux entités
- relation ternaire : relie trois entités
- relation n-aire : relie n entités.
On peut associer des propriétés à une relation. Ces propriétés doivent caractériser la relation
et non un sous-ensemble des entités qui participent à la relation.
Une relation est représentée par :
ENTITE A ENTITE B
RELATION
Propriétés [Propriétés] Propriétés 2
Exemple : Représenter une relation de mariage entre une personne et une autre personne.

PERSONNE
0,n
Données personne epouser

0,1

Remarque : Plusieurs associations peuvent être définies sur les mêmes entités.
Exercice : Représenter la relation entre une voiture et une personne qui la conduit. Entre une
voiture et le propriétaire.
Une occurrence d’association est un lien particulier qui relie les occurrences des entités en
relation. Une occurrence de relation est constituée d’une et une seule occurrence d’entités qui
participent à la relation et de une et une seule occurrence de chaque propriété portée par la relation.
Exemple : Sur les entités PERSONNE et VOITURE on peut définir les associations propriétaire,
conducteur.
Si P = {p1, p2, p3} et V = {v1, v2, v3}
Propriétaire : R1 (P, V) = {(p1,v1),(p3,v2),(p3,v3)}
Conducteur : R2 (P, V) = {(p1,v1),(p2,v2),(p3,v3)}

II.2.4 Les cardinalités

Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à
laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une borne
maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut prendre sa
valeur:
- la borne minimale (généralement 0 ou 1) indique le nombre minimal de fois que chaque
occurrence de l’entité doit participer à des occurrences de relation
- la borne maximale (généralement 1 ou n) indique le nombre maximal de fois que chaque
occurrence d’entité peut participer à des occurrences de relation.
Les différentes cardinalités qu’on peut rencontrer sont :
 (0,1) : au plus une fois
 (1,1) : exactement une fois
 (0,n) : 0 ou plusieurs fois
 (1,n) : au moins une fois
En général, on peut avoir (n,m) : au moins n fois et au plus m fois.
Remarque : Les cardinalités dépendent des REGLES de GESTION propre à l’organisation étudiée.
Exemple : Considérons la commande des produits par les clients. On sait qu’un client commande
des produits. Il doit donc exister une relation « commander » entre CLIENT et PRODUIT.
Pour la cardinalité minimale entre CLIENT et « commander », il faut se poser la question :
Pour un client donné, combien de fois au minimum il commande ?
Si la réponse est «tout client doit passer au moins une commande sinon ce n’est pas un client» on
met la cardinalité minimale à 1.

3
 Mais on peut très bien imaginer que l’entreprise veut aussi mémoriser les clients potentiels
(prospects), qui n’ont encore rien commandé. Dans ce cas, un client peut très bien ne pas avoir
encore commandé, et on met la cardinalité minimale à 0.

Questions :
1. Donner les questions qui permettent de trouver les cardinalités minimales et maximales de
l’association « commander ».
2. Faites deux hypothèses de règle de gestion concernant ce lien et trouver les cardinalités
minimales et maximales correspondantes.
3. Donner les règles de gestion et les cardinalités appropriées de la relation « EtreEffecter »
entre EMPLOYE et SERVICE.
4. En considérant les relations ci-dessous, donner les règles de gestion qui ont permis
d’identifier les cardinalités.

II.3. Règles de construction du modèle EA

La construction du modèle EA consiste à identifier, à partir d’une description exprimée en
langage naturel (Français ou Anglais), les entités et les associations. Cela passe par l’identification
des attributs des entités, des associations et des attributs des associations.
Il est conseillé pour la construction du modèle EA de procéder par la démarche suivante :
1. Analyser l’existant et constituer le dictionnaire de données. Dresser la liste des entités
primaires qui se dégagent.
2. Procéder à l’épuration des polysèmes, des synonymes et des redondances.
3. Repérer ou définir les identifiants des différentes entités.
4. Déterminer les relations entre les entités et leur rattacher leurs éventuelles propriétés
5. Déterminer les cardinalités de chaque couple entité-relation en s’appuyant sur les règles de
gestion
6. Construire le modèle ER de base et décomposer si possible les associations n-aires
7. Procéder à la vérification et normalisation du modèle de base.
L’application systématique des règles de vérification sur les éléments du modèle EA permet de
s’assurer qu’il est conforme à ce que l’on attend, et donc apte à évoluer vers une base de données
correspondant à la réalité ; l’objectif étant que la base de données résultante soit normalisée.
Règle 1 : Il ne doit pas exister de synonymes, de polysèmes ou de redondances et chaque propriété
4
doit être portée par une et une seule entité ou relation
Règle 2 : Chaque occurrence d’entité ou relation doit avoir une et une seule occurrence de chaque
propriété portée (pas de propriété répétitive)
Règle 3 : Pour chaque occurrence d’une relation, il doit exister une et une seule occurrence de
chaque entité qui participe à la relation.
Règle 4 : Chaque entité doit avoir un identifiant
Règle 5 : Des propriétés portées par une relation doivent caractériser la relation
et non un sous-ensemble des entités qui participent à cette relation.